[lwip-users] AutoIP/link-local status?

[Alex Broadhead]

Howdy,

I'm running lwIP on an embedded Blackfin (BF536) using ADI's port,
drivers, and VDK OS.

I've got things running OK with either DHCP or static addressing, but am
working on a request to add link local addressing.  The latest update to
the ADI tools has lwIP 1.3, and so seems to support link local via the
'autoip.[ch]' files.  Following the instructions in the header comments
in autoip.c, I recompiled their lwIP project after adding:

        /* ---------- AUTOIP options ---------- */
        #define LWIP_AUTOIP             1
        #define LWIP_DHCP_AUTOIP_COOP   1

to my 'lwipopts.h' file.  There is one more instruction in that file
(assuming TCP/IP and DHCP, both of which I'm using):  "Configure your
DHCP Client."  I have no idea what this entails, and cannot find any
further clarification in dhcp.[ch] - can anyone point me in the right
direction?

Anyway, recompiling my project with the new library, disconnecting my
switch from the local network (and thus DHCP), and running, I do
(eventually) get an address, presumably from autoip.  It takes two
minutes (every time), and it's always 169.254.23.0 (the .0 at the end
seems strange, but is apparently legal?).  So far, so good-ish.

Now, though, the problems begin.  There are two methods my PC GUI uses
to connect to the Blackfin:  UDP broadcast bootstrap, or specified
address list.  When I try the first mode, I am able to recvfrom() the
UDP packets from the PC, but echoing the packet back via sendto() fails
every time with the error 'EHOSTUNREACH', indicating no route to the
host.  I've never seen such an error before (using DHCP or static
addressing).  Entering 169.254.23.0 into the list of specified addresses
and trying to connect directly using TCP/IP, accept() never unblocks,
which would seem to indicate that no packets are making it to the
Blackfin.  Again, this method works flawlessly when not using an autoip
supplied address.

Do any of these issues sound familiar to anyone?  I acknowledge that the
issue may lie with ADI's port or configuration, but it seems like this
should be a pretty straightforward service to add, and don't see how
effectively spoofing a DHCP server could cause such significant issues.

Thanks,
Alex