[dhcwg] DHCP : transaction ID issue.
"Paradiso, Francesco" <Francesco_Paradiso@alliedtelesyn.com> Mon, 12 July 2004 12:32 UTC
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03493; Mon, 12 Jul 2004 08:32:47 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bjzmz-0008PV-TO; Mon, 12 Jul 2004 08:20:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BjzcZ-00073X-KP for dhcwg@megatron.ietf.org; Mon, 12 Jul 2004 08:09:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02009 for <dhcwg@ietf.org>; Mon, 12 Jul 2004 08:09:22 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BjzcZ-0002W0-7b for dhcwg@ietf.org; Mon, 12 Jul 2004 08:09:23 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bjzbl-0002Kl-00 for dhcwg@ietf.org; Mon, 12 Jul 2004 08:08:34 -0400
Received: from maileu.alliedtelesyn.com ([81.116.95.49] helo=alliedtelesyn.com) by ietf-mx with esmtp (Exim 4.12) id 1Bjzav-0001vr-00 for dhcwg@ietf.org; Mon, 12 Jul 2004 08:07:41 -0400
Received: from svr-mila-e2k1.eu.alliedtelesyn.com ([10.17.39.17] RDNS failed) by alliedtelesyn.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 12 Jul 2004 14:01:38 +0200
Received: from svr-mila-fs3.eu.alliedtelesyn.com ([10.17.90.11]) by svr-mila-e2k1.eu.alliedtelesyn.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 12 Jul 2004 14:06:53 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 12 Jul 2004 14:06:53 +0200
Message-ID: <BDF585B7763FB84CADEE238EC6FF4898096A57@svr-mila-fs3.eu.alliedtelesyn.com>
Thread-Topic: DHCP : transaction ID issue.
Thread-Index: AcRoCLhq3fhmLzqrQr+LwvcTTIZQLw==
From: "Paradiso, Francesco" <Francesco_Paradiso@alliedtelesyn.com>
To: dhcwg@ietf.org
X-OriginalArrivalTime: 12 Jul 2004 12:06:53.0787 (UTC) FILETIME=[B88382B0:01C46808]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60
Subject: [dhcwg] DHCP : transaction ID issue.
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2085942161=="
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Hello, When a client receive a OFFER ACK message it must check the transaction ID. Why the field chaddr must not be validate? I have a case in which two different clients generate the same transaction ID. OK I am very unluky but this has happen. Both the clients accepts the OFFERs and the ACKs sent in broadcast and get the same IP address. If the clients would check the chaddr before accepting a message this would not be occured. There are some unknow (to me) side effects created by a clients that execs this check of the chaddr field? Thanks in advance. Best Regards. Francesco Francesco Paradiso > ------------------------------------ Integration Test Engineer Allied Telesis Multimedia S.r.l. P.zza Tirana 24/4B - 20147 Milano MI - Italy Office +39 02 414112908 Fax +39 02 41411260
_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] DHCP : transaction ID issue. Paradiso, Francesco