lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Re: [lwip] ARP request ...and then?


From: Adam Dunkels
Subject: [lwip-users] Re: [lwip] ARP request ...and then?
Date: Thu, 09 Jan 2003 01:13:05 -0000

Hi Leon!

On Saturday 16 February 2002 09.40, you wrote:
> Very true. This gives a startup problem when the lwIP side is the initial
> party to open an outgoing connection to a yet unknown ARP address (this can
> be the gateway also).

With TCP, this introduces a three second delay until the initial SYN is 
retransmitted but doesn't break anything. Still, it is anoying.

> > The ARP code is pretty stupid - it just sends out an ARP request and
> > hopes to
> > get a reply sometime. In the meantime, it would just keep sending ARP
> > requests, and wouldn't even notice if it didn't get an ARP reply.
>
> I've been thinking about "solving" this at least for 1 outgoing packet as
> follows in
> the (cs8900a) network driver:
>
> - use a "struct pbuf *unresolved = NULL;" as a remember pointer.
> - when an ARP request has to be performed for an outgoing packet, remember
> the packet.
> - when an ARP reply comes in, check if it comes from the intended
> destination for a
> remembered packet. If so, send the packet, otherwise dump it (as happens
> now).
>
> I think this would work in most cases (depending on your network traffic
> characteristics).

I think your idea is a good one; a simple approach well suited for a limited 
system. Another variant would be to add a state field and a packet queue for 
each ARP entry. When an ARP query is sent, the state field is set to 
"QUERYING" and the packet is queued. When a response is received, the state 
is changed to "STABLE" (or whatever) and the packet is sent. If a table entry 
has been in QUERYING for too long, the packet is dropped and the state is set 
to "UNREACHABLE", meaning that the host isn't on the local network. After a 
while in UNREACHABLE, the table entry is discarded. (I believe the BSD 
implementation behaves something like this.)

One problem with packet queues and TCP in lwIP 0.5.1 is that TCP will reset 
the pointers and length fields in the pbuf (to prepare for a retransmission). 
This will mess up the packet that is queued. I have begun making a few 
changes to TCP so that it won't have to restore the pbuf pointers in that 
way. But still, there may be problems with race conditions if ARP and TCP run 
in different threads.

/adam
-- 
Adam Dunkels <address@hidden>
http://www.sics.se/~adam

[This message was sent through the lwip discussion list.]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]