Thomas Schäfer <tschaefer@xxxxxxxxxxx> writes:
> Am Samstag, 12. Oktober 2013, 00:13:59 schrieb Bjørn Mork:
>> Thomas Schäfer <tschaefer@xxxxxxxxxxx> writes:
>> > Bjørn writes:
>> >> Could be the driver. I don't know if it is ever tested with IPv6, and
>> >> it does a bit of header magic so it is possible to screw up. Of course,
>> >> the same goes for the firmware (including the testing, i assume :-)
>> >>
>> >> usbmon dumps would be interesting.
>> >
>> > I attached a file, I am not sure, it is very small, I would expect more.
>>
>> Yes, sorry. I didn't think far enough. We need to see more of the
>> frames than this interface will allow. Use tshark/wireshark or some
>> other application supporting dumping the full buffers.
>
> I tried wireshark. But it is not more. Maybe now it is better. usb-dumps seems
> to me very ugly compared to nice dumps of network-interfaces :-)
Well, the main problem is that wireshark doesn't know how to decode the
NCM frames, so you have to identify and dissect those yourself.
Fortunately it's quite easy to scan visually for the 'NCMH' marker. And
you usually can just recognize the IPv4 or IPv6 packets inside based on
the common patterns in their headers instead of looking them up based on
the tables in the NCM frame.
Look at this one for example from your k5150-umts-ipv6-a.pcapng dump:
Frame 1937: 266 bytes on wire (2128 bits), 266 bytes captured (2128 bits) on interface 0
Interface id: 0
Encapsulation type: USB packets with Linux header and padding (115)
Arrival Time: Oct 12, 2013 11:22:57.315519000 CEST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1381569777.315519000 seconds
[Time delta from previous captured frame: 0.239506000 seconds]
[Time delta from previous displayed frame: 0.239506000 seconds]
[Time since reference or first frame: 139.068681000 seconds]
Frame Number: 1937
Frame Length: 266 bytes (2128 bits)
Capture Length: 266 bytes (2128 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: usb:usbms]
USB URB
URB id: 0xffff88004e179740
URB type: URB_COMPLETE ('C')
URB transfer type: URB_BULK (0x03)
Endpoint: 0x83, Direction: IN
1... .... = Direction: IN (1)
.000 0011 = Endpoint value: 3
Device: 4
URB bus id: 1
Device setup request: not relevant ('-')
Data: present (0)
URB sec: 1381569777
URB usec: 315519
URB status: Success (0)
URB length [bytes]: 202
Data length [bytes]: 202
[Request in: 1927]
[Time from request: 1.419822000 seconds]
[bInterfaceClass: Mass Storage (0x08)]
USB Mass Storage
SCSI Payload (Request Sense Response Data)
[LUN: 0]
[Command Set:Direct Access Device (0x00) ]
[SBC Opcode: Request Sense (0x03)]
[Request in: 1923]
[Response in: 1928]
Valid: 0
.100 1110 = SNS Error Type: Unknown (0x4e)
0000 40 97 17 4e 00 88 ff ff 43 03 83 04 01 00 2d 00 @..N....C.....-.
0010 f1 14 59 52 00 00 00 00 7f d0 04 00 00 00 00 00 ..YR............
0020 ca 00 00 00 ca 00 00 00 00 00 00 00 00 00 00 00 ................
0030 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 ................
0040 4e 43 4d 48 0c 00 05 00 ca 00 0c 00 49 50 53 00 NCMH........IPS.
0050 14 00 00 00 22 00 60 00 82 00 48 00 00 00 00 00 ....".`...H.....
0060 00 00 60 00 00 00 00 38 3a ff fe 80 00 00 00 00 ..`....8:.......
0070 00 00 4e 54 99 ff fe 45 e5 d5 ff 02 00 00 00 00 ..NT...E........
0080 00 00 00 00 00 00 00 00 00 01 86 00 9f 62 ff 40 .............b.@
0090 23 28 00 36 ee 80 00 00 00 00 01 01 4c 54 99 45 #(.6........LT.E
00a0 e5 d5 03 04 40 40 ff ff ff ff ff ff ff ff 00 00 ....@@..........
00b0 00 00 2a 01 01 98 02 4c c1 7b 00 00 00 00 00 00 ..*....L.{......
00c0 00 00 60 00 00 00 00 20 3a ff fe 80 00 00 00 00 ..`.... :.......
00d0 00 00 4e 54 99 ff fe 45 e5 d5 ff 02 00 00 00 00 ..NT...E........
00e0 00 00 00 00 00 01 ff 77 cd cf 87 00 5e f5 00 00 .......w....^...
00f0 00 00 2a 01 01 98 02 4c c1 7b 29 82 a8 d8 26 77 ..*....L.{)...&w
0100 cd cf 01 01 4c 54 99 45 e5 d5 ....LT.E..
Wireshark wrongly identifies this as "USB Mass Storage", but as you can
see in the data starting at 0040, this is a NCM frame. The device
firmware generates a shortest possible table of packets (not wasting
space on a fixed table size like the driver does...), so you see that
the first IP packet starts already at 0062. There are two IP packets
here. The second one starts at 00c2.
Splitting them out:
0060 60 00 00 00 00 38 3a ff fe 80 00 00 00 00 ..`....8:.......
0070 00 00 4e 54 99 ff fe 45 e5 d5 ff 02 00 00 00 00 ..NT...E........
0080 00 00 00 00 00 00 00 00 00 01 86 00 9f 62 ff 40 .............b.@
0090 23 28 00 36 ee 80 00 00 00 00 01 01 4c 54 99 45 #(.6........LT.E
00a0 e5 d5 03 04 40 40 ff ff ff ff ff ff ff ff 00 00 ....@@..........
00b0 00 00 2a 01 01 98 02 4c c1 7b 00 00 00 00 00 00 ..*....L.{......
00c0 00 00
This is an ICMPv6 packet from fe80::4e54:99ff:fe45:e5d5 to ff02::1. The
IP version is the first nibble, and scanning for the addresses you
easily find the link local unicast and multicast prefixes. Then you make
out the rest. The two bytes preceding the source address are next
header (0x3a == ICMPv6) and hop limit (0xff). Following the destination
you can find the ICMPv6 type (0x86 = RA) and code (0x00) bytes. You'll
probably recognize the announced prefix in the last part of this packet:
2a01:198:24c:c17b::/64
00c0 60 00 00 00 00 20 3a ff fe 80 00 00 00 00 ..`.... :.......
00d0 00 00 4e 54 99 ff fe 45 e5 d5 ff 02 00 00 00 00 ..NT...E........
00e0 00 00 00 00 00 01 ff 77 cd cf 87 00 5e f5 00 00 .......w....^...
00f0 00 00 2a 01 01 98 02 4c c1 7b 29 82 a8 d8 26 77 ..*....L.{)...&w
0100 cd cf 01 01 4c 54 99 45 e5 d5 ....LT.E..
This is also an ICMPv6 packet from fe80::4e54:99ff:fe45:e5d5 to
ff02::1:ff77:cdcf, with type 0x87 (NS) and code 0x00. This seems to be
a neighbour solictiation for 2a01:198:24c:c17b:2982:a8d8:2677:cdcf from
your good l2 ethernet(!) neighbour 4c-54-99-45-e5-d5.
Not too surprising for an IPv6 session.... I guess the question is how
this procedes. And there I see that you send a number of ping requests,
but I never see that you actually answer that NS. I don't know why. Or
maybe I do...
Do those packets (the RA and NS from the firmware) show up in a normal
IP packet dump from the wwan interface? Do you see any replies? I
guess you don't. We set NOARP on the interface because MBIM really
doesn't have any L2 headers. But here we see that the firmware
obviously believes that it needs to do neighbour discovery, and it even
announces a L2 MAC address for the reply. I believe this is a firmware
screwup, but you could try turning on ARP on the interface and see what
happens:
ifconfig wwan0 arp
No guarantees. I haven't tested this, and I haven't really thought much
about it. The ND does not make any sense at all.
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
