From mboxrd@z Thu Jan 1 00:00:00 1970 From: gvb.uboot Date: Sun, 06 Jan 2008 19:09:10 -0500 Subject: [U-Boot-Users] Duplicate IP address check In-Reply-To: <4781486B.7030305@gmail.com> References: <47805BD6.9070109@gmail.com> <4780C0EA.8040701@gmail.com> <4781486B.7030305@gmail.com> Message-ID: <47816DA6.8070308@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Ben Warren wrote: > gvb.uboot wrote: >> Ben Warren wrote: >>> Hi Dan, >>> >>> Dan Batryn wrote: >>>> Due to a mis-configuration of our DHCP server there was an >>>> overlapping range of DHCP assigned IP address and units configured >>>> to have IP addresses statically assigned. I was surprised to find >>>> that UBOOT did not complain of a duplicate IP address while trying >>>> to boot via the network. Looking through the source I cannot see >>>> any code to perform the typical ARP for yourself check that I have >>>> seen before. Could someone please tell me if I have overlooked >>>> something or is this feature missing? >>>> >>> There is no explicit check for duplicate IP assignment. U-boot's >>> networking code is intentionally minimalist and thus lacks many such >>> features. Feel free to provide a patch and a convincing argument of >>> why it's needed. >>> >>> regards, >>> Ben >> >> Ditto on the patch. >> >> WRT the convincing argument, I think the bar would be *really* low on >> this one. :-) I would consider a convincing argument to be "The nearly >> universal convention of performing an ARP to verify that the >> DHCP-assigned IP address is unused is missing." > Sure, this is a no-brainer. But, it shouldn't be limited to DHCP since > having a dynamic address trouncing a static one is only one trouble > scenario. Who knows, there may be people out there who object to the > extra milliseconds that this ARP will add to boot time (not me). > > regards, > Ben Ahh, so right. It is actually a worse risk for human-assigned addresses. s/DHCP-// It would be simple enough to have a configurable ARP response wait timeout and use a special value (say <= 0) to disable the ARP test. gvb