Comment 3 for bug 1799795

@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.