Hi David, thanks for your analysis. Responses are inline.
On 08/03/2012 09:53 AM, David Kopf wrote:
> The sequence numbers in your pcap are not incrementing, may or may not
> be a problem but some software will ignore duplicates.
>
I see the sequence number in the 802.15.4 header is always set to zero
in the data from :1 . That's the Econotag. The sequence numbers from :2
(the mrf24j40) do increment. That's strange since the sequence number
isn't set in the driver, and the two systems should have the same upper
layers because they have the same kernel. I'll take a look.
> Your first fragment is nothing but the fragmentation header and my
> wireshark shows that is garbled, I suspect because the fragmentation
> offset field is missing.
I initially thought the same, but the fragmentation offset field is not
supposed to be part of the first packet.
See Section 5.3 of RFC 4944:
http://tools.ietf.org/html/rfc4944#page-11
> Usually the first fragment contains as much data as will fit in the
> rest of the packet.
I'd think that to be the case, but I checked the code and the Linux
6LoWPAN implementation intentionally doesn't do that. Maybe it's just
that way for now as a first pass for coding ease. I don't know what the
effect of not having a data section is. I didn't see it in the RFC but
it was really late when I was looking at it, so it might be there.
This might be a case where something that's technically not compliant
(and thus throws an error in Wireshark) might work between Linux systems
if the TX and RX sides both expect the same thing. That's of course why
I'm asking about these kinds of things here.
> My wireshark says it assembles the other fragments anyway, but ends up
> with a short garbled packet. Maybe because the first fragment was not
> part of the reassembly, even though it was zero length.
I see that same kind of thing.
> You report a 12090 byte window size in your syn ack. I don’t think
> 6lowpan can pass a 12000 byte frame from the host, if it had that much
> to send.
Interesting. I'm not sure what to make of that.
>
> Low baud rates will throttle transmission of short pings, which can be
> an advantage. But tx of the first fragment of a long packet may not
> start until the entire packet has been downloaded, also the packet
> upload could be delayed until all fragments are received. That adds 2x
> the serial delay, plus the possibly of too-short interpacket spacings
> if the radio does not do enough throttling.
>
I guess I'm not sure what this means. The serial.c driver is handed
fragments by the ieee802154 layer, which should get only fragments from
the 6lowpan code. In this case, I'd expect neither the serial.c driver
nor the Econotag to know anything about ipv6, 6lowpan or the meaning of
any of the fragmented packets it gets from the PC.
In other words, the Econotag does not do fragmentation or reassembly.
Maybe I misunderstand what you're trying to say.
> The 802.15.4 ack reqest bit is not being set, so ack waits are not
> slowing down the tx. I think the default wait is 740 microseconds.
> csma will also increase the tx delay, or the MACA_WARMUP parameter in
> the radio initialize routine.
I also noticed in the Econotag firmware that the NO_ACK status is ignored.
Thanks!
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
