On Sun 12 Jul 2009 09:14, Michael Zaidman pondered: > > On Fri, Jul 10, 2009 at 10:18 PM, Robin Getz <rg...@blackfin.uclinux.org> wrote: > > > On Fri 10 Jul 2009 12:27, Robin Getz pondered: > > > http://git.denx.de/?p=u-boot/u-boot-net.git;a=commitdiff;h=3c172c4fdbbb5858fae38478d6399be4a16be3fc > > > > causes a regression on my network's DHCP server. > > The part of the diff that causes the problem: > > > > #if defined(CONFIG_CMD_DHCP) > > > > case DHCP: > > - /* Start with a clean slate... */ > > BootpTry = 0; > > - NetOurIP = 0; > > - NetServerIP = getenv_IPaddr ("serverip"); > > DhcpRequest(); /* Basically same as BOOTP */ > > break; > > > > Since we are leaving the "NetOurIP" to whatever it was... The test at: > > NetReceive(): > > > > case PROT_IP: > > [snip] > > tmp = NetReadIP(&ip->ip_dst); > > if (NetOurIP && tmp != NetOurIP && tmp != 0xFFFFFFFF) { > > return; > > } > > > > Will return - (we leave the 'NetOurIP' set to the old value, the offered > > address (what is in tmp) is not our's and tmp is not 0xFFFFFFFF). > > > > You never process the DHCP_OFFER... > > > > Did you try to remove the CONFIG_IPADDR from the board's config file? > In this case the NetOurIP will get 0. That should solve the problem.
No it does not - the problem occurs if you do dhcp, save, and then move to a different subnet, and a dhcp again (which is when I found it - recently moved offices, and needed new IP addresses for all my development systems) As Wolfgang stated: the initial state (what CONFIG_IPADDR controls) doesn't change the issue that the bug exists - it just controls when the bug appears - sooner or later - but it is still there.... Rather than call BootpCheckPkt() as I suggested - Ben could just check the value of packetHandler... (if it is DhcpHandler, don't return)... -Robin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
