Hi Alex, So the current 802.15.4 implementation will try and send beacon frames but it doesn't support receiving beacon frames?
I didn't see any type = 2 but that may be down to this problem in our receiver. SSH is over Ethernet so no 6LoWPAN fragmentation I'm afraid. I did try ping6 with large packets but due to the problem in our receiver I was only seeing every other packet of the fragmented PDU. What I did see looked ok though, both source and destination IP addresses were compressed. It was using long 802.15.4 source/dest addressing mode, is this because the IP address are derived from the MAC addresses? When would it use the short addressing? The version of Wireshark (1.10.2) I'm using shows the MAC header, it even decodes the frame control field :) Cheers, Martin. On 27/01/14 13:06, Alexander Aring wrote: > Hi Martin, > > On Mon, Jan 27, 2014 at 12:44:59PM +0000, Martin Townsend wrote: >> Hi Alex, >> >> I have taken your latest commit and can confirm that I can now setup >> a simple point to point lowpan :) >> >> First thing I notice is that I get the following messages on the >> first node after configuring the second node >> >> [ 23.411334] ieee802154: bad frame received (type = 0) >> [ 23.621046] ieee802154: bad frame received (type = 0) >> [ 25.061514] ieee802154: bad frame received (type = 0) >> [ 25.271149] ieee802154: bad frame received (type = 0) >> >> Tried configuring again and the same 4 messages. Does anyone else see this? > Yes me, currently only Dataframes are supported and when you get an > another frametype then it will show this message. > > So your frametype is 0 and this is a beacon frame. We don't handle > beacon frames at the moment. But you don't get any (type = 2)? >> I then tried a ping6 and this was ok. I've now got wirehsark >> remotely capturing packets using tcpdump over ssh and into a pipe on >> the host and this works really well too. :) >> > I had some bad experience to using wireshark on a lowpan device. It > doesn't show the mac header... but this isn't unusual. It's because > the current architecture with a wpan and a lowpan device. I need to > think about this if we can handle this anyway. > >> We've still got a few issues to sort on our receiver so as soon as >> this is fixed I'll let you know how I get on with the fragmentation. >> > if you using ssh you should already used some fragmentation. Try a ping6 > -s $SOME_SIZE_MORE_THAN_127 (my contiki usb stick can handle up to 1024 > bytes and a smaller sensornode can handle 135 bytes. It's possible to > use a (2^16)-(PING_ICMPv6_HEADER) size but this will end in a high > fragmentation. > In a linux<->linux connection without ACKs I can use ~8KB without > trouble and this sounds good. In a normal sensornetwork you don't want a > 8KB payload) > > - Alex ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
