[network-manager] [modem-manager] Network Manager seems to ignore MTU supplied by Modem Manager

[Eric Stutzenberger]

We are working on bringing up cellular gateways for some of our customers. Cellular networks require the MTU to be honored or the packets are silently dropped without error. At the very least, this is true for Verizon's network.

The behavior I see is that while `modem-manager` provides an appropriate MTU for the connected cellular modem, `network-manager` does not discover this value. As such, `network-manager` does not properly configure a `gsm` network connection and allows packets with a size larger than the allowed MTU to be sent.

Some dbus snippets:

MTU for the cellular device as shown in `modem-manager` via dbus:
dict entry(
   string "mtu"
   variant uint32 1428
)

MTU for the cellular device as shown in `network-manager` via the dbus:
dict entry(
    string "Mtu"
    variant uint32 0
)

According to the network manager documentation, it is possible to set the MTU for a `gsm` connection using the `gsm.mtu` property. However, the version of network manager on UC 16 is behind the current generation of network manager and does not provide this property. In fact, there does not appear to be a way we can set the MTU using the network manager DBus API. The only MTU property available to us is in the Device object and it is a read only property.

We have determined a workaround that is not great: We can set the MTU using `ifconfig` but this is not maintained across reboots. To further complicate the issue, our agent snap is generally started before `modem-manager` has made the cellular modem available to the system. So, we cannot simply set the MTU at boot. Instead, we have to wait a while to ensure the cellular device is available and then set the MTU.

Why doesn't network-manager using the MTU show in modem-manager? Is there a way we can set the MTU for a given device that holds across reboots?

Ideally, network-manager would honor the MTU provided by modem-manager and ensure an appropriate MTU is assigned to connections which use the modem.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

I would say that in general the cellular connection MTU is negotiated:

1. By pppd for modem that use serial connections
2. By ModemManager for MBIM/QMI modems

In case 1) (which is gemalto modem for rigado), you can actually control the MTU using NM, as NM launches pppd:

$ ip l show ppp0
6: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1430 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 3
    link/ppp
$ nmcli c modify pepe ppp.mtu 1000
$ nmcli c down pepe
$ nmcli c up pepe
$ ip l show ppp0
7: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1000 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 3
    link/ppp

For the Quectel modem, which uses QMI, it seems correct to me that you cannot set the MTU permanently in an easy way. But, it is quite surprising that you need to do this. QMI should negotiate this properly, and in fact I have never had problems with MTU sizes in cellular connections. Is this really a problem you are finding? Verizon connections worked fine for me when I tested the modem.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

Also, note that MTU is a read-only property in MM's bearer:

https://www.freedesktop.org/software/ModemManager/api/latest/gdbus-org.freedesktop.ModemManager1.Bearer.html

I think that the property is only known to MM for QMI/MBIM. In principle, the MTU should be a good one as it is negotiated, otherwise something is going wrong somewhere.

[Eric Stutzenberger (estutzenberger)]

@alfonso

The `nmcli` commands provided are useful but we do not have access to the serial console on production units. The `network-manager` slot does not provide access to `nmcli` either. Our only option for configuring things in network manager is through the DBus API and version 1.2.x does not provide a way to configure the MTU.

"But, it is quite surprising that you need to do this. QMI should negotiate this properly, and in fact I have never had problems with MTU sizes in cellular connections. Is this really a problem you are finding?"

We are not surprised at all by this behavior. We have seen it before on past systems, including our Yocto based system. Verizon's network will happily tell you it sent some data, but instead, the network drops the packet somewhere later on. This results in data not making it to servers even though no error is reported. In fact, a current customer is experiencing this exact problem with Verizon. Once we set the MTU for the `gsm` connection (using ifconfig), their data started making it to the server. If you reboot the gateway (which resets the MTU back to 1500 as the default), then the data stops being delivered to their server. If we set the MTU back to 1428 again, then it starts working.

...

Yes, in the description, I pointed out that modem manager provides a MTU property. The fact that is set correctly and that *network-manager* does not use this value when creating the GSM connection is what I think is a bug here. Instead, *network-manager* leaves the MTU at the default of 1500 which is found by running `ifconfig`. *network-manager* never seems to update the MTU for the connection.

[Bob/Paul (ubuntu-launchpad-bobpaul)]

Has this been reported upstream to NetworkManager? We're experiencing this with one of our modems with NetworkManager 1.18.

[Matthias Lüscher (m-luescher)]

We have had the same issue and luckily it got fixed upstream here: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/499