search

ARMmbed / mbed-os

Arm Mbed OS is a platform operating system designed for the internet of things
https://mbed.com
Other
4.67k stars 2.97k forks source link

Gemalto cellular driver loses received TCP data #12076

Closed jporter4 closed 2 years ago

jporter4 commented 4 years ago

Description of defect

The function "GEMALTO_CINTERION_CellularStack::socket_recvfrom_impl" in file "GEMALTO_CINTERION_CellularStack.cpp" implements the lowest layer in a recv call to a TCP socket. If the size of the buffer passed to the function is smaller than the amount of data received by the modem, the excess is held by the modem but will never be retrieved on subsequent calls to the function because it mismanages the flag "socket->rx_avail".

Target(s) affected by this defect ?

Any target with a Gemalto EMS31-US cellular modem attached.

Toolchain(s) (name and version) displaying this defect ?

I'm using IAR EWB for ARM 8.40. The issue should be observed regardless of which toolchain is used however.

What version of Mbed-os are you using (tag or sha) ?

5.14.1

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

IAR EWB for ARM 8.40.

How is this defect reproduced ?

Build for GEMALTO_CINTERION (edit "mbed-os\features\cellular\framework\targets\GEMALTO\CINTERION\mbed_lib.json", set "provide-default" value to true). The simple TCP client example "https://os.mbed.com/teams/mbed-os-examples/code/mbed-os-example-sockets/docs/tip/main_8cpp_source.html" works nicely, just replacing Ethernet with Gemalto cellular. The server "ifconfig.io" sends over 1000 bytes, but the recv call gets only the first 256, then the next recv call hangs somewhere.

AriParkkila commented 4 years ago

This driver is quite challenging to implement because ^SISR is used for both URC and response. ^SISR is not issued when cnfReadLength is less or equal to reqReadLength, even when there is more data available, and thus the driver does not know it should read more. For that reason, TCP implementation should probably be rewritten to use polling mode (see "Tcp/WithURCs"), and meanwhile, an application can handle the problem by always reading more than expected and/or use UDP.

jporter4 commented 4 years ago

My application requires TCP, no option to use UDP. I've stuck a workaround in it for now. I agree 100% that the ^SISR implementation makes the driver challenging. Are you the author of the driver ?

AriParkkila commented 4 years ago

@jporter4 I am one of the authors. TCP support has been added lately and that seems to be quite tricky. If you can use PPP that should work on TCP fine since it uses LWIP sockets.

jporter4 commented 4 years ago

@AriParkkila What is the link to "Tcp/WithURCs" that you mentioned above ?

AriParkkila commented 4 years ago

@jporter4 Please see ELS61-E2_ATC_V01.000 or EMS31-US_ATC_V4.9.5.x for URC mode or polling mode for Internet service commands.

0xc0170 commented 4 years ago

@jporter4 Have you been able to resolve this one as there has not been any update?

ciarmcom commented 4 years ago

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers. Internal Jira reference: https://jira.arm.com/browse/IOTOSM-2310

ciarmcom commented 2 years ago

We closed this issue because it has been inactive for quite some time and we believe it to be low priority. If you think that the priority should be higher, then please reopen with your justification for increasing the priority.