Hi,
Answers inline.
> >> 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.
Note that event with my fix, wireshark will complain about overlapping
fragment (but will reassemble correctly), even through the
(first) fragment seems OK.
> >> 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.
My bad. It's using IPHC encoding format (RFC6282).
> > 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.
I'll try to get something out during the week-end.
> > - 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.
True, but the node can run into some problem when the transmitter
tries to send Neighbor Discovery packet and they are mixed into its
own UDP packets. In some of my packet captures, I witnessed such a
scenario, and the Neighbor Solicitation is sent multiple times when
there is not reason to.
> 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).
For a packet to be rescheduled by the MAC, your device driver only has
to say that the device is busy when trying to TX. Maybe that's what
happen with your first packet.
> > - 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.
OK, I really need to get my patches out, rather that detailing what they
do. :)
> > 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?
The device is not supposed to send any acknowledgment as long as you
don't set it through set_prm_mode(AUTOACK) on the device. If you do
so, you'll enable the MAC filtering on the device so that it receives
only packet destined to the device. In that case, you'll have to set
the device's own PANID, short address and long address in the
appropriate memory. I've extended the serial protocol to do that.
> I guess I don't understand why the 6lowpan and mac802154 code would
> need to be modified for L2 acknowledgement to work.
I chose (and this is maybe not the best choice) that it would be the
6lowpan layer that ask (or don't ask) for L2 acknowledgment (this
behavior is configurable via a /proc entry in my patchset). If the
6lowpan wants to have L2 ack, it sets a flag when building part of the
IEEE 802.15.4 header. However, currently, the MAC layer would ignore
this flag and set it to 0 before transmitting to the device. The
econotag firmware will then not expected any ACK for the outgoing
packets.
[...]
> 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.
I don't know. I only "reboot -f" my systems (or else they get stuck
during reboot).
> Thanks for all your help and comments on this.
You're welcome. I'll release some patches as soon as I can.
Regards,
Tony
------------------------------------------------------------------------------
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
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
