ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages

ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages

[Baptiste Clenet]

Hi,

Here is how I set the network:
modprobe at86rf230
iwpan dev wpan0 set pan_id 0xbeef
ip link set wpan0 up
ip link add link wpan0 name lowpan0 type lowpan
ip link set lowpan0 up

Then I try to do:
ping6 -I lowpan0 fe80::a8af:ac69:e53e:c7f1

Nothing is sent. (I checked by sniffing the SPI pins). No errors from
ping6 or other layers in the network stack.

root@OpenWrt:/# ifconfig
lowpan0   Link encap:UNSPEC  HWaddr
05-38-09-06-90-E0-5E-3E-00-00-00-00-00-00-00-00
          inet6 addr: fe80::738:906:90e0:5e3e/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
05-38-09-06-90-E0-5E-3E-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING NOARP  MTU:127  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:300
          RX bytes:0 (0.0 B)  TX bytes:75 (75.0 B)

(TX bytes:75 (75.0 B), seems to be sent when you up lowpan0 ?)


Is my settings right? What should I check to make sure the data goes
from each layer of the network stack?

Regards,

-- 
Baptiste

Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages

[Baptiste Clenet]

2015-07-13 16:59 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> Hi,
>
> Here is how I set the network:
> modprobe at86rf230
> iwpan dev wpan0 set pan_id 0xbeef
> ip link set wpan0 up
> ip link add link wpan0 name lowpan0 type lowpan
> ip link set lowpan0 up
>
> Then I try to do:
> ping6 -I lowpan0 fe80::a8af:ac69:e53e:c7f1
>
> Nothing is sent. (I checked by sniffing the SPI pins). No errors from
> ping6 or other layers in the network stack.
>
> root@OpenWrt:/# ifconfig
> lowpan0   Link encap:UNSPEC  HWaddr
> 05-38-09-06-90-E0-5E-3E-00-00-00-00-00-00-00-00
>           inet6 addr: fe80::738:906:90e0:5e3e/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
> 05-38-09-06-90-E0-5E-3E-00-00-00-00-00-00-00-00
>           UP BROADCAST RUNNING NOARP  MTU:127  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:300
>           RX bytes:0 (0.0 B)  TX bytes:75 (75.0 B)
>
> (TX bytes:75 (75.0 B), seems to be sent when you up lowpan0 ?)
>
>
> Is my settings right? What should I check to make sure the data goes
> from each layer of the network stack?
>
> Regards,
>
> --
> Baptiste

More info:
Running Linux 4.1.0

root@OpenWrt:/# ip link
6: wpan0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 127 qdisc fq_codel state
UNKNOWN mode DEFAULT group default qlen 300
    link/ieee802.15.4 ef:57:b2:a9:2f:4e:90:76 brd ff:ff:ff:ff:ff:ff:ff:ff
7: lowpan0@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc
noqueue state UNKNOWN mode DEFAULT group default
    link/[825] ef:57:b2:a9:2f:4e:90:76 brd ff:ff:ff:ff:ff:ff:ff:ff

root@OpenWrt:/# iwpan phy
wpan_phy phy0
supported channels:
        page 0: 0,1,2,3,4,5,6,7,8,9,10
        page 2: 0,1,2,3,4,5,6,7,8,9,10
current_page: 0
current_channel: 5
cca_mode: 1
tx_power: 0

root@OpenWrt:/# iwpan dev
phy#0
        Interface wpan0
                ifindex 6
                wpan_dev 0x1
                extended_addr 0xef57b2a92f4e9076
                short_addr 0xffff
                pan_id 0xbeef
                type node
                max_frame_retries -1
                min_be 3
                max_be 5
                max_csma_backoffs 4
                lbt 0

Let me know if you need more info.

-- 
Baptiste

Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages

[Alexander Aring]

Hi,

On Mon, Jul 13, 2015 at 06:18:47PM +0200, Baptiste Clenet wrote:
> 2015-07-13 16:59 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> > Hi,
> >
> > Here is how I set the network:
> > modprobe at86rf230
> > iwpan dev wpan0 set pan_id 0xbeef
> > ip link set wpan0 up
> > ip link add link wpan0 name lowpan0 type lowpan
> > ip link set lowpan0 up
> >
> > Then I try to do:
> > ping6 -I lowpan0 fe80::a8af:ac69:e53e:c7f1
> >
> > Nothing is sent. (I checked by sniffing the SPI pins). No errors from
> > ping6 or other layers in the network stack.
> >
> > root@OpenWrt:/# ifconfig
> > lowpan0   Link encap:UNSPEC  HWaddr
> > 05-38-09-06-90-E0-5E-3E-00-00-00-00-00-00-00-00
> >           inet6 addr: fe80::738:906:90e0:5e3e/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
> > 05-38-09-06-90-E0-5E-3E-00-00-00-00-00-00-00-00
> >           UP BROADCAST RUNNING NOARP  MTU:127  Metric:1
> >           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> >           TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
> >           collisions:0 txqueuelen:300
> >           RX bytes:0 (0.0 B)  TX bytes:75 (75.0 B)
> >
> > (TX bytes:75 (75.0 B), seems to be sent when you up lowpan0 ?)
> >

Yes, this is because the IPv6 neighbor discovery protocol. (We don't
increment the lowpan interface stats currently), but this should be some
patch later which increments the "uncompressed" part of 6LoWPAN ->
simple IPv6 view, this is also what wireshark offers you on this
interface.

> >
> > Is my settings right? What should I check to make sure the data goes
> > from each layer of the network stack?
> >

Yes, the setting is right.

I have no idea why it doesn't work on your side. That the "tx stats" of
wpan interface are incremented shows me it runs the code at [0].

Before we call "drv_xmit_async" which calls the function at [1].

Maybe you can do some 'printk(KERN_INFO "foobar\n")' at [1] to see if
you really call that function in driver layer, but it should.

Do you see SPI traffic while probing? Because at [2] we have some
id registers reads. If you don't see spi traffic and it probes
successful then your sniffing setup seems wrong. If you see spi traffic
then it seems to be correct and something is different in openwrt when
calling ?spi_async?.

Do you use now the software spi bit banging driver over gpio's?


- Alex

[0] http://lxr.free-electrons.com/source/net/mac802154/tx.c#L106
[1] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L1027
[2] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L1648

Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages

[Baptiste Clenet]

2015-07-13 19:48 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> Hi,
>
> On Mon, Jul 13, 2015 at 06:18:47PM +0200, Baptiste Clenet wrote:
>> 2015-07-13 16:59 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>> > Hi,
>> >
>> > Here is how I set the network:
>> > modprobe at86rf230
>> > iwpan dev wpan0 set pan_id 0xbeef
>> > ip link set wpan0 up
>> > ip link add link wpan0 name lowpan0 type lowpan
>> > ip link set lowpan0 up
>> >
>> > Then I try to do:
>> > ping6 -I lowpan0 fe80::a8af:ac69:e53e:c7f1
>> >
>> > Nothing is sent. (I checked by sniffing the SPI pins). No errors from
>> > ping6 or other layers in the network stack.
>> >
>> > root@OpenWrt:/# ifconfig
>> > lowpan0   Link encap:UNSPEC  HWaddr
>> > 05-38-09-06-90-E0-5E-3E-00-00-00-00-00-00-00-00
>> >           inet6 addr: fe80::738:906:90e0:5e3e/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
>> > 05-38-09-06-90-E0-5E-3E-00-00-00-00-00-00-00-00
>> >           UP BROADCAST RUNNING NOARP  MTU:127  Metric:1
>> >           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> >           TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
>> >           collisions:0 txqueuelen:300
>> >           RX bytes:0 (0.0 B)  TX bytes:75 (75.0 B)
>> >
>> > (TX bytes:75 (75.0 B), seems to be sent when you up lowpan0 ?)
>> >
>
> Yes, this is because the IPv6 neighbor discovery protocol. (We don't
> increment the lowpan interface stats currently), but this should be some
> patch later which increments the "uncompressed" part of 6LoWPAN ->
> simple IPv6 view, this is also what wireshark offers you on this
> interface.

Ok thanks.

>
>> >
>> > Is my settings right? What should I check to make sure the data goes
>> > from each layer of the network stack?
>> >
>
> Yes, the setting is right.
>
> I have no idea why it doesn't work on your side. That the "tx stats" of
> wpan interface are incremented shows me it runs the code at [0].
>
> Before we call "drv_xmit_async" which calls the function at [1].
>
> Maybe you can do some 'printk(KERN_INFO "foobar\n")' at [1] to see if
> you really call that function in driver layer, but it should.

Yes, it goes to 'at86rf230_xmit()' when lowpan goes up. That explains
the 75Bytes

>
> Do you see SPI traffic while probing? Because at [2] we have some
> id registers reads. If you don't see spi traffic and it probes
> successful then your sniffing setup seems wrong. If you see spi traffic
> then it seems to be correct and something is different in openwrt when
> calling ?spi_async?.
>

The probe runs well, I see all the exchange data (SPI traffic), it
detects the chip version of the transceiver, Write frame buffer works
great as well. The driver works with the transceiver, I think the
problem comes from upper layer.
The thing is, calling 'ip link set lowpan0 up ' goes to
'at86rf230_xmit()' and I see the data transmitted over the SPI pins
which is fine but when I try to ping6, it never goes to
'at86rf230_xmit()' and there is no data exchange on the bus.

> Do you use now the software spi bit banging driver over gpio's?
Yes I use software spi bit banging driver over gpio's which works great.
>
>
> - Alex
>
> [0] http://lxr.free-electrons.com/source/net/mac802154/tx.c#L106
> [1] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L1027
> [2] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L1648


ip link gives me that:

root@OpenWrt:/# ip link
6: wpan0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 127 qdisc fq_codel state
UNKNOWN mode DEFAULT group default qlen 300
    link/ieee802.15.4 ef:57:b2:a9:2f:4e:90:76 brd ff:ff:ff:ff:ff:ff:ff:ff
7: lowpan0@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc
noqueue state UNKNOWN mode DEFAULT group default
    link/[825] ef:57:b2:a9:2f:4e:90:76 brd ff:ff:ff:ff:ff:ff:ff:ff

I'm wondering what [825] means? Shouldn't it be ieee802.15.4 instead?
What does ping6 -I lowpan0? Does it create an ICMP6 socket? How is
ping6 connected to lowpan0 interface? (I mean in the source code)
-- 
Baptiste

Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages

[Baptiste Clenet]

2015-07-14 12:56 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> 2015-07-13 19:48 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> Hi,
>>
>> On Mon, Jul 13, 2015 at 06:18:47PM +0200, Baptiste Clenet wrote:
>>> 2015-07-13 16:59 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
>>> > Hi,
>>> >
>>> > Here is how I set the network:
>>> > modprobe at86rf230
>>> > iwpan dev wpan0 set pan_id 0xbeef
>>> > ip link set wpan0 up
>>> > ip link add link wpan0 name lowpan0 type lowpan
>>> > ip link set lowpan0 up
>>> >
>>> > Then I try to do:
>>> > ping6 -I lowpan0 fe80::a8af:ac69:e53e:c7f1
>>> >
>>> > Nothing is sent. (I checked by sniffing the SPI pins). No errors from
>>> > ping6 or other layers in the network stack.
>>> >
>>> > root@OpenWrt:/# ifconfig
>>> > lowpan0   Link encap:UNSPEC  HWaddr
>>> > 05-38-09-06-90-E0-5E-3E-00-00-00-00-00-00-00-00
>>> >           inet6 addr: fe80::738:906:90e0:5e3e/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
>>> > 05-38-09-06-90-E0-5E-3E-00-00-00-00-00-00-00-00
>>> >           UP BROADCAST RUNNING NOARP  MTU:127  Metric:1
>>> >           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>> >           TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
>>> >           collisions:0 txqueuelen:300
>>> >           RX bytes:0 (0.0 B)  TX bytes:75 (75.0 B)
>>> >
>>> > (TX bytes:75 (75.0 B), seems to be sent when you up lowpan0 ?)
>>> >
>>
>> Yes, this is because the IPv6 neighbor discovery protocol. (We don't
>> increment the lowpan interface stats currently), but this should be some
>> patch later which increments the "uncompressed" part of 6LoWPAN ->
>> simple IPv6 view, this is also what wireshark offers you on this
>> interface.
>
> Ok thanks.
>
>>
>>> >
>>> > Is my settings right? What should I check to make sure the data goes
>>> > from each layer of the network stack?
>>> >
>>
>> Yes, the setting is right.
>>
>> I have no idea why it doesn't work on your side. That the "tx stats" of
>> wpan interface are incremented shows me it runs the code at [0].
>>
>> Before we call "drv_xmit_async" which calls the function at [1].
>>
>> Maybe you can do some 'printk(KERN_INFO "foobar\n")' at [1] to see if
>> you really call that function in driver layer, but it should.
>
> Yes, it goes to 'at86rf230_xmit()' when lowpan goes up. That explains
> the 75Bytes
>
>>
>> Do you see SPI traffic while probing? Because at [2] we have some
>> id registers reads. If you don't see spi traffic and it probes
>> successful then your sniffing setup seems wrong. If you see spi traffic
>> then it seems to be correct and something is different in openwrt when
>> calling ?spi_async?.
>>
>
> The probe runs well, I see all the exchange data (SPI traffic), it
> detects the chip version of the transceiver, Write frame buffer works
> great as well. The driver works with the transceiver, I think the
> problem comes from upper layer.
> The thing is, calling 'ip link set lowpan0 up ' goes to
> 'at86rf230_xmit()' and I see the data transmitted over the SPI pins
> which is fine but when I try to ping6, it never goes to
> 'at86rf230_xmit()' and there is no data exchange on the bus.
>
>> Do you use now the software spi bit banging driver over gpio's?
> Yes I use software spi bit banging driver over gpio's which works great.
>>
>>
>> - Alex
>>
>> [0] http://lxr.free-electrons.com/source/net/mac802154/tx.c#L106
>> [1] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L1027
>> [2] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L1648
>
>
> ip link gives me that:
>
> root@OpenWrt:/# ip link
> 6: wpan0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 127 qdisc fq_codel state
> UNKNOWN mode DEFAULT group default qlen 300
>     link/ieee802.15.4 ef:57:b2:a9:2f:4e:90:76 brd ff:ff:ff:ff:ff:ff:ff:ff
> 7: lowpan0@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc
> noqueue state UNKNOWN mode DEFAULT group default
>     link/[825] ef:57:b2:a9:2f:4e:90:76 brd ff:ff:ff:ff:ff:ff:ff:ff
>
> I'm wondering what [825] means? Shouldn't it be ieee802.15.4 instead?
> What does ping6 -I lowpan0? Does it create an ICMP6 socket? How is
> ping6 connected to lowpan0 interface? (I mean in the source code)
> --
> Baptiste

Could you tell me what should be the result of:
cat ./sys/devices/virtual/net/lowpan0/type
I get 825 and for wpan 0, it is 804


-- 
Baptiste

Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages

[Alexander Aring]

On Tue, Jul 14, 2015 at 07:45:52PM +0200, Baptiste Clenet wrote:
...
> >
> > The probe runs well, I see all the exchange data (SPI traffic), it
> > detects the chip version of the transceiver, Write frame buffer works
> > great as well. The driver works with the transceiver, I think the
> > problem comes from upper layer.
> > The thing is, calling 'ip link set lowpan0 up ' goes to
> > 'at86rf230_xmit()' and I see the data transmitted over the SPI pins
> > which is fine but when I try to ping6, it never goes to
> > 'at86rf230_xmit()' and there is no data exchange on the bus.
> >

I have no idea why you have this problem. Everything should be fine to
use "ping6 -I lowpan0 ....".

> >> Do you use now the software spi bit banging driver over gpio's?
> > Yes I use software spi bit banging driver over gpio's which works great.
> >>
> >>
> >> - Alex
> >>
> >> [0] http://lxr.free-electrons.com/source/net/mac802154/tx.c#L106
> >> [1] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L1027
> >> [2] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L1648
> >
> >
> > ip link gives me that:
> >
> > root@OpenWrt:/# ip link
> > 6: wpan0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 127 qdisc fq_codel state
> > UNKNOWN mode DEFAULT group default qlen 300
> >     link/ieee802.15.4 ef:57:b2:a9:2f:4e:90:76 brd ff:ff:ff:ff:ff:ff:ff:ff
> > 7: lowpan0@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc
> > noqueue state UNKNOWN mode DEFAULT group default
> >     link/[825] ef:57:b2:a9:2f:4e:90:76 brd ff:ff:ff:ff:ff:ff:ff:ff
> >
> > I'm wondering what [825] means? Shouldn't it be ieee802.15.4 instead?
> > What does ping6 -I lowpan0? Does it create an ICMP6 socket? How is

So fat I know, ping6 utility opens an IPv6 raw socket, then you can
generate the ICMPv6 header inside the userspace. See [4].

I also saw some example which use ETH raw sockets and build the complete
mac + ipv6 + ICMPv6 inside userspace, see [5] "ping6_ll.c".

Indeed the example at [5] should not work on lowpan interface, but I
don't think that there are "ping6" implementation outside which works
like this.


Which ping6 implementation do you use, the one from busybox?

> > ping6 connected to lowpan0 interface? (I mean in the source code)

Yea, I need to write some more documentation. Maybe look at my draft for
make some "global (maybe not enough detailed) stack architecture" ascii
art [1].

You will see the 6lowpan box sends frames via "dev_queue_xmit" [2] and
receives frames from the linux packet layer [3].

Don't know what I should tell here more about "how it works", on sending
the lowpan interface puts frames via dev_queue_xmit into wpan interface
and on receiving we make 6LoWPAN to IPv6. 6LoWPAN is an adaptation
layer. The lowpan interface to this adaptation.

btw:

(Okay it's not really true that we can do everything as adaptation, you
maybe saw the 6CO question on the last mails which I haven't time yet to
review. In this case the IPv6 stack need to know something from 6LoWPAN
stack.) Or the other option would be to reparse and regenerate the
IPv6/ICMPv6 headers, but this sounds crazy.

> 
> Could you tell me what should be the result of:
> cat ./sys/devices/virtual/net/lowpan0/type
> I get 825 and for wpan 0, it is 804
> 

That's fine, they are different interface types. wpan interfaces it's
802.15.4. lowpan is IPv6. See [0].

Some userspace application will check that, e.g. wireshark will indicate
parse frames as 802.15.4 if it's ARPHRD_IEEE802154 and parse IPv6 if
it's ARPHRD_6LOWPAN. 

- Alex

[0] http://lxr.free-electrons.com/source/include/uapi/linux/if_arp.h#L89
[1] https://raw.githubusercontent.com/linux-wpan/wpan-misc/master/architecture/general/wpan
[2] http://lxr.free-electrons.com/source/net/ieee802154/6lowpan/tx.c#L262
[3] http://lxr.free-electrons.com/source/net/ieee802154/6lowpan/rx.c#L160
[4] https://github.com/iputils/iputils/blob/master/ping.c#L444
[5] http://www.pdbuchan.com/rawsock/rawsock.html

Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages

[Baptiste Clenet]

2015-07-14 20:11 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> On Tue, Jul 14, 2015 at 07:45:52PM +0200, Baptiste Clenet wrote:
> ...
>> >
>> > The probe runs well, I see all the exchange data (SPI traffic), it
>> > detects the chip version of the transceiver, Write frame buffer works
>> > great as well. The driver works with the transceiver, I think the
>> > problem comes from upper layer.
>> > The thing is, calling 'ip link set lowpan0 up ' goes to
>> > 'at86rf230_xmit()' and I see the data transmitted over the SPI pins
>> > which is fine but when I try to ping6, it never goes to
>> > 'at86rf230_xmit()' and there is no data exchange on the bus.
>> >
>
> I have no idea why you have this problem. Everything should be fine to
> use "ping6 -I lowpan0 ....".
>
>> >> Do you use now the software spi bit banging driver over gpio's?
>> > Yes I use software spi bit banging driver over gpio's which works great.
>> >>
>> >>
>> >> - Alex
>> >>
>> >> [0] http://lxr.free-electrons.com/source/net/mac802154/tx.c#L106
>> >> [1] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L1027
>> >> [2] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L1648
>> >
>> >
>> > ip link gives me that:
>> >
>> > root@OpenWrt:/# ip link
>> > 6: wpan0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 127 qdisc fq_codel state
>> > UNKNOWN mode DEFAULT group default qlen 300
>> >     link/ieee802.15.4 ef:57:b2:a9:2f:4e:90:76 brd ff:ff:ff:ff:ff:ff:ff:ff
>> > 7: lowpan0@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc
>> > noqueue state UNKNOWN mode DEFAULT group default
>> >     link/[825] ef:57:b2:a9:2f:4e:90:76 brd ff:ff:ff:ff:ff:ff:ff:ff
>> >
>> > I'm wondering what [825] means? Shouldn't it be ieee802.15.4 instead?
>> > What does ping6 -I lowpan0? Does it create an ICMP6 socket? How is
>
> So fat I know, ping6 utility opens an IPv6 raw socket, then you can
> generate the ICMPv6 header inside the userspace. See [4].
>
> I also saw some example which use ETH raw sockets and build the complete
> mac + ipv6 + ICMPv6 inside userspace, see [5] "ping6_ll.c".
>
> Indeed the example at [5] should not work on lowpan interface, but I
> don't think that there are "ping6" implementation outside which works
> like this.
>
>
> Which ping6 implementation do you use, the one from busybox?
Yes from busybox v1.23.2, iputils-s20101006 downloaded from
http://www.skbuff.net/iputils.
it differs a bit from the latest version, I'm going to try the latest
release (iputils-s20121221.tar.bz2)
OpenWRT adds some patches to iputil so I would need to review thes
patches before going to the new version.

How could I try that it actually works with something else than ping6?

>
>> > ping6 connected to lowpan0 interface? (I mean in the source code)
>
> Yea, I need to write some more documentation. Maybe look at my draft for
> make some "global (maybe not enough detailed) stack architecture" ascii
> art [1].

I need to go through all the layers to see where it fails (without
saying any errors...)
Your architecture is great! Thanks, I see that while using IPV6, we
don't use i802154 socket, this is what I was observing earlier, so
that seems ok.


> You will see the 6lowpan box sends frames via "dev_queue_xmit" [2] and
> receives frames from the linux packet layer [3].
>
> Don't know what I should tell here more about "how it works", on sending
> the lowpan interface puts frames via dev_queue_xmit into wpan interface
> and on receiving we make 6LoWPAN to IPv6. 6LoWPAN is an adaptation
> layer. The lowpan interface to this adaptation.
>
> btw:
>
> (Okay it's not really true that we can do everything as adaptation, you
> maybe saw the 6CO question on the last mails which I haven't time yet to
> review. In this case the IPv6 stack need to know something from 6LoWPAN
> stack.) Or the other option would be to reparse and regenerate the
> IPv6/ICMPv6 headers, but this sounds crazy.
>
>>
>> Could you tell me what should be the result of:
>> cat ./sys/devices/virtual/net/lowpan0/type
>> I get 825 and for wpan 0, it is 804
>>
>
> That's fine, they are different interface types. wpan interfaces it's
> 802.15.4. lowpan is IPv6. See [0].
>
> Some userspace application will check that, e.g. wireshark will indicate
> parse frames as 802.15.4 if it's ARPHRD_IEEE802154 and parse IPv6 if
> it's ARPHRD_6LOWPAN.
>
> - Alex
>
> [0] http://lxr.free-electrons.com/source/include/uapi/linux/if_arp.h#L89
> [1] https://raw.githubusercontent.com/linux-wpan/wpan-misc/master/architecture/general/wpan
> [2] http://lxr.free-electrons.com/source/net/ieee802154/6lowpan/tx.c#L262
> [3] http://lxr.free-electrons.com/source/net/ieee802154/6lowpan/rx.c#L160
> [4] https://github.com/iputils/iputils/blob/master/ping.c#L444
> [5] http://www.pdbuchan.com/rawsock/rawsock.html

Ok, thanks for your explanation. What can say now is, it goes to
dev_queue_xmit each time but not to at86rf230_xmit.

While setting up lowpan 0, 7 messages are sent (dev_queue_xmit) but
actually only one is sent to the 230! because only one at86rf230_xmit
is called.
So I'm wondering if IRQ has something to do with that? It feels like
the at86rf230 is locked and can't send more messages.

-- 
Baptiste

Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages

[Baptiste Clenet]

Kind of a backtrace (printk at each beginning of a function)
root@OpenWrt:/# ip link set lowpan0 up
[  214.708111] lowpan_header_create
[  214.714520] lowpan_xmit
[  214.719378] lowpan_header
[  214.724569] tx.c dev_queue_xmit
[  214.727769] at86rf230_xmit (I added a printk here as well)
[  214.730795] at86rf230_xmit_start
[  214.737669] at86rf230_write_frame
[  214.745539] at86rf230_write_frame_complete
[  214.828082] lowpan_header_create
[  214.834484] lowpan_xmit
[  214.839334] lowpan_header
[  214.844523] tx.c dev_queue_xmit
[  215.368119] lowpan_header_create
[  215.374529] lowpan_xmit
[  215.379398] lowpan_header
[  215.384589] tx.c dev_queue_xmit
[  216.368196] lowpan_header_create
[  216.374604] lowpan_xmit
[  216.379468] lowpan_header
[  216.384658] tx.c dev_queue_xmit
[  216.390934] lowpan_header_create
[  216.397319] lowpan_xmit
[  216.402168] lowpan_header
[  216.407351] tx.c dev_queue_xmit
[  216.898090] lowpan_header_create
[  216.904496] lowpan_xmit
[  216.909350] lowpan_header
[  216.914539] tx.c dev_queue_xmit
[  216.978063] lowpan_header_create
[  216.984464] lowpan_xmit
[  216.989312] lowpan_header
[  216.994498] tx.c dev_queue_xmit

You see that at86rf230_xmit_start is called only once so I seems
logical that while doing a ping6, it's not called as well.

2015-07-14 23:18 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> 2015-07-14 20:11 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> On Tue, Jul 14, 2015 at 07:45:52PM +0200, Baptiste Clenet wrote:
>> ...
>>> >
>>> > The probe runs well, I see all the exchange data (SPI traffic), it
>>> > detects the chip version of the transceiver, Write frame buffer works
>>> > great as well. The driver works with the transceiver, I think the
>>> > problem comes from upper layer.
>>> > The thing is, calling 'ip link set lowpan0 up ' goes to
>>> > 'at86rf230_xmit()' and I see the data transmitted over the SPI pins
>>> > which is fine but when I try to ping6, it never goes to
>>> > 'at86rf230_xmit()' and there is no data exchange on the bus.
>>> >
>>
>> I have no idea why you have this problem. Everything should be fine to
>> use "ping6 -I lowpan0 ....".
>>
>>> >> Do you use now the software spi bit banging driver over gpio's?
>>> > Yes I use software spi bit banging driver over gpio's which works great.
>>> >>
>>> >>
>>> >> - Alex
>>> >>
>>> >> [0] http://lxr.free-electrons.com/source/net/mac802154/tx.c#L106
>>> >> [1] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L1027
>>> >> [2] http://lxr.free-electrons.com/source/drivers/net/ieee802154/at86rf230.c#L1648
>>> >
>>> >
>>> > ip link gives me that:
>>> >
>>> > root@OpenWrt:/# ip link
>>> > 6: wpan0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 127 qdisc fq_codel state
>>> > UNKNOWN mode DEFAULT group default qlen 300
>>> >     link/ieee802.15.4 ef:57:b2:a9:2f:4e:90:76 brd ff:ff:ff:ff:ff:ff:ff:ff
>>> > 7: lowpan0@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc
>>> > noqueue state UNKNOWN mode DEFAULT group default
>>> >     link/[825] ef:57:b2:a9:2f:4e:90:76 brd ff:ff:ff:ff:ff:ff:ff:ff
>>> >
>>> > I'm wondering what [825] means? Shouldn't it be ieee802.15.4 instead?
>>> > What does ping6 -I lowpan0? Does it create an ICMP6 socket? How is
>>
>> So fat I know, ping6 utility opens an IPv6 raw socket, then you can
>> generate the ICMPv6 header inside the userspace. See [4].
>>
>> I also saw some example which use ETH raw sockets and build the complete
>> mac + ipv6 + ICMPv6 inside userspace, see [5] "ping6_ll.c".
>>
>> Indeed the example at [5] should not work on lowpan interface, but I
>> don't think that there are "ping6" implementation outside which works
>> like this.
>>
>>
>> Which ping6 implementation do you use, the one from busybox?
> Yes from busybox v1.23.2, iputils-s20101006 downloaded from
> http://www.skbuff.net/iputils.
> it differs a bit from the latest version, I'm going to try the latest
> release (iputils-s20121221.tar.bz2)
> OpenWRT adds some patches to iputil so I would need to review thes
> patches before going to the new version.
>
> How could I try that it actually works with something else than ping6?
>
>>
>>> > ping6 connected to lowpan0 interface? (I mean in the source code)
>>
>> Yea, I need to write some more documentation. Maybe look at my draft for
>> make some "global (maybe not enough detailed) stack architecture" ascii
>> art [1].
>
> I need to go through all the layers to see where it fails (without
> saying any errors...)
> Your architecture is great! Thanks, I see that while using IPV6, we
> don't use i802154 socket, this is what I was observing earlier, so
> that seems ok.
>
>
>> You will see the 6lowpan box sends frames via "dev_queue_xmit" [2] and
>> receives frames from the linux packet layer [3].
>>
>> Don't know what I should tell here more about "how it works", on sending
>> the lowpan interface puts frames via dev_queue_xmit into wpan interface
>> and on receiving we make 6LoWPAN to IPv6. 6LoWPAN is an adaptation
>> layer. The lowpan interface to this adaptation.
>>
>> btw:
>>
>> (Okay it's not really true that we can do everything as adaptation, you
>> maybe saw the 6CO question on the last mails which I haven't time yet to
>> review. In this case the IPv6 stack need to know something from 6LoWPAN
>> stack.) Or the other option would be to reparse and regenerate the
>> IPv6/ICMPv6 headers, but this sounds crazy.
>>
>>>
>>> Could you tell me what should be the result of:
>>> cat ./sys/devices/virtual/net/lowpan0/type
>>> I get 825 and for wpan 0, it is 804
>>>
>>
>> That's fine, they are different interface types. wpan interfaces it's
>> 802.15.4. lowpan is IPv6. See [0].
>>
>> Some userspace application will check that, e.g. wireshark will indicate
>> parse frames as 802.15.4 if it's ARPHRD_IEEE802154 and parse IPv6 if
>> it's ARPHRD_6LOWPAN.
>>
>> - Alex
>>
>> [0] http://lxr.free-electrons.com/source/include/uapi/linux/if_arp.h#L89
>> [1] https://raw.githubusercontent.com/linux-wpan/wpan-misc/master/architecture/general/wpan
>> [2] http://lxr.free-electrons.com/source/net/ieee802154/6lowpan/tx.c#L262
>> [3] http://lxr.free-electrons.com/source/net/ieee802154/6lowpan/rx.c#L160
>> [4] https://github.com/iputils/iputils/blob/master/ping.c#L444
>> [5] http://www.pdbuchan.com/rawsock/rawsock.html
>
> Ok, thanks for your explanation. What can say now is, it goes to
> dev_queue_xmit each time but not to at86rf230_xmit.
>
> While setting up lowpan 0, 7 messages are sent (dev_queue_xmit) but
> actually only one is sent to the 230! because only one at86rf230_xmit
> is called.
> So I'm wondering if IRQ has something to do with that? It feels like
> the at86rf230 is locked and can't send more messages.
>
> --
> Baptiste



-- 
Baptiste

Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages

[Alexander Aring]

Hi,

adding missed cc.

On Wed, Jul 15, 2015 at 09:12:14AM +0200, Alexander Aring wrote:
> On Tue, Jul 14, 2015 at 11:22:32PM +0200, Baptiste Clenet wrote:
> ...
> > 
> > Kind of a backtrace (printk at each beginning of a function)
> > root@OpenWrt:/# ip link set lowpan0 up
> > [  214.708111] lowpan_header_create
> > [  214.714520] lowpan_xmit
> > [  214.719378] lowpan_header
> > [  214.724569] tx.c dev_queue_xmit
> > [  214.730795] at86rf230_xmit_start
> > [  214.737669] at86rf230_write_frame
> > [  214.745539] at86rf230_write_frame_complete
> > [  214.828082] lowpan_header_create
> > [  214.834484] lowpan_xmit
> > [  214.839334] lowpan_header
> > [  214.844523] tx.c dev_queue_xmit
> > [  215.368119] lowpan_header_create
> > [  215.374529] lowpan_xmit
> > [  215.379398] lowpan_header
> > [  215.384589] tx.c dev_queue_xmit
> > [  216.368196] lowpan_header_create
> > [  216.374604] lowpan_xmit
> > [  216.379468] lowpan_header
> > [  216.384658] tx.c dev_queue_xmit
> > [  216.390934] lowpan_header_create
> > [  216.397319] lowpan_xmit
> > [  216.402168] lowpan_header
> > [  216.407351] tx.c dev_queue_xmit
> > [  216.898090] lowpan_header_create
> > 
> >     [  216.904496] lowpan_xmit
> > 
> >                  [  216.909350] lowpan_header
> > [  216.914539] tx.c dev_queue_xmit
> > [  216.978063] lowpan_header_create
> > [  216.984464] lowpan_xmit
> > [  216.989312] lowpan_header
> > [  216.994498] tx.c dev_queue_xmit
> > 
> > You see that at86rf230_xmit_start is called only once so I seems
> > logical that while doing a ping6, it's not called as well.
> 
> I maybe know what happens here.
> 
> You transmit only one frame at beginning, this occurs that the netdev
> queue will be stopped -> The driver layer doesn't get new "send a frame",
> the xmit callback.
> 
> This happens once, then the queue is stopped on the "tx completion
> interrupt" we awake the queue again. -> The driver layer can send a
> frame again.
> 
> It seems for me that you don't get any irq, instrument please the function:
> 
> at86rf230_isr
> 
> and check
> 
> cat /proc/interrupts 
> 
> if you see that the at86rf230 driver gets any interrupt. If not check
> your irq settings.
> 
> - Alex

Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages

[Baptiste Clenet]

2015-07-15 9:13 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> Hi,
>
> adding missed cc.
>
> On Wed, Jul 15, 2015 at 09:12:14AM +0200, Alexander Aring wrote:
>> On Tue, Jul 14, 2015 at 11:22:32PM +0200, Baptiste Clenet wrote:
>> ...
>> >
>> > Kind of a backtrace (printk at each beginning of a function)
>> > root@OpenWrt:/# ip link set lowpan0 up
>> > [  214.708111] lowpan_header_create
>> > [  214.714520] lowpan_xmit
>> > [  214.719378] lowpan_header
>> > [  214.724569] tx.c dev_queue_xmit
>> > [  214.730795] at86rf230_xmit_start
>> > [  214.737669] at86rf230_write_frame
>> > [  214.745539] at86rf230_write_frame_complete
>> > [  214.828082] lowpan_header_create
>> > [  214.834484] lowpan_xmit
>> > [  214.839334] lowpan_header
>> > [  214.844523] tx.c dev_queue_xmit
>> > [  215.368119] lowpan_header_create
>> > [  215.374529] lowpan_xmit
>> > [  215.379398] lowpan_header
>> > [  215.384589] tx.c dev_queue_xmit
>> > [  216.368196] lowpan_header_create
>> > [  216.374604] lowpan_xmit
>> > [  216.379468] lowpan_header
>> > [  216.384658] tx.c dev_queue_xmit
>> > [  216.390934] lowpan_header_create
>> > [  216.397319] lowpan_xmit
>> > [  216.402168] lowpan_header
>> > [  216.407351] tx.c dev_queue_xmit
>> > [  216.898090] lowpan_header_create
>> >
>> >     [  216.904496] lowpan_xmit
>> >
>> >                  [  216.909350] lowpan_header
>> > [  216.914539] tx.c dev_queue_xmit
>> > [  216.978063] lowpan_header_create
>> > [  216.984464] lowpan_xmit
>> > [  216.989312] lowpan_header
>> > [  216.994498] tx.c dev_queue_xmit
>> >
>> > You see that at86rf230_xmit_start is called only once so I seems
>> > logical that while doing a ping6, it's not called as well.
>>
>> I maybe know what happens here.
>>
>> You transmit only one frame at beginning, this occurs that the netdev
>> queue will be stopped -> The driver layer doesn't get new "send a frame",
>> the xmit callback.
>>
>> This happens once, then the queue is stopped on the "tx completion
>> interrupt" we awake the queue again. -> The driver layer can send a
>> frame again.
>>
>> It seems for me that you don't get any irq, instrument please the function:
>>
>> at86rf230_isr
No call for isr but most of all, no irq on the irq line. polarity set
to 0 (reg 0x04), TRX enable (reg 0x0E)
This is definitely the problem

>>
>> and check
>>
>> cat /proc/interrupts
Yes the spi int is defined
 23:          0      INTC  15  spi32765.0
Why 23 on the left and 15 ont the right?

>>
>> if you see that the at86rf230 driver gets any interrupt. If not check
>> your irq settings.
>>
>> - Alex



-- 
Baptiste

Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages

[Baptiste Clenet]

2015-07-15 16:34 GMT+02:00 Baptiste Clenet <bapclenet@gmail.com>:
> 2015-07-15 9:13 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
>> Hi,
>>
>> adding missed cc.
>>
>> On Wed, Jul 15, 2015 at 09:12:14AM +0200, Alexander Aring wrote:
>>> On Tue, Jul 14, 2015 at 11:22:32PM +0200, Baptiste Clenet wrote:
>>> ...
>>> >
>>> > Kind of a backtrace (printk at each beginning of a function)
>>> > root@OpenWrt:/# ip link set lowpan0 up
>>> > [  214.708111] lowpan_header_create
>>> > [  214.714520] lowpan_xmit
>>> > [  214.719378] lowpan_header
>>> > [  214.724569] tx.c dev_queue_xmit
>>> > [  214.730795] at86rf230_xmit_start
>>> > [  214.737669] at86rf230_write_frame
>>> > [  214.745539] at86rf230_write_frame_complete
>>> > [  214.828082] lowpan_header_create
>>> > [  214.834484] lowpan_xmit
>>> > [  214.839334] lowpan_header
>>> > [  214.844523] tx.c dev_queue_xmit
>>> > [  215.368119] lowpan_header_create
>>> > [  215.374529] lowpan_xmit
>>> > [  215.379398] lowpan_header
>>> > [  215.384589] tx.c dev_queue_xmit
>>> > [  216.368196] lowpan_header_create
>>> > [  216.374604] lowpan_xmit
>>> > [  216.379468] lowpan_header
>>> > [  216.384658] tx.c dev_queue_xmit
>>> > [  216.390934] lowpan_header_create
>>> > [  216.397319] lowpan_xmit
>>> > [  216.402168] lowpan_header
>>> > [  216.407351] tx.c dev_queue_xmit
>>> > [  216.898090] lowpan_header_create
>>> >
>>> >     [  216.904496] lowpan_xmit
>>> >
>>> >                  [  216.909350] lowpan_header
>>> > [  216.914539] tx.c dev_queue_xmit
>>> > [  216.978063] lowpan_header_create
>>> > [  216.984464] lowpan_xmit
>>> > [  216.989312] lowpan_header
>>> > [  216.994498] tx.c dev_queue_xmit
>>> >
>>> > You see that at86rf230_xmit_start is called only once so I seems
>>> > logical that while doing a ping6, it's not called as well.
>>>
>>> I maybe know what happens here.
>>>
>>> You transmit only one frame at beginning, this occurs that the netdev
>>> queue will be stopped -> The driver layer doesn't get new "send a frame",
>>> the xmit callback.
>>>
>>> This happens once, then the queue is stopped on the "tx completion
>>> interrupt" we awake the queue again. -> The driver layer can send a
>>> frame again.
>>>
>>> It seems for me that you don't get any irq, instrument please the function:
>>>
>>> at86rf230_isr
> No call for isr but most of all, no irq on the irq line. polarity set
> to 0 (reg 0x04), TRX enable (reg 0x0E)
> This is definitely the problem
>
>>>
>>> and check
>>>
>>> cat /proc/interrupts
> Yes the spi int is defined
>  23:          0      INTC  15  spi32765.0
> Why 23 on the left and 15 ont the right?
>
>>>
>>> if you see that the at86rf230 driver gets any interrupt. If not check
>>> your irq settings.
>>>
>>> - Alex
>
>
>
> --
> Baptiste

By the way, I'm using the 212B

-- 
Baptiste

Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages

[Alexander Aring]

On Wed, Jul 15, 2015 at 04:34:09PM +0200, Baptiste Clenet wrote:
> 2015-07-15 9:13 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> > Hi,
> >
> > adding missed cc.
> >
> > On Wed, Jul 15, 2015 at 09:12:14AM +0200, Alexander Aring wrote:
> >> On Tue, Jul 14, 2015 at 11:22:32PM +0200, Baptiste Clenet wrote:
> >> ...
> >> >
> >> > Kind of a backtrace (printk at each beginning of a function)
> >> > root@OpenWrt:/# ip link set lowpan0 up
> >> > [  214.708111] lowpan_header_create
> >> > [  214.714520] lowpan_xmit
> >> > [  214.719378] lowpan_header
> >> > [  214.724569] tx.c dev_queue_xmit
> >> > [  214.730795] at86rf230_xmit_start
> >> > [  214.737669] at86rf230_write_frame
> >> > [  214.745539] at86rf230_write_frame_complete
> >> > [  214.828082] lowpan_header_create
> >> > [  214.834484] lowpan_xmit
> >> > [  214.839334] lowpan_header
> >> > [  214.844523] tx.c dev_queue_xmit
> >> > [  215.368119] lowpan_header_create
> >> > [  215.374529] lowpan_xmit
> >> > [  215.379398] lowpan_header
> >> > [  215.384589] tx.c dev_queue_xmit
> >> > [  216.368196] lowpan_header_create
> >> > [  216.374604] lowpan_xmit
> >> > [  216.379468] lowpan_header
> >> > [  216.384658] tx.c dev_queue_xmit
> >> > [  216.390934] lowpan_header_create
> >> > [  216.397319] lowpan_xmit
> >> > [  216.402168] lowpan_header
> >> > [  216.407351] tx.c dev_queue_xmit
> >> > [  216.898090] lowpan_header_create
> >> >
> >> >     [  216.904496] lowpan_xmit
> >> >
> >> >                  [  216.909350] lowpan_header
> >> > [  216.914539] tx.c dev_queue_xmit
> >> > [  216.978063] lowpan_header_create
> >> > [  216.984464] lowpan_xmit
> >> > [  216.989312] lowpan_header
> >> > [  216.994498] tx.c dev_queue_xmit
> >> >
> >> > You see that at86rf230_xmit_start is called only once so I seems
> >> > logical that while doing a ping6, it's not called as well.
> >>
> >> I maybe know what happens here.
> >>
> >> You transmit only one frame at beginning, this occurs that the netdev
> >> queue will be stopped -> The driver layer doesn't get new "send a frame",
> >> the xmit callback.
> >>
> >> This happens once, then the queue is stopped on the "tx completion
> >> interrupt" we awake the queue again. -> The driver layer can send a
> >> frame again.
> >>
> >> It seems for me that you don't get any irq, instrument please the function:
> >>
> >> at86rf230_isr
> No call for isr but most of all, no irq on the irq line. polarity set
> to 0 (reg 0x04), TRX enable (reg 0x0E)
> This is definitely the problem
> 

"no irq on the irq line" -> this means you check the irq line on the
at86rf212 and it's not high? If not can you please check that with some
multimeter.

> >>
> >> and check
> >>
> >> cat /proc/interrupts
> Yes the spi int is defined
>  23:          0      INTC  15  spi32765.0
> Why 23 on the left and 15 ont the right?
> 

23 is definitely the irqnum, the 15 is some system internal number of
your arm soc. Maybe 15 is GPIO15, does this makes any sense? :-)

I have there (beaglebone):

141:      77445  481ae000.gpio  19 Level     spi1.0

(RPi):

111:        129  pinctrl-bcm2835  23 Level     spi32766.0

When the above test results into "the irq line is high and the system
doesn't do anything at the at86rf230_isr function" then something is
wrong with your interrupt setup in your device tree file and I can't
help you there.

- Alex

Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages

[Baptiste Clenet]

Le 15 juil. 2015 19:48, "Alexander Aring" <alex.aring@gmail.com> a écrit :
>
> On Wed, Jul 15, 2015 at 04:34:09PM +0200, Baptiste Clenet wrote:
> > 2015-07-15 9:13 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> > > Hi,
> > >
> > > adding missed cc.
> > >
> > > On Wed, Jul 15, 2015 at 09:12:14AM +0200, Alexander Aring wrote:
> > >> On Tue, Jul 14, 2015 at 11:22:32PM +0200, Baptiste Clenet wrote:
> > >> ...
> > >> >
> > >> > Kind of a backtrace (printk at each beginning of a function)
> > >> > root@OpenWrt:/# ip link set lowpan0 up
> > >> > [  214.708111] lowpan_header_create
> > >> > [  214.714520] lowpan_xmit
> > >> > [  214.719378] lowpan_header
> > >> > [  214.724569] tx.c dev_queue_xmit
> > >> > [  214.730795] at86rf230_xmit_start
> > >> > [  214.737669] at86rf230_write_frame
> > >> > [  214.745539] at86rf230_write_frame_complete
> > >> > [  214.828082] lowpan_header_create
> > >> > [  214.834484] lowpan_xmit
> > >> > [  214.839334] lowpan_header
> > >> > [  214.844523] tx.c dev_queue_xmit
> > >> > [  215.368119] lowpan_header_create
> > >> > [  215.374529] lowpan_xmit
> > >> > [  215.379398] lowpan_header
> > >> > [  215.384589] tx.c dev_queue_xmit
> > >> > [  216.368196] lowpan_header_create
> > >> > [  216.374604] lowpan_xmit
> > >> > [  216.379468] lowpan_header
> > >> > [  216.384658] tx.c dev_queue_xmit
> > >> > [  216.390934] lowpan_header_create
> > >> > [  216.397319] lowpan_xmit
> > >> > [  216.402168] lowpan_header
> > >> > [  216.407351] tx.c dev_queue_xmit
> > >> > [  216.898090] lowpan_header_create
> > >> >
> > >> >     [  216.904496] lowpan_xmit
> > >> >
> > >> >                  [  216.909350] lowpan_header
> > >> > [  216.914539] tx.c dev_queue_xmit
> > >> > [  216.978063] lowpan_header_create
> > >> > [  216.984464] lowpan_xmit
> > >> > [  216.989312] lowpan_header
> > >> > [  216.994498] tx.c dev_queue_xmit
> > >> >
> > >> > You see that at86rf230_xmit_start is called only once so I seems
> > >> > logical that while doing a ping6, it's not called as well.
> > >>
> > >> I maybe know what happens here.
> > >>
> > >> You transmit only one frame at beginning, this occurs that the netdev
> > >> queue will be stopped -> The driver layer doesn't get new "send a frame",
> > >> the xmit callback.
> > >>
> > >> This happens once, then the queue is stopped on the "tx completion
> > >> interrupt" we awake the queue again. -> The driver layer can send a
> > >> frame again.
> > >>
> > >> It seems for me that you don't get any irq, instrument please the function:
> > >>
> > >> at86rf230_isr
> > No call for isr but most of all, no irq on the irq line. polarity set
> > to 0 (reg 0x04), TRX enable (reg 0x0E)
> > This is definitely the problem
> >
>
> "no irq on the irq line" -> this means you check the irq line on the
> at86rf212 and it's not high?

Yes indeed, I solved that first problem.

If not can you please check that with some
> multimeter.
>
> > >>
> > >> and check
> > >>
> > >> cat /proc/interrupts
> > Yes the spi int is defined
> >  23:          0      INTC  15  spi32765.0
> > Why 23 on the left and 15 ont the right?
> >
>
> 23 is definitely the irqnum, the 15 is some system internal number of
> your arm soc. Maybe 15 is GPIO15, does this makes any sense? :-)

Yes it makes sense, I'm looking at how are defined the irq in my dts.
Which file should take of setting the irq ? Gpio driver of each board
?  Or is there another driver for irq ?  Because in gpio-mt7621, I
can't see any write in the registers for handling IRQ...

>
> I have there (beaglebone):
>
> 141:      77445  481ae000.gpio  19 Level     spi1.0
>
> (RPi):
>
> 111:        129  pinctrl-bcm2835  23 Level     spi32766.0
>
> When the above test results into "the irq line is high and the system
> doesn't do anything at the at86rf230_isr function" then something is
> wrong with your interrupt setup in your device tree file and I can't
> help you there.

Yep I know :-\
I'm going to look a bit more a those drivers and see how they set IRQs

>
> - Alex