buglwIP - A Lightweight TCP/IP stack - Bugs: bug #57346, TCP stop working

 
 

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

bug #57346: TCP stop working

Submitted by:  Hubert Sack <hs4smd>
Submitted on:  Tue 03 Dec 2019 09:30:39 AM UTC  
Votes:  90  
 
Category:  TCP Severity:  3 - Normal
Item Group:  None Status:  Invalid
Privacy:  Public Assigned to:  Simon Goldschmidt <goldsimon>
Open/Closed:  Closed Planned Release:  None
lwIP version:  git head

( Jump to the original submission)

Tue 04 Feb 2020 09:17:06 PM UTC, comment #7: 

> I've actually I very similar problem


We need similiarities in "similar code", not similard as "it just doesn't work".

I'm closing this as invalid, please just continue posting here if anyone has valuable input on why this should be an lwIP bug (not a memory config error or whatever).

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Mon 20 Jan 2020 07:19:12 AM UTC, comment #6: 

I've actually I very similar problem. In my case I implemented a virtual network interface to send raw ethernet frames to an UART connected WLAN module. The module it self has no LwIP stack active, but sends out all the incoming data from the ┬ÁC board and all received data are sent back to the LwIP stack.

In my case the problem occurs as soon as the WLAN gets unstable (wlan client moved too far away from access point) and suddenly the connection drops. After WLAN reconnection, the LwIP side is broken. Ping'ing the device is still possible (ICMP seems to be not affected) but TCP/IP is not working any more. I will analyze the problem in more depth in the next days, may be I can provide some more detailed information.

Benjamin K <bkausbk>
Fri 10 Jan 2020 07:47:57 PM UTC, comment #5: 

Last ping before closing as invalid...

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Tue 03 Dec 2019 08:46:18 PM UTC, comment #4: 

OK, so you're using netconn API. That means you can have a bunch of problems when threading is done wrong.

From your previous posts, I couldn't read ping is still working. Maybe you should concentrate on one scenario that fails first instead of making too many words that distract from the problem :-)

Your lwipopts.h is wrong. Seems like a copy of opt.h, but it should really only be a file that overwrites the options you need to change.

Keeping all that aside, have you checked you don't run out of memory? A perfect explanation would be that the TCP connections where the "wire" is broken hog all buffers so that the remaining connections at some point just cannot send anything.

To check that, you can print lwip_stats from your main task, e.g. every second or so. I wouldn't have expected an ASSERT though.

I'm still not convinced this is a bug in lwIP.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Tue 03 Dec 2019 08:33:01 PM UTC, comment #3: 

Yes, I'm sure that this is something in lwIP. Why? Because "ping" is not affected at all and I saw Dup ACK, Spurious Packets after returning the power of switch B.

My application on PC #1, which should not being affected by cutting the traffic to PC #2 (by power off the switch), disconnected after internal timeout and tried to reconnect, but there was no answer from lwIP. As said before, "ping" works the hole time without problems (even with no change of the packet response time reported)

OK, I'll add a serial output for the ASSERT strings and capture them im puTTY. At the moment I startet the target from within "Softconsole" and got no break in any ASSERT

I didn't know that wireshark is so common. Because the behaviour is so easy to reproduce in my testenvironment, I'll capture the behaviour when switching the power of the switch and send it as pcap

I added "main" (.c and .h) and "lwipopts.h" of my application. You'll see, the application is really very simple. In principle, one connection does just do coping data from TCP to a buffer in the PLC Controller and vice versa.
An other connection reads a DP-RAM in the FPGA fabric and sends the data to TCP

(file #47980, file #47981, file #47982)

Hubert Sack <hs4smd>
Tue 03 Dec 2019 07:35:05 PM UTC, comment #2: 

How is this a crash error? How are you even sure this is a bug in lwIP?

Aside from that, you are stying much too vague. Get a debugger and see what your target is doing. And when sending wireshark captures, send pcap files, not pdf or txt.

Keeping that aside, you don't even say how your application looks like. Oh, and I do remember the MAC driver coming with SmartFusion2 was kind of hard to use when it comes to using multiple interrupt levels.

Simon Goldschmidt <goldsimon>
Project AdministratorIn charge of this item.
Tue 03 Dec 2019 02:11:26 PM UTC, comment #1: 

I did one more test and this discovered a huge problem:

I turn off power of switch B for approx. 2 minutes while the Appl. on PC #2 was not stopped.
After power was applied to switch B again, the traffic was completely confused.

After resetting the CM3 both applications on PC #1 and #2 reconnected successfuly. But this is neihter a solution nor a work-around for the problem

The captured network traffic is in the attached textfile

(file #47974)

Hubert Sack <hs4smd>
Tue 03 Dec 2019 09:30:39 AM UTC, original submission:  

The following text references the attached picture where my test environment is drawn. I did 6 tests - test 1 to 4 seems not to cause any problems. Test 5 and 6 results in stopping any further TCP traffic
On both PC (#1 and #2) I startet "ping" during all tests
"Appl." on the PCs is my application, which establishes 2 TCP connections each (drawn in red color)

Test 1:
1.) The "Appl." is not running on either PC
2.) The network overview is shown on PC #1
3.) The network used for the connection is set to deactivated
4.) In result "ping" stops responding
5.) Some seconds later the network used for the connection is set to activated again
6.) A little amount of time later "ping" response again

Test 2: Same as Test 1, but deactivating/reactivating is done on PC #2

Test 3:
1.) The "Appl." is running only on PC #1
2.) The network overview is shown on PC #2
3.) The network used for the connection is set to deactivated
4.) In result "ping" stops responding
5.) Some seconds later the network used for the connection is set to activated again
6.) A little amount of time later "ping" response again
7.) "Appl." on PC #1 is unaffected - working all the time

Test 4: Same as Test 3, but "Appl." running on PC #2 and deactivating/reactivating is done on PC #1

Test 5:
1.) The "Appl." is running on both PCs (#1 and #2)
2.) The network overview is shown on PC #2
3.) The network used for the connection is set to deactivated
4.) In result "Appl." on PC #2 and PC #1 (yes, #1 !) stops working
5.) In result "ping" stops responding
6.) Some seconds later the network used for the connection is set to activated again
7.) A little amount of time later "ping" response again
8.) "Appl." on both PCs doesn't reconnect anymore

Test 6: Same as Test 5, but deactivating/reactivating is done on PC #1

My question: Is the reason causing this behaviour already known? And if, is any solution or work arround existing?

Hubert Sack <hs4smd>

 

Attached Files
file #47980:  main.c added by hs4smd (20KiB - application/octet-stream)
file #47981:  main.h added by hs4smd (3KiB - application/octet-stream)
file #47982:  lwipopts.h added by hs4smd (56KiB - application/octet-stream)
file #47974:  Errors.txt added by hs4smd (35KiB - text/plain)
file #47971:  Topology.png added by hs4smd (303KiB - image/png - Topology of my test environment)
file #47972:  WireShark.pdf added by hs4smd (70KiB - application/pdf - Topology of my test environment)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bkausbk (Posted a comment)
  • -email is unavailable- added by bkausbk (Voted in favor of this item)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by hs4smd (Submitted the item)
  •  

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

    Only logged-in users can vote.

     

     

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-02-04 goldsimon StatusNeed Info => Invalid
        Assigned toNone => goldsimon
        Open/ClosedOpen => Closed
    2020-01-20 bkausbk Carbon-Copy- => Added bkausbk
    2020-01-10 goldsimon StatusNone => Need Info
    2019-12-03 hs4smd Attached File- => Added main.c, #47980
        Attached File- => Added main.h, #47981
        Attached File- => Added lwipopts.h, #47982
    2019-12-03 goldsimon Item GroupCrash Error => None
    2019-12-03 hs4smd Attached File- => Added Errors.txt, #47974
    2019-12-03 hs4smd Attached File- => Added Topology.png, #47971
        Attached File- => Added WireShark.pdf, #47972

    Back to the top


    Powered by Savane 3.5