QMI IPv6 crashes

Dan Williams dcbw at redhat.com
Tue Apr 22 13:44:49 PDT 2014


On Tue, 2014-04-22 at 18:35 +0200, Bjørn Mork wrote:
> Aleksander Morgado <aleksander at aleksander.es> writes:
> > On Tue, Apr 22, 2014 at 10:20 AM, Bjørn Mork <bjorn at mork.no> wrote:
> >
> >> Sorry, but it looks like I'll be unable to test this today. After
> >> surviving all the crazy skiing last week, I ended up with a broken
> >> shoulder after a motorcycle accident on my way to work today. Well,
> >> well...
> >
> >
> > Ufff... get well soon... :/
> 
> Looks like I'm lucky.  Just a broken collarbone, and I managed to avoid
> an operation.  So just wait a few weeks and everything is OK :-)
> 
> The bike looks worse..  A local newspaper was kind enough to publish a
> photo of it:
> http://www.budstikka.no/nyheter/mc-forer-slapp-med-skrubbsar-etter-kollisjon-med-bil-1.8390995

You're lucky!  I'm sure we'd all rather have you in one piece, otherwise
who would debug and fix all these WWAN issues? :)

> Anyway, getting back to topic.  I am not quite sure exactly what to
> test, as usual. Tried to get some info from the MC7710 first:

Basically, test the dcbw/icera-ipv6 branch of ModemManager, possibly
with the dcbw/wwan-ipv6 branch of NetworkManager.

The modems I have never crash just retrieving the settings, but seem to
crash when an address is configured on them and something starts to send
traffic (like the kernel ndisc code).

> bjorn at nemi:~$ mmcli -m 0 
> 
> /org/freedesktop/ModemManager1/Modem/0 (device id '031a79ae23fec4be1c3ef3c0fb8267c44f98899f')
>   -------------------------
>   Hardware |   manufacturer: 'Sierra Wireless, Incorporated'
>            |          model: 'MC7710'
>            |       revision: 'SWI9200X_03.05.24.00ap r5792 carmd-en-10527 2013/05/02 13:35:47'
>            |      supported: 'gsm-umts
>            |                  lte
>            |                  gsm-umts, lte'
>            |        current: 'gsm-umts, lte'
>            |   equipment id: '358178040092316'
>   -------------------------
>   System   |         device: '/sys/devices/pci0000:00/0000:00:1d.7/usb4/4-4'
>            |        drivers: 'qcserial, qmi_wwan'
>            |         plugin: 'Gobi'
>            |   primary port: 'cdc-wdm0'
>            |          ports: 'ttyUSB3 (qcdm), cdc-wdm0 (qmi), cdc-wdm1 (qmi), wwan0 (net), wwan1 (net), ttyUSB6 (at)'
>   -------------------------
>   Numbers  |           own : 'unknown'
>   -------------------------
>   Status   |           lock: 'sim-pin2'
>            | unlock retries: 'sim-pin (3), sim-pin2 (3), sim-puk (10), sim-puk2 (10)'
>            |          state: 'connected'
>            |    power state: 'on'
>            |    access tech: 'lte'
>            | signal quality: '60' (recent)
>   -------------------------
>   Modes    |      supported: 'allowed: 2g, 3g, 4g; preferred: none'
>            |        current: 'allowed: 2g, 3g, 4g; preferred: none'
>   -------------------------
>   Bands    |      supported: 'cdma-bc15-aws, dcs, egsm, pcs, u2100, u900, eutran-i, eutran-iii, eutran-vii, eutran-viii, eutran-xx'
>            |        current: 'cdma-bc15-aws, dcs, egsm, pcs, u2100, u900, eutran-i, eutran-iii, eutran-vii, eutran-viii, eutran-xx'
>   -------------------------
>   IP       |      supported: 'ipv4, ipv6, ipv4v6'
>   -------------------------
>   3GPP     |           imei: '358178040092316'
>            |  enabled locks: 'none'
>            |    operator id: '24201'
>            |  operator name: 'TELENOR'
>            |   subscription: 'provisioned'
>            |   registration: 'home'
>   -------------------------
>   SIM      |           path: '/org/freedesktop/ModemManager1/SIM/0'
> 
>   -------------------------
>   Bearers  |          paths: '/org/freedesktop/ModemManager1/Bearer/0'
> 
> 
> Connecting works fine and reports:
> 
> ModemManager[29310]: <debug> [1398183123.610013] [mm-bearer-qmi.c:464] get_current_settings_ready():  IP Family: IPv6
> ModemManager[29310]: <debug> [1398183123.610041] [mm-bearer-qmi.c:382] get_ipv6_config(): QMI IPv6 Settings:
> ModemManager[29310]: <debug> [1398183123.610104] [mm-bearer-qmi.c:393] get_ipv6_config():     Address: 2a02:2121:1:83c0:9cb4:37ae:a24b:de74/64
> ModemManager[29310]: <debug> [1398183123.610133] [mm-bearer-qmi.c:399] get_ipv6_config():     Gateway: 2a02:2121:1:83c0:1ce0:fced:9cb0:fe1b
> ModemManager[29310]: <debug> [1398183123.610154] [mm-bearer-qmi.c:410] get_ipv6_config():     DNS #1: 2001:4600:4:fff::54
> ModemManager[29310]: <debug> [1398183123.610174] [mm-bearer-qmi.c:421] get_ipv6_config():     DNS #2: 2001:4600:4:1fff::54
> ModemManager[29310]: <debug> [1398183123.610198] [mm-bearer-qmi.c:433] get_ipv6_config():        MTU: 1500
> ModemManager[29310]: <debug> [1398183123.610217] [mm-bearer-qmi.c:490] get_current_settings_ready():    Domains: 
> ModemManager[29310]: <debug> [1398183123.610245] [mm-port.c:93] mm_port_set_connected(): (wwan0): port now connected
> ModemManager[29310]: <debug> [1398183123.610295] [mm-bearer.c:489] connect_ready(): Connected bearer '/org/freedesktop/ModemManager1/Bearer/0'
> ModemManager[29310]: <info>  [1398183123.610481] [mm-iface-modem.c:1392] __iface_modem_update_state_internal(): Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> connected)
> ModemManager[29310]: <info>  [1398183123.611268] [mm-iface-modem-simple.c:602] connection_step(): Simple connect state (8/8): All done

Was this an IPv4v6 context?  Or just an IPv6 one?  I think I was mostly
testing with IPv4v6 to check out dual-stack since that seems to be the
normal use-case for providers here in the US (T-Mobile, Verizon, etc).

> and:
> 
> bjorn at nemi:~$ mmcli -b 0 
> Bearer '/org/freedesktop/ModemManager1/Bearer/0'
>   -------------------------
>   Status             |   connected: 'yes'
>                      |   suspended: 'no'
>                      |   interface: 'wwan0'
>                      |  IP timeout: '20'
>   -------------------------
>   Properties         |         apn: 'telenor.ipv6'
>                      |     roaming: 'allowed'
>                      |     IP type: 'ipv6'
>                      |        user: 'none'
>                      |    password: 'none'
>                      |      number: 'none'
>                      | Rm protocol: 'unknown'
>   -------------------------
>   IPv4 configuration |   method: 'unknown'
>   -------------------------
>   IPv6 configuration |   method: 'static'
>                      |  address: '2a02:2121:1:83c0:9cb4:37ae:a24b:de74'
>                      |   prefix: '64'
>                      |  gateway: '2a02:2121:1:83c0:1ce0:fced:9cb0:fe1b'
>                      |      DNS: '2001:4600:4:fff::54', '2001:4600:4:1fff::54'
>                      |      MTU: '1500'
> 
> 
> Adding this address manually works fine:
> 
> nemi:/usr/local/src/git# ip addr add dev wwan0 2a02:2121:1:83c0:9cb4:37ae:a24b:de74/64
> nemi:/usr/local/src/git# ifconfig wwan0
> wwan0     Link encap:Ethernet  HWaddr 3e:e0:c5:61:2e:7b  
>           inet6 addr: 2a02:2121:1:83c0:9cb4:37ae:a24b:de74/64 Scope:Global
>           BROADCAST MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000 
>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
> 
> 
> Setting the link up triggers a RS and the modem replies with a RA, and
> the kernel autoconfigures another address in addition:
> 
> nemi:/usr/local/src/git# ip link set wwan0 up
> nemi:/usr/local/src/git# ifconfig wwan0
> wwan0     Link encap:Ethernet  HWaddr 3e:e0:c5:61:2e:7b  
>           inet6 addr: 2a02:2121:1:83c0:3ce0:c5ff:fe61:2e7b/64 Scope:Global
>           inet6 addr: 2a02:2121:1:83c0:9cb4:37ae:a24b:de74/64 Scope:Global
>           inet6 addr: fe80::3ce0:c5ff:fe61:2e7b/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:5 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:456 (456.0 B)  TX bytes:830 (830.0 B)
> 
> 
> So far this is just fine and as expected. No crash.
> 
> Adding a route through the announced gw works, and both source addresses
> can be used:
> 
> nemi:/usr/local/src/git# ip route add 2001:67c:21e0::16 via 2a02:2121:1:83c0:1ce0:fced:9cb0:fe1b
> nemi:/usr/local/src/git# ping6 -I 2a02:2121:1:83c0:3ce0:c5ff:fe61:2e7b 2001:67c:21e0::16
> PING 2001:67c:21e0::16(2001:67c:21e0::16) from 2a02:2121:1:83c0:3ce0:c5ff:fe61:2e7b : 56 data bytes
> 64 bytes from 2001:67c:21e0::16: icmp_seq=1 ttl=57 time=302 ms
> 64 bytes from 2001:67c:21e0::16: icmp_seq=2 ttl=54 time=25.0 ms
> 64 bytes from 2001:67c:21e0::16: icmp_seq=3 ttl=54 time=22.7 ms
> ^C
> --- 2001:67c:21e0::16 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2002ms
> rtt min/avg/max/mdev = 22.724/116.905/302.945/131.553 ms
> nemi:/usr/local/src/git# ping6 -I 2a02:2121:1:83c0:9cb4:37ae:a24b:de74 2001:67c:21e0::16
> PING 2001:67c:21e0::16(2001:67c:21e0::16) from 2a02:2121:1:83c0:9cb4:37ae:a24b:de74 : 56 data bytes
> 64 bytes from 2001:67c:21e0::16: icmp_seq=1 ttl=58 time=305 ms
> 64 bytes from 2001:67c:21e0::16: icmp_seq=2 ttl=54 time=20.4 ms
> 64 bytes from 2001:67c:21e0::16: icmp_seq=3 ttl=58 time=21.6 ms
> 64 bytes from 2001:67c:21e0::16: icmp_seq=4 ttl=54 time=20.6 ms
> 64 bytes from 2001:67c:21e0::16: icmp_seq=5 ttl=54 time=23.5 ms
> ^C
> --- 2001:67c:21e0::16 ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4006ms
> rtt min/avg/max/mdev = 20.452/78.416/305.828/113.711 ms
> 
> 
> But I guess I shouldn't let the kernel manage these things, but instead
> test with NM?  It will deal with the RS and neighbour discovery on its
> own, is that right?

It shouldn't matter either way, though I've been doing testing with NM,
which does all the IPv6 addressing in userland.  However, I tested both
static and RA/RS, and both appeared to crash.  My theory based on the
7750 backtrace info was that after adding an address, something sending
a neighbor discovery packets crashes the kernel.  I'll do some more
testing and report.

Dan



More information about the ModemManager-devel mailing list