UDP records not transmitted when debugging

1

We’re trying to debug a data corruption issue and find that when using the debugger in VS Code to debug our C code, records which are normally transmitted without issue don’t get sent. I’m guessing it’s a firewall or iptables issue but am not sure what it is or how to fix it? Thanks in advance…

2
  1. Does this randomly happen?
  2. are you able to ping to the other side in console?
  3. Any problem with TCP communication?
  4. is it OK to debug by printing debug message in logread instead of using VSCode debugger?
  5. Any problem with the nc binary here?

Transfer to the module , and then type the following:


root@swi-mdm9x28:/tmp# chmod 777 ./nc
root@swi-mdm9x28:/tmp# ./nc -u  123.123.123.123 5043

This can help to isolate if problem only happens to legato application only.

3
  1. No it happens every time when using the debugger, never when the debugger isn’t running
  2. We can’t ping at all, either with the debugger or without (never understood why as there’s a rule for ICMP in the iptables)
  3. We don’t currently use TCP in our application so I don’t know
  4. Yes logread works fine and we’ve been relying on it. Using the debugger would be preferable though, and we’d like to get it working if we can.
  5. I’m not sure what you’re asking, I think you’re asking to install the nc binary and run the commands you list? - when we do that we get a segmentation fault
4

Something I forgot to mention is the sendto function returns the number of bytes we’re trying to send as though it succeeded. The data just never leaves the module for some reason.

5

Do you mean you cannot do “ping 8.8.8.8” with cellular network?
(i.e. ping after “cm data connect &”)

BTW, I don't see problem on running the nc tool:

root@fx30:~# chmod 777 ./nc
root@fx30:~# ./nc -h
[v1.10]
connect to somewhere:   nc [-options] hostname port[s] [ports] ...
listen for inbound:     nc -l -p port [-options] [hostname] [port]
options:
        -g gateway              source-routing hop point[s], up to 8
        -G num                  source-routing pointer: 4, 8, 12, ...
        -h                      this cruft
        -i secs                 delay interval for lines sent, ports scanned
        -l                      listen mode, for inbound connects
        -n                      numeric-only IP addresses, no DNS
        -o file                 hex dump of traffic
        -p port                 local port number
        -r                      randomize local and remote ports
        -s addr                 local source address
        -u                      UDP mode
        -v                      verbose [use twice to be more verbose]
        -w secs                 timeout for connects and final net reads
        -z                      zero-I/O mode [used for scanning]
port numbers can be individual or ranges: lo-hi [inclusive]
root@fx30:~# ./nc -u  123.123.123.123 5043
root@fx30:~# cm info
Device:                        WP7608
IMEI:                          352913090512345
IMEISV:                        12
FSN:                           XG207430712345
Firmware Version:              SWI9X07Y_02.37.06.05 b15b59 jenkins 2022/09/27 07:54:33
Bootloader Version:            SWI9X07Y_02.37.06.05 b15b59 jenkins 2022/09/27 07:54:33
MCU Version:
PRI Part Number (PN):          9908665
PRI Revision:                  001.004
Carrier PRI Name:              GENERIC
Carrier PRI Revision:          002.121_002
SKU:                           1104194
Last Reset Cause:              Power Down
Resets Count:                  Expected: 552    Unexpected: 0
6

Correct, ping doesn’t work at all on our WP76xx based devices even with the below rules in our iptables (we’ve tried it with both rules active as well as using each independently and it makes no difference). UDP works fine on our devices even though ping doesn’t.

-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -i rmnet_data0 -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -i rmnet_data0 -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -i rmnet_data0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i rmnet_data0 -p udp --dport 67:68 --sport 67:68

root@swi-mdm9x28-wp:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes

— 8.8.8.8 ping statistics —
8 packets transmitted, 0 packets received, 100% packet loss

root@swi-mdm9x28-wp:~# ./nc -h
Segmentation fault

root@swi-mdm9x28-wp:~# cm info
Device: WP7603
IMEI: 359528080139667
IMEISV: E
FSN: U3844171371310
Firmware Version: SWI9X07Y_02.37.03.00 73df45 jenkins 2020/04/08 10:59:14
Bootloader Version: SWI9X07Y_02.37.03.00 73df45 jenkins 2020/04/08 10:59:14
MCU Version: 002.015
PRI Part Number (PN): 9907323
PRI Revision: 002.002
Carrier PRI Name: GENERIC
Carrier PRI Revision: 002.095_000
SKU: 1103507
Last Reset Cause: Power Down
Resets Count: Expected: 17 Unexpected: 0
root@swi-mdm9x28-wp:~#

Note we’re using these modules with SMACK disabled and I wonder if that’s got something to do with the strange behavior.

7

Did you try the official firmware?
Ping should be some basic function