SARA-R4 module closes socket unexpectedly #165
Comments
|
[ |
|
Pff, and now I am getting even different behavior:
The logs look like this now:
... And then every so ofton data does get through for a moment
The frustrating part is that all seems to go well on the internet side of things, but that on the packetization on the AT interface stuff goes really slow, and I don't understand why? |
|
Hi there: first thing to say is thanks for the very detailed report, second thing to say is that, since this cellular, there is the cellular network's firewall to consider in the equation; whether it is anything to do with this or not I don't know, just thought I'd mention it. And of course there is a radio path in the way. Comments/questions: (1) the This aligns with your suggestion that the process of reading data from the module is lagging the IP traffic significantly. Of course, the IP behaviour within the module will have a different timing to the activity logged at that AT interface; the "wireshark equivalent" is inside the module somewhere. I don't know how large the module's internal IP buffers are for received data but I'd guess that, at some point, it must stop receiving IP traffic from the server and wait for the MCU to read the stuff it has buffered out, and it may be that your 10 second socket timeout kicks-in. I don't have my copy of Stevens et al to hand, but I would guess that the socket option to do a receive timeout is set locally, at "your" end of the IP link, so if that link does nothing for 10 seconds then the module should terminate the IP link (not sure what else it would do)? (2) concerning the variability of throughput, it would be worth you putting in a few calls to check what the radio environment is like, in case that is a factor. Just call uCellInfoRefreshRadioParameters() every so often, maybe between packet receives; no need to do more than that, with logging on as you have it, radio stuff will be printed in the log. |
|
Hi,
So coming back to this, what the module -should- normally do is the following:
At no point in time, should the module decide to -close- a connection, without the application explicitly saying to do so, unless malformed TCP packets or whatever were to arrive. Coming back to your question regarding the socket timeout - This is normally used for a the blocking read call. The read call will normally block forever, until some data is available, some errror on the socket happens (e.g. remote closes the connection), OR a timeout happens. But again, this timeout should never cause a connection to be actively closed by the module/OS. |
|
FYI, this is the log file with after every succesful read, doing the ucell parameter refresh Note that this time it succeeded. I'll run it a couple of more times and add a failure as well |
|
This is a failure: |
|
Ah, yes, I should have checked the code, the So we are back to what reason there might be for an
There are 192 of them, so likely around 192 kbytes downloaded when the |
|
Thanks! |
|
OK, so the exact person I need, who is specifically expert in the IP stack implementation of SARA-R422, is out of the office until Monday but, generically, I have confirmed that, to get a cause out of the module, will require a debug trace from the debug trace port (USB) of the module. For you to be able to get that, in the SARA-422 case, assuming you have access to the USB port, would unfortunately also need an NDA. Alternatively, I can try doing exactly the same thing with a SARA-R422 from my desk here and hope the problem occurs for me also: I guess I can just bounce off your server and pull that same file? |
|
Hi, NDA is no problem - feel free to get in touch directly for that. Kind regards, |
|
The |
Hi,
I ran into an unexpected issue while trying to fetch a large file over HTTP, using the socket lib.
(This relates a bit to #161, where also the reference to some example code was put).
Scenario:
uSockConnectto my own HTTP server (non SSL)uSockOptionSet(sock, U_SOCK_OPT_LEVEL_SOCK, U_SOCK_OPT_RCVTIMEO, ..)to 10suSockWriteuSockReaduntil either it returns and error (-1) or I get all the data I wantThe issue:
Sometimes this works..
But sometimes, it doesn't, and in this case, I see unexpected things:
In the ubxlib log, I see:
Note the +UUSOCL: 0 URC here. This seems to indicate that the remote closed the session.
However, since I run my own HTTP server, I took some wireshark captures of the actual data. This does not align..
6.9s after the first packet was captured, the big transfer starts from the LTE modem.
In my logs, this corresponds to the +- 34 second mark:
I then see, that the module sends a FIN, 35 seconds after the fetching of data!
This is totally unexpected. In fact, on AT, the transfer just keeps going on and on (it's just slow), until the 1min 25s mark, when it finally reports a remote-initiated closure.
So, I see two main things here:
If I'd have to guess, this "could" be caused by something like the following:
But this is unexpected no?
Am I doing anything wrong here?
Thanks for your feedback,
Arnout
The text was updated successfully, but these errors were encountered: