data blocked on cellular cdc-wdm0

Right now I’m unable to ping via cellular interface (100% packet loss) while connected to cellular network (wwp1s0u1u4i4 interface). When I remove the ethernet connection the RPI shows ACT green light 4 blinks (unable to connect to internet). Hologram portal online shows SIM is connected to internet throughout all my testing.

It feels like data is being block through wwp1s0u4i4 route but I’m not sure how else to debug. Can anyone provide guidance?

RPI4 (2GB) [balenaOS 2.85.2+rev3]
Hologram SIM
Quectel UC20-G (Quectel UC20-G Mini PCle 3G Module - Sixfab)

route showing ethernet and cellular connections as default. Then ping wwp1s0u1u4i4 with 100% packet loss

nmcli confirms cdc-wdm0 connection
image

mmcli showing connection to network and SIM operation

root@b8bf853:~# mmcli -m 0
  -----------------------------
  General  |         dbus path: /org/freedesktop/ModemManager1/Modem/0
           |         device id: [redacted]
  -----------------------------
  Hardware |      manufacturer: QUALCOMM INCORPORATED
           |             model: 0
           | firmware revision: UC20GQCR03A16E1G  1  [2014/05/05 9:00:00]
           |      h/w revision: 40490000
           |         supported: gsm-umts
           |           current: gsm-umts
           |      equipment id: [redacted]
  -----------------------------
  System   |            device: /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4
           |           drivers: option1, qmi_wwan
           |            plugin: quectel
           |      primary port: cdc-wdm0
           |             ports: cdc-wdm0 (qmi), wwp1s0u1u4i4 (net), ttyUSB2 (at), 
           |                    ttyUSB0 (qcdm), ttyUSB3 (at)
  -----------------------------
  Status   |              lock: sim-pin2
           |    unlock retries: sim-pin (3), sim-puk (10), sim-pin2 (3), sim-puk2 (10)
           |             state: connected
           |       power state: on
           |       access tech: gsm
           |    signal quality: 42% (recent)
  -----------------------------
  Modes    |         supported: allowed: 2g; preferred: none
           |                    allowed: 3g; preferred: none
           |                    allowed: 2g, 3g; preferred: 3g
           |                    allowed: 2g, 3g; preferred: 2g
           |           current: allowed: 2g, 3g; preferred: none
  -----------------------------
  Bands    |         supported: egsm, dcs, pcs, g850, utran-1, utran-6, utran-5, utran-8, 
           |                    utran-2
           |           current: egsm, dcs, pcs, g850, utran-1, utran-6, utran-5, utran-8, 
           |                    utran-2
  -----------------------------
  IP       |         supported: ipv4, ipv6, ipv4v6
  -----------------------------
  3GPP     |              imei: [redacted]
           |       operator id: 310260
           |     operator name: T-Mobile
           |      registration: home
  -----------------------------
  SIM      |         dbus path: /org/freedesktop/ModemManager1/SIM/0
  -----------------------------
  Bearer   |         dbus path: /org/freedesktop/ModemManager1/Bearer/66929

I was able to get multiple units connected and communicating over gsm by doing a fresh fleet install using the factory image and a basic gsm profile. This allowed the modem profile to configure properly (I guess) because from there I was able to ping via gsm interface. I then moved the device to my application fleet and verified the gsm connection profile. I really can’t say why this worked.

[connection]
id=cellular
type=gsm
autoconnect=true

[gsm]
apn=hologram
number=*99#

[serial]
baud=115200

[ipv4]
method=auto

[ipv6]
addr-gen-mode=stable-privacy
method=auto```

Hey @rcalderon1 Welcome to the forums. Thank you for this info. I will make a note of it for the future and also ping our OS team so that they are aware.

Just a clarification, when you refer to a factory image, do you mean a Balena factory image with no application containers on it? Or are you saying that you used Raspian initially and then moved to Balena OS?

Balena factory image.
FROM balenalib/raspberrypi3-debian-python:3.8.3-buster-build

Verified device registered on the fleet online (just Host OS). Then transferred to my application fleet (which triggered a new pull of application image)

oh interesting… And so the connection profile, how did it get on to the device? You configured an SO image using balena os configure? I’m a little confused because of the Dockefile reference, which implies that there was a container involved. I just want to be sure I have it straight.

I’ll document this. This workaround really should not be necessary. It sounds to me like there is a bug. Thank you for for reporting this and for the additional info.

Another question: What did the connection profile look like for the new fleet (the second one). Was it the same? If not, can you post it?

Apologies. I didn’t formulate my response well and forgot how all this was done. Let me re-explain:

downloaded and installed factory balena OS image on SD and configured cellular connection profile (as shown above). This image was for test-fleet
The RPI booted up and connected to internet via cellular as verified via LED lights and balena VPN dashboard.

Next, I transferred the device to my application fleet. Here is where I have a docker file that built a container. The docker file is not present in my test-fleet
The cellular connection profile is the same in both fleets (of course because it’s load via SD card (system-connections) and not changed during the fleet transfer)

Hi, could you try to setup the networkmanager debug logging and compare the logs between the working and not working scenarios? To setup the logging from the hostOS shell:

nmcli general logging level DEBUG domain ALL
journalctl -u NetworkManager -f

To configure the logging persistently;

mount -o remount,rw /
vi /etc/NetworkManager/NetworkManager.conf

Then add the following section:

[logging]
level=DEBUG
domains=ALL

Restart the service:

mount -o remount,ro /
systemctl restart NetworkManager