We’re using a Huawei E3372h-320 and an Ethernet USB adapter in our project. One is for a 4G connection and the USB ethernet adapter is for passthrough. On startup, my Node.js script gets all devices from NetworkManager via DBus and filters out all non-ethernet devices and eth0 (because we’re using that for Ethernet-in). But the Huawei E3372h-320 functions as a ethernet device, which is nice because it works out of the box. Because of this however, NetworkManager says it’s a ethernet device instead of a 4G device. So how can we determine which is which?
I’ve checked the DBus docs, but I couldn’t find anything. The only value that’s different is the driver the devices use. The Huawei E3372h-320 uses the cdc_ether driver and the USB uses the ax88179_178a driver. So I can filter on that, but it’s not that reliable for future purposes.
Does anyone know if there’s another way to determine which is the 4G USB via the NetworkManager DBus?
I do not think NetworkManager has a similar functionality. Can you please run ip route when the modem is attached and let me know what the output is? If the route metric is 700 then it is treated as a LTE modem, if it is 100 then it is treated as Ethernet device completely.
default via 192.168.10.1 dev eth0 metric 101
default via 192.168.8.1 dev enp1s0u1u1 metric 102
10.114.101.0/24 dev balena0 scope link src 10.114.101.1
10.114.102.0/24 dev resin-dns scope link src 10.114.102.1
10.114.104.0/25 dev supervisor0 scope link src 10.114.104.1
10.240.0.1 dev resin-vpn scope link src 10.240.0.4
172.18.0.0/16 dev br-6f1d482825cf scope link src 172.18.0.1
192.168.8.0/24 dev enp1s0u1u1 scope link src 192.168.8.101 metric 102
192.168.10.0/24 dev eth0 scope link src 192.168.10.41 metric 101
Device enp1s0u1u1 is the 4G USB Dongle. The metric seems to be 102, so it’s treated as an ethernet device according to your answer…
The good news at least is that since it is a USB dongle, it is assigned a metric of 102, which is lower priority than the built-in eth0 with 101.
For you question I think the only option is to do some custom filtering using the general properties of the interface. You can see those for your device by running nmcli -p -f general device show enp1s0u1u1.
I do not think there is a generic way for filtering those out as behind the cdc_ether driver could be a real Ethernet device as well. So maybe you can do some filtering by the GENERAL.VENDOR property?
Probably not exactly what you are looking for, but something that works quite well for me.
In the projects where I use a Raspberry Pi and Huawei dongles, I have added an udev rule to rename the ethernet devices as they are added.
The way I do that is to filter on MAC address (ex. 0c:5b:8f:* for Huawei, b8:27:eb:* for Raspberry) and assign a descriptive name (ex. huawei_eth_1 and pi_eth_0).
After that, I use the newly defined names in my scripts.
Note that there may be multiple vendor-specific MAC address prefixes for the same vendor.
Seeing as you can get general information of an interface via DBus, you could also use that to filter out devices based on MAC address.
Thanks for your reply. I didn’t know that about the metric numbers, always good to know!
About the GENERAL.VENDOR, that would be a better solution for filtering. However, I can’t seem to figure out how to get those details from the NetworkManager API. They aren’t available in the org.freedesktop.NetworkManager.Device or the org.freedesktop.NetworkManager.Device.Wired. And I can’t find another path where to get them from…
Is this impossible to do? I’d like to use the DBus API to gather all this information because of the library I’ve built.
Thanks for replying. The MAC address prefix would be a solution!
The udev rules however are something I’m having problems with on balenaOS. I can make them work, however, balenaOS is focused on doing everything remotely using software updates. That being said, one of those things you can’t update automatically is the config.json, and thus udev rules. So I’m trying to keep away from them, because our products can be stored in a warehouse with ‘old’ udev rules. If our client makes the decision to switch to another USB dongle (or the current is discontinued), we’ve to re-flash every SD card with the new udev rules.
I’ll look into the MAC address prefix if I can’t get the GENERAL.VENDOR and/or GENERAL.PRODUCT from the DBus API!
For Node.js you can do that by using the node-gtk module. This however will require for you to reimplement what you have already did. Not sure how hard would that be for you or whether you would like to go that route.
Using the libnm library isn’t something I’d like to use at the moment, because it’ll take me loads of time to build for such a ‘small’ problem. It’s just that I want a more reliable way to determine which is the 4G dongle and which is the USB Ethernet dongle. So I’ll take a look at the MAC address (probably).
Nonetheless, thanks for letting me know about the libnm library and trying to solve my problem!
Hmm the MAC address nmcli returns using nmcli d show enp1s0u1u1 is 00:1E:10:1F:00:00. Really weird address to be honest. But not the Huawei Prefix. So that’s not an option…
I’m thinking about using the idVendor and idProduct from a USB library. But I don’t know for sure if I have enough data to link that data to the interface name…
Using Huawei dongles on Balena always makes it virtual ethernet mode due to the USB-modem switcher on the host os. My experience is that it always be eth1 since it is added after startup and recognizable by the always same address of 192.168.8.1.
If you need more verification, this can be done by reading out lsusb, or similar tools, to look up the hardware address, which will be typical for a Huawei dongle in virtual ethernet mode. You can then also use a tool like the Hilink Go application to read out the settings etc.
If you want to use the device in modem manager, the USB mode switcher in the host os has to be disabled or its configuration altered to keep it in serial modem mode.
I’ll probably take a look at using lsusb to figure out more about the USB dongle. The dongle works quite nicely in the hostOS, because it just works as an ethernet interface out of the box, so I don’t want to make it complicated.