Open davidalo opened 3 years ago
@davidalo thank you for raising this issue.Please take a look at the following comments:
It would help if you could also specify the versions of any tools you are using?
NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'. This indicates to us that at least all the fields have been considered. Please update the issue header with the missing information.
cc @ARMmbed/mbed-os-connectivity
Description of defect
I have been developing a new driver for a QUECTEL modem. I am trying to run the Mbed OS tests using the new porting, all of them works as expected except two:
mbed-os-connectivity-netsocket-tests-tests-netsocket-udp : UDPSOCKET_ECHOTEST_BURST
mbed-os-connectivity-netsocket-tests-tests-netsocket-udp : UDPSOCKET_ECHOTEST_BURST_NONBLOCK
I have been reviewing those tests and they perform the following actions:
The problem is that, this tests are assuming that the UDP socket API will pop a UDP packet (and no more). For example, if we receive three packets of 100, 300 and 200 bytes and we try to read 600 bytes, we will have to perform three read operations and read 100, 300 and 200 bytes respectively.
The problem is that, in some modems, such as in QUECTEL ones, UDP datagrams are stored as if they were a TCP stream, it does not have delimiters for the different received packets so when you try to read 600 bytes, it will return you the three packets (in the order they have been received).
I actually don't know how to approach this in order to make the component pass the tests.
Target(s) affected by this defect ?
Cellular components.
Toolchain(s) (name and version) displaying this defect ?
GCC_ARM
What version of Mbed-os are you using (tag or sha) ?
mbed-os-6.14.0
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
mbed-cli version 1.10.5
How is this defect reproduced ?
Running Mbed OS connectivity tests: