[lwip-users] [lwip] Problems with arp/udp

[Lars Kanis]

Hi !

I am new in the lwip community. Nevertheless I found some bugs/problems in the 
arp handling. I am using the current CVS code and a modificated version of 
the cs8900if-driver (to work with the new etharp) on a C167-microcontroler. 
The same problems occure, when I use the unmodificated code on linux with 
/dev/tap.

1. If I send a ping with linux to the stack, the address resolution works as 
following:
   arp request  from linux -> lwip
   arp reply            from lwip -> linux
   ping         from linux -> lwip
   arp request  from lwip -> linux
   arp reply            from linux -> lwip
   pong         from lwip -> linux (wrong, see below)
   ping         from linux -> lwip
   pong         from lwip -> linux

according to rfc 826 the src-hwaddress of the arp request should be stored in 
the arp-tab so there is no need to do a second reverse arp request from the 
lwip-side to answer the ping.

2. The delayed transmission of the pong above has a wrong src-hwaddress 
because the src-field is only filled in, if the packet could be send 
immediately.

3. To send a UDP-packet, I call udp_send with a allocated pbuf. The function 
chains my pbuf with a new allocated pbuf. If the driver has no 
dest-hwaddress, it stores the pbuf in the arp-table and sends a arp request 
immediately. At the end of udp_send the pbufs are dechained and because of a 
reference-counter of 2 not freed. If the lwip receives the arp replay, the 
arp-module gives the driver the address of the original packet (without the 
correct src-hwaddr.) without the chained pbuf. The packet is therefor invalid 
and is not sent.

4. How should a know, that the udp-packet is sent, to free the pbuf?

5. Why is not just a pointer to the pbuf stored in the arp-tab, but payload, 
len and tot_len in addition?


Regards,
Lars Kanis


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