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

[Leon Woestenberg]

Hello Alexander, Adam,

> On Friday 15 February 2002 15.20, Adam wrote:
> > How should I send any other datagram? The application does not know
wheter
> > the successful return code comes from a succeeded ARP query or UDP
> > datagram. I hope anybody can help me solve this problem.
>
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).

> 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).

The only thing that would disturb this solution, are concurrent ARP requests
initiated by lwIP (possible, if you open to multiple hosts on the local
network which
are not yet ARP-cached), or unexpected ARP replies (very unlikely).

To improve on this, the "remembered" packet queue can be made bigger, and,
the
number of incoming ARP replies before the packets are dumped can be
increased.
This is, however, not in the spirit of "a" small embedded stack, but grows
towards
big transmit queues. Also, I think the driver needs a notation of (real)
time in order
to dump outstanding items in the queue.

I will implement the first, simple tactique in my driver (as #define-able
behaviour)
somewhere next week, because initiating a TPC connection is on my list as
well.

Regards,

Leon Woestenberg.

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