Re: [lwip-devel] STM32, FreeRTOS and lwIP - Timeout problems

[Rüdiger Asche]

where actually do you pull the trace? On the unit itself? That won't be of much help; what you should do is get yourself a little 4 port hub, hook a PC running wireshark (for sniffing) and the target unit in the same segment and then monitor the traffic on the bus witht eh PC. If you already lose the packets on the driver side, your sniffer on the unit will see them as little as your application. Plus, you really want to see the full packets, not only the summary, so one can verify that all the checksums etc. are ok. A full external trace already gives a lot of meaningful information.

 

The HTTP headers are of no relevance here because you don't even get to send them. HTTP sits on top of TCP, and the underlying Tcp connection needs to be established before any HTTP payload will be sent. The connection establishment is a 3 packet exchange called a handshake. It consists of the packet SYN - SYN ACK - ACK. Your traces reveal that the initial SYN is never answered (or the answer is simply not seen), so HTTP doesn't even come into play yet.

 

I still believe that the responses to the SYN are on the net and you'll see them in the external trace, but they never make it to your stack. More evidence for that theory is that it takes three attempts to find your peer with ARP; this suggests that two ARP responses get lost the same way.

 

There are ways to analyze that, but you need to be familiar with the packet control flow in lwip to set your breakpoints at the right places. I don't have the code in front of me right now, but there should be something like tcp_input in tcpip.c where you can start looking at how incoming packets are dispatched through the system. That is where all packets come in; those beginning with 0xffffffffffff are broadcasts that are processed by the ARP layer. Packets that go directly to your unit (your MAC address in the header) are then processed somewhere else; step through a few times to get a feeling for what happens. 

 

I am a freelancer, and this would be right up my alley, but unfortuantely I don't have capacities to take the issue up right now, sorry.

2013/1/8 Thomas Kølbæk Jespersen <address@hidden>

2013/1/8 Rüdiger Asche <address@hidden>

If your RXBUFS count is small (<= 5) AND that there are many
broadcasts in the net, chances are that the broadcasts eat up all
available buffers before a packet directed to your stack has a chance
to be processed by your unit. If you have sufficient RAM available,
try for testing to raise the number to, say, 20. My prediction is that
your successful connection rate will be much higher.

Thank you for your very good suggestions which I really hoped would work.

Unfortunately the issues are the same, and I'm just left with much less RAM available ;-)

I have tested both with and without the web server together with the client function, but it doesn't make any difference.

But I have done what you suggested about the logging and sniffing of the data packets, and it actually seems like the server is never responding! :O

This is the log:

address@hidden:/tmp/smbshare/tmp/ipkg# tcpdump host 192.168.0.136

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes

21:06:16.755439 arp who-has 192.168.0.136 tell DD-WRT

21:06:17.749425 arp who-has 192.168.0.136 tell DD-WRT

21:06:18.749419 arp who-has 192.168.0.136 tell DD-WRT

21:06:19.009820 IP DD-WRT > 192.168.0.136: ICMP echo request, id 24829, seq 0, length 28

21:06:19.010268 IP DD-WRT.bootps > 192.168.0.136.bootpc: BOOTP/DHCP, Reply, length: 300

21:06:19.013484 IP DD-WRT.bootps > 192.168.0.136.bootpc: BOOTP/DHCP, Reply, length: 300

21:06:19.013816 arp who-has 192.168.0.136 tell 0.0.0.0

21:06:19.253541 arp who-has 192.168.0.136 tell 0.0.0.0

21:06:20.755843 arp who-has DD-WRT tell 192.168.0.136

21:06:20.756171 arp reply DD-WRT is-at 00:1c:10:36:55:d5 (oui Unknown)

21:06:20.756363 IP 192.168.0.136.49153 > api.theblast.dk.www: S 6509:6509(0) win 5840 <mss 1460>

21:06:23.505626 IP 192.168.0.136.49153 > api.theblast.dk.www: S 6509:6509(0) win 5840 <mss 1460>

21:06:26.505681 IP 192.168.0.136.49153 > api.theblast.dk.www: S 6509:6509(0) win 5840 <mss 1460>

21:06:29.505745 IP 192.168.0.136.49153 > api.theblast.dk.www: S 6509:6509(0) win 5840 <mss 1460>

21:06:32.505805 IP 192.168.0.136.49153 > api.theblast.dk.www: S 6509:6509(0) win 5840 <mss 1460>

21:06:35.505865 IP 192.168.0.136.49153 > api.theblast.dk.www: S 6509:6509(0) win 5840 <mss 1460>

21:06:38.505924 IP 192.168.0.136.49153 > api.theblast.dk.www: S 6509:6509(0) win 5840 <mss 1460>

STM32 Debug: TIMEOUT 

21:06:40.058179 IP 192.168.0.136.49154 > api.theblast.dk.www: S 6583:6583(0) win 5840 <mss 1460>

21:06:43.058028 IP 192.168.0.136.49154 > api.theblast.dk.www: S 6583:6583(0) win 5840 <mss 1460>

21:06:46.058071 IP 192.168.0.136.49154 > api.theblast.dk.www: S 6583:6583(0) win 5840 <mss 1460>

21:06:49.058133 IP 192.168.0.136.49154 > api.theblast.dk.www: S 6583:6583(0) win 5840 <mss 1460>

21:06:52.058188 IP 192.168.0.136.49154 > api.theblast.dk.www: S 6583:6583(0) win 5840 <mss 1460>

21:06:55.058256 IP 192.168.0.136.49154 > api.theblast.dk.www: S 6583:6583(0) win 5840 <mss 1460>

21:06:58.058307 IP 192.168.0.136.49154 > api.theblast.dk.www: S 6583:6583(0) win 5840 <mss 1460>

STM32 Debug: TIMEOUT 

21:06:59.565567 IP 192.168.0.136.49155 > api.theblast.dk.www: S 6731:6731(0) win 5840 <mss 1460>

21:06:59.587891 IP api.theblast.dk.www > 192.168.0.136.49155: S 2608560878:26085 60878(0) ack 6732 win 14600 <mss 1460>

21:06:59.588153 IP 192.168.0.136.49155 > api.theblast.dk.www: . ack 1 win 5840

21:06:59.589999 IP 192.168.0.136.49155 > api.theblast.dk.www: P 1:164(163) ack 1 win 5840

21:06:59.611974 IP api.theblast.dk.www > 192.168.0.136.49155: . ack 164 win 15544

21:06:59.677696 IP api.theblast.dk.www > 192.168.0.136.49155: P 1:221(220) ack 164 win 15544

21:06:59.678214 IP api.theblast.dk.www > 192.168.0.136.49155: F 221:221(0) ack 164 win 15544

21:06:59.678451 IP 192.168.0.136.49155 > api.theblast.dk.www: . ack 222 win 5619

21:06:59.729786 IP 192.168.0.136.49155 > api.theblast.dk.www: F 164:164(0) ack 222 win 5619

21:06:59.750428 IP api.theblast.dk.www > 192.168.0.136.49155: . ack 165 win 15544

In that case, as the server isn't responding properly, could it be something with the HTTP header?

The header I'm sending/using is:

GET / HTTP/1.1\r\nUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 1.0.3705)\r\nHost: api.theblast.dk\r\n\r\n

 

Looking forward to your feedback.

Regards Thomas

_______________________________________________
lwip-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-devel