* ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages @ 2015-07-13 14:59 Baptiste Clenet 2015-07-13 16:18 ` Baptiste Clenet 0 siblings, 1 reply; 13+ messages in thread From: Baptiste Clenet @ 2015-07-13 14:59 UTC (permalink / raw) To: linux-wpan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages 2015-07-13 14:59 ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages Baptiste Clenet @ 2015-07-13 16:18 ` Baptiste Clenet 2015-07-13 17:48 ` Alexander Aring 0 siblings, 1 reply; 13+ messages in thread From: Baptiste Clenet @ 2015-07-13 16:18 UTC (permalink / raw) To: linux-wpan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages 2015-07-13 16:18 ` Baptiste Clenet @ 2015-07-13 17:48 ` Alexander Aring 2015-07-14 10:56 ` Baptiste Clenet 0 siblings, 1 reply; 13+ messages in thread From: Alexander Aring @ 2015-07-13 17:48 UTC (permalink / raw) To: Baptiste Clenet; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages 2015-07-13 17:48 ` Alexander Aring @ 2015-07-14 10:56 ` Baptiste Clenet 2015-07-14 17:45 ` Baptiste Clenet 0 siblings, 1 reply; 13+ messages in thread From: Baptiste Clenet @ 2015-07-14 10:56 UTC (permalink / raw) To: Alexander Aring; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages 2015-07-14 10:56 ` Baptiste Clenet @ 2015-07-14 17:45 ` Baptiste Clenet 2015-07-14 18:11 ` Alexander Aring 0 siblings, 1 reply; 13+ messages in thread From: Baptiste Clenet @ 2015-07-14 17:45 UTC (permalink / raw) To: Alexander Aring; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages 2015-07-14 17:45 ` Baptiste Clenet @ 2015-07-14 18:11 ` Alexander Aring 2015-07-14 21:18 ` Baptiste Clenet 0 siblings, 1 reply; 13+ messages in thread From: Alexander Aring @ 2015-07-14 18:11 UTC (permalink / raw) To: Baptiste Clenet; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages 2015-07-14 18:11 ` Alexander Aring @ 2015-07-14 21:18 ` Baptiste Clenet 2015-07-14 21:50 ` Baptiste Clenet [not found] ` <CAPpUg6Odxw1F6+3frQibxtORaUic0M1F_9rGdY6RWZK1uaM17Q@mail.gmail.com> 0 siblings, 2 replies; 13+ messages in thread From: Baptiste Clenet @ 2015-07-14 21:18 UTC (permalink / raw) To: Alexander Aring; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages 2015-07-14 21:18 ` Baptiste Clenet @ 2015-07-14 21:50 ` Baptiste Clenet [not found] ` <CAPpUg6Odxw1F6+3frQibxtORaUic0M1F_9rGdY6RWZK1uaM17Q@mail.gmail.com> 1 sibling, 0 replies; 13+ messages in thread From: Baptiste Clenet @ 2015-07-14 21:50 UTC (permalink / raw) To: Alexander Aring; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <CAPpUg6Odxw1F6+3frQibxtORaUic0M1F_9rGdY6RWZK1uaM17Q@mail.gmail.com>]
[parent not found: <20150715071214.GA5680@omega>]
* Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages [not found] ` <20150715071214.GA5680@omega> @ 2015-07-15 7:13 ` Alexander Aring 2015-07-15 14:34 ` Baptiste Clenet 0 siblings, 1 reply; 13+ messages in thread From: Alexander Aring @ 2015-07-15 7:13 UTC (permalink / raw) To: Baptiste Clenet; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages 2015-07-15 7:13 ` Alexander Aring @ 2015-07-15 14:34 ` Baptiste Clenet 2015-07-15 14:37 ` Baptiste Clenet 2015-07-15 17:48 ` Alexander Aring 0 siblings, 2 replies; 13+ messages in thread From: Baptiste Clenet @ 2015-07-15 14:34 UTC (permalink / raw) To: Alexander Aring; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages 2015-07-15 14:34 ` Baptiste Clenet @ 2015-07-15 14:37 ` Baptiste Clenet 2015-07-15 17:48 ` Alexander Aring 1 sibling, 0 replies; 13+ messages in thread From: Baptiste Clenet @ 2015-07-15 14:37 UTC (permalink / raw) To: Alexander Aring; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages 2015-07-15 14:34 ` Baptiste Clenet 2015-07-15 14:37 ` Baptiste Clenet @ 2015-07-15 17:48 ` Alexander Aring 2015-07-21 6:52 ` Baptiste Clenet 1 sibling, 1 reply; 13+ messages in thread From: Alexander Aring @ 2015-07-15 17:48 UTC (permalink / raw) To: Baptiste Clenet; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages 2015-07-15 17:48 ` Alexander Aring @ 2015-07-21 6:52 ` Baptiste Clenet 0 siblings, 0 replies; 13+ messages in thread From: Baptiste Clenet @ 2015-07-21 6:52 UTC (permalink / raw) To: Alexander Aring; +Cc: linux-wpan 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-07-21 6:52 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-07-13 14:59 ping6 -> lowpan0 -> wpan0. Ping6 doesn't succeed to send messages Baptiste Clenet 2015-07-13 16:18 ` Baptiste Clenet 2015-07-13 17:48 ` Alexander Aring 2015-07-14 10:56 ` Baptiste Clenet 2015-07-14 17:45 ` Baptiste Clenet 2015-07-14 18:11 ` Alexander Aring 2015-07-14 21:18 ` Baptiste Clenet 2015-07-14 21:50 ` Baptiste Clenet [not found] ` <CAPpUg6Odxw1F6+3frQibxtORaUic0M1F_9rGdY6RWZK1uaM17Q@mail.gmail.com> [not found] ` <20150715071214.GA5680@omega> 2015-07-15 7:13 ` Alexander Aring 2015-07-15 14:34 ` Baptiste Clenet 2015-07-15 14:37 ` Baptiste Clenet 2015-07-15 17:48 ` Alexander Aring 2015-07-21 6:52 ` Baptiste Clenet
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.