NDISDUP+wwan for Huawei devices using the new 'huawei_cdc_ncm' driver
Bjørn Mork
bjorn at mork.no
Fri Feb 28 05:01:12 PST 2014
Bjørn Mork <bjorn at mork.no> writes:
> Bjørn Mork <bjorn at mork.no> writes:
>
>>> Also note that only 36xx and 55xx modules have *E2IPCFG; the 3507 does
>>> not. We didn't bother with E2IPCFG in ModemManager because the modules
>>> support DHCP. Unfortunately there's nobody from ericsson around anymore
>>> to tell us about IPv6...
>>
>> I have a F3507g and H5321gw (NCM only and not upgradable) too. Will
>> test them if/when I can find the time.
>
> I am probably doing something wrong. I have the same problem with both
> the F3507g and the H5321gw: No RAs, no DHCPv6, and AT*E2IPCFG only
> gives a LL address (only on the H5321gw of course - the F3507g doesn't
> support this command as you noted). And I cannot find any way to use
> this LL address.
Additional data point here. As I now temporarily have access to a MBIM
enabled H5321gw, I tested IPv6 there as well. And whaddyknow, it
gives us only a LL address in MBIM mode as well:
ModemManager[8775]: [/dev/cdc-wdm4] Received message...
>>>>>> RAW:
>>>>>> length = 160
>>>>>> data = 03:00:00:80:A0:00:00:00:20:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:0F:00:00:00:00:00:00:00:70:00:00:00:00:00:00:00:00:00:00:00:0D:00:00:00:00:00:00:00:00:00:00:00:01:00:00:00:3C:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:02:00:00:00:50:00:00:00:00:00:00:00:DC:05:00:00:40:00:00:00:FE:80:00:00:00:00:00:00:00:00:00:0B:FF:B6:93:01:20:01:46:00:00:04:0F:FF:00:00:00:00:00:00:00:54:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
ModemManager[8775]: [/dev/cdc-wdm4] Received message (translated)...
>>>>>> Header:
>>>>>> length = 160
>>>>>> type = command-done (0x80000003)
>>>>>> transaction = 32
>>>>>> Fragment header:
>>>>>> total = 1
>>>>>> current = 0
>>>>>> Contents:
>>>>>> status error = 'None' (0x00000000)
>>>>>> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df)
>>>>>> cid = 'ip-configuration' (0x0000000f)
ModemManager[8775]: <debug> [1393589003.121209] [mm-bearer-mbim.c:211] ip_configuration_query_ready(): IPv4 configuration available: 'none'
ModemManager[8775]: <debug> [1393589003.121691] [mm-bearer-mbim.c:255] ip_configuration_query_ready(): IPv6 configuration available: 'address, dns, mtu'
ModemManager[8775]: <debug> [1393589003.122253] [mm-bearer-mbim.c:261] ip_configuration_query_ready(): IP addresses (1)
ModemManager[8775]: <debug> [1393589003.122763] [mm-bearer-mbim.c:265] ip_configuration_query_ready(): IP [0]: 'fe80::b:ffb6:9301/64'
ModemManager[8775]: <debug> [1393589003.123081] [mm-bearer-mbim.c:282] ip_configuration_query_ready(): DNS addresses (2)
ModemManager[8775]: <debug> [1393589003.123405] [mm-bearer-mbim.c:286] ip_configuration_query_ready(): DNS [0]: '2001:4600:4:fff::54'
ModemManager[8775]: <debug> [1393589003.123727] [mm-bearer-mbim.c:286] ip_configuration_query_ready(): DNS [1]: '::'
ModemManager[8775]: <debug> [1393589003.124220] [mm-bearer-mbim.c:293] ip_configuration_query_ready(): MTU: '1500'
ModemManager[8775]: <debug> [1393589003.124624] [mm-port.c:149] mm_port_set_connected(): (wwan3): port now connected
Really odd. The DNS server list is also strange. The provider gives me
2 servers, but as you can see one them is just zeroes instead of the
expected ('2001:4600:4:1fff::54'). And I am still not able to get any
reply to any RS.
But then I tried connecting while the interface was up, so that I could
snoop whatever packets were being received on connect. That was
interesting, because we *do* get a couple of RAs like this one then:
Internet Protocol Version 6, Src: fe80::215:e0ff:feec:101 (fe80::215:e0ff:feec:101), Dst: ff02::1 (ff02::1)
0110 .... = Version: 6
[0110 .... = This field makes the filter "ip.version == 6" possible: 6]
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
.... 0000 00.. .... .... .... .... .... = Differentiated Services Field: Default (0x00000000)
.... .... ..0. .... .... .... .... .... = ECN-Capable Transport (ECT): Not set
.... .... ...0 .... .... .... .... .... = ECN-CE: Not set
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 56
Next header: ICMPv6 (58)
Hop limit: 255
Source: fe80::215:e0ff:feec:101 (fe80::215:e0ff:feec:101)
[Source SA MAC: 00:15:e0:ec:01:01 (00:15:e0:ec:01:01)]
Destination: ff02::1 (ff02::1)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0x1935 [correct]
Cur hop limit: 255
Flags: 0x40
0... .... = Managed address configuration: Not set
.1.. .... = Other configuration: Set
..0. .... = Home Agent: Not set
...0 0... = Prf (Default Router Preference): Medium (0)
.... .0.. = Proxy: Not set
.... ..0. = Reserved: 0
Router lifetime (s): 65535
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (Prefix information : 2a02:2121:1:f23::/64)
Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0x40
0... .... = On-link flag(L): Not set
.1.. .... = Autonomous address-configuration flag(A): Set
..0. .... = Router address flag(R): Not set
...0 0000 = Reserved: 0
Valid Lifetime: 4294967295 (Infinity)
Preferred Lifetime: 4294967295 (Infinity)
Reserved
Prefix: 2a02:2121:1:f23:: (2a02:2121:1:f23::)
ICMPv6 Option (Source link-layer address : 00:15:e0:ec:01:01)
Type: Source link-layer address (1)
Length: 1 (8 bytes)
Link-layer address: 00:15:e0:ec:01:01 (00:15:e0:ec:01:01)
Anyone spotting the obvious problem with that? No? Well, compare it
with e.g. the one sent by the Sierra Wireless MC7710:
Internet Protocol Version 6, Src: fe80::ecf6:f053:4c92:b473 (fe80::ecf6:f053:4c92:b473), Dst: ff02::1 (ff02::1)
0110 .... = Version: 6
[0110 .... = This field makes the filter "ip.version == 6" possible: 6]
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
.... 0000 00.. .... .... .... .... .... = Differentiated Services Field: Default (0x00000000)
.... .... ..0. .... .... .... .... .... = ECN-Capable Transport (ECT): Not set
.... .... ...0 .... .... .... .... .... = ECN-CE: Not set
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 64
Next header: ICMPv6 (58)
Hop limit: 255
Source: fe80::ecf6:f053:4c92:b473 (fe80::ecf6:f053:4c92:b473)
Destination: ff02::1 (ff02::1)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0x738e [correct]
Cur hop limit: 255
Flags: 0x00
0... .... = Managed address configuration: Not set
.0.. .... = Other configuration: Not set
..0. .... = Home Agent: Not set
...0 0... = Prf (Default Router Preference): Medium (0)
.... .0.. = Proxy: Not set
.... ..0. = Reserved: 0
Router lifetime (s): 65535
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (Source link-layer address : 00:00:00:00:00:00)
Type: Source link-layer address (1)
Length: 1 (8 bytes)
Link-layer address: 00:00:00:00:00:00 (00:00:00:00:00:00)
ICMPv6 Option (MTU : 1500)
Type: MTU (5)
Length: 1 (8 bytes)
Reserved
MTU: 1500
ICMPv6 Option (Prefix information : 2a02:2121:1:9059::/64)
Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0xc0
1... .... = On-link flag(L): Set
.1.. .... = Autonomous address-configuration flag(A): Set
..0. .... = Router address flag(R): Not set
...0 0000 = Reserved: 0
Valid Lifetime: 4294967295 (Infinity)
Preferred Lifetime: 4294967295 (Infinity)
Reserved
Prefix: 2a02:2121:1:9059:: (2a02:2121:1:9059::)
Forget about the link layer and MTU options. They don't matter. The
important difference is the On-link flag. Without this, the prefix
isn't going to be used for SLAAC on this interface. At least not by the
Linux kernel. Is this correct? I cannot seem to read that behaviour out
of RFC 4862.
Anyway, manually configuring an address from the prefix and setting the
default route to the src address of the RA makes the H5321gw too work
with IPv6:
nemi:/home/bjorn# ip addr add 2a02:2121:1:f23::f00 dev wwan3
nemi:/home/bjorn# ip -6 route add default via fe80::215:e0ff:feec:101 dev wwan3
nemi:/home/bjorn# traceroute6 vg.no
traceroute to vg.no (2001:67c:21e0::16) from 2a02:2121:1:f23::f00, port 33434, from port 56609, 30 hops max, 60 bytes packets
1 2a02:2121:1:f23:0:38:c499:9740 (2a02:2121:1:f23:0:38:c499:9740) 726.721 ms 168.416 ms 209.552 ms
2 2a02:2120::1000:0:0:2 (2a02:2120::1000:0:0:2) 248.303 ms 299.426 ms 44.099 ms
3 2a02:2120::1000:0:0:5 (2a02:2120::1000:0:0:5) 439.290 ms 42.024 ms 40.960 ms
4 ti280819892j580-vlan51.ti.telenor.net (2001:4600:a:101::56) 44.085 ms 42.728 ms 36.272 ms
5 ti0001a400-xe2-1-1-51.ti.telenor.net (2001:4600:5:100::d) 42.800 ms 48.118 ms 38.712 ms
6 xe-2-3-0.cr1-osl2.n.bitbit.net (2001:4600:9:200::2) 36.191 ms 38.770 ms 39.581 ms
7 vlan-9.cs1-osl2.n.bitbit.net (2a02:c0:1:1::7) 42.509 ms 49.341 ms 36.817 ms
8 www.vg.no (2001:67c:21e0::16) 41.294 ms 36.837 ms 53.003 ms
But yuck! This is not straight forward.
Also note that the H5321gw sets the "Other configuration" flag, which
looks promising. But I can't get any replies to any DHCPv6 Solicit or
Info-Request so it doesn't seem to work properly.
Bjørn
More information about the ModemManager-devel
mailing list