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

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to