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

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

[Baptiste Clenet]

Hi,

What is SAM value? I got "ieee802154 phy0 wpan0: SAM value 0x3 not
supported" when I receive a ping from another board.

Cheers,

-- 
Baptiste

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

[Alexander Aring]

Hi,

On Fri, Jul 24, 2015 at 09:56:49AM +0200, Baptiste Clenet wrote:
> Hi,
> 
> What is SAM value? I got "ieee802154 phy0 wpan0: SAM value 0x3 not
> supported" when I receive a ping from another board.
> 

I think you hit [0]. You got that because we received some 6LoWPAN frame
with context based address compression (the source address). See also [1].

Your options are:

 - That the other board use stateless (means SAC = 0, see [1]) address
   compression.

 - Implement context based address compression, there was recently a
   RFC patch series which implemented it. This maybe depends also for
   handling 6CO field correctly.

- Alex

[0] http://lxr.free-electrons.com/source/net/6lowpan/iphc.c#L147
[1] https://tools.ietf.org/html/rfc6282#section-3.1

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

[Baptiste Clenet]

2015-07-24 10:31 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> Hi,
>
> On Fri, Jul 24, 2015 at 09:56:49AM +0200, Baptiste Clenet wrote:
>> Hi,
>>
>> What is SAM value? I got "ieee802154 phy0 wpan0: SAM value 0x3 not
>> supported" when I receive a ping from another board.
>>
>
> I think you hit [0]. You got that because we received some 6LoWPAN frame
> with context based address compression (the source address). See also [1].
Yes for [0]

>
> Your options are:
>
>  - That the other board use stateless (means SAC = 0, see [1]) address
>    compression.
How may I check?
They use both the same settings, they are based on the same source code.

>
>  - Implement context based address compression, there was recently a
>    RFC patch series which implemented it. This maybe depends also for
>    handling 6CO field correctly.
Could you provide a link? Is that ported to Bluetooth-next branch or Linux-4.1?

>
> - Alex
>
> [0] http://lxr.free-electrons.com/source/net/6lowpan/iphc.c#L147
> [1] https://tools.ietf.org/html/rfc6282#section-3.1



-- 
Baptiste

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

[Baptiste Clenet]

2015-07-24 10:47 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> 2015-07-24 10:31 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> Hi,
>>
>> On Fri, Jul 24, 2015 at 09:56:49AM +0200, Baptiste Clenet wrote:
>>> Hi,
>>>
>>> What is SAM value? I got "ieee802154 phy0 wpan0: SAM value 0x3 not
>>> supported" when I receive a ping from another board.
>>>
>>
>> I think you hit [0]. You got that because we received some 6LoWPAN frame
>> with context based address compression (the source address). See also [1].
> Yes for [0]
>
>>
>> Your options are:
>>
>>  - That the other board use stateless (means SAC = 0, see [1]) address
>>    compression.
> How may I check?
> They use both the same settings, they are based on the same source code.
SAC bit is set.
>
>>
>>  - Implement context based address compression, there was recently a
>>    RFC patch series which implemented it. This maybe depends also for
>>    handling 6CO field correctly.
> Could you provide a link? Is that ported to Bluetooth-next branch or Linux-4.1?
>
>>
>> - Alex
>>
>> [0] http://lxr.free-electrons.com/source/net/6lowpan/iphc.c#L147
>> [1] https://tools.ietf.org/html/rfc6282#section-3.1
>
>
>
> --
> Baptiste



-- 
Baptiste

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

[Baptiste Clenet]

2015-07-24 11:02 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> 2015-07-24 10:47 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>> 2015-07-24 10:31 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>>> Hi,
>>>
>>> On Fri, Jul 24, 2015 at 09:56:49AM +0200, Baptiste Clenet wrote:
>>>> Hi,
>>>>
>>>> What is SAM value? I got "ieee802154 phy0 wpan0: SAM value 0x3 not
>>>> supported" when I receive a ping from another board.
>>>>
>>>
>>> I think you hit [0]. You got that because we received some 6LoWPAN frame
>>> with context based address compression (the source address). See also [1].
>> Yes for [0]
>>
>>>
>>> Your options are:
>>>
>>>  - That the other board use stateless (means SAC = 0, see [1]) address
>>>    compression.
>> How may I check?
>> They use both the same settings, they are based on the same source code.
> SAC bit is set.

            0     1   2   3    4     5    6    7   8    9        0
1   2     3    4   5
          +---+---+---+---+---+---+---+---+---+---    +---+---+---+---
 +---+---+
          | 0   | 1 | 1  |   TF   |NH |HLIM |CID|SAC|  SAM| M |DAC|  DAM |
          +---+---+---+---+---+---+---+---+---+---    +---+---+---+---
 +---+---+
Mine:    0    1    1    1    1   1    0    0   1      1      1    1
1     0     0   1
7bf9

Is something wrong?

>>
>>>
>>>  - Implement context based address compression, there was recently a
>>>    RFC patch series which implemented it. This maybe depends also for
>>>    handling 6CO field correctly.
>> Could you provide a link? Is that ported to Bluetooth-next branch or Linux-4.1?
>>
>>>
>>> - Alex
>>>
>>> [0] http://lxr.free-electrons.com/source/net/6lowpan/iphc.c#L147
>>> [1] https://tools.ietf.org/html/rfc6282#section-3.1
>>
>>
>>
>> --
>> Baptiste
>
>
>
> --
> Baptiste



-- 
Baptiste

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

[Alexander Aring]

On Fri, Jul 24, 2015 at 11:45:48AM +0200, Baptiste Clenet wrote:
> 2015-07-24 11:02 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> > 2015-07-24 10:47 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> >> 2015-07-24 10:31 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> >>> Hi,
> >>>
> >>> On Fri, Jul 24, 2015 at 09:56:49AM +0200, Baptiste Clenet wrote:
> >>>> Hi,
> >>>>
> >>>> What is SAM value? I got "ieee802154 phy0 wpan0: SAM value 0x3 not
> >>>> supported" when I receive a ping from another board.
> >>>>
> >>>
> >>> I think you hit [0]. You got that because we received some 6LoWPAN frame
> >>> with context based address compression (the source address). See also [1].
> >> Yes for [0]
> >>
> >>>
> >>> Your options are:
> >>>
> >>>  - That the other board use stateless (means SAC = 0, see [1]) address
> >>>    compression.
> >> How may I check?
> >> They use both the same settings, they are based on the same source code.
> > SAC bit is set.
> 
>             0     1   2   3    4     5    6    7   8    9        0
> 1   2     3    4   5
>           +---+---+---+---+---+---+---+---+---+---    +---+---+---+---
>  +---+---+
>           | 0   | 1 | 1  |   TF   |NH |HLIM |CID|SAC|  SAM| M |DAC|  DAM |
>           +---+---+---+---+---+---+---+---+---+---    +---+---+---+---
>  +---+---+
> Mine:    0    1    1    1    1   1    0    0   1      1      1    1
> 1     0     0   1
> 7bf9
> 
> Is something wrong?
> 

There is nothing wrong. The question is here "What does the current
6LoWPAN implementation support?" and you try do something "context based
address compression" which we don't currently support. We are not
_fully_ rfc6282 compliant.

- Alex

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

[Alexander Aring]

On Fri, Jul 24, 2015 at 11:02:30AM +0200, Baptiste Clenet wrote:
> 2015-07-24 10:47 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> > 2015-07-24 10:31 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> >> Hi,
> >>
> >> On Fri, Jul 24, 2015 at 09:56:49AM +0200, Baptiste Clenet wrote:
> >>> Hi,
> >>>
> >>> What is SAM value? I got "ieee802154 phy0 wpan0: SAM value 0x3 not
> >>> supported" when I receive a ping from another board.
> >>>
> >>
> >> I think you hit [0]. You got that because we received some 6LoWPAN frame
> >> with context based address compression (the source address). See also [1].
> > Yes for [0]
> >
> >>
> >> Your options are:
> >>
> >>  - That the other board use stateless (means SAC = 0, see [1]) address
> >>    compression.
> > How may I check?
> > They use both the same settings, they are based on the same source code.
> SAC bit is set.

Yes SAC bit means context based address compression and we don't support
it. We should support it, that's what rfc6282 said. But we don't have
support for that now. :-)

What do you mean with "they are based on the same source code"? It's a
linux<->linux communication? Then SAC bit should not set, if you try to
communicate with another 802.15.4 6LoWPAN stack then you need to
implement SAC/DAC handling or turn it off on the other side.

> >
> >>
> >>  - Implement context based address compression, there was recently a
> >>    RFC patch series which implemented it. This maybe depends also for
> >>    handling 6CO field correctly.
> > Could you provide a link? Is that ported to Bluetooth-next branch or Linux-4.1?
> >

http://www.spinics.net/lists/linux-wpan/msg02613.html

It's based on bluetooth-next like all others patches which you like to
bring into mainline state. Read [0].

- Alex

[0] http://wpan.cakelab.org/#_developing

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

[Baptiste Clenet]

2015-07-24 11:48 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> On Fri, Jul 24, 2015 at 11:02:30AM +0200, Baptiste Clenet wrote:
>> 2015-07-24 10:47 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>> > 2015-07-24 10:31 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> >> Hi,
>> >>
>> >> On Fri, Jul 24, 2015 at 09:56:49AM +0200, Baptiste Clenet wrote:
>> >>> Hi,
>> >>>
>> >>> What is SAM value? I got "ieee802154 phy0 wpan0: SAM value 0x3 not
>> >>> supported" when I receive a ping from another board.
>> >>>
>> >>
>> >> I think you hit [0]. You got that because we received some 6LoWPAN frame
>> >> with context based address compression (the source address). See also [1].
>> > Yes for [0]
>> >
>> >>
>> >> Your options are:
>> >>
>> >>  - That the other board use stateless (means SAC = 0, see [1]) address
>> >>    compression.
>> > How may I check?
>> > They use both the same settings, they are based on the same source code.
>> SAC bit is set.
>
> Yes SAC bit means context based address compression and we don't support
> it. We should support it, that's what rfc6282 said. But we don't have
> support for that now. :-)
>
> What do you mean with "they are based on the same source code"? It's a
> linux<->linux communication?
Yes it is linux to linux transmission.
Yeah I understand for the support :-)
The question is now why my linux use context based address compression
if it shouldn't? Where is it (SAC) set when transmitting a message?

Then SAC bit should not set, if you try to
> communicate with another 802.15.4 6LoWPAN stack then you need to
> implement SAC/DAC handling or turn it off on the other side.
>
>> >
>> >>
>> >>  - Implement context based address compression, there was recently a
>> >>    RFC patch series which implemented it. This maybe depends also for
>> >>    handling 6CO field correctly.
>> > Could you provide a link? Is that ported to Bluetooth-next branch or Linux-4.1?
>> >
>
> http://www.spinics.net/lists/linux-wpan/msg02613.html
>
> It's based on bluetooth-next like all others patches which you like to
> bring into mainline state. Read [0].
>
> - Alex
>
> [0] http://wpan.cakelab.org/#_developing



-- 
Baptiste

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

[Alexander Aring]

On Fri, Jul 24, 2015 at 11:56:08AM +0200, Baptiste Clenet wrote:
> 2015-07-24 11:48 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> > On Fri, Jul 24, 2015 at 11:02:30AM +0200, Baptiste Clenet wrote:
> >> 2015-07-24 10:47 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> >> > 2015-07-24 10:31 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> >> >> Hi,
> >> >>
> >> >> On Fri, Jul 24, 2015 at 09:56:49AM +0200, Baptiste Clenet wrote:
> >> >>> Hi,
> >> >>>
> >> >>> What is SAM value? I got "ieee802154 phy0 wpan0: SAM value 0x3 not
> >> >>> supported" when I receive a ping from another board.
> >> >>>
> >> >>
> >> >> I think you hit [0]. You got that because we received some 6LoWPAN frame
> >> >> with context based address compression (the source address). See also [1].
> >> > Yes for [0]
> >> >
> >> >>
> >> >> Your options are:
> >> >>
> >> >>  - That the other board use stateless (means SAC = 0, see [1]) address
> >> >>    compression.
> >> > How may I check?
> >> > They use both the same settings, they are based on the same source code.
> >> SAC bit is set.
> >
> > Yes SAC bit means context based address compression and we don't support
> > it. We should support it, that's what rfc6282 said. But we don't have
> > support for that now. :-)
> >
> > What do you mean with "they are based on the same source code"? It's a
> > linux<->linux communication?
> Yes it is linux to linux transmission.
> Yeah I understand for the support :-)
> The question is now why my linux use context based address compression
> if it shouldn't? Where is it (SAC) set when transmitting a message?
> 

We don't set it. Which kernel do you use?

- Alex

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

[Baptiste Clenet]

2015-07-24 12:18 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> On Fri, Jul 24, 2015 at 11:56:08AM +0200, Baptiste Clenet wrote:
>> 2015-07-24 11:48 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> > On Fri, Jul 24, 2015 at 11:02:30AM +0200, Baptiste Clenet wrote:
>> >> 2015-07-24 10:47 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>> >> > 2015-07-24 10:31 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> >> >> Hi,
>> >> >>
>> >> >> On Fri, Jul 24, 2015 at 09:56:49AM +0200, Baptiste Clenet wrote:
>> >> >>> Hi,
>> >> >>>
>> >> >>> What is SAM value? I got "ieee802154 phy0 wpan0: SAM value 0x3 not
>> >> >>> supported" when I receive a ping from another board.
>> >> >>>
>> >> >>
>> >> >> I think you hit [0]. You got that because we received some 6LoWPAN frame
>> >> >> with context based address compression (the source address). See also [1].
>> >> > Yes for [0]
>> >> >
>> >> >>
>> >> >> Your options are:
>> >> >>
>> >> >>  - That the other board use stateless (means SAC = 0, see [1]) address
>> >> >>    compression.
>> >> > How may I check?
>> >> > They use both the same settings, they are based on the same source code.
>> >> SAC bit is set.
>> >
>> > Yes SAC bit means context based address compression and we don't support
>> > it. We should support it, that's what rfc6282 said. But we don't have
>> > support for that now. :-)
>> >
>> > What do you mean with "they are based on the same source code"? It's a
>> > linux<->linux communication?
>> Yes it is linux to linux transmission.
>> Yeah I understand for the support :-)
>> The question is now why my linux use context based address compression
>> if it shouldn't? Where is it (SAC) set when transmitting a message?
>>
>
> We don't set it. Which kernel do you use?
Linux 4.1.0 (yeah I should use bluetooth-next kernel)
I see that the only way it is set is when
'source address is unspecified, setting SAC'

root@OpenWrt:/# ifconfig
lowpan0   Link encap:UNSPEC  HWaddr
07-7B-21-44-65-D9-6F-AC-00-00-00-00-00-00-00-00
          inet6 addr: fe80::57b:2144:65d9:6fac/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1280  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wpan0     Link encap:UNSPEC  HWaddr
07-7B-21-44-65-D9-6F-AC-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING NOARP  MTU:127  Metric:1
          RX packets:20 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:300
          RX bytes:1001 (1001.0 B)  TX bytes:568 (568.0 B)

(There is some printk for irq as well)
root@OpenWrt:/#ip link set lowpan0 up
root@OpenWrt:/# [   66.248286] IPv6 header dump:
[   66.248286]  version = 6
[   66.248286]  length  = 36
[   66.248286]  nexthdr = 0x00
[   66.248286]  hop_lim = 1
[   66.248286]  dest    = ff02::16
[   66.281193] source address is unspecified, setting SAC
// ??
[   66.301541] destination address is multicast: compressed to 1 octet
[   66.313959] header len 4 skb 40
[   66.320242] at86rf230_xmit
[   66.340482]  GINT_STAT_0 8000
[   66.346539] at86rf230_isr
[   66.598282] IPv6 header dump:
[   66.598282]  version = 6
[   66.598282]  length  = 36
[   66.598282]  nexthdr = 0x00
[   66.598282]  hop_lim = 1
[   66.598282]  dest    = ff02::16
[   66.631184] source address is unspecified, setting SAC
[   66.651532] destination address is multicast: compressed to 1 octet


root@OpenWrt:/# ping6 -I lowpan0 fe80::a8af:ac69:e53e:c7f1
PING fe80::a8af:ac69:e53e:c7f1(f
[ 6770.810640] IPv6 header dump:
[ 6770.810640]  version = 6
[ 6770.810640]  length  = 40
[ 6770.810640]  nexthdr = 0x3a
[ 6770.810640]  hop_lim = 255
[ 6770.810640]  dest    = ff02::1:ff3e:c7f1
e80::a8af:ac69:e[ 6770.847947] address compression 0 bits
53e:c7f1) from f[ 6770.857961] source address unicast link-local
fe80::57b:2144:65d9:6fac iphc1 0x30
e80::57b:2144:65[ 6770.875515] destination address is multicast:
d9:6fac lowpan0:compressed to 6 octets
 56 data bytes
[ 6770.893603] header len 9 skb 49
[ 6770.902635] at86rf230_xmit
[ 6770.925237]  GINT_STAT_0 8000
[ 6770.931285] at86rf230_isr
[ 6771.808151] IPv6 header dump:
[ 6771.808151]  version = 6
[ 6771.808151]  length  = 40
[ 6771.808151]  nexthdr = 0x3a
[ 6771.808151]  hop_lim = 255
[ 6771.808151]  dest    = ff02::1:ff3e:c7f1
[ 6771.842953] address compression 0 bits
[ 6771.850379] source address unicast link-local
fe80::57b:2144:65d9:6fac iphc1 0x30
[ 6771.865198] destination address is multicast: compressed to 6 octets


>
> - Alex



-- 
Baptiste

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

[Alexander Aring]

On Fri, Jul 24, 2015 at 02:03:09PM +0200, Baptiste Clenet wrote:
> 2015-07-24 12:18 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> > On Fri, Jul 24, 2015 at 11:56:08AM +0200, Baptiste Clenet wrote:
> >> 2015-07-24 11:48 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> >> > On Fri, Jul 24, 2015 at 11:02:30AM +0200, Baptiste Clenet wrote:
> >> >> 2015-07-24 10:47 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> >> >> > 2015-07-24 10:31 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> >> >> >> Hi,
> >> >> >>
> >> >> >> On Fri, Jul 24, 2015 at 09:56:49AM +0200, Baptiste Clenet wrote:
> >> >> >>> Hi,
> >> >> >>>
> >> >> >>> What is SAM value? I got "ieee802154 phy0 wpan0: SAM value 0x3 not
> >> >> >>> supported" when I receive a ping from another board.
> >> >> >>>
> >> >> >>
> >> >> >> I think you hit [0]. You got that because we received some 6LoWPAN frame
> >> >> >> with context based address compression (the source address). See also [1].
> >> >> > Yes for [0]
> >> >> >
> >> >> >>
> >> >> >> Your options are:
> >> >> >>
> >> >> >>  - That the other board use stateless (means SAC = 0, see [1]) address
> >> >> >>    compression.
> >> >> > How may I check?
> >> >> > They use both the same settings, they are based on the same source code.
> >> >> SAC bit is set.
> >> >
> >> > Yes SAC bit means context based address compression and we don't support
> >> > it. We should support it, that's what rfc6282 said. But we don't have
> >> > support for that now. :-)
> >> >
> >> > What do you mean with "they are based on the same source code"? It's a
> >> > linux<->linux communication?
> >> Yes it is linux to linux transmission.
> >> Yeah I understand for the support :-)
> >> The question is now why my linux use context based address compression
> >> if it shouldn't? Where is it (SAC) set when transmitting a message?
> >>
> >
> > We don't set it. Which kernel do you use?
> Linux 4.1.0 (yeah I should use bluetooth-next kernel)
> I see that the only way it is set is when
> 'source address is unspecified, setting SAC'
> 

yes, apologize it wasn't correct. But the SAM value was 0x3 in your case
and this shouldn't be.

The SAC = 1 and SAM = 0 is a very simple case [0]. It's simple do
nothing.

> root@OpenWrt:/# ifconfig
> lowpan0   Link encap:UNSPEC  HWaddr
> 07-7B-21-44-65-D9-6F-AC-00-00-00-00-00-00-00-00
>           inet6 addr: fe80::57b:2144:65d9:6fac/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1280  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:0
>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
> 
> wpan0     Link encap:UNSPEC  HWaddr
> 07-7B-21-44-65-D9-6F-AC-00-00-00-00-00-00-00-00
>           UP BROADCAST RUNNING NOARP  MTU:127  Metric:1
>           RX packets:20 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:300
>           RX bytes:1001 (1001.0 B)  TX bytes:568 (568.0 B)
> 
> (There is some printk for irq as well)
> root@OpenWrt:/#ip link set lowpan0 up
> root@OpenWrt:/# [   66.248286] IPv6 header dump:
> [   66.248286]  version = 6
> [   66.248286]  length  = 36
> [   66.248286]  nexthdr = 0x00
> [   66.248286]  hop_lim = 1
> [   66.248286]  dest    = ff02::16
> [   66.281193] source address is unspecified, setting SAC
> // ??

Yes this is simple case at [0]. But then SAM should be 0 not 3. And in
some previous mail it was set 3 in your case.

We set the SAC bit once at [1] only, but then SAM should be 0. 

- Alex

[0] http://lxr.free-electrons.com/source/net/6lowpan/iphc.c#L148

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

[Baptiste Clenet]

2015-07-24 14:13 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> On Fri, Jul 24, 2015 at 02:03:09PM +0200, Baptiste Clenet wrote:
>> 2015-07-24 12:18 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> > On Fri, Jul 24, 2015 at 11:56:08AM +0200, Baptiste Clenet wrote:
>> >> 2015-07-24 11:48 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> >> > On Fri, Jul 24, 2015 at 11:02:30AM +0200, Baptiste Clenet wrote:
>> >> >> 2015-07-24 10:47 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>> >> >> > 2015-07-24 10:31 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> >> >> >> Hi,
>> >> >> >>
>> >> >> >> On Fri, Jul 24, 2015 at 09:56:49AM +0200, Baptiste Clenet wrote:
>> >> >> >>> Hi,
>> >> >> >>>
>> >> >> >>> What is SAM value? I got "ieee802154 phy0 wpan0: SAM value 0x3 not
>> >> >> >>> supported" when I receive a ping from another board.
>> >> >> >>>
>> >> >> >>
>> >> >> >> I think you hit [0]. You got that because we received some 6LoWPAN frame
>> >> >> >> with context based address compression (the source address). See also [1].
>> >> >> > Yes for [0]
>> >> >> >
>> >> >> >>
>> >> >> >> Your options are:
>> >> >> >>
>> >> >> >>  - That the other board use stateless (means SAC = 0, see [1]) address
>> >> >> >>    compression.
>> >> >> > How may I check?
>> >> >> > They use both the same settings, they are based on the same source code.
>> >> >> SAC bit is set.
>> >> >
>> >> > Yes SAC bit means context based address compression and we don't support
>> >> > it. We should support it, that's what rfc6282 said. But we don't have
>> >> > support for that now. :-)
>> >> >
>> >> > What do you mean with "they are based on the same source code"? It's a
>> >> > linux<->linux communication?
>> >> Yes it is linux to linux transmission.
>> >> Yeah I understand for the support :-)
>> >> The question is now why my linux use context based address compression
>> >> if it shouldn't? Where is it (SAC) set when transmitting a message?
>> >>
>> >
>> > We don't set it. Which kernel do you use?
>> Linux 4.1.0 (yeah I should use bluetooth-next kernel)
>> I see that the only way it is set is when
>> 'source address is unspecified, setting SAC'
>>
>
> yes, apologize it wasn't correct. But the SAM value was 0x3 in your case
> and this shouldn't be.
>
> The SAC = 1 and SAM = 0 is a very simple case [0]. It's simple do
> nothing.
>
>> root@OpenWrt:/# ifconfig
>> lowpan0   Link encap:UNSPEC  HWaddr
>> 07-7B-21-44-65-D9-6F-AC-00-00-00-00-00-00-00-00
>>           inet6 addr: fe80::57b:2144:65d9:6fac/64 Scope:Link
>>           UP BROADCAST RUNNING MULTICAST  MTU:1280  Metric:1
>>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>>           collisions:0 txqueuelen:0
>>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>>
>> wpan0     Link encap:UNSPEC  HWaddr
>> 07-7B-21-44-65-D9-6F-AC-00-00-00-00-00-00-00-00
>>           UP BROADCAST RUNNING NOARP  MTU:127  Metric:1
>>           RX packets:20 errors:0 dropped:0 overruns:0 frame:0
>>           TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
>>           collisions:0 txqueuelen:300
>>           RX bytes:1001 (1001.0 B)  TX bytes:568 (568.0 B)
>>
>> (There is some printk for irq as well)
>> root@OpenWrt:/#ip link set lowpan0 up
>> root@OpenWrt:/# [   66.248286] IPv6 header dump:
>> [   66.248286]  version = 6
>> [   66.248286]  length  = 36
>> [   66.248286]  nexthdr = 0x00
>> [   66.248286]  hop_lim = 1
>> [   66.248286]  dest    = ff02::16
>> [   66.281193] source address is unspecified, setting SAC
>> // ??
>
> Yes this is simple case at [0]. But then SAM should be 0 not 3. And in
> some previous mail it was set 3 in your case.

Yes if SAC = 1, SAM should be 0 I agree.

Is that somehow possible that I send ihpc of 7b39 (taken at the end of
lowpan_header_compress) and I receive and iphc of 7bf9 (taken at the
begginning of lowpan_header_decompress) every time??

>
> We set the SAC bit once at [1] only, but then SAM should be 0.
>
> - Alex
>
> [0] http://lxr.free-electrons.com/source/net/6lowpan/iphc.c#L148



-- 
Baptiste

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

[Alexander Aring]

On Fri, Jul 24, 2015 at 02:53:52PM +0200, Baptiste Clenet wrote:
...
> 
> Yes if SAC = 1, SAM should be 0 I agree.
> 
> Is that somehow possible that I send ihpc of 7b39 (taken at the end of
> lowpan_header_compress) and I receive and iphc of 7bf9 (taken at the
> begginning of lowpan_header_decompress) every time??
>

So far I know that is not possible. I think you need to debug it, do you
have maybe some kind of monitor interface to see what on the air?

When this happens randomly I had sometimes some corrupted data when the
spi clock is too high, but I think you use the bitbang gpio spi driver
now, or? Then I think the spi clock isn't the issue.

- Alex

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

[Baptiste Clenet]

2015-07-24 15:07 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> On Fri, Jul 24, 2015 at 02:53:52PM +0200, Baptiste Clenet wrote:
> ...
>>
>> Yes if SAC = 1, SAM should be 0 I agree.
>>
>> Is that somehow possible that I send ihpc of 7b39 (taken at the end of
>> lowpan_header_compress) and I receive and iphc of 7bf9 (taken at the
>> begginning of lowpan_header_decompress) every time??
>>
>
> So far I know that is not possible. I think you need to debug it, do you
> have maybe some kind of monitor interface to see what on the air?
>
Here is what tcpdump gives me when I receive a message:

13:15:40.253868   P ethertype Unknown (0x00f6), length 82:
        0x0000:  41c8 13ef beff ff56 7863 ed54 89a7 cffb  A  ......Vxc.T....
        0x0010:  f93a 0201 ff34 1234 8700 a5ee 0000 0000   .:...4.4........
        0x0020:  fe80 0000 0000 0000 1234 1234 1234 1234  .........4.4.4.4
        0x0030:  0102 cfa7 8954 ede3 7856 0000 0000 0000  .....T..xV......
        0x0040:  05c7

There is neither 7b39 or  7bf9.
Can't use tshark on openwrt.

Btw, why can't I add  lowpan0 on top of monitor0?
root@OpenWrt:/# ip link add link monitor0 name lowpan0 type lowpan
RTNETLINK answers: Invalid argument



> When this happens randomly I had sometimes some corrupted data when the
> spi clock is too high, but I think you use the bitbang gpio spi driver
> now, or? Then I think the spi clock isn't the issue.
>
> - Alex



-- 
Baptiste

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

[Stefan Schmidt]

Hello.

On 24/07/15 16:45, Baptiste Clenet wrote:
> 2015-07-24 15:07 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> On Fri, Jul 24, 2015 at 02:53:52PM +0200, Baptiste Clenet wrote:
>> ...
>>> Yes if SAC = 1, SAM should be 0 I agree.
>>>
>>> Is that somehow possible that I send ihpc of 7b39 (taken at the end of
>>> lowpan_header_compress) and I receive and iphc of 7bf9 (taken at the
>>> begginning of lowpan_header_decompress) every time??
>>>
>> So far I know that is not possible. I think you need to debug it, do you
>> have maybe some kind of monitor interface to see what on the air?
>>
> Here is what tcpdump gives me when I receive a message:
>
> 13:15:40.253868   P ethertype Unknown (0x00f6), length 82:
>          0x0000:  41c8 13ef beff ff56 7863 ed54 89a7 cffb  A  ......Vxc.T....
>          0x0010:  f93a 0201 ff34 1234 8700 a5ee 0000 0000   .:...4.4........
>          0x0020:  fe80 0000 0000 0000 1234 1234 1234 1234  .........4.4.4.4
>          0x0030:  0102 cfa7 8954 ede3 7856 0000 0000 0000  .....T..xV......
>          0x0040:  05c7
>
> There is neither 7b39 or  7bf9.
> Can't use tshark on openwrt.

That makes it harder as neccassary for debugging. Either try to use 
something like netcat to bring the stream to you host and look at it 
with wireshark or save it as pcap file, transfer it to your host and 
look at it with wireshark.

Doing it like above is really error prone. Why would you make your life 
harder as you should? :)

>
> Btw, why can't I add  lowpan0 on top of monitor0?
> root@OpenWrt:/# ip link add link monitor0 name lowpan0 type lowpan
> RTNETLINK answers: Invalid argument

Hmm, why would you want to do that? A monitor interface should give you 
all the information you need during sniffing. For what do you want to 
add a lowpan interface on top?

regards
Stefan Schmidt

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

[Baptiste Clenet]

2015-07-24 16:51 GMT+02:00 Stefan Schmidt <stefan@osg.samsung.com>:
> Hello.
>
> On 24/07/15 16:45, Baptiste Clenet wrote:
>>
>> 2015-07-24 15:07 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>>>
>>> On Fri, Jul 24, 2015 at 02:53:52PM +0200, Baptiste Clenet wrote:
>>> ...
>>>>
>>>> Yes if SAC = 1, SAM should be 0 I agree.
>>>>
>>>> Is that somehow possible that I send ihpc of 7b39 (taken at the end of
>>>> lowpan_header_compress) and I receive and iphc of 7bf9 (taken at the
>>>> begginning of lowpan_header_decompress) every time??
>>>>
>>> So far I know that is not possible. I think you need to debug it, do you
>>> have maybe some kind of monitor interface to see what on the air?
>>>
>> Here is what tcpdump gives me when I receive a message:
>>
>> 13:15:40.253868   P ethertype Unknown (0x00f6), length 82:
>>          0x0000:  41c8 13ef beff ff56 7863 ed54 89a7 cffb  A
>> ......Vxc.T....
>>          0x0010:  f93a 0201 ff34 1234 8700 a5ee 0000 0000
>> .:...4.4........
>>          0x0020:  fe80 0000 0000 0000 1234 1234 1234 1234
>> .........4.4.4.4
>>          0x0030:  0102 cfa7 8954 ede3 7856 0000 0000 0000
>> .....T..xV......
>>          0x0040:  05c7
>>
>> There is neither 7b39 or  7bf9.
>> Can't use tshark on openwrt.
>
>
> That makes it harder as neccassary for debugging. Either try to use
> something like netcat to bring the stream to you host and look at it with
> wireshark or save it as pcap file, transfer it to your host and look at it
> with wireshark.
>
> Doing it like above is really error prone. Why would you make your life
> harder as you should? :)

Ok, will try with netcat as soon as I can, thanks.

>
>>
>> Btw, why can't I add  lowpan0 on top of monitor0?
>> root@OpenWrt:/# ip link add link monitor0 name lowpan0 type lowpan
>> RTNETLINK answers: Invalid argument
>
>
> Hmm, why would you want to do that? A monitor interface should give you all
> the information you need during sniffing. For what do you want to add a
> lowpan interface on top?

I would like to send IPV6 packet (ping6) through the interface lowpan0.

I think I misunderstood something here about sniffing packet and
interface. Should I have lowpan monitor interface instead of the wpan
monitor?

>
> regards
> Stefan Schmidt



-- 
Baptiste

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

[Stefan Schmidt]

Hello.

On 24/07/15 17:14, Baptiste Clenet wrote:
> 2015-07-24 16:51 GMT+02:00 Stefan Schmidt <stefan@osg.samsung.com>:
>> Hello.
>>
>> On 24/07/15 16:45, Baptiste Clenet wrote:
>>> 2015-07-24 15:07 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>>>> On Fri, Jul 24, 2015 at 02:53:52PM +0200, Baptiste Clenet wrote:
>>>> ...
>>>>> Yes if SAC = 1, SAM should be 0 I agree.
>>>>>
>>>>> Is that somehow possible that I send ihpc of 7b39 (taken at the end of
>>>>> lowpan_header_compress) and I receive and iphc of 7bf9 (taken at the
>>>>> begginning of lowpan_header_decompress) every time??
>>>>>
>>>> So far I know that is not possible. I think you need to debug it, do you
>>>> have maybe some kind of monitor interface to see what on the air?
>>>>
>>> Here is what tcpdump gives me when I receive a message:
>>>
>>> 13:15:40.253868   P ethertype Unknown (0x00f6), length 82:
>>>           0x0000:  41c8 13ef beff ff56 7863 ed54 89a7 cffb  A
>>> ......Vxc.T....
>>>           0x0010:  f93a 0201 ff34 1234 8700 a5ee 0000 0000
>>> .:...4.4........
>>>           0x0020:  fe80 0000 0000 0000 1234 1234 1234 1234
>>> .........4.4.4.4
>>>           0x0030:  0102 cfa7 8954 ede3 7856 0000 0000 0000
>>> .....T..xV......
>>>           0x0040:  05c7
>>>
>>> There is neither 7b39 or  7bf9.
>>> Can't use tshark on openwrt.
>>
>> That makes it harder as neccassary for debugging. Either try to use
>> something like netcat to bring the stream to you host and look at it with
>> wireshark or save it as pcap file, transfer it to your host and look at it
>> with wireshark.
>>
>> Doing it like above is really error prone. Why would you make your life
>> harder as you should? :)
> Ok, will try with netcat as soon as I can, thanks.

Cool.
>>> Btw, why can't I add  lowpan0 on top of monitor0?
>>> root@OpenWrt:/# ip link add link monitor0 name lowpan0 type lowpan
>>> RTNETLINK answers: Invalid argument
>>
>> Hmm, why would you want to do that? A monitor interface should give you all
>> the information you need during sniffing. For what do you want to add a
>> lowpan interface on top?
> I would like to send IPV6 packet (ping6) through the interface lowpan0.
>
> I think I misunderstood something here about sniffing packet and
> interface. Should I have lowpan monitor interface instead of the wpan
> monitor?

You want to use the same interface for sniffing normal data transfer? 
Not really a good idea imho. While sniffing you should keep that 
interface "read only".

If I got you right the case you want to debug is that you receive the 
SAM value message on one device when sending a ping from another device, 
correct? In this case you should use the mintor interface on the 
receiving side and ping6 from the other device. That should give you the 
packet send over the air which you can dissect in wireshark.

regards
Stefan Schmidt

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

[Baptiste Clenet]

2015-07-24 18:24 GMT+02:00 Stefan Schmidt <stefan@osg.samsung.com>:
> Hello.
>
> On 24/07/15 17:14, Baptiste Clenet wrote:
>>
>> 2015-07-24 16:51 GMT+02:00 Stefan Schmidt <stefan@osg.samsung.com>:
>>>
>>> Hello.
>>>
>>> On 24/07/15 16:45, Baptiste Clenet wrote:
>>>>
>>>> 2015-07-24 15:07 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>>>>>
>>>>> On Fri, Jul 24, 2015 at 02:53:52PM +0200, Baptiste Clenet wrote:
>>>>> ...
>>>>>>
>>>>>> Yes if SAC = 1, SAM should be 0 I agree.
>>>>>>
>>>>>> Is that somehow possible that I send ihpc of 7b39 (taken at the end of
>>>>>> lowpan_header_compress) and I receive and iphc of 7bf9 (taken at the
>>>>>> begginning of lowpan_header_decompress) every time??
>>>>>>
>>>>> So far I know that is not possible. I think you need to debug it, do
>>>>> you
>>>>> have maybe some kind of monitor interface to see what on the air?
>>>>>
>>>> Here is what tcpdump gives me when I receive a message:
>>>>
>>>> 13:15:40.253868   P ethertype Unknown (0x00f6), length 82:
>>>>           0x0000:  41c8 13ef beff ff56 7863 ed54 89a7 cffb  A
>>>> ......Vxc.T....
>>>>           0x0010:  f93a 0201 ff34 1234 8700 a5ee 0000 0000
>>>> .:...4.4........
>>>>           0x0020:  fe80 0000 0000 0000 1234 1234 1234 1234
>>>> .........4.4.4.4
>>>>           0x0030:  0102 cfa7 8954 ede3 7856 0000 0000 0000
>>>> .....T..xV......
>>>>           0x0040:  05c7
>>>>
>>>> There is neither 7b39 or  7bf9.
>>>> Can't use tshark on openwrt.
>>>
>>>
>>> That makes it harder as neccassary for debugging. Either try to use
>>> something like netcat to bring the stream to you host and look at it with
>>> wireshark or save it as pcap file, transfer it to your host and look at
>>> it
>>> with wireshark.
>>>
>>> Doing it like above is really error prone. Why would you make your life
>>> harder as you should? :)
>>
>> Ok, will try with netcat as soon as I can, thanks.
>
>
> Cool.
>>>>
>>>> Btw, why can't I add  lowpan0 on top of monitor0?
>>>> root@OpenWrt:/# ip link add link monitor0 name lowpan0 type lowpan
>>>> RTNETLINK answers: Invalid argument
>>>
>>>
>>> Hmm, why would you want to do that? A monitor interface should give you
>>> all
>>> the information you need during sniffing. For what do you want to add a
>>> lowpan interface on top?
>>
>> I would like to send IPV6 packet (ping6) through the interface lowpan0.
>>
>> I think I misunderstood something here about sniffing packet and
>> interface. Should I have lowpan monitor interface instead of the wpan
>> monitor?
>
>
> You want to use the same interface for sniffing normal data transfer?
Yes this is what I wanted.
 Not
> really a good idea imho. While sniffing you should keep that interface "read
> only".
Ok, thanks.

>
> If I got you right the case you want to debug is that you receive the SAM
> value message on one device when sending a ping from another device,
> correct?
Yes, exactly. Thanks to some printk I can see the SAM value in
lowpan_header_decompress and  lowpan_header_compress (receiving and
sending) but maybe sniffing the wpan0 will give me different results?

>In this case you should use the mintor interface on the receiving
> side and ping6 from the other device. That should give you the packet send
> over the air which you can dissect in wireshark.
Ok, will do that tomorrow with nc

Thanks



>
> regards
> Stefan Schmidt



-- 
Baptiste

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

[Baptiste Clenet]

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
        .... .... .... 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

Which are all the ways to change the SAM value? It is definitely
changed somehow before sending.

2015-07-24 17:14 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> 2015-07-24 16:51 GMT+02:00 Stefan Schmidt <stefan@osg.samsung.com>:
>> Hello.
>>
>> On 24/07/15 16:45, Baptiste Clenet wrote:
>>>
>>> 2015-07-24 15:07 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>>>>
>>>> On Fri, Jul 24, 2015 at 02:53:52PM +0200, Baptiste Clenet wrote:
>>>> ...
>>>>>
>>>>> Yes if SAC = 1, SAM should be 0 I agree.
>>>>>
>>>>> Is that somehow possible that I send ihpc of 7b39 (taken at the end of
>>>>> lowpan_header_compress) and I receive and iphc of 7bf9 (taken at the
>>>>> begginning of lowpan_header_decompress) every time??
>>>>>
>>>> So far I know that is not possible. I think you need to debug it, do you
>>>> have maybe some kind of monitor interface to see what on the air?
>>>>
>>> Here is what tcpdump gives me when I receive a message:
>>>
>>> 13:15:40.253868   P ethertype Unknown (0x00f6), length 82:
>>>          0x0000:  41c8 13ef beff ff56 7863 ed54 89a7 cffb  A
>>> ......Vxc.T....
>>>          0x0010:  f93a 0201 ff34 1234 8700 a5ee 0000 0000
>>> .:...4.4........
>>>          0x0020:  fe80 0000 0000 0000 1234 1234 1234 1234
>>> .........4.4.4.4
>>>          0x0030:  0102 cfa7 8954 ede3 7856 0000 0000 0000
>>> .....T..xV......
>>>          0x0040:  05c7
>>>
>>> There is neither 7b39 or  7bf9.
>>> Can't use tshark on openwrt.
>>
>>
>> That makes it harder as neccassary for debugging. Either try to use
>> something like netcat to bring the stream to you host and look at it with
>> wireshark or save it as pcap file, transfer it to your host and look at it
>> with wireshark.
>>
>> Doing it like above is really error prone. Why would you make your life
>> harder as you should? :)
>
> Ok, will try with netcat as soon as I can, thanks.
>
>>
>>>
>>> Btw, why can't I add  lowpan0 on top of monitor0?
>>> root@OpenWrt:/# ip link add link monitor0 name lowpan0 type lowpan
>>> RTNETLINK answers: Invalid argument
>>
>>
>> Hmm, why would you want to do that? A monitor interface should give you all
>> the information you need during sniffing. For what do you want to add a
>> lowpan interface on top?
>
> I would like to send IPV6 packet (ping6) through the interface lowpan0.
>
> I think I misunderstood something here about sniffing packet and
> interface. Should I have lowpan monitor interface instead of the wpan
> monitor?
>
>>
>> regards
>> Stefan Schmidt
>
>
>
> --
> Baptiste



-- 
Baptiste

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

[Baptiste Clenet]

2015-07-27 10:03 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> 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

EDIT: I've just noticed that the source address is wrong, ifconfig
lowpan0 ont board A (which pings):
root@OpenWrt:/# ifconfig lowpan0
lowpan0   Link encap:UNSPEC  HWaddr
6C-47-E8-1E-40-BF-D4-73-00-00-00-00-00-00-00-00
          inet6 addr: fe80::6e47:e81e:40bf:d473/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1280  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

>
> 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
>         .... .... .... 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
>
> Which are all the ways to change the SAM value? It is definitely
> changed somehow before sending.
>

-- 
Baptiste

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

[Alexander Aring]

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.

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.

- Alex

[0] http://lxr.free-electrons.com/source/net/6lowpan/iphc.c#L233

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

[Baptiste Clenet]

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)

>
> 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?

>
> - Alex
>
> [0] http://lxr.free-electrons.com/source/net/6lowpan/iphc.c#L233



-- 
Baptiste

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

[Baptiste Clenet]

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

>
>>
>> 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?
>
>>
>> - Alex
>>
>> [0] http://lxr.free-electrons.com/source/net/6lowpan/iphc.c#L233
>
>
>
> --
> Baptiste



-- 
Baptiste

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

[Alexander Aring]

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

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

[Baptiste Clenet]

2015-07-27 11:30 GMT+02:00 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.

Receiving side:
[  176.921637] CID flag is set, increase header with one
[  176.931640] NH flag is set, next header carried inline: 02
[  176.942502] SAC bit is set. Handle context based source address.
[  176.954397]
[  176.957352] ieee802154 phy0 wpan0: SAM value 0x3 not supported

>
>> >
>> >>
>> >> 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



-- 
Baptiste

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

[Alexander Aring]

On Mon, Jul 27, 2015 at 12:08:18PM +0200, Baptiste Clenet wrote:
...
> 
> Receiving side:
> [  176.921637] CID flag is set, increase header with one
> [  176.931640] NH flag is set, next header carried inline: 02
> [  176.942502] SAC bit is set. Handle context based source address.
> [  176.954397]
> [  176.957352] ieee802154 phy0 wpan0: SAM value 0x3 not supported
> 

Yes this is not what it was transmitted before from the other node.
That's why I would ask for some sniffing device, somewhere in the lower
layers mac or phy it will fill your frame with garbage.

I can't tell you now if it's the transmitted node or the receiving node.
You need to debug it there.

To ensure the transmitted node don't send garbage I would like to check
it with some sniffer device. If you see garbage on the sniffer device
then it's something wrong with the transmitting.

- Alex

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

[Baptiste Clenet]

2015-07-27 12:21 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> On Mon, Jul 27, 2015 at 12:08:18PM +0200, Baptiste Clenet wrote:
> ...
>>
>> Receiving side:
>> [  176.921637] CID flag is set, increase header with one
>> [  176.931640] NH flag is set, next header carried inline: 02
>> [  176.942502] SAC bit is set. Handle context based source address.
>> [  176.954397]
>> [  176.957352] ieee802154 phy0 wpan0: SAM value 0x3 not supported
>>
>
> Yes this is not what it was transmitted before from the other node.
> That's why I would ask for some sniffing device, somewhere in the lower
> layers mac or phy it will fill your frame with garbage.
>
> I can't tell you now if it's the transmitted node or the receiving node.
> You need to debug it there.
Yeah, I agree.

>
> To ensure the transmitted node don't send garbage I would like to check
> it with some sniffer device. If you see garbage on the sniffer device
> then it's something wrong with the transmitting.
Ok, but I did sniffing with monitor0 on the receiver as I mentioned earlier.
How may I sniff a packet ont the sender? Because I can't set up
lowpan0 on top of monitor0.
How may I sniff on lower layers?

Also, I would add that even if I change the destination IP, I still
receive the message. Shouldn't the transceiver blocks messages which
are not addressed to it?

>
> - Alex



-- 
Baptiste

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

[Alexander Aring]

On Mon, Jul 27, 2015 at 12:31:28PM +0200, Baptiste Clenet wrote:
> 2015-07-27 12:21 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> > On Mon, Jul 27, 2015 at 12:08:18PM +0200, Baptiste Clenet wrote:
> > ...
> >>
> >> Receiving side:
> >> [  176.921637] CID flag is set, increase header with one
> >> [  176.931640] NH flag is set, next header carried inline: 02
> >> [  176.942502] SAC bit is set. Handle context based source address.
> >> [  176.954397]
> >> [  176.957352] ieee802154 phy0 wpan0: SAM value 0x3 not supported
> >>
> >
> > Yes this is not what it was transmitted before from the other node.
> > That's why I would ask for some sniffing device, somewhere in the lower
> > layers mac or phy it will fill your frame with garbage.
> >
> > I can't tell you now if it's the transmitted node or the receiving node.
> > You need to debug it there.
> Yeah, I agree.
> 
> >
> > To ensure the transmitted node don't send garbage I would like to check
> > it with some sniffer device. If you see garbage on the sniffer device
> > then it's something wrong with the transmitting.
> Ok, but I did sniffing with monitor0 on the receiver as I mentioned earlier.
> How may I sniff a packet ont the sender? Because I can't set up
> lowpan0 on top of monitor0.
> How may I sniff on lower layers?
> 

In short:

Monitor is just for sniffing, we don't parse any payload data on it. You
can't create a lowpan interface on it, please use the L2 interface
(wpan0). See [0], you maybe need a third node which running as monitor.

> Also, I would add that even if I change the destination IP, I still
> receive the message. Shouldn't the transceiver blocks messages which
> are not addressed to it?
> 

for L2 (ieee802154) addresses yes, for L3 (IPv6) no.

- Alex

[0] http://wpan.cakelab.org/#_sniffing

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

[Baptiste Clenet]

2015-07-27 12:38 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> On Mon, Jul 27, 2015 at 12:31:28PM +0200, Baptiste Clenet wrote:
>> 2015-07-27 12:21 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> > On Mon, Jul 27, 2015 at 12:08:18PM +0200, Baptiste Clenet wrote:
>> > ...
>> >>
>> >> Receiving side:
>> >> [  176.921637] CID flag is set, increase header with one
>> >> [  176.931640] NH flag is set, next header carried inline: 02
>> >> [  176.942502] SAC bit is set. Handle context based source address.
>> >> [  176.954397]
>> >> [  176.957352] ieee802154 phy0 wpan0: SAM value 0x3 not supported
>> >>
>> >
>> > Yes this is not what it was transmitted before from the other node.
>> > That's why I would ask for some sniffing device, somewhere in the lower
>> > layers mac or phy it will fill your frame with garbage.
>> >
>> > I can't tell you now if it's the transmitted node or the receiving node.
>> > You need to debug it there.
>> Yeah, I agree.
>>
>> >
>> > To ensure the transmitted node don't send garbage I would like to check
>> > it with some sniffer device. If you see garbage on the sniffer device
>> > then it's something wrong with the transmitting.
>> Ok, but I did sniffing with monitor0 on the receiver as I mentioned earlier.
>> How may I sniff a packet ont the sender? Because I can't set up
>> lowpan0 on top of monitor0.
>> How may I sniff on lower layers?
>>
>
> In short:
>
> Monitor is just for sniffing, we don't parse any payload data on it. You
> can't create a lowpan interface on it, please use the L2 interface
> (wpan0). See [0], you maybe need a third node which running as monitor.

I don't think I've got it, you want me to set up a network of 3 nodes with:
1            2             3
sender   receiver    receiver
wpan0    wpan0      monitor0

But I will see exactly the same things as earlier.
And I won't sniff phy layer.

>
>> Also, I would add that even if I change the destination IP, I still
>> receive the message. Shouldn't the transceiver blocks messages which
>> are not addressed to it?
>>
>
> for L2 (ieee802154) addresses yes, for L3 (IPv6) no.
ok
>
> - Alex
>
> [0] http://wpan.cakelab.org/#_sniffing



-- 
Baptiste

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

[Alexander Aring]

On Mon, Jul 27, 2015 at 12:52:42PM +0200, Baptiste Clenet wrote:
> 2015-07-27 12:38 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> > On Mon, Jul 27, 2015 at 12:31:28PM +0200, Baptiste Clenet wrote:
> >> 2015-07-27 12:21 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> >> > On Mon, Jul 27, 2015 at 12:08:18PM +0200, Baptiste Clenet wrote:
> >> > ...
> >> >>
> >> >> Receiving side:
> >> >> [  176.921637] CID flag is set, increase header with one
> >> >> [  176.931640] NH flag is set, next header carried inline: 02
> >> >> [  176.942502] SAC bit is set. Handle context based source address.
> >> >> [  176.954397]
> >> >> [  176.957352] ieee802154 phy0 wpan0: SAM value 0x3 not supported
> >> >>
> >> >
> >> > Yes this is not what it was transmitted before from the other node.
> >> > That's why I would ask for some sniffing device, somewhere in the lower
> >> > layers mac or phy it will fill your frame with garbage.
> >> >
> >> > I can't tell you now if it's the transmitted node or the receiving node.
> >> > You need to debug it there.
> >> Yeah, I agree.
> >>
> >> >
> >> > To ensure the transmitted node don't send garbage I would like to check
> >> > it with some sniffer device. If you see garbage on the sniffer device
> >> > then it's something wrong with the transmitting.
> >> Ok, but I did sniffing with monitor0 on the receiver as I mentioned earlier.
> >> How may I sniff a packet ont the sender? Because I can't set up
> >> lowpan0 on top of monitor0.
> >> How may I sniff on lower layers?
> >>
> >
> > In short:
> >
> > Monitor is just for sniffing, we don't parse any payload data on it. You
> > can't create a lowpan interface on it, please use the L2 interface
> > (wpan0). See [0], you maybe need a third node which running as monitor.
> 
> I don't think I've got it, you want me to set up a network of 3 nodes with:
> 1            2             3
> sender   receiver    receiver
> wpan0    wpan0      monitor0
> 
> But I will see exactly the same things as earlier.

You can save the dump (e.g. tshark I think with -w $FILE) somewhere or
doing pipe via ssh, refer [0].

I don't know what "But I will see exactly the same things as earlier" I
don't know now if the sender transmit correct things and the receiver do
some garbage then OR the sender already transmit incorrect data.

When you have such dump file you can easily open this dump with
wireshark, wireshark will autodetect the 6LoWPAN header then from the
wpan interface and shows "hopefully" correct 6LoWPAN decompressed data
(IPv6) which should be the same like what lowpan interface shows.

> And I won't sniff phy layer.
> 

Yes, we all don't want to decode the phy layer manually. :D I don't have
the equipment and knowledge for doing this.

- Alex

[0] http://wpan.cakelab.org/#_sniffing

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

[Baptiste Clenet]

2015-07-27 13:30 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> On Mon, Jul 27, 2015 at 12:52:42PM +0200, Baptiste Clenet wrote:
>> 2015-07-27 12:38 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> > On Mon, Jul 27, 2015 at 12:31:28PM +0200, Baptiste Clenet wrote:
>> >> 2015-07-27 12:21 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> >> > On Mon, Jul 27, 2015 at 12:08:18PM +0200, Baptiste Clenet wrote:
>> >> > ...
>> >> >>
>> >> >> Receiving side:
>> >> >> [  176.921637] CID flag is set, increase header with one
>> >> >> [  176.931640] NH flag is set, next header carried inline: 02
>> >> >> [  176.942502] SAC bit is set. Handle context based source address.
>> >> >> [  176.954397]
>> >> >> [  176.957352] ieee802154 phy0 wpan0: SAM value 0x3 not supported
>> >> >>
>> >> >
>> >> > Yes this is not what it was transmitted before from the other node.
>> >> > That's why I would ask for some sniffing device, somewhere in the lower
>> >> > layers mac or phy it will fill your frame with garbage.
>> >> >
>> >> > I can't tell you now if it's the transmitted node or the receiving node.
>> >> > You need to debug it there.
>> >> Yeah, I agree.
>> >>
>> >> >
>> >> > To ensure the transmitted node don't send garbage I would like to check
>> >> > it with some sniffer device. If you see garbage on the sniffer device
>> >> > then it's something wrong with the transmitting.
>> >> Ok, but I did sniffing with monitor0 on the receiver as I mentioned earlier.
>> >> How may I sniff a packet ont the sender? Because I can't set up
>> >> lowpan0 on top of monitor0.
>> >> How may I sniff on lower layers?
>> >>
>> >
>> > In short:
>> >
>> > Monitor is just for sniffing, we don't parse any payload data on it. You
>> > can't create a lowpan interface on it, please use the L2 interface
>> > (wpan0). See [0], you maybe need a third node which running as monitor.
>>
>> I don't think I've got it, you want me to set up a network of 3 nodes with:
>> 1            2             3
>> sender   receiver    receiver
>> wpan0    wpan0      monitor0
>>
>> But I will see exactly the same things as earlier.
>
> You can save the dump (e.g. tshark I think with -w $FILE) somewhere or
> doing pipe via ssh, refer [0].
OpenWRT doesn't provide tshark.
I could use tcpdump instead but there is something I still don't get,
sorry. How can I sniff a packet I send? (Sniffing on the sender). If I
well-understand, to sniff I need to use monitor0 interface but when I
use it I can't use lowpan0 so I can't send ICMP packet and I can't
sniff.

>
> I don't know what "But I will see exactly the same things as earlier"
it means that the receiver will receive the same things as earlier and
I have already given to you the details about the message that
Wireshark gave me (which comes from the receiver).
> I
> don't know now if the sender transmit correct things and the receiver do
> some garbage then OR the sender already transmit incorrect data.
>
> When you have such dump file you can easily open this dump with
> wireshark, wireshark will autodetect the 6LoWPAN header then from the
> wpan interface and shows "hopefully" correct 6LoWPAN decompressed data
> (IPv6) which should be the same like what lowpan interface shows.
Yes, just need the dump now :-)

>
>> And I won't sniff phy layer.
>>
>
> Yes, we all don't want to decode the phy layer manually. :D I don't have
> the equipment and knowledge for doing this.
>
> - Alex
>
> [0] http://wpan.cakelab.org/#_sniffing



-- 
Baptiste

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

[Alexander Aring]

On Mon, Jul 27, 2015 at 02:29:09PM +0200, Baptiste Clenet wrote:
> 2015-07-27 13:30 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> > On Mon, Jul 27, 2015 at 12:52:42PM +0200, Baptiste Clenet wrote:
> >> 2015-07-27 12:38 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> >> > On Mon, Jul 27, 2015 at 12:31:28PM +0200, Baptiste Clenet wrote:
> >> >> 2015-07-27 12:21 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> >> >> > On Mon, Jul 27, 2015 at 12:08:18PM +0200, Baptiste Clenet wrote:
> >> >> > ...
> >> >> >>
> >> >> >> Receiving side:
> >> >> >> [  176.921637] CID flag is set, increase header with one
> >> >> >> [  176.931640] NH flag is set, next header carried inline: 02
> >> >> >> [  176.942502] SAC bit is set. Handle context based source address.
> >> >> >> [  176.954397]
> >> >> >> [  176.957352] ieee802154 phy0 wpan0: SAM value 0x3 not supported
> >> >> >>
> >> >> >
> >> >> > Yes this is not what it was transmitted before from the other node.
> >> >> > That's why I would ask for some sniffing device, somewhere in the lower
> >> >> > layers mac or phy it will fill your frame with garbage.
> >> >> >
> >> >> > I can't tell you now if it's the transmitted node or the receiving node.
> >> >> > You need to debug it there.
> >> >> Yeah, I agree.
> >> >>
> >> >> >
> >> >> > To ensure the transmitted node don't send garbage I would like to check
> >> >> > it with some sniffer device. If you see garbage on the sniffer device
> >> >> > then it's something wrong with the transmitting.
> >> >> Ok, but I did sniffing with monitor0 on the receiver as I mentioned earlier.
> >> >> How may I sniff a packet ont the sender? Because I can't set up
> >> >> lowpan0 on top of monitor0.
> >> >> How may I sniff on lower layers?
> >> >>
> >> >
> >> > In short:
> >> >
> >> > Monitor is just for sniffing, we don't parse any payload data on it. You
> >> > can't create a lowpan interface on it, please use the L2 interface
> >> > (wpan0). See [0], you maybe need a third node which running as monitor.
> >>
> >> I don't think I've got it, you want me to set up a network of 3 nodes with:
> >> 1            2             3
> >> sender   receiver    receiver
> >> wpan0    wpan0      monitor0
> >>
> >> But I will see exactly the same things as earlier.
> >
> > You can save the dump (e.g. tshark I think with -w $FILE) somewhere or
> > doing pipe via ssh, refer [0].
> OpenWRT doesn't provide tshark.
> I could use tcpdump instead but there is something I still don't get,
> sorry. How can I sniff a packet I send? (Sniffing on the sender). If I
> well-understand, to sniff I need to use monitor0 interface but when I
> use it I can't use lowpan0 so I can't send ICMP packet and I can't
> sniff.
> 

This is correct. The transceiver goes into promiscuous mode and in
short: you cannot operate as node in the same time then.

Then forget that and make some at86rf230 driver debug messages. See
"print_hex_dump" [0]. Add this add skb->data in at86rf230_xmit and
at86rf230_rx_read_frame_complete (but after the skb is filled with data,
otherwise it makes no sense).

This will allow us to see what's the lowest layer is. If the transmit
side looks correct, but receive side looks weird then I suppose
something is wrong again with your spi setup.

The reason is that we get the lowest dump of the transmitted and
received buffer and nobody touched that buffer then.

> >
> > I don't know what "But I will see exactly the same things as earlier"
> it means that the receiver will receive the same things as earlier and
> I have already given to you the details about the message that
> Wireshark gave me (which comes from the receiver).

Now with these sentence it looks like what I said above. The transmit
buffer looks correct, but the receive buffer looks completely different.

You cannot debug in upper layers and then say "It's the same whats was
on the air". Please confirm this by debugging the driver layer and
dumping the frame buffer on receiving and transmitting, which is the
lowest layer which we can debug. (Maybe we should add some debug switch
for that in at86rf230 driver).

If transmit looks correct and the receiving buffer looks completely
different than what was transmitted before. Then this is not an issue
with mac802154/6LoWPAN stack. Something is broken then with spi/cable
connectors/whatever I don't know.

- Alex

[0] http://lxr.free-electrons.com/source/include/linux/printk.h#L429

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

[Baptiste Clenet]

2015-07-27 14:42 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> On Mon, Jul 27, 2015 at 02:29:09PM +0200, Baptiste Clenet wrote:
>> 2015-07-27 13:30 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> > On Mon, Jul 27, 2015 at 12:52:42PM +0200, Baptiste Clenet wrote:
>> >> 2015-07-27 12:38 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> >> > On Mon, Jul 27, 2015 at 12:31:28PM +0200, Baptiste Clenet wrote:
>> >> >> 2015-07-27 12:21 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> >> >> > On Mon, Jul 27, 2015 at 12:08:18PM +0200, Baptiste Clenet wrote:
>> >> >> > ...
>> >> >> >>
>> >> >> >> Receiving side:
>> >> >> >> [  176.921637] CID flag is set, increase header with one
>> >> >> >> [  176.931640] NH flag is set, next header carried inline: 02
>> >> >> >> [  176.942502] SAC bit is set. Handle context based source address.
>> >> >> >> [  176.954397]
>> >> >> >> [  176.957352] ieee802154 phy0 wpan0: SAM value 0x3 not supported
>> >> >> >>
>> >> >> >
>> >> >> > Yes this is not what it was transmitted before from the other node.
>> >> >> > That's why I would ask for some sniffing device, somewhere in the lower
>> >> >> > layers mac or phy it will fill your frame with garbage.
>> >> >> >
>> >> >> > I can't tell you now if it's the transmitted node or the receiving node.
>> >> >> > You need to debug it there.
>> >> >> Yeah, I agree.
>> >> >>
>> >> >> >
>> >> >> > To ensure the transmitted node don't send garbage I would like to check
>> >> >> > it with some sniffer device. If you see garbage on the sniffer device
>> >> >> > then it's something wrong with the transmitting.
>> >> >> Ok, but I did sniffing with monitor0 on the receiver as I mentioned earlier.
>> >> >> How may I sniff a packet ont the sender? Because I can't set up
>> >> >> lowpan0 on top of monitor0.
>> >> >> How may I sniff on lower layers?
>> >> >>
>> >> >
>> >> > In short:
>> >> >
>> >> > Monitor is just for sniffing, we don't parse any payload data on it. You
>> >> > can't create a lowpan interface on it, please use the L2 interface
>> >> > (wpan0). See [0], you maybe need a third node which running as monitor.
>> >>
>> >> I don't think I've got it, you want me to set up a network of 3 nodes with:
>> >> 1            2             3
>> >> sender   receiver    receiver
>> >> wpan0    wpan0      monitor0
>> >>
>> >> But I will see exactly the same things as earlier.
>> >
>> > You can save the dump (e.g. tshark I think with -w $FILE) somewhere or
>> > doing pipe via ssh, refer [0].
>> OpenWRT doesn't provide tshark.
>> I could use tcpdump instead but there is something I still don't get,
>> sorry. How can I sniff a packet I send? (Sniffing on the sender). If I
>> well-understand, to sniff I need to use monitor0 interface but when I
>> use it I can't use lowpan0 so I can't send ICMP packet and I can't
>> sniff.
>>
>
> This is correct. The transceiver goes into promiscuous mode and in
> short: you cannot operate as node in the same time then.
>
> Then forget that and make some at86rf230 driver debug messages. See
> "print_hex_dump" [0]. Add this add skb->data in at86rf230_xmit and
> at86rf230_rx_read_frame_complete (but after the skb is filled with data,
> otherwise it makes no sense).
>
> This will allow us to see what's the lowest layer is. If the transmit
> side looks correct, but receive side looks weird then I suppose
> something is wrong again with your spi setup.
>
> The reason is that we get the lowest dump of the transmitted and
> received buffer and nobody touched that buffer then.
>
>> >
>> > I don't know what "But I will see exactly the same things as earlier"
>> it means that the receiver will receive the same things as earlier and
>> I have already given to you the details about the message that
>> Wireshark gave me (which comes from the receiver).
>
> Now with these sentence it looks like what I said above. The transmit
> buffer looks correct, but the receive buffer looks completely different.
>
> You cannot debug in upper layers and then say "It's the same whats was
> on the air". Please confirm this by debugging the driver layer and
> dumping the frame buffer on receiving and transmitting, which is the
> lowest layer which we can debug. (Maybe we should add some debug switch
> for that in at86rf230 driver).
>
> If transmit looks correct and the receiving buffer looks completely
> different than what was transmitted before. Then this is not an issue
> with mac802154/6LoWPAN stack. Something is broken then with spi/cable
> connectors/whatever I don't know.
>
Thank you for the clarification :-). I have the feeling that spi does
some magic again...

> - Alex
>
> [0] http://lxr.free-electrons.com/source/include/linux/printk.h#L429



-- 
Baptiste

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

[Baptiste Clenet]

>> Then forget that and make some at86rf230 driver debug messages. See
>> "print_hex_dump" [0]. Add this add skb->data in at86rf230_xmit and
>> at86rf230_rx_read_frame_complete (but after the skb is filled with data,
>> otherwise it makes no sense).
>>
>> This will allow us to see what's the lowest layer is. If the transmit
>> side looks correct, but receive side looks weird then I suppose
>> something is wrong again with your spi setup.
>>
>> The reason is that we get the lowest dump of the transmitted and
>> received buffer and nobody touched that buffer then.

I dump the packet in at86rf230_xmit and
at86rf230_rx_read_frame_complete (just before
ieee802154_rx_irqsafe(lp->hw, skb, lqi)). This is wireshark analyse of
the two packets. The first one is correct and comes from the sender,
the second is from the receiver (I manually created the hex dump file)
which is wrong! So something seem to occur when the frame goes to the
transceiver.
Those dump was created with :
root@OpenWrt:/#ieee802154_rx_irqsafe(lp->hw, skb, lqi);

No.     Time           Source                Destination
Protocol Length Info
      1 0.000000000    fe80::335d:7cf9:67f5:1017 ff02::1:ff3e:c7f1
ICMPv6   64     Neighbor Solicitation for fe80::a8af:ac69:e53e:c7f1
from 31:5d:7c:f9:67:f5:10:17

Frame 1: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on
interface 0
    Interface id: 0
    Packet flags: 0x00000000
        .... .... .... .... .... .... .... ..00 = Direction: Not
available (0x00000000)
        .... .... .... .... .... .... ...0 00.. = Reception type: Not
specified (0)
        .... .... .... .... .... ...0 000. .... = FCS length: 0
        .... .... .... .... 0000 000. .... .... = Reserved: 0
        .... ...0 .... .... .... .... .... .... = CRC error: Not set
        .... ..0. .... .... .... .... .... .... = Packet too long error: Not set
        .... .0.. .... .... .... .... .... .... = Packet too short
error: Not set
        .... 0... .... .... .... .... .... .... = Wrong interframe gap
error: Not set
        ...0 .... .... .... .... .... .... .... = Unaligned frame error: Not set
        ..0. .... .... .... .... .... .... .... = Start frame
delimiter error: Not set
        .0.. .... .... .... .... .... .... .... = Preamble error: Not set
        0... .... .... .... .... .... .... .... = Symbol error: Not set
    Encapsulation type: IEEE 802.15.4 Wireless PAN with FCS not present (127)
    Arrival Time: Jul 25, 2015 00:54:17.000000000 CEST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1437778457.000000000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 64 bytes (512 bits)
    Capture Length: 64 bytes (512 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wpan:6lowpan:ipv6:icmpv6]
    [Number of per-protocol-data: 1]
    [IEEE 802.15.4 Low-Rate Wireless PAN, key 0]
    [Coloring Rule Name: ICMP]
    [Coloring Rule String: icmp || icmpv6]

IEEE 802.15.4 Data, Dst: Broadcast, Src: 31:5d:7cf9:67:f510:17
    Frame Control Field: Data (0xc841)
        .... .... .... .001 = Frame Type: Data (0x0001)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..0. .... = Acknowledge Request: False
        .... .... .1.. .... = Intra-PAN: True
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x0002)
        ..00 .... .... .... = Frame Version: 0
        11.. .... .... .... = Source Addressing Mode: Long/64-bit (0x0003)
    Sequence Number: 212
    Destination PAN: 0xbeef
    Destination: 0xffff
    Extended Source: 31:5d:7cf9:67:f510:17 (31:5d:7c:f9:67:f5:10:17)

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)
        .... .... 0... .... = Context identifier extension: False
        .... .... .0.. .... = Source address compression: Stateless
        .... .... ..11 .... = Source address mode: Compressed (0x0003)
        .... .... .... 1... = Multicast address compression: True
        .... .... .... .0.. = Destination address compression: Stateless
        .... .... .... ..01 = Destination address mode: 48-bits inline (0x0001)
        [Source context: fe80:: (fe80::)]
        [Destination context: fe80:: (fe80::)]
    Next header: ICMPv6 (0x3a)
    Source: fe80::335d:7cf9:67f5:1017 (fe80::335d:7cf9:67f5:1017)
    Destination: ff02::1:ff3e:c7f1 (ff02::1:ff3e:c7f1)

Internet Protocol Version 6, Src: fe80::335d:7cf9:67f5:1017
(fe80::335d:7cf9:67f5:1017), Dst: ff02::1:ff3e:c7f1
(ff02::1:ff3e:c7f1)
    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: 40
    Next header: ICMPv6 (58)
    Hop limit: 255
    Source: fe80::335d:7cf9:67f5:1017 (fe80::335d:7cf9:67f5:1017)
    Destination: ff02::1:ff3e:c7f1 (ff02::1:ff3e:c7f1)
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]

Internet Control Message Protocol v6
    Type: Neighbor Solicitation (135)
    Code: 0
    Checksum: 0x6354 [correct]
    Reserved: 00000000
    Target Address: fe80::a8af:ac69:e53e:c7f1 (fe80::a8af:ac69:e53e:c7f1)
    ICMPv6 Option (Source link-layer address : 31:5d:7c:f9:67:f5:10:17)
        Type: Source link-layer address (1)
        Length: 2 (16 bytes)
        Link-layer address: 31:5d:7cf9:67:f510:17 (31:5d:7c:f9:67:f5:10:17)
        Padding



No.     Time           Source                Destination
Protocol Length Info
      2 0.000001000    f1:5d:7c:f9:e7:f5:10:f7 Broadcast
IEEE 802.15.4 66     Data, Dst: Broadcast, Src: f1:5d:7cf9:e7:f510:f7

Frame 2: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on
interface 0
    Interface id: 0
    Packet flags: 0x00000000
        .... .... .... .... .... .... .... ..00 = Direction: Not
available (0x00000000)
        .... .... .... .... .... .... ...0 00.. = Reception type: Not
specified (0)
        .... .... .... .... .... ...0 000. .... = FCS length: 0
        .... .... .... .... 0000 000. .... .... = Reserved: 0
        .... ...0 .... .... .... .... .... .... = CRC error: Not set
        .... ..0. .... .... .... .... .... .... = Packet too long error: Not set
        .... .0.. .... .... .... .... .... .... = Packet too short
error: Not set
        .... 0... .... .... .... .... .... .... = Wrong interframe gap
error: Not set
        ...0 .... .... .... .... .... .... .... = Unaligned frame error: Not set
        ..0. .... .... .... .... .... .... .... = Start frame
delimiter error: Not set
        .0.. .... .... .... .... .... .... .... = Preamble error: Not set
        0... .... .... .... .... .... .... .... = Symbol error: Not set
    Encapsulation type: IEEE 802.15.4 Wireless PAN with FCS not present (127)
    Arrival Time: Jul 25, 2015 00:54:17.000001000 CEST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1437778457.000001000 seconds
    [Time delta from previous captured frame: 0.000001000 seconds]
    [Time delta from previous displayed frame: 0.000001000 seconds]
    [Time since reference or first frame: 0.000001000 seconds]
    Frame Number: 2
    Frame Length: 66 bytes (528 bits)
    Capture Length: 66 bytes (528 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wpan:data]
    [Number of per-protocol-data: 1]
    [IEEE 802.15.4 Low-Rate Wireless PAN, key 0]

IEEE 802.15.4 Data, Dst: Broadcast, Src: f1:5d:7cf9:e7:f510:f7
    Frame Control Field: Data (0xc841)
        .... .... .... .001 = Frame Type: Data (0x0001)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..0. .... = Acknowledge Request: False
        .... .... .1.. .... = Intra-PAN: True
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x0002)
        ..00 .... .... .... = Frame Version: 0
        11.. .... .... .... = Source Addressing Mode: Long/64-bit (0x0003)
    Sequence Number: 252
    Destination PAN: 0xbeef
    Destination: 0xffff
    Extended Source: f1:5d:7cf9:e7:f510:f7 (f1:5d:7c:f9:e7:f5:10:f7)
Data (51 bytes)

0000  fb f9 3a 02 01 ff 3e c7 f1 87 00 63 54 00 00 00   ..:...>....cT...
0010  00 fe 80 00 00 00 00 00 00 a8 af ac 69 e5 3e c7   ............i.>.
0020  f1 ff 02 31 dd 7c f9 e7 f5 10 17 00 00 00 00 00   ...1.|..........
0030  00 5c 4c                                          .\L
    Data: fbf93a0201ff3ec7f18700635400000000fe800000000000...
    [Length: 51]


-- 
Baptiste

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

[Baptiste Clenet]

2015-07-27 17:13 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>>> Then forget that and make some at86rf230 driver debug messages. See
>>> "print_hex_dump" [0]. Add this add skb->data in at86rf230_xmit and
>>> at86rf230_rx_read_frame_complete (but after the skb is filled with data,
>>> otherwise it makes no sense).
>>>
>>> This will allow us to see what's the lowest layer is. If the transmit
>>> side looks correct, but receive side looks weird then I suppose
>>> something is wrong again with your spi setup.
>>>
>>> The reason is that we get the lowest dump of the transmitted and
>>> received buffer and nobody touched that buffer then.
>
> I dump the packet in at86rf230_xmit and
> at86rf230_rx_read_frame_complete (just before
> ieee802154_rx_irqsafe(lp->hw, skb, lqi)). This is wireshark analyse of
> the two packets. The first one is correct and comes from the sender,
> the second is from the receiver (I manually created the hex dump file)
> which is wrong! So something seem to occur when the frame goes to the
> transceiver.
> Those dump was created with :
> root@OpenWrt:/#ieee802154_rx_irqsafe(lp->hw, skb, lqi);
>
> No.     Time           Source                Destination
> Protocol Length Info
>       1 0.000000000    fe80::335d:7cf9:67f5:1017 ff02::1:ff3e:c7f1
> ICMPv6   64     Neighbor Solicitation for fe80::a8af:ac69:e53e:c7f1
> from 31:5d:7c:f9:67:f5:10:17
>
> Frame 1: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on
> interface 0
>     Interface id: 0
>     Packet flags: 0x00000000
>         .... .... .... .... .... .... .... ..00 = Direction: Not
> available (0x00000000)
>         .... .... .... .... .... .... ...0 00.. = Reception type: Not
> specified (0)
>         .... .... .... .... .... ...0 000. .... = FCS length: 0
>         .... .... .... .... 0000 000. .... .... = Reserved: 0
>         .... ...0 .... .... .... .... .... .... = CRC error: Not set
>         .... ..0. .... .... .... .... .... .... = Packet too long error: Not set
>         .... .0.. .... .... .... .... .... .... = Packet too short
> error: Not set
>         .... 0... .... .... .... .... .... .... = Wrong interframe gap
> error: Not set
>         ...0 .... .... .... .... .... .... .... = Unaligned frame error: Not set
>         ..0. .... .... .... .... .... .... .... = Start frame
> delimiter error: Not set
>         .0.. .... .... .... .... .... .... .... = Preamble error: Not set
>         0... .... .... .... .... .... .... .... = Symbol error: Not set
>     Encapsulation type: IEEE 802.15.4 Wireless PAN with FCS not present (127)
>     Arrival Time: Jul 25, 2015 00:54:17.000000000 CEST
>     [Time shift for this packet: 0.000000000 seconds]
>     Epoch Time: 1437778457.000000000 seconds
>     [Time delta from previous captured frame: 0.000000000 seconds]
>     [Time delta from previous displayed frame: 0.000000000 seconds]
>     [Time since reference or first frame: 0.000000000 seconds]
>     Frame Number: 1
>     Frame Length: 64 bytes (512 bits)
>     Capture Length: 64 bytes (512 bits)
>     [Frame is marked: False]
>     [Frame is ignored: False]
>     [Protocols in frame: wpan:6lowpan:ipv6:icmpv6]
>     [Number of per-protocol-data: 1]
>     [IEEE 802.15.4 Low-Rate Wireless PAN, key 0]
>     [Coloring Rule Name: ICMP]
>     [Coloring Rule String: icmp || icmpv6]
>
> IEEE 802.15.4 Data, Dst: Broadcast, Src: 31:5d:7cf9:67:f510:17
>     Frame Control Field: Data (0xc841)
>         .... .... .... .001 = Frame Type: Data (0x0001)
>         .... .... .... 0... = Security Enabled: False
>         .... .... ...0 .... = Frame Pending: False
>         .... .... ..0. .... = Acknowledge Request: False
>         .... .... .1.. .... = Intra-PAN: True
>         .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x0002)
>         ..00 .... .... .... = Frame Version: 0
>         11.. .... .... .... = Source Addressing Mode: Long/64-bit (0x0003)
>     Sequence Number: 212
>     Destination PAN: 0xbeef
>     Destination: 0xffff
>     Extended Source: 31:5d:7cf9:67:f510:17 (31:5d:7c:f9:67:f5:10:17)
>
> 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)
>         .... .... 0... .... = Context identifier extension: False
>         .... .... .0.. .... = Source address compression: Stateless
>         .... .... ..11 .... = Source address mode: Compressed (0x0003)
>         .... .... .... 1... = Multicast address compression: True
>         .... .... .... .0.. = Destination address compression: Stateless
>         .... .... .... ..01 = Destination address mode: 48-bits inline (0x0001)
>         [Source context: fe80:: (fe80::)]
>         [Destination context: fe80:: (fe80::)]
>     Next header: ICMPv6 (0x3a)
>     Source: fe80::335d:7cf9:67f5:1017 (fe80::335d:7cf9:67f5:1017)
>     Destination: ff02::1:ff3e:c7f1 (ff02::1:ff3e:c7f1)
>
> Internet Protocol Version 6, Src: fe80::335d:7cf9:67f5:1017
> (fe80::335d:7cf9:67f5:1017), Dst: ff02::1:ff3e:c7f1
> (ff02::1:ff3e:c7f1)
>     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: 40
>     Next header: ICMPv6 (58)
>     Hop limit: 255
>     Source: fe80::335d:7cf9:67f5:1017 (fe80::335d:7cf9:67f5:1017)
>     Destination: ff02::1:ff3e:c7f1 (ff02::1:ff3e:c7f1)
>     [Source GeoIP: Unknown]
>     [Destination GeoIP: Unknown]
>
> Internet Control Message Protocol v6
>     Type: Neighbor Solicitation (135)
>     Code: 0
>     Checksum: 0x6354 [correct]
>     Reserved: 00000000
>     Target Address: fe80::a8af:ac69:e53e:c7f1 (fe80::a8af:ac69:e53e:c7f1)
>     ICMPv6 Option (Source link-layer address : 31:5d:7c:f9:67:f5:10:17)
>         Type: Source link-layer address (1)
>         Length: 2 (16 bytes)
>         Link-layer address: 31:5d:7cf9:67:f510:17 (31:5d:7c:f9:67:f5:10:17)
>         Padding
>
>
>
> No.     Time           Source                Destination
> Protocol Length Info
>       2 0.000001000    f1:5d:7c:f9:e7:f5:10:f7 Broadcast
> IEEE 802.15.4 66     Data, Dst: Broadcast, Src: f1:5d:7cf9:e7:f510:f7
>
> Frame 2: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on
> interface 0
>     Interface id: 0
>     Packet flags: 0x00000000
>         .... .... .... .... .... .... .... ..00 = Direction: Not
> available (0x00000000)
>         .... .... .... .... .... .... ...0 00.. = Reception type: Not
> specified (0)
>         .... .... .... .... .... ...0 000. .... = FCS length: 0
>         .... .... .... .... 0000 000. .... .... = Reserved: 0
>         .... ...0 .... .... .... .... .... .... = CRC error: Not set
>         .... ..0. .... .... .... .... .... .... = Packet too long error: Not set
>         .... .0.. .... .... .... .... .... .... = Packet too short
> error: Not set
>         .... 0... .... .... .... .... .... .... = Wrong interframe gap
> error: Not set
>         ...0 .... .... .... .... .... .... .... = Unaligned frame error: Not set
>         ..0. .... .... .... .... .... .... .... = Start frame
> delimiter error: Not set
>         .0.. .... .... .... .... .... .... .... = Preamble error: Not set
>         0... .... .... .... .... .... .... .... = Symbol error: Not set
>     Encapsulation type: IEEE 802.15.4 Wireless PAN with FCS not present (127)
>     Arrival Time: Jul 25, 2015 00:54:17.000001000 CEST
>     [Time shift for this packet: 0.000000000 seconds]
>     Epoch Time: 1437778457.000001000 seconds
>     [Time delta from previous captured frame: 0.000001000 seconds]
>     [Time delta from previous displayed frame: 0.000001000 seconds]
>     [Time since reference or first frame: 0.000001000 seconds]
>     Frame Number: 2
>     Frame Length: 66 bytes (528 bits)
>     Capture Length: 66 bytes (528 bits)
>     [Frame is marked: False]
>     [Frame is ignored: False]
>     [Protocols in frame: wpan:data]
>     [Number of per-protocol-data: 1]
>     [IEEE 802.15.4 Low-Rate Wireless PAN, key 0]
>
> IEEE 802.15.4 Data, Dst: Broadcast, Src: f1:5d:7cf9:e7:f510:f7
>     Frame Control Field: Data (0xc841)
>         .... .... .... .001 = Frame Type: Data (0x0001)
>         .... .... .... 0... = Security Enabled: False
>         .... .... ...0 .... = Frame Pending: False
>         .... .... ..0. .... = Acknowledge Request: False
>         .... .... .1.. .... = Intra-PAN: True
>         .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x0002)
>         ..00 .... .... .... = Frame Version: 0
>         11.. .... .... .... = Source Addressing Mode: Long/64-bit (0x0003)
>     Sequence Number: 252
>     Destination PAN: 0xbeef
>     Destination: 0xffff
>     Extended Source: f1:5d:7cf9:e7:f510:f7 (f1:5d:7c:f9:e7:f5:10:f7)
> Data (51 bytes)
>
> 0000  fb f9 3a 02 01 ff 3e c7 f1 87 00 63 54 00 00 00   ..:...>....cT...
> 0010  00 fe 80 00 00 00 00 00 00 a8 af ac 69 e5 3e c7   ............i.>.
> 0020  f1 ff 02 31 dd 7c f9 e7 f5 10 17 00 00 00 00 00   ...1.|..........
> 0030  00 5c 4c                                          .\L
>     Data: fbf93a0201ff3ec7f18700635400000000fe800000000000...
>     [Length: 51]
>
>
> --
> Baptiste


I've observed something, if I don't dump the sending packet, I receive
a different one on the receiver:
No.     Time           Source                Destination
Protocol Length Info
      1 0.000001000    ::639:10d1:8b6d:141e  ff01::ff:3ec7:f187
IGMPv0   66     Unknown Type:0x00

Frame 1: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on
interface 0
    Interface id: 0
    Packet flags: 0x00000000
        .... .... .... .... .... .... .... ..00 = Direction: Not
available (0x00000000)
        .... .... .... .... .... .... ...0 00.. = Reception type: Not
specified (0)
        .... .... .... .... .... ...0 000. .... = FCS length: 0
        .... .... .... .... 0000 000. .... .... = Reserved: 0
        .... ...0 .... .... .... .... .... .... = CRC error: Not set
        .... ..0. .... .... .... .... .... .... = Packet too long error: Not set
        .... .0.. .... .... .... .... .... .... = Packet too short
error: Not set
        .... 0... .... .... .... .... .... .... = Wrong interframe gap
error: Not set
        ...0 .... .... .... .... .... .... .... = Unaligned frame error: Not set
        ..0. .... .... .... .... .... .... .... = Start frame
delimiter error: Not set
        .0.. .... .... .... .... .... .... .... = Preamble error: Not set
        0... .... .... .... .... .... .... .... = Symbol error: Not set
    Encapsulation type: IEEE 802.15.4 Wireless PAN with FCS not present (127)
    Arrival Time: Jul 25, 2015 01:41:02.000001000 CEST
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1437781262.000001000 seconds
    [Time delta from previous captured frame: 0.000001000 seconds]
    [Time delta from previous displayed frame: 0.000001000 seconds]
    [Time since reference or first frame: 0.000001000 seconds]
    Frame Number: 1
    Frame Length: 66 bytes (528 bits)
    Capture Length: 66 bytes (528 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: 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]
IEEE 802.15.4 Data, Dst: Broadcast, Src: 04:39:10d1:8b:6d14:1e
    Frame Control Field: Data (0xc841)
        .... .... .... .001 = Frame Type: Data (0x0001)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..0. .... = Acknowledge Request: False
        .... .... .1.. .... = Intra-PAN: True
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x0002)
        ..00 .... .... .... = Frame Version: 0
        11.. .... .... .... = Source Addressing Mode: Long/64-bit (0x0003)
    Sequence Number: 132
    Destination PAN: 0xbeef
    Destination: 0xffff
    Extended Source: 04:39:10d1:8b:6d14:1e (04:39:10:d1:8b:6d:14:1e)
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)
        .... .... .... 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: ::639:10d1:8b6d:141e (::639:10d1:8b6d:141e)
    Destination: ff01::ff:3ec7:f187 (ff01::ff:3ec7:f187)
Internet Protocol Version 6, Src: ::639:10d1:8b6d:141e
(::639:10d1:8b6d:141e), Dst: ff01::ff:3ec7:f187 (ff01::ff:3ec7:f187)
    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: 41
    Next header: IGMP (2)
    Hop limit: 255
    Source: ::639:10d1:8b6d:141e (::639:10d1:8b6d:141e)
    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: 70
    Header checksum: 0xef00 [incorrect, should be 0x6481]
    Identifier: 254
    Multicast Address: 128.0.0.0 (128.0.0.0)
    Access Key: 000000a8afac69e5
    Type: Unknown (0x00)
    Data

-- 
Baptiste

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

[Alexander Aring]

Hi,

please don't send me tcpdumps from interfaces. Instrument the driver,
which is the lowest level which we have, for dumping the framebuffer at
before willing at xmit function and on receiving. Don't know exactly
the function inside at86rf230 driver, I said that previously.

If the transmitted frame and received frame is different, then I don't
know what's going on there and can't help you. It seems for me that your
spi functionality is broken.

The reason why you should not dump the wpan/lowpan interface is that the
data goes through the layers and I will detect if the raw data which
should be transmitted is correctly received. If not -> something weird
goes wrong. And again, I would not trust the wpan/lowpan dumps because
it will goes through layers which "could maybe" manipulate the raw data.

My consideration was look if the "raw" data is correct, because we don't
do anything which "raw" data. If you send "0xabcd" as frame to some node
and the receiving node receives "0xefgh" then something goes wrong with
the transceiver and I don't know why. So please capture the raw data
with the printk_hex_dump functionality and do a diff afterwards. On
transmit and receiving side.

- Alex

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

[Alexander Aring]

On Mon, Jul 27, 2015 at 05:55:27PM +0200, Baptiste Clenet wrote:
> 2015-07-27 17:13 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> >>> Then forget that and make some at86rf230 driver debug messages. See
> >>> "print_hex_dump" [0]. Add this add skb->data in at86rf230_xmit and
> >>> at86rf230_rx_read_frame_complete (but after the skb is filled with data,
> >>> otherwise it makes no sense).
> >>>
> >>> This will allow us to see what's the lowest layer is. If the transmit
> >>> side looks correct, but receive side looks weird then I suppose
> >>> something is wrong again with your spi setup.
> >>>
> >>> The reason is that we get the lowest dump of the transmitted and
> >>> received buffer and nobody touched that buffer then.
> >
> > I dump the packet in at86rf230_xmit and
> > at86rf230_rx_read_frame_complete (just before
> > ieee802154_rx_irqsafe(lp->hw, skb, lqi)). This is wireshark analyse of
> > the two packets. The first one is correct and comes from the sender,
> > the second is from the receiver (I manually created the hex dump file)
> > which is wrong! So something seem to occur when the frame goes to the
> > transceiver.

ah, sorry I misunderstood you. So you have capture the raw data for
transmit and receiving and it differs. Then I have still no idea what's
wrong on your side. :-)

- Alex

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

[Baptiste Clenet]

2015-07-27 19:28 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> On Mon, Jul 27, 2015 at 05:55:27PM +0200, Baptiste Clenet wrote:
>> 2015-07-27 17:13 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>> >>> Then forget that and make some at86rf230 driver debug messages. See
>> >>> "print_hex_dump" [0]. Add this add skb->data in at86rf230_xmit and
>> >>> at86rf230_rx_read_frame_complete (but after the skb is filled with data,
>> >>> otherwise it makes no sense).
>> >>>
>> >>> This will allow us to see what's the lowest layer is. If the transmit
>> >>> side looks correct, but receive side looks weird then I suppose
>> >>> something is wrong again with your spi setup.
>> >>>
>> >>> The reason is that we get the lowest dump of the transmitted and
>> >>> received buffer and nobody touched that buffer then.
>> >
>> > I dump the packet in at86rf230_xmit and
>> > at86rf230_rx_read_frame_complete (just before
>> > ieee802154_rx_irqsafe(lp->hw, skb, lqi)). This is wireshark analyse of
>> > the two packets. The first one is correct and comes from the sender,
>> > the second is from the receiver (I manually created the hex dump file)
>> > which is wrong! So something seem to occur when the frame goes to the
>> > transceiver.
>
> ah, sorry I misunderstood you. So you have capture the raw data for
> transmit and receiving and it differs. Then I have still no idea what's
> wrong on your side. :-)
>
> - Alex

Yes it's what I did :-)
But you gave me an idea by saying that I should send only 0xabcd and
see if I receive the same. Which is the easiest way to send 0xabcd as
a raw value? at86rf230_xmit requires struct ieee802154_hw *hw, struct
sk_buff *skb and at86rf230_xmit_start a void *context. Why don't we
have a simple at86rf230_send_raw_data :-)

-- 
Baptiste

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

[Alexander Aring]

On Mon, Jul 27, 2015 at 07:43:13PM +0200, Baptiste Clenet wrote:
> 2015-07-27 19:28 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> > On Mon, Jul 27, 2015 at 05:55:27PM +0200, Baptiste Clenet wrote:
> >> 2015-07-27 17:13 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> >> >>> Then forget that and make some at86rf230 driver debug messages. See
> >> >>> "print_hex_dump" [0]. Add this add skb->data in at86rf230_xmit and
> >> >>> at86rf230_rx_read_frame_complete (but after the skb is filled with data,
> >> >>> otherwise it makes no sense).
> >> >>>
> >> >>> This will allow us to see what's the lowest layer is. If the transmit
> >> >>> side looks correct, but receive side looks weird then I suppose
> >> >>> something is wrong again with your spi setup.
> >> >>>
> >> >>> The reason is that we get the lowest dump of the transmitted and
> >> >>> received buffer and nobody touched that buffer then.
> >> >
> >> > I dump the packet in at86rf230_xmit and
> >> > at86rf230_rx_read_frame_complete (just before
> >> > ieee802154_rx_irqsafe(lp->hw, skb, lqi)). This is wireshark analyse of
> >> > the two packets. The first one is correct and comes from the sender,
> >> > the second is from the receiver (I manually created the hex dump file)
> >> > which is wrong! So something seem to occur when the frame goes to the
> >> > transceiver.
> >
> > ah, sorry I misunderstood you. So you have capture the raw data for
> > transmit and receiving and it differs. Then I have still no idea what's
> > wrong on your side. :-)
> >
> > - Alex
> 
> Yes it's what I did :-)
> But you gave me an idea by saying that I should send only 0xabcd and
> see if I receive the same. Which is the easiest way to send 0xabcd as
> a raw value? at86rf230_xmit requires struct ieee802154_hw *hw, struct
> sk_buff *skb and at86rf230_xmit_start a void *context. Why don't we
> have a simple at86rf230_send_raw_data :-)
> 

Your use case smells like a 802.15.4 raw socket for the raw data from
userspace. But I would send only "0xabcd" this is an invalid 802.15.4
frame and will be filtered. Simple use some data like 6LoWPAN maybe your
issue occurs on high payload only. This would clarify why your
transceiver is right detected and such things (reading/writing
registers).

- Alex