[systemd-devel] Mobile broadband modems support in systemd-networkd
Bruce A. Johnson
bjohnson at blueridgenetworks.com
Fri Aug 20 20:01:00 UTC 2021
Mantas' and Ulrich's responses gave me insights to dig more. Neither the
mbim-cli nor ModemManager sets the IP address on the interface, and some
kind of agent needs to do that.
When I start the connection using ModemManager, I am able to retrieve
addresses that mmcli displays like the below. If I manually assign the
IPv4 address to the interface and set up the route, I'm able to send
traffic to and from other nodes. I haven't yet looked into how
ModemManager communicates this info to NetworkManager or how things like
a change of address are handled. As I see it, these addresses aren't
really static, because the IPv6 addresses are different from one mobile
session to the next.
> --------------------------------
> IPv4 configuration | method: static
> | address: 6.147.139.XXX
> | prefix: 30
> | gateway: 6.147.139.YYY
> | dns: 10.177.0.34, 10.177.0.210
> | mtu: 1500
> --------------------------------
> IPv6 configuration | method: static
> | address: 2607:fb90:648f:2648:a5b3:8146:95aa:2955
> | prefix: 64
> | gateway: 2607:fb90:648f:2648:68d8:1c67:a27:b968
> | dns: fd00:976a::9, fd00:976a::10
> | mtu: 1500
> --------------------------------
I took a closer look at what's going on with systemd-networkd, and I
found whether I use ModemManager or mbim-cli to connect to the mobile
network, the .network file will be processed, but _only after I restart
systemd-networkd_. When it is processed, the only address the interface
gets is an IPv6 address, and it doesn't match the one in the
ModemManager message above. I'm guessing that T-Mobile isn't providing
DHCP for IPv4, and probably with good reason.
> [root at url-000db95362a6:~]# ip addr show wwan0
> 6: wwan0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
> pfifo_fast state UNKNOWN group default qlen 1000
> link/ether 52:95:20:b7:93:0f brd ff:ff:ff:ff:ff:ff
> inet6 2607:fb90:648f:2648:5095:20ff:feb7:930f/64 scope global
> mngtmpaddr noprefixroute
> valid_lft forever preferred_lft forever
> inet6 fe80::5095:20ff:feb7:930f/64 scope link
> valid_lft forever preferred_lft forever
> [root at url-000db95362a6:~]# ip -6 route
> ::1 dev lo proto kernel metric 256 pref medium
> 2607:fb90:648f:2648::/64 dev wwan0 proto ra metric 1024 pref medium
> fe80::/64 dev wwan0 proto kernel metric 256 pref medium
> ff00::/8 dev wwan0 metric 256 pref medium
> default via fe80::68d8:1c67:a27:b968 dev wwan0 proto ra metric 1024
> expires 65524sec mtu 1500 pref medium
At this point, I have a usable IP(v6) connection managed by
systemd-networkd, but I can't see any indication that I'm getting DNS
information. This could be that the only DNS tools I know of on my box
are nslookup from Busybox and the gethostbyname() call in Python. Both
are returning ESRCH.
My .network file for the interface looks like this:
> [Match]
> Name=wwan0
>
> [Network]
> Description=WAN connection on wwan0
> DHCP=yes
> IPv6AcceptRA=true
>
> [DHCP]
> UseDNS=yes
> UseNTP=no
> SendHostname=no
> RouteMetric=0
>
> [IPv6AcceptRA]
> UseDNS=true
Is there something more that I need to add to get DNS addresses via the
IPv6 router solicitation/advertisement mechanism, or does it appear that
T-Mobile isn't providing DNS addresses except via the klunky method
exposed by ModemManager?
Bruce A. Johnson | Firmware Engineer
Blue Ridge Networks, Inc.
14120 Parke Long Court Suite 103 | Chantilly, VA 20151
Main: 1.800.722.1168 | Direct: 703-633-7332
http://www.blueridgenetworks.com
OpenPGP key ID: 296D1CD6F2B84CABhttps://keys.openpgp.org/
On 20/08/2021 03:15, Ulrich Windl wrote:
> Isn't the trick that the WIFI driver or kernel doe most of the magic
> required to make WIFI work, while a modem driver typically does not
> know much about the modem, i.e. a cellular modem requires some
> "special treatment".
> Dumb question: Does it work without systemd (i.e..: Do yoiu hgave some code that does all that handling)?
On 20/08/2021 05:51, Mantas Mikulėnas wrote:
>
> Wouldn't e.g. `mbimcli` configure IP on its own?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20210820/9af19e53/attachment.sig>
More information about the systemd-devel
mailing list