Balena OS + raspberry pi not working with Huawei dongle anymore

I think there might have been some breaking changes in the balena OS versions released in the last months that caused it to stop working on Huawei dongles that had always worked before. I’ve been having to go back to the old versions to have them work, so I thought of dropping a link to the exact product here:

It was working until June 2019, then something happened… any advice?

Thank you for the support!

Hi, for using the Huawei modem in new OS versions, you would need to add a NM connection profile for it.
See here for details
Can you try this on a machine and let us know if that fixes your problem?

We had a similar issue. We reverted back to cdc_ether.

Our BalenaOS (meta-balena) patch we appended follows:

diff --git a/usb_modeswitch.d/12d1:1f01 b/usb_modeswitch.d/12d1:1f01

index 84fa96e..c7a9b5f 100644

--- usb-modeswitch-data-20170806.orig/usb_modeswitch.d/12d1:1f01

+++ usb-modeswitch-data-20170806/usb_modeswitch.d/12d1:1f01

@@ -1,6 +1,6 @@

# Huawei E353 ( and others







The change this reverts is a nasty change for deployed fleets since the mode only changes on dongle power cycle, we missed it in QA and only started seeing it after the first power outage :frowning:

@tgirotto @SplitIce this has now been reverted in release 2.47 so it uses again cdc_ether by default so no need to do any additional changes.

@floion Thanks @brdrcol noticed the change in meta-balena in our team and reverted our patch. Looks good.

@floion still not working with version 2.47.

Here is my gsm connection, as modified in the system-connections folder:





Hey there @tgirotto, can you share any specific details about the problems you’re facing now? As @SplitIce confirmed the reverted change resolved their issue above, perhaps what you’re hitting is something else entirely.

What debugging steps have you tried so far? You could try journalctl -u NetworkManager from a terminal to the hostOS and see if that shows anything useful. Do you know if the modem is successfully establishing a connection to the cell network but not connecting to the internet, or is it not even getting that far?

The balena team also overrode the upstream change. This results in an effect the same as ours. In turn we have removed our patch and are back with the balena team on this one.

It’s now fine to use the latest balenaOS (or meta-balena-common).

@chrisys unfortunately I do not have access to the physical device, so debugging is a little difficult. If it can help, I am actually using open balena, and the last working release for me was 2.46.1+rev1. Is there any repo where I can get a copy of that release and see whether it works?

Thank you!

@tgirotto You can download balenaOS releases from
The source code is here

@tgirotto 2.46.1+rev1 for rpi3 is here

Ok I tried using the image posted by @zvin with the following settings in system-connections






So far we know that:

  • the modem works on a mac, so the modem and the sim card work. Also, there is connectivity;
  • the raspberry pi could connect to wifi on balena cloud;
  • the app on open balena that we are using is ok, because it is already being used by other devices;
  • the configuration above works with other devices (we are using the exact same).

My self-hosted version of open balena seems to work, as I can access data about all the other devices in my fleet. No logs in the docker showing anything weird…

Hi Tgirotto,

Can you clarify that it does work on raspberry pi or not with the image provide before?
Also it doesn’t matter what you are connected to, it should work the same with both openBalena and balenaCloud.

Thanks for the support.

I tried using the image from the link above (2.46). It does not work, which is weird, because I have used exactly the same image in the past. I am attaching a screenshot of my current fleet. Maybe it can give more insight?

Since I have been trying for days now, I have tried configuring the image by @zvin above to work with ah18-spagna because I know that one works already, but the technician on the ground is telling me it only blinks in green, which means it’s looking for network…


As you can see from the docs, we don’t test this modem. You can try one of the supported modems instead. If you’d still like to debug the issue, we recommend you to connect the said device to wifi/ethernet and then shh into the device to get a better sense of why it’s not working by reviewing the system logs.

journalctl -u ModemManager

Mm I will see if I can have someone on the field connect it to a wifi. However, we have been using that exact modem for more than a year and it never created problems. I will write back in case we figure it out.


I have also been having issues with the new cellular setup using a Huawei E3131h-2 and E3533s-2 on Balena 2.47.0+rev1.
I ended up reverting the E3533s-2 to cdc_ether.
It is important to note that I have never had the E3131h-2 as a cdc_ether device.

What I noticed was that when running with just the dongle, ModemManager would quite often not see any devices (within a reasonable timeframe); when running with ethernet connected, it would much more often/faster detect the device.

What I have done now as a workaround for this issue, is to periodically (every 30 seconds) query ModemManager through dbus to check if it has any devices; if it doesn’t, I restart ModemManager (dbus query to systemd).
For now this seems to work for me, YMMV.

@zvin where can I find Balena OS 2.3x versions? is there a repo with all the old versions?

I have just tried connecting RPI 3B+ to wifi through open balena and it worked, which means it is something that has to do with network manager (I have tested every other bit of the system separately).

@TJvV how can I change cdc_ether?

thank you

I just checked and unfortunately we do not list older OS versions for vanilla balena OS versions that are suitable for openBalena. I raised this to our product team as an issue now. Probably the easiest way to get an older OS version currently is by checking which versions are available in from our cloud dashboard and then download manually by modifying the URL from the latest. E.g. switch to

I simply needed to add the correct usb_modeswitch message in the udev rules.
This way it overrides the usb_modeswitch default.

In this case it was.

#huawei e3533
ACTION==“add”, SUBSYSTEM==“usb”, ATTRS{idVendor}==“12d1”, ATTRS{idProduct}==“157d”, RUN+="/usr/sbin/usb_modeswitch -v 0x12d1 -p 0x157d -M ‘55534243123456780000000000000a11062000000000000100000000000000’"

You will need to modify the config.json as specified in the documentation.

Note that this is similar to what @SplitIce did, just configured in a different place.

You can reload and trigger the udev rules through udevadm, but this won’t affect the dongle if it has already been configured. You will need to reconnect the dongle, or power cycle the whole device.