Re: What is SAM value? "ieee802154 phy0 wpan0: SAM value 0x3 not supported"

[Alexander Aring <alex.aring@gmail.com>]

On Mon, Jul 27, 2015 at 11:05:37AM +0200, Baptiste Clenet wrote:
> 2015-07-27 10:58 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> > 2015-07-27 10:32 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> >> Hi,
> >>
> >> On Mon, Jul 27, 2015 at 10:03:27AM +0200, Baptiste Clenet wrote:
> >>> Here is what Wireshark gives me when I ping my board A from another
> >>> board B (same kind of board with same image flashed):
> >>>
> >>> No.     Time           Source                       Destination
> >>>    Protocol Length Info
> >>> 8 37.192838000   ::6e47:e81e:40bf:d4f3   ff01::ff:3ec7:f187    IGMPv0
> >>>  82     Unknown Type:0x00
> >>>
> >>> Frame 8: 82 bytes on wire (656 bits), 82 bytes captured (656 bits) on
> >>> interface 0
> >>>     Interface id: 0
> >>>     Encapsulation type: Linux cooked-mode capture (25)
> >>>     Arrival Time: Jul 24, 2015 15:28:52.786786000 CEST
> >>>     [Time shift for this packet: 0.000000000 seconds]
> >>>     Epoch Time: 1437744532.786786000 seconds
> >>>     [Time delta from previous captured frame: 34.054126000 seconds]
> >>>     [Time delta from previous displayed frame: 34.054126000 seconds]
> >>>     [Time since reference or first frame: 37.192838000 seconds]
> >>>     Frame Number: 8
> >>>     Frame Length: 82 bytes (656 bits)
> >>>     Capture Length: 82 bytes (656 bits)
> >>>     [Frame is marked: False]
> >>>     [Frame is ignored: False]
> >>>     [Protocols in frame: sll:wpan:6lowpan:ipv6:igmp]
> >>>     [Number of per-protocol-data: 1]
> >>>     [IEEE 802.15.4 Low-Rate Wireless PAN, key 0]
> >>>     [Coloring Rule Name: Routing]
> >>>     [Coloring Rule String: hsrp || eigrp || ospf || bgp || cdp || vrrp
> >>> || gvrp || igmp || ismp]
> >>>
> >>> Linux cooked capture
> >>>     Packet type: Unicast to another host (3)
> >>>     Link-layer address type: 805
> >>>     Link-layer address length: 0
> >>>     Protocol: IEEE 802.15.4 (0x00f6)
> >>>
> >>> IEEE 802.15.4 Data, Dst: Broadcast, Src: 6c:47:e81e:40:bfd4:f3
> >>>     Frame Control Field: Data (0xc841)
> >>>     Sequence Number: 80
> >>>     Destination PAN: 0xbeef
> >>>     Destination: 0xffff
> >>>     Extended Source: 6c:47:e81e:40:bfd4:f3 (6c:47:e8:1e:40:bf:d4:f3)
> >>>     FCS: 0xdff3 (Correct)
> >>>
> >>> 6LoWPAN
> >>>     IPHC Header
> >>>         011. .... = Pattern: IP header compression (0x03)
> >>>         ...1 1... .... .... = Traffic class and flow label: Version,
> >>> traffic class, and flow label compressed (0x0003)
> >>>         .... .0.. .... .... = Next header: Inline
> >>>         .... ..11 .... .... = Hop limit: 255 (0x0003)
> >>>         .... .... 1... .... = Context identifier extension: True
> >>>         .... .... .1.. .... = Source address compression: Stateful
> >>>         .... .... ..11 .... = Source address mode: Compressed (0x0003)
> >>>   //it is definitely 3
> >>
> >> I would do now some "instrumentations of pr_debug/printk/whatever"
> >> inside of [0]. Always look for the iphc0/iphc1 if you want you can also
> >> send some patches for doing a better a debugging handling there. Then
> >> use simple the already introduced pr_debug mechanism.
> >
> > Here is the results of pr_debug enabled:
> > root@OpenWrt:/# ping6 -I lowpan0 fe80::a8af:ac69:e53e:c7f1
> > PING fe80::a8af:ac69:e53e:c7f1(fe80::a8af:ac69:e53e:c7f1) from fe80::6e47:e81e:4
> > [  138.949067] IPv6 header dump:
> > [  138.949067]  version = 6
> > [  138.949067]  length  = 40
> > [  138.949067]  nexthdr = 0x3a
> > [  138.949067]  hop_lim = 255
> > [  138.949067]  dest    = ff02::1:ff3e:c7f1
> > [  138.986374] Lowpan compression addr_type 33 source address
> > fe80::6e47:e81e:40bf:d473
> > [  139.004297] address compression 0 bits
> > [  139.014467] source address unicast link-local
> > fe80::6e47:e81e:40bf:d473 iphc1 0x30
> > compressed to 6 octets.032192] destination address is multicast: : 56 data bytes
> >
> >
> > [  139.050274] header len 9 skb 49
> > [  139.056635] iphc0-iphc1 7b-39  //added instrumentation at the end
> > of lowpan_header_compress)
> 
> Sorry for the previous alignement, better now:
> [  139.948257] IPv6 header dump:
> [  139.948257]  version = 6
> [  139.948257]  length  = 40
> [  139.948257]  nexthdr = 0x3a
> [  139.948257]  hop_lim = 255
> [  139.948257]  dest    = ff02::1:ff3e:c7f1
> [  139.983059] Lowpan compression addr_type 33 source address
> fe80::6e47:e81e:40bf:d473
> [  139.998393] address compression 0 bits
> [  140.005808] source address unicast link-local
> fe80::6e47:e81e:40bf:d473 iphc1 0x30
> [  140.020796] destination address is multicast: compressed to 6 octets
> 

Yes, this looks more correct. How does looks like the receiving side if
you enable the pr_debug.

> >
> >>
> >> And I would look into both nodes, for the sending node add
> >> instrumentations inside "lowpan_header_compress" for receiving node add
> >> instrumentations inside "lowpan_header_decompress".
> >>
> >>>         .... .... .... 1... = Multicast address compression: True
> >>>         .... .... .... .0.. = Destination address compression: Stateless
> >>>         .... .... .... ..01 = Destination address mode: 48-bits inline (0x0001)
> >>>         0011 .... = Source context identifier: 0x03
> >>>         .... 1010 = Destination context identifier: 0x0a
> >>>         [Destination context: fe80:: (fe80::)]
> >>>     Next header: IGMP (0x02)
> >>>     Source: ::6e47:e81e:40bf:d4f3 (::6e47:e81e:40bf:d4f3)
> >>>     Destination: ff01::ff:3ec7:f187 (ff01::ff:3ec7:f187)
> >>>
> >>> Internet Protocol Version 6, Src: ::6e47:e81e:40bf:d4f3
> >>> (::6e47:e81e:40bf:d4f3), Dst: ff01::ff:3ec7:f187 (ff01::ff:3ec7:f187)
> >>>     0110 .... = Version: 6
> >>>     .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
> >>>     .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
> >>>     Payload length: 39
> >>>     Next header: IGMP (2)
> >>>     Hop limit: 255
> >>>     Source: ::6e47:e81e:40bf:d4f3 (::6e47:e81e:40bf:d4f3)
> >>>     Destination: ff01::ff:3ec7:f187 (ff01::ff:3ec7:f187)
> >>>     [Source GeoIP: Unknown]
> >>>     [Destination GeoIP: Unknown]
> >>>
> >>> Internet Group Management Protocol
> >>>     [IGMP Version: 0]
> >>>     Type: Unknown (0x00)
> >>>     Reply Pending: 220
> >>>     Header checksum: 0xe700 [incorrect, should be 0x63eb]
> >>>     Identifier: 254
> >>>     Multicast Address: 128.0.0.0 (128.0.0.0)
> >>>     Access Key: 000000a8afac69e5
> >>>     Type: Unknown (0x00)
> >>>     Data
> >>
> >>
> >> The complete IPv6 Header looks like garbage and does not look like some
> >> ICMPv6 ping message.
> > Ok, how should it be?
> >

If you using ping6 it should some ICMPv6 echo request/echo reply
messages. See [0]. But this required working neighbor discovery and when
you have such issues right now, I don't believe that the IPv6 stack
tries to send such messages like [0]. It's hard to determine what's
going wrong at your side.

- Alex

[0] https://tools.ietf.org/html/rfc4443#section-4