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

[Rüdiger Asche]

...and one more thing while you're at it: Try operating the client and
server in a standalone environment (ie hook them up together with a
hub and remove the uplink to the rest of the network. You may have to
reconfigure your unit from a DHCP client to a fixed IP address unless
the Web server and the DHCP server execute on the same machine). If
the communication runs smooth now, it's definitely a problem with a
congested net eating up your receive buffers,

2013/1/9, Rüdiger Asche <address@hidden>:
> 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
>>
>>
>