Wwan not getting an IP

Hello all -
I have a USB LTE modem (Telit LM960A18) that works great when it’s simply plugged into another device. When it’s plugged into my vyos box, I can get an IP if I use udhcpc -i wwan0.

For some reason, when using the configure shell and I set wwan0 address dhcp, it will not get an ip address.

I have the apn set, and I have the address set to dhcp, but no IP ever shows up when I do a “show interfaces.”

I know I must be missing something simple here, but I have no idea what it may be.
Anyone know where I may be going wrong here?


Hello @reno138
I haven’t had any experience with USB LTE modems on VYOS, but it looks interesting to get any log or debugging information. I saw some user guidance for this modem on his official site, try to follow it

Hello all,

Glad to see VyOS LTE4 wwan development is progressing again! It almost works however:

I can confirm the same problem for both Telit LM940 and a Sierra Wireless MC7455 card.

The LTE modem seems to expect Link layer protocol: ‘raw-ip’ and not the Ethernet type.

root@vyos:~# qmicli --device=/dev/cdc-wdm0 --device-open-proxy --wda-get-data-format
[/dev/cdc-wdm0] Successfully got data format
                   QoS flow header: no
               Link layer protocol: 'raw-ip'
  Uplink data aggregation protocol: 'disabled'
Downlink data aggregation protocol: 'disabled'
                     NDP signature: '0'
Downlink data aggregation max datagrams: '0'
Downlink data aggregation max size: '0'

After starting:

dhclient -4 -nw -cf /var/lib/dhcp/dhclient_wwan0.conf -pf /var/lib/dhcp/dhclient_wwan0.pid -lf /var/lib/dhcp/dhclient_wwan0.leases wwan0

fails with an:

Unsupported device type 65534 for “wwan0”

This was tested using:

Version:          VyOS 1.4-rolling-202111090317
Release train:    sagitta

Built by:         autobuild@vyos.net
Built on:         Tue 09 Nov 2021 03:17 UTC
Build UUID:       65b8318e-dbe2-4856-a090-cefd6713891d
Build commit ID:  ee81272116cd68


interfaces {
    wwan wwan0 {
        address dhcp
        apn internet.access.nl

I suspect that dhclient does not support Link layer protocol: ‘raw-ip’ for IPv4.

Question: Does anyone know how to reconfiger/change firmware a LTE modem cards to change from raw-ip to a different supported format like Ethernet 802.3?
Alternatively: some users switch to a different dhcp client udhcp but that is probably not what Vyos wants to support.

More discussion: debian - DHCP client fails to get IP address (Modem EM7430) - Unix & Linux Stack Exchange

Kinds regards,

Hi all,
didn’t try any of your configs, but all i know is that Data LTE is just a fancy DialUpSerialLine that needs PPP to do all his IP configurations.
At least in my setup with pfsense i use PPP interfaces.
Cheers and good luck

It seems as if VyOS only executes mmcli --modem 0 --simple-connect when bringing up the wwan interface. According to the NetworkManager mailing list this is not enough, since it’s typically NetworkManager’s job to trigger mmcli and then set up the IP address once the connection has been established. You can see the current status, including the assigned IP address, prefix, gateway, DNS by checking the currently connected bearer with mmcli --bearer 0. When I look through the source code of VyOS there is no handling of this information happening anywhere. The “dhcp” option in the configuration is only used to decide what type of IP address (4/6) to request from the cell provider.


Bumping this up to see if there has been any progress. I have an EM12G working with VyOS 1.3, it is detected successfully and the appropriate interfaces are created, however an IP address is never assigned.

As @ahovda said above, it looks like VyOS is not finishing the configuration. Executing mmcli --bearer 0 shows that the IP info is successfully obtained from the network, but it never gets assigned to the interface.

I can make the interface work by manually applying this IP to the interface, but of course this will not work for non-static IPs.

Any thoughts?

Just bumping this up. I was able to get this to work by building vyos with network-manager, which will auto-assign the IP when the cellular interface comes up. But it’s not a great solution because NM then has full control of the interface, and in my case it stops load-balacing from working correctly.

Any further ideas on how we might get vyos to obtain and assign the IP after modem-manager does its thing?

Have you found a solution yet?

Kind of. My solution was to build VyOS with network-manager included, and let it manage only the wwan interface. This works, the IP gets assigned to wwan0, but it’s pretty hacky and I wish there was a better solution.

The problem is that dhclient does not support raw-ip mode and my WWAN modem only supports this mode. udhcpd does work, but it is not used by VyOS.

Would love some VyOS eyes on this to see what could be done.

Like a few here, my WWAN modem doesn’t get an ip because it only supports RawIP mode. Because I got this for loadbalancing, it took a bit to figure out. RawIP generally uses interface routing, so I did this first off.

# show protocols static route
 dhcp-interface eth0
 interface wwan0 {
     distance 215

Which sorted out actual routes and getting around the loadbalancing issues. Don’t ask me how it works, it just does… haha.

Actual IP though on the interface? I toyed with installing networkmanager, but as mentioned above, that breaks loadbalancing which I wanted. So I did this instead.

# Check status of the interface

wwanip=$(ip -f inet addr show wwan0 | sed -En -e 's/.*inet ([0-9.]+).*/\1/p')
wipmask=$(ip -f inet addr show wwan0 | awk '/inet / {print $2}')

bearer=$(mmcli -m 0 --output-keyvalue | grep modem.generic.bearers.value |awk '{print $3}' |cut -d "/" -f6)
bearerip=$(mmcli -b $bearer --output-keyvalue |grep bearer.ipv4-config.address | awk '{print $3}')
bearermask=$(mmcli -b $bearer --output-keyvalue |grep bearer.ipv4-config.prefix | awk '{print $3}')

if [ "$wwanip" != "$bearerip" ]
        echo "Data is different"
        /usr/sbin/ip addr del $wipmask dev wwan0
        /usr/sbin/ip addr add $bearerip/$bearermask dev wwan0
    echo "Data are equal"

Set that to run via cron every 5 minutes. What I’ve found, at least with mine, is that once I start pushing a ping through the loadbalancer, it holds the bearer ip for days on end. So all working. It’s hacky, and ugly, but it works at least until we get scripts that read mmcli and implement the IP

1 Like

Apparently work is underway in ISC dhcp to support raw-ip (Draft: Resolve "Add support for raw IP interface type" (!67) · Merge requests · ISC Open Source Projects / dhcp · GitLab) but it seems stuck atm.

Unless VyOS devs plan on utilizing dbus to control ModemManager they could instead consider using qmicli directly to interface with the modem instead of ModemManager. VyOS then needs to do something similar to what the qmi-network script is doing when plumbing and tearing down the connection: libqmi/qmi-network.in at master · E3V3A/libqmi · GitHub

root@oslfirewall3:~# qmi-network /dev/cdc-wdm0 start
Profile at '/etc/qmi-network.conf' not found...
Checking data format with 'qmicli -d /dev/cdc-wdm0 --wda-get-data-format '...
Device link layer protocol retrieved: raw-ip
Getting expected data format with 'qmicli -d /dev/cdc-wdm0 --get-expected-data-format'...
Expected link layer protocol retrieved: raw-ip
Device and kernel link layer protocol match: raw-ip
Starting network with 'qmicli -d /dev/cdc-wdm0 --wds-start-network=  --client-no-release-cid '...
Saving state at /tmp/qmi-network-state-cdc-wdm0... (CID: 1)
Saving state at /tmp/qmi-network-state-cdc-wdm0... (PDH: 3783580864)
Network started successfully

root@oslfirewall3:~# qmicli -p -d /dev/cdc-wdm0 --wds-get-current-settings
[/dev/cdc-wdm0] Current settings retrieved:
           IP Family: IPv4
        IPv4 address: x.x.x.x
    IPv4 subnet mask:
IPv4 gateway address: x.x.x.x
    IPv4 primary DNS: x.x.x.x
  IPv4 secondary DNS: x.x.x.x
                 MTU: 1500
             Domains: none

Still requires scripting or raw-ip dhcp support to assign IP to the interface.

Are you finding that this works reliably? Can you test what happens if you lose upstream connectivity on the primary provider (eth0) but don’t actually lose link? Does it still failover OK?

Yeah it fails over. Basically in the interface health for it, i was setting test 1 to and test 2 to, with the primary link (dhcp from my ISP) test 1 set to their time server (because their BNG deprio’s ping), and test 2 to their mail server.

Works fine. The only thing I’ve had happen is occasionally wwan will time out, but for the most part, it flicks back and forth between primary/secondary ok.

Like I said, it’s hacky and ugly, but best I can do at this point in time, short of hanging my qmi off a raspberry pi or something and running that way.

Would you mind letting me know which version you are on, and maybe uploading your santized config? I just can’t seem to get wan load balancing to work with wwan. Would appreciate it.