NDISDUP+wwan for Huawei devices using the new 'huawei_cdc_ncm' driver
Dan Williams
dcbw at redhat.com
Fri Feb 28 08:28:15 PST 2014
On Fri, 2014-02-28 at 14:01 +0100, Bjørn Mork wrote:
> 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:
Icera devices do the same with the %IPDPADDR command, they give you a
link-local address and *one* DNS server (and I know T-Mobile returns
two, because that's what QMI hands back to us), and then presumably you
need to use SLAAC on the net port to get the real prefix.
> 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
I've got a dcbw/icera-ipv6 branch going that mostly fixes Icera devices,
but adds some generic IPv6 fixes too. I changed the Icera and the MBIM
bearer code to return method "DHCP" (eg, SLAAC) when the only address
retrieved was a link-local one, since clearly that's what clients need
to do rather than assigning the link-local address and calling it done.
> 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.
Same for me with DNS servers on Icera.
> 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:
[snip]
> 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.
That seems bizarre... Maybe it's a firmware quirk and clients just have
to assume that WWAN devices return a fault on-link? I mean, assuming
this was all standards-compliant and firmware didn't suck, when would
you get a *legitimate* on-link=0 advertisement on a WWAN network?
Dan
> 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
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
More information about the ModemManager-devel
mailing list