Thomas Schäfer <tschae...@t-online.de> writes: > Am Freitag, 18. Dezember 2015, 21:51:42 schrieb Bjørn Mork: > >> Just FYI: I ended up with an automated random address, which will be >> stable for the lifetime of the interface. This has now been accepted >> into net-next, so SLAAC will be in place along with the qmi raw-ip >> support in v4.5. > > > It is nice to see the support of raw ip in kernel 4.5. > > Now my questions are: > > What are the next steps in libqmi, MM and NM? > > How to make the address/DNS-settings? > > in-band - dhcp/slaac > or > out-band via bearer-information? > > To bypass some commands of qmi/mm/nm works for tests, but this is far away > for > daily use "out of the box". > > Where should I focus my test activities?
That's up to you to decide :) Regarding the dhcp support: It would be nice to see a set of DHCP(v6) utilities which were somewhat more agnostic wrt interface type. And that's a completely generic wish, independently of the current wwan/lte modem support. All DHCPv6 clients should be expected to support ppp interfaces for example. For DHCPv6 there is absolutely no reason whatsoever to care about interface type. But some clients will still refuse to run on anything but ethernet. Go figure: nemi:/tmp# echo Y >/sys/class/net/wwan0/qmi/raw_ip nemi:/tmp# ifconfig wwan0 up nemi:/tmp# ifconfig wwan0 wwan0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet6 addr: fe80::7f1c:9e91:8e04:70b2/64 Scope:Link inet6 addr: 2a02:2121:86:891:d33:30fa:222c:3628/64 Scope:Global UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:1 errors:0 dropped:0 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:104 (104.0 B) TX bytes:696 (696.0 B) nemi:/tmp# dhclient -d -S wwan0 Internet Systems Consortium DHCP Client 4.3.1 Copyright 2004-2014 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Unsupported device type 65534 for "wwan0" If you think you have received this message due to a bug rather than a configuration issue please read the section on submitting bugs on either our web page at www.isc.org or in the README file before submitting a bug. These pages explain the proper process and the information we find helpful for debugging.. exiting. Luckily there are better choices availabe. The Wide DHCPv6 client works on any type of IPv6 interface: nemi:/tmp# dhcp6c -fDi wwan0 Dec/19/2015 17:32:33: get_duid: extracted an existing DUID from /var/lib/dhcpv6/dhcp6c_duid: 00:01:00:01:1e:08:2b:25:00:21:86:a3:25:7d Dec/19/2015 17:32:33: dhcp6_reset_timer: reset a timer on wwan0, state=INIT, timeo=0, retrans=731 Dec/19/2015 17:32:34: client6_send: a new XID (67c25c) is generated Dec/19/2015 17:32:34: copy_option: set client ID (len 14) Dec/19/2015 17:32:34: copy_option: set elapsed time (len 2) Dec/19/2015 17:32:34: client6_send: send information request to ff02::1:2%wwan0 Dec/19/2015 17:32:34: dhcp6_reset_timer: reset a timer on wwan0, state=INFOREQ, timeo=0, retrans=900 Dec/19/2015 17:32:34: client6_recv: receive reply from fe80::5dc:b41:f9a3:46f8%wwan0 on wwan0 Dec/19/2015 17:32:34: dhcp6_get_options: get DHCP option client ID, len 14 Dec/19/2015 17:32:34: DUID: 00:01:00:01:1e:08:2b:25:00:21:86:a3:25:7d Dec/19/2015 17:32:34: dhcp6_get_options: get DHCP option server ID, len 10 Dec/19/2015 17:32:34: DUID: 00:03:00:01:02:50:f3:00:01:00 Dec/19/2015 17:32:34: dhcp6_remove_event: removing an event on wwan0, state=INFOREQ Dec/19/2015 17:32:34: client6_recvreply: got an expected reply, sleeping. Dec/19/2015 17:32:34: check_exit: exiting And no, the above is not faked: The MC7455 supports DHCPv6 :) And it uses an ethernet DUID-LL, for whatever reason. A with a non-unique local address, just to be on the safe side. You might wonder where Qualcomm gets their firmware developers... There is no reason to suspect any of them for wasting time on RFCs ;) Well, whatever. It will probably work most of the time. But if you ever want an example of a BAD choice of DUID, there you have it. The above shows that the Wide DHCPv6 client also has its share of problems: It does not request DNS servers by default in 'information' mode. Creating a config file works around this problem: nemi:/tmp# dhcp6c -fDc /tmp/dhcp6c.conf wwan0 Dec/19/2015 17:32:38: get_duid: extracted an existing DUID from /var/lib/dhcpv6/dhcp6c_duid: 00:01:00:01:1e:08:2b:25:00:21:86:a3:25:7d Dec/19/2015 17:32:38: cfdebug_print: <3>[interface] (9) Dec/19/2015 17:32:38: cfdebug_print: <5>[wwan0] (5) Dec/19/2015 17:32:38: cfdebug_print: <3>begin of closure [{] (1) Dec/19/2015 17:32:38: cfdebug_print: <3>[information-only] (16) Dec/19/2015 17:32:38: cfdebug_print: <3>end of sentence [;] (1) Dec/19/2015 17:32:38: cfdebug_print: <3>[request] (7) Dec/19/2015 17:32:38: cfdebug_print: <3>[domain-name-servers] (19) Dec/19/2015 17:32:38: cfdebug_print: <3>end of sentence [;] (1) Dec/19/2015 17:32:38: cfdebug_print: <3>[request] (7) Dec/19/2015 17:32:38: cfdebug_print: <3>[domain-name] (11) Dec/19/2015 17:32:38: cfdebug_print: <3>end of sentence [;] (1) Dec/19/2015 17:32:38: cfdebug_print: <3>[script] (6) Dec/19/2015 17:32:38: cfdebug_print: <3>["/usr/bin/env"] (14) Dec/19/2015 17:32:38: cfdebug_print: <3>end of sentence [;] (1) Dec/19/2015 17:32:38: cfdebug_print: <3>end of closure [}] (1) Dec/19/2015 17:32:38: cfdebug_print: <3>end of sentence [;] (1) Dec/19/2015 17:32:38: configure_pool: called Dec/19/2015 17:32:38: clear_poolconf: called Dec/19/2015 17:32:38: dhcp6_reset_timer: reset a timer on wwan0, state=INIT, timeo=0, retrans=728 Dec/19/2015 17:32:39: client6_send: a new XID (c3242f) is generated Dec/19/2015 17:32:39: copy_option: set client ID (len 14) Dec/19/2015 17:32:39: copy_option: set elapsed time (len 2) Dec/19/2015 17:32:39: copy_option: set option request (len 4) Dec/19/2015 17:32:39: client6_send: send information request to ff02::1:2%wwan0 Dec/19/2015 17:32:39: dhcp6_reset_timer: reset a timer on wwan0, state=INFOREQ, timeo=0, retrans=1020 Dec/19/2015 17:32:39: client6_recv: receive reply from fe80::5dc:b41:f9a3:46f8%wwan0 on wwan0 Dec/19/2015 17:32:39: dhcp6_get_options: get DHCP option client ID, len 14 Dec/19/2015 17:32:39: DUID: 00:01:00:01:1e:08:2b:25:00:21:86:a3:25:7d Dec/19/2015 17:32:39: dhcp6_get_options: get DHCP option DNS, len 32 Dec/19/2015 17:32:39: dhcp6_get_options: get DHCP option server ID, len 10 Dec/19/2015 17:32:39: DUID: 00:03:00:01:02:50:f3:00:01:00 Dec/19/2015 17:32:39: info_printf: nameserver[0] 2001:4600:4:fff::52 Dec/19/2015 17:32:39: info_printf: nameserver[1] 2001:4600:4:1fff::52 Dec/19/2015 17:32:39: client6_recvreply: executes /usr/bin/env REASON=NBI new_domain_name_servers=2001:4600:4:fff::52 2001:4600:4:1fff::52 Dec/19/2015 17:32:39: client6_script: script "/usr/bin/env" terminated Dec/19/2015 17:32:39: dhcp6_remove_event: removing an event on wwan0, state=INFOREQ Dec/19/2015 17:32:39: client6_recvreply: got an expected reply, sleeping. So DHCPv6 is supportable with existing software. But tying it all together will probably need more work, as you indicate. This is usable for testing only at the moment. And DHCP support is even more complex. DHCP clients must know how to handle (add/remove/parse) L2 headers. Or lack of headers in this case. I don't know of any client supporting that at the moment. But it should be easier than any other L2 interface type support, since all you need to do is drop the L2 header adding/removing/parsing. So it is tempting to say that QMI modems are best configured with QMI. But one interesting issue to be aware of there, is that the IPv6 interface ID seems to be generated on the fly, and will change with every request. Here are two consequetive requests (notice that the /64 prefix is the same): bjorn@nemi:~$ qmicli -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=35 --wds-get-current-settings [/dev/cdc-wdm0] Current settings retrieved: IP Family: IPv6 IPv6 address: 2a02:2121:86:891:a434:13cc:f516:4e6c/64 IPv6 gateway address: 2a02:2121:86:891:5dc:b41:f9a3:46f8/64 IPv6 primary DNS: 2001:4600:4:fff::52 IPv6 secondary DNS: 2001:4600:4:1fff::52 MTU: 1500 Domains: none [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '35' bjorn@nemi:~$ qmicli -d /dev/cdc-wdm0 --client-no-release-cid --client-cid=35 --wds-get-current-settings [/dev/cdc-wdm0] Current settings retrieved: IP Family: IPv6 IPv6 address: 2a02:2121:86:891:50a7:fb96:653:c4ec/64 IPv6 gateway address: 2a02:2121:86:891:5dc:b41:f9a3:46f8/64 IPv6 primary DNS: 2001:4600:4:fff::52 IPv6 secondary DNS: 2001:4600:4:1fff::52 MTU: 1500 Domains: none [/dev/cdc-wdm0] Client ID not released: Service: 'wds' CID: '35' The gateway address is stable, although I don't see the point. There is nothing responding to that address, so it's just a dummy. My proposal would be to use this only to extract the prefix, select your own interface ID using whatever scheme you like, and just set any routes pointing to the interface. It's a P-t-P interface with no L2 headers, so any "gateway address" is pretty pointless. Bjørn _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list