buglwIP - A Lightweight TCP/IP stack - Bugs: bug #20640, Request getting lost/unanswered in...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #20640: Request getting lost/unanswered in lwip stack

Submitted by:  Vipin <vipin_dce>
Submitted on:  Tue 31 Jul 2007 09:18:35 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Postponed
Privacy: PublicAssigned to: None
Open/Closed: ClosedPlanned Release: None
lwIP version: None

(Jump to the original submission Jump to the original submission)

Wed 29 Aug 2007 09:10:09 AM UTC, comment #9:

I'm going to close this as I don't think we can make any progress on this issue. I suspect that it's probably a port issue, rather than the core stack, but please re-open if there is any evidence to the contrary.

Kieran Mansley <kieranm>
Project Administrator
Mon 13 Aug 2007 07:51:30 PM UTC, comment #8:

I think windows should be allowed to reset the connection, but not after such a short period of time. If it gets no response to a packet it should first try retransmitting it. TCP normally tries many times (in a process lasting many minutes) to retransmit a packet before it gives up and closes a connection.

I'm afraid that as far as solving your problem goes the best I can suggest is contacting whoever did your port (STMicro or FreeRTOS by the look of it) and see if they're willing to support it. As I can't possibly reproduce the problem myself without your hardware and code, it will be very hard to debug. At the moment I wouldn't be surprised if this is based on an old version of lwIP.

Kieran Mansley <kieranm>
Project Administrator
Mon 06 Aug 2007 07:57:28 AM UTC, comment #7:

I am not getting fully convinced with your explanation about windows behaviour bcoz when it sends request and it does not get any response from the board, What should it do? The PC is left with no other option except restting the connection.

These are just my thoughts. As I don't have good knowledge of TCP
may be your comments are more valid than mine.

What I observed on the CRO (by toggling port bit) is that the request is not coming at http layer though it is coming at tcp layer. (I made port high in Tcp layer and low in http layer and i oserved that many a times port remains high which ideally should go low after some time).

Is this an indication that there is some problem in TCP layer?

I am in dire need to have this solution.

Kieran, Can you suggest me any other alternative to solve this issue.

Vipin <vipin_dce>
Fri 03 Aug 2007 08:48:11 AM UTC, comment #6:

The PC reseting a connection after just 200ms is crazy, and totally breaks TCP. It basically means if there's any packet loss at all the connection will get reset. It prevents the TCP retransmission stuff ever getting a chance to run and recover. It also rides completely over the top of the TCP delayed ACK mechanism, which could delay an ACK for 200ms. This surely can't be standard windows behaviour!

However, that doesn't explain why there's no response from the lwIP board in that time. I'm afraid that is going to be very hard to debug remotely in the time available without knowledge of your hardware or port.

Kieran Mansley <kieranm>
Project Administrator
Fri 03 Aug 2007 08:24:58 AM UTC, comment #5:

I am using the code, available at

http://mcu.st.com/mcdfiles/STR9_dongle_IAR_alpha_0-6.zip

Vipin <vipin_dce>
Fri 03 Aug 2007 08:23:05 AM UTC, comment #4:

I tried to analysed trace more deeply. I found that PC is resetting the connection only when it is expecting data from the board but after waiting for some time but it doesn't get a response.
E.G.
In Packet 45, 85, 156, 172, 244 connection is getting reset becoz PC was expecting an ACK for the request it has send but it gets no response hence after a timeout of 200 ms it resets the connection.

Similarly, In the remaining connection resets by PC i.e. in packet 168, 244 it is expecting more data from the board but when it doesn't receive that data it issues a reset of connection.

If this analysis is correct then it would mean that lwip stack is missing the requests from the ethernet and hence ACK is not provided, which will mean that we have some problem in the stack?

Moreover the connections reset by lwip board is also not understood. I will try to print the debug statements but I don't have any great knowledge of TCP/IP.

Please help.

Vipin <vipin_dce>
Tue 31 Jul 2007 12:19:06 PM UTC, comment #3:

Not sure how to reduce the RSTs - we'd need to get to the bottom of what's causing them to work out how to reduce them. They're going in both directions, which doesn't help narrow it down.

I suppose you could using some of the DEBUG print statements in lwIP to trace why it is sending RST packets, but that's only the lwIP half of the story.

From looking at the trace, lwIP seems to send a RST when it serves no purpose - for example the connection beginning at packet 120 is RST by packet 185 just 1.5 seconds both ends have sent a FIN. I suppose if packet 135 got lost or dropped in the network it might not know the other end has responded to its FIN, but to RST so quickly is odd - usually it would wait considerably longer. I wonder if you're calling the TCP timers correctly? Also, for the PC to not retransmit packet 135 in the intervening time is odd.

The RSTs from the PC may just be Windows being overly-aggressive in the way it closes connections, but again it's giving up so quickly that it's a bit odd: e.g the connection beginning in packet 240 is reset in packet 244 just 200ms later.

Kieran Mansley <kieranm>
Project Administrator
Tue 31 Jul 2007 11:55:17 AM UTC, comment #2:

>>Which IP address is the PC and which is the lwIP board, and at which end did you get the packet capture (I'm assuming PC)?


192.168.2.2 is the client (PC) address
192.168.2.1 is the LWIP board address

>>Looking at your trace I see a lot of RST packets. Any idea why the FINs aren't getting correctly ACKed and instead RST?


No idea about these. How can this be reduced?

Vipin <vipin_dce>
Tue 31 Jul 2007 09:37:55 AM UTC, comment #1:

Fundamentally TCP is not a real-time protocol and will not be able to provide the sort of timing guarantees you're hoping for. Any packet loss in the network will mean things take longer than 200ms to complete.

Which IP address is the PC and which is the lwIP board, and at which end did you get the packet capture (I'm assuming PC)?

Looking at your trace I see a lot of RST packets. Any idea why the FINs aren't getting correctly ACKed and instead RST?

I suspect that this may be the cause of some of your problems - if connections remain active because they haven't been properly closed, it may be that new connections can't be properly established. Just a guess though as I can't spare enough time at the moment to look in detail.

Finally, if the PC is issuing these requests every 200ms, and the capture is made on the PC, why don't they appear in the trace every 200ms? That suggests that the PC is in fact no making requests at the frequency you want. Perhaps it is waiting for the response to earlier ones?

Kieran Mansley <kieranm>
Project Administrator
Tue 31 Jul 2007 09:18:35 AM UTC, original submission:

Hello all,

I found some problem related with LWIP stack. I will be happy if you can take out some time for this.

My Application is: //Same as mentioned in Bug #20506

1. To request 4000 bytes of data from my board through web browser running on the PC.
2. I am requesting this much data from browser after every 200ms.
3. The request is handled by http layer of my firmware.

Observation:
1. Since request is issued by client (PC) after every 200ms it should reach http layer at this frequency but I observed that many a times this request is not reaching the http layer.

2. The time between requests is also varying and it goes upto 500ms(it is expected to remain constant at 200ms).See timings and transaction between 139 & 155 packets in the attached trace.

3. Some of the requests don't found an answer (check 177 and 243 packets in the attached ethereal trace)

What are your comments on this?

Vipin <vipin_dce>

 

Attached Files
file #13533:  flick added by vipin_dce (77KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by kieranm (Posted a comment)
  • -unavailable- added by vipin_dce (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 29 Aug 2007 09:10:09 AM UTCkieranmStatusNone=>Postponed
      Open/ClosedOpen=>Closed
    Tue 31 Jul 2007 09:18:35 AM UTCvipin_dceAttached File-=>Added flick, #13533

    Back to the top


    Powered by Savane 3.1-cleanup1