buglwIP - A Lightweight TCP/IP stack - Bugs: bug #35015, Lost segments over wireless access...

 
 

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

bug #35015: Lost segments over wireless access point

Submitter:  Brad Benjamin <bradbenj5952>
Submitted:  Thu 08 Dec 2011 04:58:06 PM UTC
   
 
Category:  TCP Severity:  2 - Minor
Item Group:  Faulty Behaviour Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Planned Release:  None
lwIP version:  1.4.0

Jump to the original submission

Fri 10 Feb 2012 05:05:53 PM UTC, comment #7: 

It turns out you were right, as I suspected, it was a bug in our port. The problem was that the netif_add() was passing in a pointer to ethernet_input rather than tcpip_input. The mistake I made was borrowing code from a non-OS implementation and then porting to the OS without making the change to the input handler. Now that the repair has been made, lwIP is working great!

Brad Benjamin <bradbenj5952>
Wed 25 Jan 2012 05:32:18 PM UTC, comment #6: 

It seemed prudent to also post the ethernetif.c port as well which I obtained from a contrib for the STM32F107.

(file #24891)

Brad Benjamin <bradbenj5952>
Wed 25 Jan 2012 03:18:40 PM UTC, comment #5: 

The OS I'm using is Rowley's CTL which is part of their CrossStudio development environment. I've attached the sys_arch.c and sys_arch.h porting sources. I am using the C heap for dynamic memory allocation instead of lwIP's memory allocator. I've checked that my exclusion mechanism works properly cross threading and with the Ethernet interrupt (only one execution context gains access to malloc and free at a time). There may be a problem here but I haven't had any success capturing it.

As stated in my original post, the Ethernet driver is STM32_ETH V1.1.

I've compared my OS port to the port used in FreeRTOS contribution and, as best I can tell, I've implemented the API the same. Perhaps someone else can spot my mistake.

Also, I realize now I should have started by posting this in the discussion forum but there are so many scrapes of various forums related to lwIP I just can't figure out the proper place to start. If someone can provide a link, that would be most helpful.

(file #24889, file #24890)

Brad Benjamin <bradbenj5952>
Wed 25 Jan 2012 06:55:26 AM UTC, comment #4: 

Interesting. Still this looks like a bug in your port. Which port of lwIP are you using? Which OS and netif driver are you using? Did you write the code yourself or using a port written by someone else?

Simon Goldschmidt <goldsimon>
Group administrator
Tue 24 Jan 2012 09:45:50 PM UTC, comment #3: 

Sorry this took so long but I got side tracked to other matters. Anyway, while investigating further I've made some tests that may help reveal what may be going on here. I'll explain my changes and observations and then I'll enable logging as you advised below and report the results in a follow-on comment later.

It seems that if the protocol stack can transport segments on the wire faster than my web server can generate them everything works fine (files for web content reside on a microSD card connected through an 18MHz SPI interface and the network is running at 100Mb). However, as soon as I attempt to browse via an access point hop over WiFi I see the lost segment issue which is shown in the PCAP file attached to original post below. Once the segment is lost, the stack never recovers and frequently crashes to a hardfault on Cortex-M3. Analyzing the crash reveals that there are buffer overlaps (not having trace this has proven very difficult to back track).

Now here's the really interesting part: if I insert a thread sleep (10ms) just after each call to netconn_write, it works. Page loads are very slow, obviously, but the overwrites and lost segments are not observed.

This is just a data point which seems relevant.

Brad Benjamin <bradbenj5952>
Mon 19 Dec 2011 05:43:00 PM UTC, comment #2: 

Waiting for input... -> minor

Simon Goldschmidt <goldsimon>
Group administrator
Fri 09 Dec 2011 03:06:43 PM UTC, comment #1: 

The pcap looks indeed strange: between packets #104 and #106, 519 bytes are missing. However, that's no loss on the wire since packet #104 has the IP-ID 60 and #106 has 61, so lwIP did not send the missing bytes in the first place.

What's even more strange is that when the missing packet is re-sent (packet #112 starting at seqno #18073), it contains 485 bytes of data, not 519.

The first error seems to imply a bug in your lwIP port as this normally works. Can you say for sure that you don't have more than one thread (or ISR and non-ISR level) running in lwIP code at the same time? If you can rule out this, please try to reproduce this with TCP logging enabled so we can try to reproduce it in a test environment.

Simon Goldschmidt <goldsimon>
Group administrator
Thu 08 Dec 2011 04:58:06 PM UTC, original submission:  

I'm using an OS port, sequential API (netconn), MSS == 536, window is 2 * MSS. Our application has a web server and serves up content from a microSD card. All works very well when browsing over a wired network. However, whenever browsing is attempted using a client which connects via WiFi, lwIP frequently appears to lose segments from which it fails to recover. The net effect of this behavior is that netconn_write() fails to return to the server thread because the op_completed semaphore is never signaled by the TCP core. I've attached a PCAP file which shows a typical session. This scenario is very repeatable. You'll notice in the PCAP trace that there is a lost segment near the session start from which lwIP recovers gracefully, however, later in the session there is another lost segment from which it does not recover.

CPU: STM32F107VC
ETH Driver: stm32_eth V1.1
PHY: DP83848

Brad Benjamin <bradbenj5952>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #24891:  ethernetif.c added by bradbenj5952 (15KiB - text/x-csrc)
file #24889:  sys_arch.c added by bradbenj5952 (10KiB - text/x-csrc - Rowley CTL OS Porting Layer)
file #24890:  sys_arch.h added by bradbenj5952 (2KiB - text/x-chdr - Rowley CTL OS Porting Layer)
file #24547:  Lost Segments.pcap added by bradbenj5952 (39KiB - application/octet-stream - Typical lost segment sessions)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by goldsimon (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-02-11 goldsimon StatusNeed Info Invalid
        Open/ClosedOpen Closed
    2012-01-25 bradbenj5952 Attached File- Added ethernetif.c, #24891
    2012-01-25 bradbenj5952 Attached File- Added sys_arch.c, #24889
        Attached File- Added sys_arch.h, #24890
    2011-12-19 goldsimon Severity3 - Normal 2 - Minor
        StatusNone Need Info
    2011-12-08 bradbenj5952 Attached File- Added Lost Segments.pcap, #24547

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code