Bjørn Mork <bjorn@xxxxxxx> writes:
> And I still haven't found out how to do a dual stack connection. The
> second QMI_WDS_START_NETWORK_INTERFACE fails with QMI_ERR_POLICY_MISMATCH
That one was simple: "Do as Windows does, don't try to be smart"
Turns out that doing "start net" with a IP family TLV will work for
starting either an IPv4 session or an IPv6 session, but not for dual
stack. But doing as Dan snooped from his Windows driver works:
WDS/Set IP Family (to IPv4, using client ID 0x03)
WDS/Start Net (using client ID 0x03)
WDS/Set IP Family (to IPv6, using client ID 0x04)
WDS/Start Net (using client ID 0x04)
So I now have one IPv4 session with client ID 0x2d:
<= QMUX Header:
<= len: 0x008f
<= sender: 0x80
<= svc: 0x01
<= cid: 0x2d
<= QMI Header:
<= Flags: 0x02
<= TXN: 0x0006
<= Cmd: 0x002d
<= Size: 0x0083
<= [0x02] ( 4) 00 00 00 00 SUCCESS - QMI_ERR_NONE
<= [0x10] ( 8) 70 72 6f 66 69 6c 65 31 profile1
<= [0x11] ( 1) 03 PDP-IPV4V6
<= [0x14] (14) 74 64 74 2e 69 70 76 34 76 36 2e 70 67 77 tdt.ipv4v6.pgw
<= [0x15] ( 4) 04 70 d5 c1 193.213.112.4
<= [0x16] ( 4) c6 0f 43 82 130.67.15.198
<= [0x17] (33) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .................................
<= [0x1d] ( 1) 00 .
<= [0x1e] ( 4) 68 03 10 4d 77.16.3.104
<= [0x1f] ( 2) 00 01 ..
<= [0x20] ( 4) 69 03 10 4d 77.16.3.105
<= [0x21] ( 4) fc ff ff ff 255.255.255.252
<= [0x22] ( 1) 00 .
<= [0x23] ( 1) 00 .
<= [0x24] ( 1) 00 .
and one IPv6 session with client ID 0x2e:
<= QMUX Header:
<= len: 0x00ba
<= sender: 0x80
<= svc: 0x01
<= cid: 0x2e
<= QMI Header:
<= Flags: 0x02
<= TXN: 0x0006
<= Cmd: 0x002d
<= Size: 0x00ae
<= [0x02] ( 4) 00 00 00 00 SUCCESS - QMI_ERR_NONE
<= [0x10] ( 8) 70 72 6f 66 69 6c 65 31 profile1
<= [0x11] ( 1) 03 PDP-IPV4V6
<= [0x14] (14) 74 64 74 2e 69 70 76 34 76 36 2e 70 67 77 tdt.ipv4v6.pgw
<= [0x17] (33) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .................................
<= [0x1d] ( 1) 00 .
<= [0x1f] ( 2) 00 01 ..
<= [0x22] ( 1) 00 .
<= [0x24] ( 1) 00 .
<= [0x25] (17) 2a 02 21 21 00 00 00 01 3c 4b 7d 6e fe cc 1d 26 40 2a02:2121:0:1:3c4b:7d6e:fecc:1d26/64
<= [0x26] (17) 2a 02 21 21 00 00 00 01 70 f1 7b 7a a8 83 88 c8 40 2a02:2121:0:1:70f1:7b7a:a883:88c8/64
<= [0x27] (16) 20 01 46 00 00 04 00 00 00 00 00 00 00 01 00 53 2001:4600:4::1:53
<= [0x28] (16) 20 01 46 00 00 04 10 00 00 00 00 00 00 01 00 53 2001:4600:4:1000::1:53
<= [0x2e] ( 1) 00 .
resulting in an autoconfigured (DHCP for IPv4 and SLAAC for IPv6) dual
IP stack ethernet interface:
bjorn@nemi:~$ ifconfig wwan1
wwan1 Link encap:Ethernet HWaddr ba:2d:da:84:a6:ad
inet addr:77.16.3.104 Bcast:77.16.3.111 Mask:255.255.255.240
inet6 addr: 2a02:2121:0:1:b82d:daff:fe84:a6ad/64 Scope:Global
inet6 addr: fe80::b82d:daff:fe84:a6ad/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:12870 errors:0 dropped:0 overruns:0 frame:0
TX packets:8135 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:17573627 (16.7 MiB) TX bytes:611031 (596.7 KiB)
But the headers of the received IPv6 packets are even weirder than
before. They do now come with the expected 14 extra bytes prepended,
but those bytes are completely messed up (most important: The ethertype
is bogus):
8.114635 fe:60:11:f9:56:a5 -> 60:47:18:2b:50:47 0xb6ee 118 Ethernet II
0000 60 47 18 2b 50 47 fe 60 11 f9 56 a5 b6 ee 60 00 `G.+PG.`..V...`.
0010 00 00 00 40 3a 35 20 01 46 20 00 09 00 00 00 00 ...@:5 .F ......
0020 00 00 00 00 00 01 2a 02 21 21 00 00 00 01 b8 2d ......*.!!.....-
0030 da ff fe 84 a6 ad 81 00 31 0b 1e ee 00 19 5c f2 ........1.....\.
0040 59 4f 00 00 00 00 cc ae 03 00 00 00 00 00 10 11 YO..............
0050 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 .............. !
0060 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 "#$%&'()*+,-./01
0070 32 33 34 35 36 37 234567
This looks very much like the modem knows it's supposed to send the
header but forgets to initialize it. The header does not change at
all, regardless of IPv6 source address:
35.297854 fe:60:11:f9:56:a5 -> 60:47:18:2b:50:47 0xb6ee 118 Ethernet II
0000 60 47 18 2b 50 47 fe 60 11 f9 56 a5 b6 ee 60 00 `G.+PG.`..V...`.
0010 00 00 00 40 3a 36 20 01 06 10 02 40 00 00 00 53 ...@:6 ....@...S
0020 00 00 00 00 01 93 2a 02 21 21 00 00 00 01 b8 2d ......*.!!.....-
0030 da ff fe 84 a6 ad 81 00 cc a4 1f 24 00 04 89 f4 ...........$....
0040 59 4f 00 00 00 00 3a e6 08 00 00 00 00 00 10 11 YO....:.........
0050 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 .............. !
0060 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 "#$%&'()*+,-./01
0070 32 33 34 35 36 37 234567
or protocol (TCP SYN ACK):
229.256847 fe:60:11:f9:56:a5 -> 60:47:18:2b:50:47 0xb6ee 74 Ethernet II
0000 60 47 18 2b 50 47 fe 60 11 f9 56 a5 b6 ee 60 00 `G.+PG.`..V...`.
0010 00 00 00 14 06 36 20 01 06 7c 21 e0 00 00 00 00 .....6 ..|!.....
0020 00 00 00 00 00 16 2a 02 21 21 00 00 00 01 b8 2d ......*.!!.....-
0030 da ff fe 84 a6 ad 00 17 d4 83 00 00 00 00 7c ce ..............|.
0040 c6 bb 50 14 00 00 cb b4 00 00 ..P.......
I am promised new firmware specifically fixed for IPv6. Don't know what
that means, but I am hoping that this issue is on the fix list. Let's
see.
Otherwise we'll have to do as Windows does here too, and go for raw IP.
But I believe the only sane way making that support DCHP and SLAAC on
Linux will be stripping/adding the L2 headers in the driver. Which I'd
rather avoid if possible.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
