[lwip-devel] [bug #49422] strange behavior when Win7 host closes socket on LwIP on ARM processor

[Marc Desmarais]

URL:
  <http://savannah.nongnu.org/bugs/?49422>

                 Summary: strange behavior when Win7 host closes socket on
LwIP on ARM processor
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: marcdesm
            Submitted on: Sun 23 Oct 2016 07:48:25 AM GMT
                Category: TCP
                Severity: 3 - Normal
              Item Group: Faulty Behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: 1.4.1

    _______________________________________________________

Details:

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).





    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?49422>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/