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

Submitter:  Marc Desmarais <marcdesm>
Submitted:  Sun 23 Oct 2016 07:48:25 AM UTC
   
 
Category:  TCP Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Planned 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>
Group administrator
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>

 

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

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dziegel (Posted a comment)
  • -email is unavailable- added by marcdesm (Submitted the item)
  •  

    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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-10-28 dziegel StatusNone Invalid
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code