Hi,
okay I will try to answer all question in this mail.
On Mon, Feb 17, 2014 at 04:32:48PM +0530, Varka Bhadram wrote:
> This is the packet i received from TinyOS node :
>
> 41 c8 00 22 00 ff ff c6 0f 7c 50 45 6d 12 00 6b 3b 00 40 e0 3a 02 85 00 12 be
> 00
> 00 00 00 01 02 c6 0f 7c 50 45 6d 12 00 00 00 00 00 00 00 16 ec
>
> I put some debug messges in the kernel the results are as follows:
>
> [ 65.724839] Bhadra : ieee802154_rx_irqsafe
> [ 65.724890] Bhadra : mac802154_subif_rx
> [ 65.724948] Bhadra : lowpan_recv
> [ 65.724964] Bhadra : lowpan_process_data
> [ 65.724995] Bhadra : lowpan_give_skb_to_devices
> [ 65.725010] pkt->type : 00, pkt->protocol: dd86
> [ 65.725028] Bhadra : lowpan_give_skb_to_devices : netif_rx
>
>
> those are the function names in the kernel. With the protocol and packet type
> ,
> the skb is handed over to the netif_rx() in lowpan_give_skb_to devices()
> function , but it is not reaching to ip6_input_finish() function.
>
> What can be the problem. ? I am working on 3.12 kernel.
>
What I can see from your trace is that you calling
"lowpan_give_skb_to_devices" right after "lowpan_process_data".
This can have only one reason. Your TinyOS don't make any IPv6
compression, because your IPv6 packet fits into one PDU. (Then we have
the special dispatch value of LOWPAN_DISPATCH_IPV6).
You get in this branch [1]. And I saw (yes, I already noticed that) there
is something wrong with the memory management.
We make a "kfree_skb(local_skb);" in this branch and not in the others,
but this can't be working. Please try to following patch (which should
included in my rework of fragmentation patches):
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index ff41b4d..383f0a4 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -1332,7 +1332,6 @@ static int lowpan_rcv(struct sk_buff *skb, struct
net_device *dev,
lowpan_give_skb_to_devices(local_skb);
- kfree_skb(local_skb);
kfree_skb(skb);
} else {
switch (skb->data[0] & 0xe0) {
I think local_skb is freed a little bit too early, and then you transmit some
garbage to
ipv6. Please reply if it works or not for you.
>
>
>
> On February 17, 2014 at 3:53 PM Varka Bhadram <var...@cdac.in> wrote:
>
> > Hai..
> >
> > May i know the status of 6LoWPAN implementation in the kernel.. Is it
> > implemented according to RFC6282/4944 ?
> >
> >
RFC6282 is most implemented except context based address compression.
RFC4944 which also describes fragmentation is currently not rfc
complaint. I have patches for this to make this rfc complaint.
RFC4944 describes lot of other things like a 6LoWPAN mesh routing. (But
this kind of routing have no partical relevance, means the most people
use RPL as routing protocol (That's my point of view, can somebody
confirm this))?
> > Right now i am testing integration of 6LoWPAN with TinyOS . When i received
> > the packet ,it is reaching upto 6lowpan layer but not reaching to IP Layer.
> >
I never used the 6LoWPAN TinyOS. I use contiki on my side to test
something with another 6LoWPAN Stack. Maybe there are some bugs in
6LoWPAN of TinyOS?
[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/ieee802154/6lowpan.c?id=refs/tags/v3.12#n1316
- Alex
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
