On 08/03/2012 07:25 PM, Tony Cheneau wrote:
>
>> 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.
That would be great!
>> 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.
>
Hmm, I don't return -EBUSY, but my xmit function does block until the
packet is sent. (I made it work the same as the cc2420.) Maybe the
higher level is noticing that I'm blocked in xmit... I haven't looked at
that part of the code yet.
>>> 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.
>
Yes. I have hw_filt support in my driver, but I had to put my device in
promiscuous mode to defeat all that for now.
>> 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.
It seems to me that it would be best handled at the 802154 layer and
configured using a tool like iz over the netlink interface. I'd envision
it being similar to the set of controls that would include things like:
security and key management
beacon-configuration
guaranteed-time-slot (GTS) configuration.
I guess in my mind iz is analogous to iwconfig.
Of course also 6lowpan isn't the only method of communication on
802.15.4. We also have PF_IEEE802154 sockets (which izchat uses) and
maybe even other protocols in the future (Zigbee, if the Zigbee Alliance
ever changes their mind about their license, MiWi, and others). Putting
L2 configuration items in 6lowpan.c would cause them to not work with
these other protocols.
Part of the current issue is that 6lowpan.c currently builds too much of
the 802.15.4 header (hence the hard-coding to pan 0x00ff and others).
Clearly you already know this since you wrote a comment block about it
(and that's the only reason _I_ noticed it :) ). I haven't yet looked
into what a solution might be yet.
Thanks again for all your information. I look forward to your patches.
Alan.
------------------------------------------------------------------------------
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
