We tried to reproduce the issue, but at this point the issue is not reproducible on our testbench.

We received a log file containing the case where the problem appears. From this log we can see that the 3 Way Handshake is done correctly, but after that the stack doesn't issue a GET command towards the server.

This happens because the sending function, returns an error. We asked Daniel to provide this error so we can narrow down where the problem is.

Attached the log file. /media/uploads/tass/pico.pcapng

I amended the code as follows (http://mbed.org/users/mbed714/code/TCPSocket_HelloWorldTest_PicoTCP/rev/ac10f2f5ca42):

        int send_result = sock.send_all(http_cmd, sizeof(http_cmd) - 1);
        if (send_result <= 0)
            printf("Internal stack error : %d\n", pico_err);

However, the printf is never called, despite the program ultimately locking up (after the problem with the send/receive).

In terms of reproduceability, if the mbed and code are assumed to behave the same, and the mbed server providing the response is the same, then the issue must be triggered by some difference in the network between the mbed and the server.

As an aside, the same code running on the lwip based stack locked up for me after a few hours, but that problem could not be reproduced by Adam in the US.

Regards
Daniel

Hello Daniel,

We could reproduce this issue (on windows with ICS enabled) and while reproducing it a few other bugs appeared which were fixed, so thank you again for reporting this.

To sum up what was happening, after a few open - close connections, our scheduler was getting confused and no data frames were being sent out from the stack.

For more details regarding this bug and the others please check https://github.com/tass-belgium/picotcp/issues.

For the moment a memory leak has appeared and we are working on fixing that, afterwards you should be able to run your robustness test.

Thank you for your patience and feel free to contact us on any matter regarding PicoTCP.

Hi

I'm happy you could reproduce the problem - I was beginning to wonder if I had a dodgy network cable (though that still wouldn't explain the lock up).

I've invested in a switch with port mirroring, so if any wireshark traces are required in future, I don't need to involve Windows ICS (which seems to mess up DHCP).

I do have some other tests in mind, these involve disconnections and reconnections (of the network cable and/or route to DHCP server). Can you let me know when the memory leak is fixed, then I'll use that version?

Thanks Daniel

Hi Daniel,

Sorry for the delay on our side, we had a few months working hard, improving the stack. We fixed a lot of issues, which most likely were related to the issue you reported.

Please update PicoTCP and lpc1768-picotcp-eth to the latest versions and give your test another spin.

Thank you again for your patience

Tass Belgium

Hello, everyone,

We have had the same problem.. after some minutes with static IP, MBED stops working. We have reseted it and changed the RJ45 connector, but it has just worked when we have changed the IP. When the problem occurs, the ping works, but the data exchange via ethernet does not work.

We don't know which is the reason for this bug..

We are trying to reproduce the error, but we cannot find yet what is triggering it. We will try to update the libraries. Does anyone could confirm if the update of PicoTCP and 1768-picotcp-eth really solve the bug?

Thank you;;; Best Regards Rafael Baron