[lwip-users] lwIP 1.4.0.rc1: Problems with directed UDP sendto's
Benjamin Schelte
Hi all,
After switching from lwIP version 1.3.2 to 1.4.0.rc1 I have problems with the SNTP client I have adopted from the 1.3.2 contribution folder.
I did not change the code, but for some reason it is not working as intended anymore.
Let me explain how it was working before and how it still should work:
In the DHCP request I added the option 42 for sntp servers. They are correctly read and stored in my data container.
After 30 seconds I start the sntp task and try to get the time from one of the servers I received by DHCP.
I had to adopt the code to add option 42 to the DHCP stack of lwIP 1.4.0, because it is handled in a different way compared to 1.3.2, but it is working fine for sure.
The sequence that was working so far is the following (excerpts from my code, which was taken from the sntp contrib):
socket( AF_INET, SOCK_DGRAM, 0);
bind( sock, (struct sockaddr *)&local, sizeof(local));
sendto( sock, sntp_request, sizeof(sntp_request), 0, (struct sockaddr *)&to, sizeof(to));
lwip_recv(sock, &sntp_response[0], SNTP_MAX_DATA_LEN, 0);
In 1.3.2 this sequence was working perfectly, but in 1.4.0.rc1 it is no longer working in the first run.
If I run the same sequence twice with the same server IP address I get a result on the 2nd attempt, but if I run the same sequence twice with different server IPs (because I receive 2 by my DHCP request) I don’t get anything.
In wireshark and server logs I see that the first package is never coming to the physical layer although I get valid response from “sendto” (SNTP_MAX_DATA_LEN).
The strange thing is that packets sent as a UDP-broadcast to the network are always working with the same sequence besides “bind” and “recv”, because I don’t expect an answer to that broadcast.
And now it is getting really confusing for me:
If I hardcode the SNTP-Server IP address to be my desktop computer it is working for >90% on the first attempt.
Always keep in mind that the packets are physically not sent to the network in case that it is not working!
So far I don’t have an explanation for this behavior, but it is somehow blocking me right now.
Any ideas or similar observations with 1.4.0.rc1?
Best regards,
Benjamin
Simon Goldschmidt
The only thing that comes to mind is that you might not have enabled ARP queueing. If a UDP packet should be sent to an IP address for which the MAC address is (yet) unknown, an ARP request packet must be sent out first. Without ARP queueing, the original UDP packet is (silently!) discarded. Only with ARP queueing enabled, the original UDP packet is sent out once a valid ARP response is received.
We might want to make this the default as the RFC says at least one packet per ARP table entry should be queued.
However, I don't know why that should have changed between 1.3.2 and 1.4.0. Your PC might work since you communicate to it by other means so that its MAC address is already stored in the ARP table when the SNTP packet is sent.
BTW: Integrating an interface to DHCP to make requesting costum options easier might be a good idea for us, I guess...
Simon
--
GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
_______________________________________________
lwip-users mailing list
lwip-...@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
Benjamin Schelte
Now it is working and even some other issues like initial connects from device to device are now much faster.
Thanks a lot for this hint!
Best regards,
Benjamin