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 -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
