If you have a lte wwan modem connected to your router with proto qmi you will always get a subnet assigend over dhcp from the dhcp server of the modem. This proceed will normaly setup a network route and a default route.
On older modem which uses the proto ppp i always get one IP and so no network route only a default route.
Is it not easier and straight forward to do the same behavior for qmi as for ppp?
The fake subnet is necessary for DHCP. You cannot assign a default route in DHCP(v4) without pointing to a gateway address. And the gateway address must be directly reachable on L2, so you need the gateway and assigned address to be in the same subnet. All this is completely virtual of course, which can be a bit confusing. Except for your adress, the remaining parts of the subnet are probably part of the address pool on the PGW/GGSN. And these addresses, including your "gateway" might be assigned to other users.
But if you drop DHCP, then you certainly can run qmi with just a single address and no network route. Look up the network assigned adress and do something like
ifconfig wwan0 address/32
ifconfig wwan0 -arp
ip route add default dev wwan0
(none of this is an issue for PPP, since IPv4 address assignment is part of IPCP)
thanks for reply and that you recognize my problem.
I do not what to by pass the handling from the default system layers like "netifd" because if the modem will change the IP I will not get informed because no dhcp client is running.
I think about it to add a "bridgemode" option to the dhcp proto handler to replicate the behavior.
If this option is set, only single address with default route to the interface and no network route is set.
What do you think. Is this upstream compatible. Does anyone else need this feature?
I don't think the modem can change address without disconnect+reconnect.
But this is probably part of the problem with the simplified modem management provided by uqmi + netifd. Using DHCP as a workaround for the specific issue that the address can change seems like a horrible hack to me. The real solution is a fully featured modem management application. Look for Aleksanders ModemManager packages.
Note that this problem is not specific to QMI. It is similar for MBIM, NCM or whatever network transport protocol the modem use. And there are plenty of modems which do not support DHCP at all, in particular MBIM modems since Microsoft does not use DHCP over MBIM.
I don't know. But I think "bridgemode" might be a confusing name.
One feature I would like to see implemented for LTE (or 3G) modems is the classical half-bridge (same feature the modem implements): Two-way forwarding of IP packets between two interfaces, completely ignoring L2. But preferably implementing some basic L2 features like DHCP. We should recongnise the fact that LTE/3G modems are L3 only regardless of the current "wrapping". Attempting to treat them as ethernet devices, using e.g. ethernet bridging, will just lead to trouble. If it works at all. Which I don't think it will with the cdc_mbim driver, or the qmi_wwan driver in raw-ip mode. Or even the qmi_wwan driver in 802.3 mode when certain modem firmware bugs are present. We should just don't think of these devices as ethernet devices. Which is another reason I think it is best if we do not depend on DHCP for LTE/3G modems.
Intresting thread, have you guys found a workaround ?
I documented also this bug on another thread with a bit of details on the issue. We see clearly something wrong on the DHCP requests handled by the qmi stack on my side.