GNOME.org
 

Re: MC 7304 ipv4v6 - raw-ip in qmi/mm/nm

Thomas Schäfer <tschaefer 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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]