buglwIP - A Lightweight TCP/IP stack - Bugs: bug #49422, strange behavior when Win7 host...

 
 

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

bug #49422: strange behavior when Win7 host closes socket on LwIP on ARM processor

Submitted by:  Marc Desmarais <marcdesm>
Submitted on:  Sun 23 Oct 2016 07:48:25 AM UTC  
 
Category: TCPSeverity: 3 - Normal
Item Group: Faulty BehaviourStatus: Invalid
Privacy: PublicAssigned to: None
Open/Closed: ClosedPlanned Release: None
lwIP version: 1.4.1

Fri 28 Oct 2016 03:01:50 AM UTC, comment #2:

I found the problem and it is not related to the LwIP.

Marc Desmarais <marcdesm>
Sun 23 Oct 2016 08:43:03 AM UTC, comment #1:

Can you provide a Wireshark monitoring?

Dirk Ziegelmeier <dziegel>
Project Member
Sun 23 Oct 2016 07:48:25 AM UTC, original submission:

I have a python application running on a win7 pc. It connects to a TCP/IP "echo" server running as a bare metal application on a Xilinx Zynq (Arm core 0). The python application comes up, opens a socket and exchanges data with the echo application (which is modified to return useful information depending on the string from the PC). If the python application is closed, and then re-opened. All is fine. The new socket is used correctly by the LwIP based program running on the ARM core in the Zynq. But if the python application does not close, but keeps running and decides to only close the socket that's opened to the Zynq, and then decides to open a new socket with the Zynq, problems occur. I make sure that the Python socket is closed (even tried "shutdown()" before closing). There seems to be something lingering in the LwIP on the server side (could be in the Xilinx lib written to use LwIP). Using the second socket from the PC side is unreliable. Strange delays occurs inside the Zynq application. The work around is to shut down the Python application entirely.

I've noticed one difference between shutting down the Python application and closing the socket while the Python app is still running: when closing the socket from the running Python application , the recv_callback() function registered to run in the echo application on the Zynq is called with a null pointer. That's the only time recv_callback() is called with a null pointer. I don't know if this is significant. For the time being, I will prevent a user from closing a connection from the running Python application, and will instead force the user to close the application to properly close the connection (or to properly reset something in the LwIP lib).

Marc Desmarais <marcdesm>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by dziegel (Posted a comment)
  • -unavailable- added by marcdesm (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 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 28 Oct 2016 06:23:58 AM UTCdziegelStatusNone=>Invalid
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1