This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

uIP historical problem, uip_arp_ipin()

Not easy to find discussions about uIP. It seems that, developers who use uIP, have very good skills and encounter no problem.

If you are interested in why uip_arp_ipin() has been defined nothing.

#define uip_arp_ipin()


Here is the reason:

sourceforge.net/.../1080163152.654.76.camel@strumpa.sics.se/

------------------------------
Spiro R. Trikaliotis, 2004-03-22 14:04:51

The bug is that the ARP cache should not be updated but on ARP requests
and ARP replies. Period. ;-)
------------------------------

------------------------------
Adam Dunkels, 2004-03-22 13:04:09

The code probably could be fixed, but it
would break people's drivers. I'm not sure which is best, though.
Perhaps it would be best to simply go ahead and change the behavior so
that a driver must be prepared to send data from anywhere, by simply
handing it *two* pointers from where to fetch data. (One "header"
pointer and one "payload" pointer.)

Unfortunately this won't directly solve the "ARP overwriting the
outgoing packet problem". To solve that problem, the ARP code would have
to queue the outgoing packet and send it out when the ARP reply is
received. This would either require an extra packet buffer in the ARP
module to which the outbound packet could be copied, or some way to
dynamically allocate and keep track of the copy of the outbound packet.

Both ways increases the complexity and size of the system, which already
is a little too big to fit the web browser...

------------------------------