On 08/03/2012 10:19 AM, Tony Cheneau wrote:
>> certainly not 400ms, so I'm not seeing that issue (whatever it is/was).
> I haven't changed the baud rate (so it's 115200), and my pings are
> I'm not too certain that the baudrate gave a 20 times performance
> increase. However, I believe that a 115200 bps baudrate to transfer
> data to and from a 250kbps radio can be a bottleneck (and I clearly
> see it when my capturing device is set to only 115200 bps).
Hi Tony,
I agree. My current problem though is that the Econotag is sending _too_
fast for my mrf24j40.
>
>> Another quick question... When you do a wireshark of something with
>> 6lowpan fragmentation, are you getting malformed packet errors for the
>> first packet? I'm trying to decide whether this is something that could
>> hold me up, or whether it's a wireshark issue with 6lowpan. I uploaded a
>> capture file[1] from my embedded board. :1 is the PC with econotag and
>> :2 is the embedded board with mrf24j40. As you can see, not all the
>> packets are making it through. I'll do some testing with the rftest
>> tools.
> The current 6lowpan code for the first fragment is wrong (i.e. it
> should be more that 25 bytes or so). When I dug in the source code, I
> found out that the first fragment is always empty (i.e. no payload). I
> fixed that, but I haven't found the time to release a patch yet. I'm
> sorry about that.
> However, in my initial test, without the fix, I could still manage to
> log into SSH (sporadically, due to a failing serial driver).
>
Ok, that makes sense then. I guess that answers my question. Wireshark
is reporting an error, and there is an error, but it should still work.
>> This example capture [2] shows an HC1 header (for example, packet 4)
>> that we don't have, but my quick look at the 6lowpan RFC hasn't been
>> able to convince me that it's required in any way. Like I said, it could
>> be a Wireshark issue.
> HC1 header is required in order to "compress" the IPv6 header (from 40
> bytes to something like 20 bytes in your case). It saves bandwidth and
> prevent the need for fragmentation. This is not required so to speak,
> but your packet go through the 6lowpan module, they will have the HC1
> compression applied to them.
>
That's strange then, since I'm _not_ seeing the HC1 header in packets
sent from Linux. It is only present in that sample capture I got from
Wireshark's website that I linked to.
> While I'm at it, you might find this kind of issues as you play with
> the linux net-next kernel:
> - crash due to memory allocation in 6lowpan: on "my" kernel, I changed
> the kzalloc() call from GFP_KERNEL to GFP_ATOMIC. The backtrace was
> not always useful as it would point to random network code.
Yes, I found this and changed it to use stack arrays, since the lengths
were fixed-size and small.
Interestingly, this only stack dumps on the PC, not on my Beaglebone. On
the Beaglebone I get a pretty serious warning about deadlock though. See
[1] below. I haven't had a chance to look at that one yet.
> - the serial driver itself has some bugs (in the linux-zigbee tree).
> Some patches sent to linux-zigbee mailing list were never applied.
I'd be very happy to test any patches you have. I think those must have
been before I subscribed to the mailing list.
> - during packet burst, packets can be sent in the wrong order: this is
> due to the way the queue was implemented in the MAC layer
> (net/mac802154/tx.c): if the device is busy, the packet is rescheduled
> to be send, but at the end of the queue.
Does this cause a problem? I don't know the 6lowpan spec very well, but
for UDP fragmentation it's my understanding that the fragments can come
in any order.
In the capture, sometimes the first packet does show up last, but that
confuses me now, since it's packets _from_ the mrf24j40, which is the
slower device, and the Econotag is setup to auto-ack (but not _request_
an ack).
> - UDP header compression is broken: the header is compressed
> correctly, however both compressed and uncompressed header are sent on
> the air. Because the code is broken on the sender and the receiver, it
> still works. I have a patch for that (saves a few bytes in the packet).
>
I'd be happy to test it if you want me to.
> You currently don't have L2 acknowledgment with the current Econotag
> firmware. I need to release my "additions": I enabled auto-ack in my
> firmware and go it to work between two devices. It requires
> modification in the 6lowpan and the MAC codes as well (so that the ACK
> flag can be passed down).
Yes, I'd very much like to test those additions. I thought I saw sending
auto-ack in the code (ilnux.c:623 in maca_isr()). My mrf24j40 doesn't
complain about not getting an ack from the Econotag. My driver could be
wrong though. Are you sure you don't mean you modified the Econotag
firmware to _request_ acks?
I guess I don't understand why the 6lowpan and mac802154 code would need
to be modified for L2 acknowledgement to work.
> I plan on releasing all of that, but I've been pretty busy lately.
> Besides, some code needs to be cleaned and cannot be released as is
> (e.g. I implemented a reset mechanism on the serial driver to reset
> the econotag when it stops responding, this is not needed anymore
> because the bug has since then been fixed in the firmware).
Yes, I saw your recent change that made it into the
linux802154-serialdev project. I think I've seen the econotag stop
responding as well. At least _something_ stopped responding, and I don't
think it started working until I rebooted the PC (with the Econotag).
Again, I'm happy to test any patches, even dirty as-is patches :)
This reminds me. I'm having a hard time unloading any mac802154 drivers
once 6lowpan is attached to a wpan device. Is there a trick I'm not
getting? I see:
unregister_netdevice: waiting for wpan0 to become free. Usage count = -1
I get it at shutdown time too and have to hard-power-off. I tried
removing the lowpan0 link manually but that doesn't seem to help.
Thanks for all your help and comments on this.
Alan.
[1]
++ ifconfig lowpan0 up
[ 27.035843]
[ 27.037458] =============================================
[ 27.043117] [ INFO: possible recursive locking detected ]
[ 27.048785] 3.5.0-08895-gf50e6a0 #12 Not tainted
[ 27.053624] ---------------------------------------------
[ 27.059284] node/117 is trying to acquire lock:
[ 27.064034] (_xmit_IEEE802154#2){+.-...}, at: [<c0429360>]
sch_direct_xmit+0xac/0x30c
[ 27.072416]
[ 27.072416] but task is already holding lock:
[ 27.078529] (_xmit_IEEE802154#2){+.-...}, at: [<c0411c68>]
dev_queue_xmit+0x55c/0x7f4
[ 27.086891]
[ 27.086891] other info that might help us debug this:
[ 27.093734] Possible unsafe locking scenario:
[ 27.093734]
[ 27.099938] CPU0
[ 27.102501] ----
[ 27.105063] lock(_xmit_IEEE802154#2);
[ 27.109112] lock(_xmit_IEEE802154#2);
[ 27.113161]
[ 27.113161] *** DEADLOCK ***
[ 27.113161]
[ 27.119368] May be due to missing lock nesting notation
[ 27.119368]
[ 27.126486] 6 locks held by node/117:
[ 27.130323] #0: (&ifa->timer){+.-.+.}, at: [<c004ebd0>]
run_timer_softirq+0x104/0x3c0
[ 27.138772] #1: (rcu_read_lock){.+.+.+}, at: [<c04a7b7c>]
ndisc_send_skb+0x70/0x354
[ 27.147037] #2: (rcu_read_lock){.+.+.+}, at: [<c0494d98>]
ip6_finish_output2+0x3c/0x5c
[ 27.155668] #3: (rcu_read_lock_bh){.+....}, at: [<c041170c>]
dev_queue_xmit+0x0/0x7f4
[ 27.164112] #4: (_xmit_IEEE802154#2){+.-...}, at: [<c0411c68>]
dev_queue_xmit+0x55c/04
[ 27.172930] #5: (rcu_read_lock_bh){.+....}, at: [<c041170c>]
dev_queue_xmit+0x0/0x7f4
[ 27.181373]
[ 27.181373] stack backtrace:
[ 27.185981] [<c001b74c>] (unwind_backtrace+0x0/0xf4) from
[<c008f210>] (__lock_acquire+)
[ 27.195656] [<c008f210>] (__lock_acquire+0x1108/0x1e18) from
[<c008ffbc>] (lock_acquire)
[ 27.205153] [<c008ffbc>] (lock_acquire+0x9c/0x104) from [<c050ee24>]
(_raw_spin_lock+0x)
[ 27.214282] [<c050ee24>] (_raw_spin_lock+0x2c/0x3c) from [<c0429360>]
(sch_direct_xmit+)
[ 27.223684] [<c0429360>] (sch_direct_xmit+0xac/0x30c) from
[<c04118cc>] (dev_queue_xmit)
[ 27.233283] [<c04118cc>] (dev_queue_xmit+0x1c0/0x7f4) from
[<c04f5e1c>] (lowpan_xmit+0x)
[ 27.242597] [<c04f5e1c>] (lowpan_xmit+0x108/0x114) from [<c04113c0>]
(dev_hard_start_xm)
[ 27.252362] [<c04113c0>] (dev_hard_start_xmit+0x398/0x6e4) from
[<c0411bd0>] (dev_queue)
[ 27.262401] [<c0411bd0>] (dev_queue_xmit+0x4c4/0x7f4) from
[<c0494e74>] (ip6_finish_out)
[ 27.272348] [<c0494e74>] (ip6_finish_output2+0x118/0x5fc) from
[<c04a7dc4>] (ndisc_send)
[ 27.282294] [<c04a7dc4>] (ndisc_send_skb+0x2b8/0x354) from
[<c04a9d74>] (ndisc_send_ns+)
[ 27.291608] [<c04a9d74>] (ndisc_send_ns+0x78/0xa8) from [<c049b7e4>]
(addrconf_dad_time)
[ 27.301283] [<c049b7e4>] (addrconf_dad_timer+0x150/0x168) from
[<c004ec60>] (run_timer_)
[ 27.311512] [<c004ec60>] (run_timer_softirq+0x194/0x3c0) from
[<c0047e08>] (__do_softir)
[ 27.321096] [<c0047e08>] (__do_softirq+0xc8/0x218) from [<c0048134>]
(irq_exit+0x90/0x9)
[ 27.329692] [<c0048134>] (irq_exit+0x90/0x98) from [<c00151a4>]
(handle_IRQ+0x50/0xac)
[ 27.338004] [<c00151a4>] (handle_IRQ+0x50/0xac) from [<c0008514>]
(omap3_intc_handle_ir)
[ 27.347497] [<c0008514>] (omap3_intc_handle_irq+0x5c/0x98) from
[<c050f89c>] (__irq_usr)
[ 27.356889] Exception stack(0xcf277fb0 to 0xcf277ff8)
[ 27.362191] 7fa0: b4a90029
00000005 000000a0 0000000
[ 27.370769] 7fc0: b498b92d b59b596d bed05e44 00000001 00000000
00000000 00000004 0000000
[ 27.379345] 7fe0: 00449b00 bed05de0 001d1b2c 001d77a0 60000010 ffffffff
[ 27.388798] mrf24j40 spi1.0: Set Channel 11
root@beaglebone:[ 27.400157] mrf24j40 spi1.0: tx packet of 54 bytes
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Linux-zigbee-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
