Re: [lwip-users] RFC: ARP Queueing

[Paul]

Hi Leon,

I think that you are overestimating my understanding of ARP_QUEUEING.
I have been coding up a TFTP solution and wanted to have my system
download a system image from the dhcp server. I came across the
problem that the first udp packet would not be sent because there was no
ethernet mac address for it so I thought ah ha ARP_QUEUEING but that didnt
work until I made my suggested change.

BTW I am using the RAW API interface or at least my understanding of
raw api from lwip 0.5 documentation a new raw interface (raw the next 
generation?)
seems to have arisen in lwip 0.7. Are there any plans to document or 
rename the

udp_new()
udp_bind()
udp_connect()
udp_disconnect()
udp_recv()

interface (and the tcp equiv) API?

Can you put the UDP_FLAGS_CONNECTED patch
( I cant find a reference to it at the moment but it went along the 
lines of
(pcb->flags & UDP_FLAGS_CONNECTED ? (remote_port == src):1) )
in udp_input into the stable lwip. This allows a udp port to receive a 
connection
from any remote port until it has been connected to a fixed port.

tftp file retrieve sequence
1) send a udp packet to port 69 of an server from any local udp port X
2) recieve a udp packet from the server and unknown src port Y to the 
port X we sent from in step 1
(this is where the UDP_FLAGS_CONNECTED patch is needed as the tftp 
server can choose any value for Y)
3) make the connection to the server and port (only our set up 
connection will receive data now)
4) recieve data

[And I thought that trivial ftp would be easy]

Thanks

Paul

Leon Woestenberg wrote:

> Hello Paul,
>
> Paul wrote:
>
> > I think that ARP_QUEUEING needs to be patched in netif/etharp.c
> > Here is what I think is needed.
> >
> > /* i is available, create ARP entry */
> > arp_table[i].state = ETHARP_STATE_PENDING;
> > ip_addr_set(&arp_table[i].ipaddr, ipaddr);
> > /* queried address was already in ARP table */
> > - } else {
> > + }
> > #if ARP_QUEUEING
> > etharp_enqueue(i, q);
> > #endif
>
> >
> Yes, you found a bug there. Thanks for reporting it.
>
> Your patch fixes it, but only for the case where the ARP entry was 
> just created (with STATE_PENDING).
>
> In case the entry was already stable, we should immediately send out the
> packet-submitted-for-queue on the network link OR ALTERNATIVELY queue
> the packet and initiate a query for the address (so that it is triggered
> for transmission upon reception of the ARP response).
>
> I chose to implement the latter method (so to actively freshen the ARP 
> cache when asked to query the address).
>
> I have applied your patch, and my fix for the other case to the main
> branch.
>
> Please test and report and I will then apply it to the STABLE 0.7.x
> release branch for an upcoming stable release.
>
> Thanks,
>
> Leon Woestenberg.
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/lwip-users