gmane.linux.network.zigbee.devel

Results of a small experiment: improve serialdriver latency by increasing the baud rate (with econotags)

Tony Cheneau — 2012-05-25T18:13:46

Good afternoon,

By default, the Econotag and izattach (part of the linux-zigbee 
userspace tools) expects the communications to run at 115200 bps. I 
wanted to know of it was affecting the performances, so I tried 
different values (by recompiling the firmware and the tools 
accordingly). I was mainly interested in reducing latency, this is why I 
exclusively used ping6 for my tests, but I guess the throughput should 
improve as well.

Here is the average round-trip time reported by ping6 between two 
nodes:
- at 115200 bps: ~ 400ms
- at 921600 bps: ~ 20ms (yes , 20 times faster)
- at 1843200 bps (maximum baudrate supported by the econotag): ~ 20 ms 
(same number as above)

As a side note, 1843200 bps is not a "standard" baud rate supported by 
the Linux kernel, which make it more complex to set on the software 
side. Given that there is not performance gain compared to 921600 bps, 
there seem to be no benefit in using this baud rate (but I might be 
wrong).

I do not believe my changes should make it to the kernel (some serial 
devices might still need to operate at 115200), but I can post my 
patches if people are interested.

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/

Using a device driver for Linux-Zigbee

Pierre-Emmanuel Goudet — 2012-05-23T14:05:18

Hi all,

I'm an early tester of linux-zigbee implementation. I was, until now, playing with "Serial" driver and having quite success to use it.

Is there any tutorial in the way that a driver like CC2420 or RF231 would be used on the user side.

I mean once the modules are loaded, what should be the next action from user side to really create, test, use the corresponding interface ... ? As with serial we could use izattach , iz, ip ... to manage the wpanx interface.

For now I've compiled the modules I could "modprobe" them, but except seeing them correctly with "lsmod", I do not see any new wpan-phy interface or other ? Event more after adding some debug "printk" I saw that the "probe" function was never called after registering ?

In advance thanks for your tips

-----------------------------------------------------------------------------------------
Pierre-emmanuel

------------------------------------------------------------------------------
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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel

Is 6lowpan fragmentation working?

Tony Cheneau — 2012-05-22T21:42:56

Hello,

I'm currently playing with the 6lowpan code and was wondering if the 
fragmentation support is supposed to be operational. The reason I ask is 
because when my packets grow too big (when fragmentation should kick 
in), my communications stop working.
I sniffed the traffic with Wireshark, and found out the first fragment 
(FRAG1) is always 25 bytes long and does not contain any payload. A 
quick look at the code seems to confirm that the first fragment carries 
no payload (see lowpan_skb_fragmentation()). I fail to see where RFC 
4944 indicates that the first fragment should be empty (and I fail to 
see what would be the benefit of this behavior anyway). So, is that the 
intended behavior? Did I miss something?

Either way, I'll look more into it, maybe this is only specific to my 
system (I ported the serial driver and applied some patches to it, so 
the packets might be mangled somewhere else).

Thank you in advance.

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/

Bug in 6lowpan when uncompressing UDP datagram

Tony Cheneau — 2012-05-21T18:50:13

Hello again,

When running some connectivity tests, I discovered that UDP 
communication would not work between my nodes. Looking at the various 
printk() in the kernel, I found out that the IPv6 next header field is 
not set (set to 0) upon decompression and thus prevented correct 
processing of the decompressed packet at the upper layer (IPv6 layer).
When the next header is UDP, IPHC next header compression applies (as 
defined in Section 4.1 of RFC6282). The compression code in 6lowpan.c 
seems to behave correctly. However, upon decompression code (in 
lowpan_process_data()) fails to properly restore/set the next header 
field.

I attached a (very small) patch for this issue to this mail. It works 
in my configuration and enables the two nodes to communicate. I do not 
believe it will introduce any side-effects.

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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel

Bug in 6lowpan 16-bit short address detectioncode

Tony Cheneau — 2012-05-21T15:27:30

Hello,

Last week, I was analyzing some 6lowpan packet with Wireshark and got 
notified by the tool that the checksum (TCP, UDP or ICMPv6) was wrong. 
Some investigations showed me that this issue has been discussed and 
solved in Contiki, as pointed out in the following thread:
http://comments.gmane.org/gmane.os.contiki.devel/7053

In my case, the issue was triggered by the format of the address I 
assigned to my nodes. They were assigned with addresses fe80::1 and 
fe80::2 and the 6lowpan code wrongly interpreted them as being 16-bit 
short address mapped an EUI-64 address (although the ff:fe part was 
missing).

It turns out that the lowpan_is_iid_16_bit_compressable macro in 
net/ieee802154/6lowpan.h is not correct and does not behave according to 
RFC6282. I attached a patch that intend to correct this behavior.

Regards,
Tony
From 84a884346b175d2c2890249d122e2f34735d433a Mon Sep 17 00:00:00 2001
From: Tony Cheneau <tony.cheneau< at >amnesiak.org>
Date: Thu, 17 May 2012 17:13:06 -0400
Subject: [PATCH 1/1] lowpan_is_iid_16_bit_compressable() would not detect
 compressable address correctly (at least, not in a
 RFC6282 compliant way). This issue has been witnessed
 and solved in the past in Contiki. This patch is
 basicaly a port of their fix.

---
 net/ieee802154/6lowpan.h |   16 +++++++++-------
 1 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/net/ieee802154/6lowpan.h b/net/ieee802154/6lowpan.h
index 8c2251f..9aa3c41 100644
--- a/net/ieee802154/6lowpan.h
+++ b/net/ieee802154/6lowpan.h
< at >< at > -87,14 +87,16 < at >< at >
 #define is_addr_link_local(a) (((a)->s6_addr16[0]) == 0x80FE)
 
 /*
- * check whether we can compress the IID to 16 bits,
- * it's possible for unicast adresses with first 49 bits are zero only.
- */
+* check whether we can compress the IID to 16 bits,
+* it's possible for unicast adresses with first 49 bits are zero only.
+*/
 #define lowpan_is_iid_16_bit_compressable(a)\
-((((a)->s6_addr16[4]) == 0) &&\
- (((a)->s6_addr16[5]) == 0) &&\
- (((a)->s6_addr16[6]) == 0) &&\
- ((((a)->s6_addr[14]) & 0x80) == 0))
+((((a)->s6_addr16[4]) == 0) &&                       \
+ (((a)->s6_addr[10]) == 0)&&               \
+ (((a)->s6_addr[11]) == 0xff)&&                \
+ (((a)->s6_addr[12]) == 0xfe)&&                \
+ (((a)->s6_addr[13]) == 0))
+
 
 /* multicast address */
 #define is_addr_mcast(a) (((a)->s6_addr[0]) == 0xFF)

6lowpan Contiki fixes

Alexander Smirnov — 2012-05-14T12:21:06

Hi Jon,

I want to sync Linux 6lowpan implementation with Contiki one, so how
can I derive latest 6lowpan fixes?
Do you have any tracking system or may be just a list with bugs were fixed?

Or 'git log' must be my favorite tool? :-)

Thanks,
Alex

------------------------------------------------------------------------------
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/

Bug when setting the hop limit in 6lowpan.c

Tony Cheneau — 2012-04-26T21:46:23

Hello,

I'm reading the 6lowpan.c file and I find the following code very odd. 
I believe a bug lies in it. I cannot test at the moment because the 
serial driver I plan on using does not work with the 6lowpan stack.

In lowpan_header_create(), there is the following switch (around line 
495):

I believe the code in the default block should be:

Can you confirm this is indeed a bug?

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/

[PATCH net-next 0/2][6lowpan] codeimprovements and refactorings

Alexander Smirnov — 2012-04-26T09:35:49

The following patches contains 6lowpan code improvements.

With best regards,
Alex

8<--

The following changes since commit b89f01c8dab2b2d07729e1e6525272568bca54e0:

  6lowpan: add missing spin_lock_init() (2012-04-26 11:35:28 +0400)

are available in the git repository at:
  6lowpan_dev ..BRANCH.NOT.VERIFIED..

Alexander Smirnov (2):
      6lowpan: move frame allocation code to a separate function
      6lowpan: duplicate definition of IEEE802154_ALEN

 net/ieee802154/6lowpan.c |   85 +++++++++++++++++++++++++++-------------------
 net/ieee802154/6lowpan.h |    3 --
 2 files changed, 50 insertions(+), 38 deletions(-)

From: Alexander Smirnov <alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
Subject: [PATCH net-next 0/2][6lowpan] code improvements and refactorings
In-Reply-To: 


------------------------------------------------------------------------------
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/

[PATCH net 0/3][6lowpan] fixes for 6lowpan

Alexander Smirnov — 2012-04-26T09:24:55

The following patch set contains several fixes for the 6lowpan holes which lead
to unpredictable module state.

With best regards,
Alex

8<--

The following changes since commit 872f24dbc604ef585ea7eec73020dcdfaffd1956:

  tipc: remove inline instances from C source files. (2012-04-24 00:41:03 -0400)

are available in the git repository at:
  6lowpan_dev ..BRANCH.NOT.VERIFIED..

Alexander Smirnov (3):
      6lowpan: fix segmentation fault caused by mlme request
      6lowpan: clean up fragments list if module unloaded
      6lowpan: add missing spin_lock_init()

 net/ieee802154/6lowpan.c |   40 ++++++++++++++++++++++++++++++++++++++--
 1 files changed, 38 insertions(+), 2 deletions(-)

From: Alexander Smirnov <alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
Subject: [PATCH net 0/3][6lowpan] fixes for 6lowpan
In-Reply-To: 


------------------------------------------------------------------------------
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/

iz list command not working correctly when alowpan0 interface exists

Tony Cheneau — 2012-04-23T19:51:27

Hello,

I noted that iz list never returns the proper result (or any result) 
when 6lowpan is loaded and a lowpan0 interface exists. This is true for 
the Linus' git tree (at least in 
rev:0034102808e0dbbf3a2394b82b1bb40b5778de9e, but I haven't seen any 
changes in the more recent revisions).

Here are the steps to reproduce the "bug":

I hooked a debugger to the kernel. The problem lies in the 
ieee802154_dump_iface() function, at the line 262:

Here, function ieee802154_mlme_ops(dev) always returns NULL, because 
the 6lowpan module does not register dev->ml_priv (and set 
ARPHRD_IEEE802154 as dev->type value).

Maybe this is not the proper list to report the bug (given that the 
6lowpan code is now part of the mainstream kernel). In that case, please 
redirect me to the proper mailing list.

Please let me know if you need more details.

Regards,
Tony


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

[PATCH v1] ieee802154: MRF24J40 driver

Alan Ott — 2012-04-23T04:34:33

Driver for the Microchip MRF24J40 802.15.4 WPAN module.

---

This is a first pass. All the places marked TODO contain things which I
think need to be fixed before merge. Some of these contain questions for
the Linux-Zigbee team. All comments appreciated.

I still plan change the structure of the SPI read functions to return an
error code.
---
 drivers/ieee802154/Kconfig    |    1 +
 drivers/ieee802154/mrf24j40.c |  747 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 748 insertions(+), 0 deletions(-)
 create mode 100644 drivers/ieee802154/mrf24j40.c

diff --git a/drivers/ieee802154/Kconfig b/drivers/ieee802154/Kconfig
index a9a6145..5703e7a 100644
--- a/drivers/ieee802154/Kconfig
+++ b/drivers/ieee802154/Kconfig
< at >< at > -20,6 +20,7 < at >< at > config IEEE802154_FAKEHARD
           This driver can also be built as a module. To do so say M here.
   The module will be called 'fakehard'.
 
+<<<<<<< HEAD
 config IEEE802154_FAKELB
 depends on IEEE802154_DRIVERS && MAC802154
 tristate "Fake LR-WPAN driver with several interconnected devices"
diff --git a/drivers/ieee802154/mrf24j40.c b/drivers/ieee802154/mrf24j40.c
new file mode 100644
index 0000000..e7bef5b
--- /dev/null
+++ b/drivers/ieee802154/mrf24j40.c
< at >< at > -0,0 +1,747 < at >< at >
+/*
+ * Driver for Microchip MRF24J40 802.15.4 Wireless-PAN Networking controller
+ *
+ * Copyright (C) 2012 Alan Ott <alan-yzvJWuRpmD1zbRFIqnYvSA< at >public.gmane.org>
+ *                    Signal 11 Software
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/kernel.h>
+#include <linux/spi/spi.h>
+#include <linux/irq.h>
+#include <linux/interrupt.h>
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+
+#include <linux/netdevice.h>
+#include <linux/skbuff.h>
+#include <net/af_ieee802154.h>
+#include <net/ieee802154.h>
+#include <net/ieee802154_netdev.h>
+#include <net/nl802154.h>
+#include <net/wpan-phy.h>
+#include <net/mac802154.h>
+
+/* MRF24J40 Short Address Registers */
+#define REG_RXMCR    0x00  /* Receive MAC control */
+#define REG_PANIDL   0x01  /* PAN ID (low) */
+#define REG_PANIDH   0x02  /* PAN ID (high) */
+#define REG_SADRL    0x03  /* Short address (low) */
+#define REG_SADRH    0x04  /* Short address (high) */
+#define REG_EADR0    0x05  /* Long address (low) (high is EADR7) */
+#define REG_TXMCR    0x11  /* Transmit MAC control */
+#define REG_PACON0   0x16  /* Power Amplifier Control */
+#define REG_PACON1   0x17  /* Power Amplifier Control */
+#define REG_PACON2   0x18  /* Power Amplifier Control */
+#define REG_TXNCON   0x1B  /* Transmit Normal FIFO Control */
+#define REG_TXSTAT   0x24  /* TX MAC Status Register */
+#define REG_SOFTRST  0x2A  /* Soft Reset */
+#define REG_TXSTBL   0x2E  /* TX Stabilization */
+#define REG_INTSTAT  0x31  /* Interrupt Status */
+#define REG_INTCON   0x32  /* Interrupt Control */
+#define REG_RFCTL    0x36  /* RF Control Mode Register */
+#define REG_BBREG1   0x39  /* Baseband Registers */
+#define REG_BBREG2   0x3A  /* */
+#define REG_BBREG6   0x3E  /* */
+#define REG_CCAEDTH  0x3F  /* Energy Detection Threshold */
+
+/* MRF24J40 Long Address Registers */
+#define REG_RFCON0     0x200  /* RF Control Registers */
+#define REG_RFCON1     0x201
+#define REG_RFCON2     0x202
+#define REG_RFCON3     0x203
+#define REG_RFCON5     0x205
+#define REG_RFCON6     0x206
+#define REG_RFCON7     0x207
+#define REG_RFCON8     0x208
+#define REG_RSSI       0x210
+#define REG_SLPCON0    0x211  /* Sleep Clock Control Registers */
+#define REG_SLPCON1    0x220
+#define REG_WAKETIMEL  0x222  /* Wake-up Time Match Value Low */
+#define REG_WAKETIMEH  0x223  /* Wake-up Time Match Value High */
+#define REG_RX_FIFO    0x300  /* Receive FIFO */
+
+/** Device configuration **/
+/* Only channels 11-26 on page 0 are supported. */
+#define MRF24J40_CHAN_MIN 11
+#define MRF24J40_CHAN_MAX 26
+#define CHANNEL_MASK (((u32)1 << (MRF24J40_CHAN_MAX + 1)) \
+      - ((u32)1 << MRF24J40_CHAN_MIN))
+
+/* Device Private Data */
+struct mrf24j40 {
+struct spi_device *spi;
+struct ieee802154_dev *dev;
+
+struct mutex mutex;
+struct completion tx_complete;
+struct work_struct irqwork;
+u8 *buf; /* 3 bytes. Used for SPI single-register transfers. */
+};
+
+/* Read/Write SPI Commands for Short and Long Address registers. */
+#define MRF24J40_READSHORT(reg) ((reg) << 1)
+#define MRF24J40_WRITESHORT(reg) ((reg) << 1 | 1)
+#define MRF24J40_READLONG(reg) (1 << 15 | (reg) << 5)
+#define MRF24J40_WRITELONG(reg) (1 << 15 | (reg) << 5 | 1 << 4)
+
+/* Speed to run the device at. TODO: Get the real max value from
+   someone at Microchip since it isn't in the datasheet. */
+#define SPI_SPEED_HZ 1000000
+
+#define printdev(X) (&X->spi->dev)
+
+static int write_short_reg(struct mrf24j40 *devrec, __u8 reg, __u8 value)
+{
+int ret;
+struct spi_message msg;
+struct spi_transfer xfer = {
+.len = 2,
+.tx_buf = devrec->buf,
+.rx_buf = devrec->buf,
+};
+
+spi_message_init(&msg);
+spi_message_add_tail(&xfer, &msg);
+mutex_lock(&devrec->mutex);
+devrec->buf[0] = MRF24J40_WRITESHORT(reg);
+devrec->buf[1] = value;
+ret = spi_sync(devrec->spi, &msg);
+if (ret)
+goto out;
+
+out:
+mutex_unlock(&devrec->mutex);
+return ret;
+}
+
+static __u8 read_short_reg(struct mrf24j40 *devrec, __u8 reg)
+{
+int ret;
+struct spi_message msg;
+struct spi_transfer xfer = {
+.len = 2,
+.tx_buf = devrec->buf,
+.rx_buf = devrec->buf,
+};
+
+spi_message_init(&msg);
+spi_message_add_tail(&xfer, &msg);
+mutex_lock(&devrec->mutex);
+devrec->buf[0] = MRF24J40_READSHORT(reg);
+devrec->buf[1] = 0;
+ret = spi_sync(devrec->spi, &msg);
+if (ret) {
+printk("SPI read Failed\n");
+goto out;
+}
+else
+ret = devrec->buf[1];
+
+out:
+mutex_unlock(&devrec->mutex);
+return ret;
+}
+
+static u8 read_long_reg(struct mrf24j40 *devrec, __u16 reg)
+{
+int ret;
+u16 cmd;
+struct spi_message msg;
+struct spi_transfer xfer = {
+.len = 3,
+.tx_buf = devrec->buf,
+.rx_buf = devrec->buf,
+};
+
+spi_message_init(&msg);
+spi_message_add_tail(&xfer, &msg);
+cmd = MRF24J40_READLONG(reg);
+mutex_lock(&devrec->mutex);
+devrec->buf[0] = cmd >> 8 & 0xff;
+devrec->buf[1] = cmd & 0xff;
+devrec->buf[2] = 0;
+ret = spi_sync(devrec->spi, &msg);
+if (ret) {
+printk("SPI read Failed\n");
+goto out;
+}
+else
+ret = devrec->buf[2];
+
+out:
+mutex_unlock(&devrec->mutex);
+return ret;
+}
+
+static int write_long_reg(struct mrf24j40 *devrec, __u16 reg, u8 val)
+{
+int ret;
+u16 cmd;
+struct spi_message msg;
+struct spi_transfer xfer = {
+.len = 3,
+.tx_buf = devrec->buf,
+.rx_buf = devrec->buf,
+};
+
+spi_message_init(&msg);
+spi_message_add_tail(&xfer, &msg);
+cmd = MRF24J40_WRITELONG(reg);
+mutex_lock(&devrec->mutex);
+devrec->buf[0] = cmd >> 8 & 0xff;
+devrec->buf[1] = cmd & 0xff;
+devrec->buf[2] = val;
+ret = spi_sync(devrec->spi, &msg);
+if (ret) {
+printk("SPI write Failed\n");
+goto out;
+}
+
+out:
+mutex_unlock(&devrec->mutex);
+return ret;
+}
+
+/* This function relies on an undocumented write method. Once a write command
+   and address is set, as many bytes of data as desired can be clocked into
+   the device. The datasheet only shows setting one byte at a time. */
+static int write_tx_buf(struct mrf24j40 *devrec, __u16 reg, const u8 *data, size_t length)
+{
+int ret;
+u16 cmd;
+u8 lengths[2];
+struct spi_message msg;
+struct spi_transfer addr_xfer = {
+.len = 2,
+.tx_buf = devrec->buf,
+};
+struct spi_transfer lengths_xfer = {
+.len = 2,
+.tx_buf = &lengths, // TODO: Is DMA really required for SPI?
+};
+struct spi_transfer data_xfer = {
+.len = length,
+.tx_buf = data,
+};
+
+BUG_ON(length > 126);
+
+spi_message_init(&msg);
+spi_message_add_tail(&addr_xfer, &msg);
+spi_message_add_tail(&lengths_xfer, &msg);
+spi_message_add_tail(&data_xfer, &msg);
+cmd = MRF24J40_WRITELONG(reg);
+mutex_lock(&devrec->mutex);
+devrec->buf[0] = cmd >> 8 & 0xff;
+devrec->buf[1] = cmd & 0xff;
+lengths[0] = 0x0; /* Header Length. Set to 0 for now. TODO */
+lengths[1] = length; /* Total length */
+ret = spi_sync(devrec->spi, &msg);
+if (ret) {
+printk("SPI write Failed\n");
+goto out;
+}
+
+out:
+mutex_unlock(&devrec->mutex);
+return ret;
+}
+
+static int mrf24j40_read_rx_buf(struct mrf24j40 *devrec, u8 *data, u8 *len, u8 *lqi)
+{
+u8 val;
+u8 addr[2];
+u8 lqi_rssi[2];
+u16 cmd;
+int ret;
+struct spi_message msg;
+struct spi_transfer addr_xfer = {
+.len = 2,
+.tx_buf = &addr,
+};
+struct spi_transfer data_xfer = {
+.len = 0x0, /* set below */
+.rx_buf = data,
+};
+struct spi_transfer status_xfer = {
+.len = 2,
+.rx_buf = &lqi_rssi,
+};
+
+/* Get the length of the data in the RX FIFO. */
+val = read_long_reg(devrec, REG_RX_FIFO);
+
+if (val > 143) {
+/* RX FIFO on the MRF24J40 is 144 bytes long. One byte is
+   used at the beginning of the buffer for the length.  */
+dev_err(printdev(devrec), "Invalid length read from device. Performing short read.\n");
+val = 143;
+}
+
+if (val > *len) {
+/* We read 2 bytes more than the length at 0x300. */
+dev_err(printdev(devrec), "Buffer not big enough. Performing short read\n");
+val = *len;
+}
+
+/* Set up the commands to read the data. */
+cmd = MRF24J40_READLONG(REG_RX_FIFO+1);
+addr[0] = cmd >> 8 & 0xff;
+addr[1] = cmd & 0xff;
+data_xfer.len = val;
+
+spi_message_init(&msg);
+spi_message_add_tail(&addr_xfer, &msg);
+spi_message_add_tail(&data_xfer, &msg);
+spi_message_add_tail(&status_xfer, &msg);
+ret = spi_sync(devrec->spi, &msg);
+if (ret) {
+printk("SPI RX Buffer Read Failed.\n");
+goto out;
+}
+
+*lqi = lqi_rssi[0];
+*len = val;
+
+#ifdef DEBUG
+{
+int i;
+printk(KERN_DEBUG "%d bytes received\n", *len);
+printk(KERN_DEBUG "  ");
+for (i = 0; i < *len; i++) {
+printk("%02hhx ", data[i]);
+}
+printk("\n");
+printk(KERN_DEBUG "    %02hhx %02hhx\n",
+lqi_rssi[0], lqi_rssi[1]);
+}
+#endif
+
+out:
+return ret;
+}
+
+
+
+static int mrf24j40_tx(struct ieee802154_dev *dev, struct sk_buff *skb)
+{
+struct mrf24j40 *devrec = dev->priv;
+u8 val;
+int ret = 0;
+
+dev_dbg(printdev(devrec), "tx packet of %d bytes\n", skb->len);
+
+ret = write_tx_buf(devrec, 0x000, skb->data, skb->len);
+if (ret)
+goto err;
+
+/* Set TXNTRIG bit of TXNCON to send packet */
+val = read_short_reg(devrec, REG_TXNCON);
+val |= 0x1;
+val &= ~((u8)0x4);
+write_short_reg(devrec, REG_TXNCON, val);
+
+INIT_COMPLETION(devrec->tx_complete);
+
+/* Wait for the device to send the TX complete interrupt. */
+ret = wait_for_completion_interruptible_timeout(
+&devrec->tx_complete,
+5 * HZ);
+if (ret == -ERESTARTSYS)
+goto err;
+if (ret == 0) {
+ret = -ETIMEDOUT;
+goto err;
+}
+
+/* Check for send error from the device. */
+val = read_short_reg(devrec, REG_TXSTAT);
+if (val & 0x1) {
+dev_err(printdev(devrec), "Error Sending. Retry count exceeded\n");
+ret = -ECOMM; // TODO: Better error code ?
+}
+else
+dev_dbg(printdev(devrec), "Packet Sent\n");
+
+err:
+
+return ret;
+}
+
+static int mrf24j40_ed(struct ieee802154_dev *dev, u8 *level)
+{
+// TODO:
+printk(KERN_WARNING "mrf24j40: ed not implemented\n");
+*level = 0;
+return 0;
+}
+
+static int mrf24j40_start(struct ieee802154_dev *dev)
+{
+struct mrf24j40 *devrec = dev->priv;
+u8 val;
+
+dev_dbg(printdev(devrec), "start\n");
+
+val = read_short_reg(devrec, REG_INTCON);
+val &= ~((u8)(0x1|0x8)); /* Clear TXNIE and RXIE. Enable interrupts */
+write_short_reg(devrec, REG_INTCON, val);
+
+return 0;
+}
+
+static void mrf24j40_stop(struct ieee802154_dev *dev)
+{
+struct mrf24j40 *devrec = dev->priv;
+u8 val;
+dev_dbg(printdev(devrec), "stop\n");
+
+val = read_short_reg(devrec, REG_INTCON);
+val |= 0x1|0x8; /* Set TXNIE and RXIE. Disable Interrupts */
+write_short_reg(devrec, REG_INTCON, val);
+
+return;
+}
+
+static int mrf24j40_set_channel(struct ieee802154_dev *dev, int page, int channel)
+{
+struct mrf24j40 *devrec = dev->priv;
+__u8 val;
+
+dev_dbg(printdev(devrec), "Set Channel %d\n", channel);
+
+BUG_ON(page != 0);
+BUG_ON(channel < MRF24J40_CHAN_MIN);
+BUG_ON(channel > MRF24J40_CHAN_MAX);
+
+/* Set Channel */
+val = ((((__u8)channel)-11) << 4) | 0x03;
+write_long_reg(devrec, REG_RFCON0, val);
+
+/* RF Reset */
+val = read_short_reg(devrec, REG_RFCTL);
+val |= 0x04;
+write_short_reg(devrec, REG_RFCTL, val);
+val &= ~((__u8)0x04);
+write_short_reg(devrec, REG_RFCTL, val);
+
+udelay(192); /* per datasheet */
+
+return 0;
+}
+
+static int mrf24j40_filter(struct ieee802154_dev *dev,
+   struct ieee802154_hw_addr_filt *filt,
+   unsigned long changed)
+{
+struct mrf24j40 *devrec = dev->priv;
+
+dev_dbg(printdev(devrec), "filter\n");
+
+if (changed & IEEE802515_SADDR_CHANGED) {
+/* Short Addr */
+u8 addrh, addrl;
+addrh = filt->short_addr >> 8 & 0xff;
+addrl = filt->short_addr & 0xff;
+
+write_short_reg(devrec, REG_SADRH, addrh);
+write_short_reg(devrec, REG_SADRL, addrl);
+dev_dbg(printdev(devrec), "Set short addr to %04hx\n", filt->short_addr);
+}
+
+if (changed & IEEE802515_IEEEADDR_CHANGED) {
+/* Device Address */
+int i;
+for (i = 0; i < 8; i++)
+write_short_reg(devrec, REG_EADR0+i,
+filt->ieee_addr[i]);
+
+#ifdef DEBUG
+printk(KERN_DEBUG "Set long addr to: ");
+for (i = 0; i < 8; i++) {
+printk("%02hhx ", filt->ieee_addr[i]);
+}
+printk(KERN_DEBUG "\n");
+#endif
+}
+
+if (changed & IEEE802515_PANID_CHANGED) {
+/* PAN ID */
+u8 panidl, panidh;
+panidh = filt->pan_id >> 8 & 0xff;
+panidl = filt->pan_id & 0xff;
+write_short_reg(devrec, REG_PANIDH, panidh);
+write_short_reg(devrec, REG_PANIDL, panidl);
+
+dev_dbg(printdev(devrec), "Set PANID to %04hx\n", filt->pan_id);
+}
+
+if (changed & IEEE802515_PANC_CHANGED) {
+/* Pan Coordinator */
+u8 val;
+val = read_short_reg(devrec, REG_RXMCR);
+if (filt->pan_coord)
+val |= 0x8;
+else
+val &= ~((u8)0x8);
+write_short_reg(devrec, REG_RXMCR, val);
+
+/* REG_SLOTTED is maintained as default (unslotted/CSMA-CA).
+ * REG_ORDER is maintained as default (no beacon/superframe).
+ */
+
+dev_dbg(printdev(devrec), "Set Pan Coord to %s\n",
+filt->pan_coord? "on": "off");
+}
+
+return 0;
+}
+
+static int mrf24j40_handle_rx(struct mrf24j40 *devrec)
+{
+u8 len = 144; /* size of RX FIFO buffer */
+u8 lqi = 0;
+u8 val;
+int ret = 0;
+struct sk_buff *skb;
+
+/* Turn off reception of packets off the air. This prevents the
+ * device from overwriting the buffer while we're reading it. */
+val = read_short_reg(devrec, REG_BBREG1);
+val |= 4; /* SET RXDECINV */
+write_short_reg(devrec, REG_BBREG1, val);
+
+skb = alloc_skb(len, GFP_KERNEL);
+if (!skb) {
+ret = -ENOMEM;
+goto out;
+}
+
+ret = mrf24j40_read_rx_buf(devrec, skb_put(skb, len), &len, &lqi);
+if (ret < 0) {
+dev_err(printdev(devrec), "Failure reading RX FIFO\n");
+kfree_skb(skb);
+ret = -EINVAL;
+goto out;
+}
+
+/* Cut off the checksum */
+skb_trim(skb, len-2);
+
+ieee802154_rx_irqsafe(devrec->dev, skb, lqi);
+
+dev_dbg(printdev(devrec), "RX Handled\n");
+
+out:
+/* Turn back on reception of packets off the air. */
+val = read_short_reg(devrec, REG_BBREG1);
+val &= ~((u8)0x4); /* Clear RXDECINV */
+write_short_reg(devrec, REG_BBREG1, val);
+
+return ret;
+}
+
+static struct ieee802154_ops mrf24j40_ops = {
+.owner = THIS_MODULE,
+.xmit = mrf24j40_tx,
+.ed = mrf24j40_ed,
+.start = mrf24j40_start,
+.stop = mrf24j40_stop,
+.set_channel = mrf24j40_set_channel,
+.set_hw_addr_filt = mrf24j40_filter,
+};
+
+static irqreturn_t mrf24j40_isr(int irq, void *data)
+{
+struct mrf24j40 *devrec = data;
+
+disable_irq_nosync(irq);
+
+schedule_work(&devrec->irqwork);
+
+return IRQ_HANDLED;
+}
+
+static void mrf24j40_isrwork(struct work_struct *work)
+{
+struct mrf24j40 *devrec = container_of(work, struct mrf24j40, irqwork);
+u8 intstat;
+
+/* Check for TX complete */
+intstat = read_short_reg(devrec, REG_INTSTAT);
+if (intstat & 0x1)
+complete(&devrec->tx_complete);
+
+/* Check for Rx */
+if (intstat & 0x8) {
+mrf24j40_handle_rx(devrec);
+}
+
+intstat = read_short_reg(devrec, REG_INTSTAT);
+
+enable_irq(devrec->spi->irq);
+}
+
+static int __devinit mrf24j40_probe(struct spi_device *spi)
+{
+int ret = -ENOMEM;
+int val;
+struct mrf24j40 *devrec;
+
+printk(KERN_INFO "mrf24j40: probe(). IRQ: %d\n", spi->irq);
+
+devrec = kzalloc(sizeof(struct mrf24j40), GFP_KERNEL);
+if (!devrec)
+goto err_devrec;
+devrec->buf = kzalloc(3, GFP_KERNEL);
+if (!devrec->buf)
+goto err_buf;
+
+spi->mode = SPI_MODE_0; // TODO: Is this appropriate for right here?
+spi->max_speed_hz = SPI_SPEED_HZ;
+
+
+mutex_init(&devrec->mutex);
+init_completion(&devrec->tx_complete);
+INIT_WORK(&devrec->irqwork, mrf24j40_isrwork);
+devrec->spi = spi;
+dev_set_drvdata(&spi->dev, devrec);
+
+/* Register with the 802154 subsystem */
+
+// TODO: Shouldn't priv_size be set to zero in the call to
+// ieee802154_alloc_device()?  Other drivers do it this way, but
+// mac802154/main.c seems to suggest zero is the right answer
+// instead.
+devrec->dev = ieee802154_alloc_device(sizeof(*devrec), &mrf24j40_ops);
+if (!devrec->dev)
+goto err_alloc_dev;
+
+devrec->dev->priv = devrec;
+devrec->dev->parent = &devrec->spi->dev;
+devrec->dev->phy->channels_supported[0] = CHANNEL_MASK;
+devrec->dev->flags = IEEE802154_HW_OMIT_CKSUM|IEEE802154_HW_AACK;
+
+dev_dbg(printdev(devrec), "registered mrf24j40\n");
+ret = ieee802154_register_device(devrec->dev);
+if (ret)
+goto err_register_device;
+
+/* Initialize the device.
+From datasheet section 3.2: Initialization. */
+write_short_reg(devrec, REG_SOFTRST, 0x07);
+write_short_reg(devrec, REG_PACON2, 0x98);
+write_short_reg(devrec, REG_TXSTBL, 0x95);
+write_long_reg(devrec, REG_RFCON0, 0x03);
+write_long_reg(devrec, REG_RFCON1, 0x01);
+write_long_reg(devrec, REG_RFCON2, 0x80);
+write_long_reg(devrec, REG_RFCON6, 0x90);
+write_long_reg(devrec, REG_RFCON7, 0x80);
+write_long_reg(devrec, REG_RFCON8, 0x10);
+write_long_reg(devrec, REG_SLPCON1, 0x21);
+write_short_reg(devrec, REG_BBREG2, 0x80);
+write_short_reg(devrec, REG_CCAEDTH, 0x60);
+write_short_reg(devrec, REG_BBREG6, 0x40);
+write_short_reg(devrec, REG_RFCTL, 0x04);
+write_short_reg(devrec, REG_RFCTL, 0x0);
+udelay(192);
+
+/* Set RX Mode. RXMCR<1:0>: 0x0 normal, 0x1 promisc, 0x2 error */
+val = read_short_reg(devrec, REG_RXMCR);
+val &= ~((u8)0x3);
+write_short_reg(devrec, REG_RXMCR, val);
+
+ret = request_irq(spi->irq,
+  mrf24j40_isr,
+  IRQF_TRIGGER_FALLING,
+  dev_name(&spi->dev),
+  devrec);
+
+if (ret) {
+dev_err(printdev(devrec), "Unable to get IRQ");
+goto err_irq;
+}
+
+return 0;
+
+err_irq:
+ieee802154_unregister_device(devrec->dev);
+err_register_device:
+ieee802154_free_device(devrec->dev);
+err_alloc_dev:
+kfree(devrec->buf);
+err_buf:
+kfree(devrec);
+err_devrec:
+return ret;
+}
+
+static int __devexit mrf24j40_remove(struct spi_device *spi)
+{
+struct mrf24j40 *devrec = dev_get_drvdata(&spi->dev);
+
+dev_dbg(printdev(devrec), "remove\n");
+
+free_irq(spi->irq, devrec);
+flush_work_sync(&devrec->irqwork); /* TODO: Is this the right call? */
+ieee802154_unregister_device(devrec->dev);
+ieee802154_free_device(devrec->dev);
+// TODO: Will ieee802154_free_device() wait until ->xmit() is
+// complete?
+
+/* Clean up the SPI stuff. */
+dev_set_drvdata(&spi->dev, NULL);
+kfree(devrec->buf);
+kfree(devrec);
+return 0;
+}
+
+static const struct spi_device_id mrf24j40_ids[] = {
+{ "mrf24j40", 0 },
+{ "mrf24j40ma", 0 },
+{ },
+};
+MODULE_DEVICE_TABLE(spi, mrf24j40_ids);
+
+static struct spi_driver mrf24j40_driver = {
+.driver = {
+.name = "mrf24j40",
+.bus = &spi_bus_type,
+.owner = THIS_MODULE,
+},
+.id_table = mrf24j40_ids,
+.probe = mrf24j40_probe,
+.remove = __devexit_p(mrf24j40_remove),
+};
+
+static int __init mrf24j40_init(void)
+{
+return spi_register_driver(&mrf24j40_driver);
+}
+
+static void __exit mrf24j40_exit(void)
+{
+spi_unregister_driver(&mrf24j40_driver);
+}
+
+module_init(mrf24j40_init);
+module_exit(mrf24j40_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Alan Ott");
+MODULE_DESCRIPTION("MRF24J40 SPI 802.15.4 Controller Driver");

Unreachable code in serial.c (bug?)

Tony Cheneau — 2012-04-20T21:10:18

Hello,

I was reading the drivers/ieee802154/serial.c file (in the devel 
branch) and found the following code to be unreachable in function 
ieee802154_tty_open(), near line 889:

I believe the call to ieee802154_unregister_device() should be placed 
after the out_free label (or else, it is never reached). Can you 
confirm?

Regards,
Tony


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

Kernel freezes during transmitting via 6lowpan

Thomas Fechner — 2012-04-11T13:49:56

I'm trying to use 6lowpan between two avr32 boards. On each board there 
are two at86rf231 sharing one IRQ.
I have patched at86rf230 and mac802154 into the mainline kernel 3.3.1.
The board setup code is the following:

static struct at86rf230_platform_data at86rf230_info_a =
     {
         .rstn         = -1,
         .slp_tr       = GPIO_PIN_PB(10),
         .dig2         = -1,
         .reset       = NULL,
         .reset_data    = NULL,
     };

static struct at86rf230_platform_data at86rf230_info_b =
     {
         .rstn         = -1,
         .slp_tr     = GPIO_PIN_PB(11),
         .dig2         = -1,
         .reset        = NULL,
         .reset_data    = NULL,
     };



static struct spi_board_info spi0_board_info[] __initdata = {

     {
         .modalias       = "at86rf230",
         .max_speed_hz   = 1000000,
         .irq        = AT32_EXTINT(1),
         .chip_select       = 2,
         .mode             = SPI_MODE_0,
         .platform_data  = &at86rf230_info_a,

     },

     {
         .modalias       = "at86rf230",
         .max_speed_hz   = 1000000,
         .irq        = AT32_EXTINT(1),
         .chip_select       = 1,
         .mode             = SPI_MODE_0,
         .platform_data  = &at86rf230_info_b,
     }

};

static int __init lw_dimm_cpu_cb09_init(void)
{
   .
   .
at32_add_device_spi(0, spi0_board_info, ARRAY_SIZE(spi0_board_info));
   .
   .
}

Following modules have been loaded:

~ # lsmod
Module                  Size  Used by    Tainted: G
6lowpan                 8589  0
af_802154               6440  0
at86rf230               9083  0
mac802154              13803  1 at86rf230
ieee802154             10769  1 mac802154
mcp251x                 6460  0
spidev                  3231  0
spi_atmel               3601  0
macb

On both boards I use following sequence to start up 6lowpan:

   ~ # /usr/sbin/iz add wpan-phy0
   Registered new device ('wpan0') on phy wpan-phy0

   ~ # /sbin/ip link set wpan0 address de:ad:be:af:ca:fe:ba:be (resp. 
de:ad:be:af:ca:fe:ba:ce on the second board)

   ~ # /sbin/ifconfig wpan0 up

   ~ # /usr/sbin/iz assoc wpan0 777 1 14 short
   Received short address 8001, status 00

   ~ # /sbin/ip link add link wpan0 name lowpan0 type lowpan

   ~ # /sbin/ifconfig lowpan0 up

   ~ # /sbin/ip -6 addr add 2001:0db8:0:f101::1/64 dev lowpan0 (resp. 
2001:0db8:0:f101::2/64 on the second board)

Ping6 succeeds:

   ~ # ping6 2001:0db8:0:f101::2
   PING 2001:0db8:0:f101::2 (2001:db8:0:f101::2): 56 data bytes
   64 bytes from 2001:db8:0:f101::2: seq=0 ttl=64 time=117.366 ms
   64 bytes from 2001:db8:0:f101::2: seq=1 ttl=64 time=72.838 ms
   64 bytes from 2001:db8:0:f101::2: seq=2 ttl=64 time=67.647 ms
   64 bytes from 2001:db8:0:f101::2: seq=3 ttl=64 time=57.074 ms
   64 bytes from 2001:db8:0:f101::2: seq=4 ttl=64 time=54.589 ms
   ^C
   --- 2001:0db8:0:f101::2 ping statistics ---
   5 packets transmitted, 5 packets received, 0% packet loss
   round-trip min/avg/max = 54.589/73.902/117.366 ms
   ~ #



During transmitting udp packets (e.g. RFC868 time protocole via udp) the 
receiving kernel freezes with following output:

Oops: Unhandled exception in kernel mode, sig: 7 [#1]
FRAME_POINTER chip: 0x01f:0x1e82 rev 2
Modules linked in: 6lowpan af_802154 at86rf230 mac802154 ieee802154 
mcp251x spidev spi_atmel macb
PC is at lowpan_rcv+0x576/0x714 [6lowpan]
LR is at lowpan_rcv+0x576/0x714 [6lowpan]
pc : [<c08d97c2>]    lr : [<c08d97c2>]    Tainted: G        W
<0>sp : 97c31e04  r12: 97e3623e  r11: 97e3623e
r10: 00000008  r9 : 00000000  r8 : 97e3623a
r7 : 97c31e40  r6 : 000000f0  r5 : 97e36217  r4 : 00000000
r3 : 97e603c0  r2 : c08da4f0  r1 : c08da4e4  r0 : 0000007e
Flags: qvNzc
Mode bits: hjmde....g
CPU Mode: Supervisor
Process: kworker/u:0 [5] (task: 97c22b00 thread: 97c30000)
Stack: (0x97c31e04 to 0x97c32000)
1e00:          00000006 00000004 00000078 60000000 c08c1a40 20010db8 
0000f101
1e20: 00000000 00000002 20010db8 0000f101 00000000 00000001 90270a4c 
00400022
1e40: 90149dfc 97c31e6c c08ce184 902938a4 00000000 000000f6 97ded400 
00000000
1e60: 9028e1ec 97e603c0 c08ce1a4 9014ab64 97c31e90 90289200 90289240 
00000000
1e80: 00000000 00000001 ffff7d8a 9028e1ec 9014c866 97c31eb4 90289240 
00000040
1ea0: 00000000 00000003 0000012c ffff7d8a 9028e1ec 90021644 97c31edc 
00000100
1ec0: 97c30000 00000000 00000003 00000000 0000000c 9028e1ec 0000000a 
9002184e
1ee0: 97c31f00 00400022 97ded760 00000000 c08b2588 97e60a80 97decd60 
c08b255c
1f00: 9014c700 97c31f14 00000000 97ded760 00000000 c08b0dc4 97c31f2c 
97e603c0
1f20: 97ded760 00000000 97ded760 c08b00c6 97c31f50 97e60a80 97decd60 
00000000
1f40: 97c0e180 9028e7d0 97d86800 0000009a c08b00f8 97c31f64 97e204e0 
00000000
1f60: 00000000 90029a80 97c31f80 97e204e4 00000000 00000000 c08b00e8 
97d86805
1f80: 9002a5a8 97c31fa4 97c0e180 97c0e190 00000000 9028e7d0 97c0e190 
9002ce18
1fa0: 97c25f3c 9002ce72 97c31fdc 97c25f3c 97c0e180 00000000 9002a4a8 
9002018e
1fc0: 9002ce18 97c25f3c 00000000 97c0e180 00000000 97c31fd4 97c31fd4 
9002018e
1fe0: 00000000 00000000 00000000 00000000 00000000 9002018e 9002ce18 
97c25f3c
Call trace:
  [<90149dfc>] __netif_receive_skb+0x2f4/0x350
  [<9014ab64>] process_backlog+0x40/0xac
  [<9014c866>] net_rx_action+0x2e/0xc8
  [<90021644>] __do_softirq+0x54/0xbc
  [<9002184e>] do_softirq+0x22/0x3c
  [<9014c700>] netif_rx_ni+0x14/0x1c
  [<c08b0dc4>] mac802154_wpans_rx+0x2b8/0x328 [mac802154]
  [<c08b00c6>] mac802154_subif_rx+0x46/0x68 [mac802154]
  [<c08b00f8>] mac802154_rx_worker+0x10/0x1c [mac802154]
  [<90029a80>] process_one_work+0x134/0x212
  [<9002a5a8>] worker_thread+0x100/0x1c4
  [<9002ce72>] kthread+0x5a/0x68
  [<9002018e>] do_exit+0x0/0x432

Disabling lock debugging due to kernel taint
Kernel panic - not syncing: Fatal exception in interrupt

On the transmitting board 'dmesg' shows the following:

~ #  dmesg
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel: (lowpan_header_create): 
IPv6 header dump:
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel:        version = 6
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel:        length  = 40
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel:        nexthdr = 0x3a
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel:        hop_lim = 255
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel: (lowpan_header_create) 
raw skb network header dump:
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel:        00000000: 60 00 
00 00 00 28 3a ff 20 01 0d b8 00 00 f1 01
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel:        00000010: 00 00 
00 00 00 00 00 02 ff 02 00 00 00 00 00 00
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel:        00000020: 00 00 
00 01 ff 00 00 01
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel: (lowpan_header_create): 
send the full source address
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel: (lowpan_header_create): 
destination address is multicast
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel: compressed to 6 octets
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel: (lowpan_header_create) 
raw skb data dump:
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel:        00000000: 7b 09 
3a 20 01 0d b8 00 00 f1 01 00 00 00 00 00
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel:        00000010: 00 00 
02 02 01 ff 00 00 01 87 00 3c 1c 00 00 00
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel:        00000020: 00 20 
01 0d b8 00 00 f1 01 00 00 00 00 00 00 00
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel:        00000030: 01 01 
02 00 00 00 00 00 00 00 00 00 00 00 00 00
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel:        00000040: 00
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel: (lowpan_xmit): package xmit
Apr 11 15:13:10 Dimm-CPU-cb09 user.err kernel: at86rf230_xmit
Apr 11 15:13:10 Dimm-CPU-cb09 user.err kernel: at86rf230_state 4
Apr 11 15:13:10 Dimm-CPU-cb09 user.err kernel: at86rf230_state val1 = 6
Apr 11 15:13:10 Dimm-CPU-cb09 user.err kernel: at86rf230_state val2 = 9
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel: at86rf230 spi0.2: 
at86rf230_isr: IRQ!
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel: at86rf230 spi0.1: 
at86rf230_isr: IRQ!
Apr 11 15:13:10 Dimm-CPU-cb09 user.debug kernel: at86rf230 spi0.2: 
at86rf230_irqwork: IRQ status: 08
Apr 11 15:13:10 Dimm-CPU-cb09 user.err kernel: at86rf230_state 6
Apr 11 15:13:10 Dimm-CPU-cb09 user.err kernel: at86rf230_state val1 = 9
Apr 11 15:13:10 Dimm-CPU-cb09 user.err kernel: at86rf230_state val2 = 6
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: at86rf230 spi0.2: 
at86rf230_isr: IRQ!
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: at86rf230 spi0.1: 
at86rf230_isr: IRQ!
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: at86rf230 spi0.2: 
at86rf230_irqwork: IRQ status: 04
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: at86rf230 spi0.2: 
at86rf230_isr: IRQ!
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: at86rf230 spi0.1: 
at86rf230_isr: IRQ!
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: at86rf230 spi0.2: 
at86rf230_irqwork: IRQ status: 08
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: (lowpan_process_data) 
raw skb data dump:
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel:        00000000: 7b 00 
3a 20 01 0d b8 00 00 f1 01 00 00 00 00 00
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel:        00000010: 00 00 
01 20 01 0d b8 00 00 f1 01 00 00 00 00 00
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel:        00000020: 00 00 
02 88 00 b9 65 60 00 00 00 20 01 0d b8 00
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel:        00000030: 00 f1 
01 00 00 00 00 00 00 00 01 02 02 00 00 00
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel:        00000040: 00 00 
00 00 00 00 00 00 00 00 00
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: 
(lowpan_uncompress_addr): uncompressing 0 + 16 =>
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: 
(lowpan_uncompress_addr): uncompressing 0 + 16 =>
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: (lowpan_process_data) 
raw header dump:
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel:        00000000: 60 00 
00 00 00 28 3a ff 20 01 0d b8 00 00 f1 01
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel:        00000010: 00 00 
00 00 00 00 00 01 20 01 0d b8 00 00 f1 01
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel:        00000020: 00 00 
00 00 00 00 00 02
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: got frame, type 804, 
dev 97e12000
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: ieee802154_rcv 88 00 b9 
65 60 00 00 00 20 01 0d b8 00 00 f1 01  ...e`... .......
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: ieee802154_rcv 00 00 00 
00 00 00 00 01 02 02 00 00 00 00 00 00  ................
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: ieee802154_rcv 00 00 00 
00 00 00 00 00                          ........
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: (lowpan_header_create): 
IPv6 header dump:
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel:        version = 6
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel:        00000000: 60 00 
00 00 00 1c 11 40 20 01 0d b8 00 00 f1 01
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel:        00000010: 00 00 
00 00 00 00 00 02 20 01 0d b8 00 00 f1 01
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel:        00000020: 00 00 
00 00 00 00 00 01
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: (lowpan_header_create): 
send the full source address
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: (lowpan_header_create): 
destination address is unicast:
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: using full address
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: 
(lowpan_compress_udp_header): UDP header compression
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: 
(lowpan_compress_udp_header): can't compress header
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: (lowpan_header_create) 
raw skb data dump:
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel:        00000000: 7e 00 
20 01 0d b8 00 00 f1 01 00 00 00 00 00 00
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel:        00000010: 00 02 
20 01 0d b8 00 00 f1 01 00 00 00 00 00 00
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel:        00000020: 00 01 
f0 84 d0 30 39 14 a9 84 d0 30 39 00 1c 14
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel:        00000030: a9 44 
69 6d 6d 2d 43 50 55 2d 63 62 30 39 2e 6c
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel:        00000040: 77 2e 
6e 65 74
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: (lowpan_xmit): package xmit
Apr 11 15:13:11 Dimm-CPU-cb09 user.err kernel: at86rf230_xmit
Apr 11 15:13:11 Dimm-CPU-cb09 user.err kernel: at86rf230_state 4
Apr 11 15:13:11 Dimm-CPU-cb09 user.err kernel: at86rf230_state val1 = 6
Apr 11 15:13:11 Dimm-CPU-cb09 user.err kernel: at86rf230_state val2 = 9
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: at86rf230 spi0.2: 
at86rf230_isr: IRQ!
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: at86rf230 spi0.1: 
at86rf230_isr: IRQ!
Apr 11 15:13:11 Dimm-CPU-cb09 user.debug kernel: at86rf230 spi0.2: 
at86rf230_irqwork: IRQ status: 08
Apr 11 15:13:11 Dimm-CPU-cb09 user.err kernel: at86rf230_state 6
Apr 11 15:13:11 Dimm-CPU-cb09 user.err kernel: at86rf230_state val1 = 9
Apr 11 15:13:11 Dimm-CPU-cb09 user.err kernel: at86rf230_state val2 = 6


Can anybody help me,please ?

6lowpan in Ethernet packets

2012-04-09T19:28:09

Is there some simple way to hook the 6lowpan code up to the Ethernet
interface (private Ethertype maybe)? That would make an easy way to
test things on multiple machines (or VMs) without needing 802.15.4
radios.

[SPAM] Status of the 6LoWPAN module in thezigbee-linux kernel tree (devel branch)

Tony Cheneau — 2012-04-09T19:05:37

Good afternoon,

I'm still trying to figure out if I have the latest version of the 
6LowPAN module. I'm currently using the devel branch of the Linux Zigbee 
kernel (rev: 9155ba3a1c13ba, slightly patched the autofs4 files so that 
it compiles) and I did not managed to get the 6LoWPAN part working 
(izchat works great).

It is crashing any of the two testbed computers each time I try to set 
up a 6LoWPAN network (the crash message on the console seems to be 
changing all the time and does not point toward any error in the 802154 
or 6LoWPAN subsystem, but I'll investigate it further if needed). I've 
been using the serial driver (with an econotag) and the fakehard driver, 
both yield the same outcome: the system hangs.

Here is how I reproduce the crash:

At this point (ifconfig lowpan0 up), the system stops functioning and 
the SSH access is frozen. Perhaps there is a step that I'm missing, I do 
not know. But I start wondering if I am the only one experiencing this 
issue.

Please let me know if you need more information on my system in order 
to help me debug them.
As always, help, in any form, is greatly appreciated.

Regards,
     Tony Cheneau


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

[PATCH] izoordinator: Fixes to error handling

Alan Ott — 2012-04-05T04:28:07

Some of the error handling was checking for != 0 on functions which returned
positive values on success.

Someone should have a look at the last one. I'm not sure what it was
supposed to do, since it failed every single time.

Signed-off-by: Alan Ott <alan-yzvJWuRpmD1zbRFIqnYvSA< at >public.gmane.org>
---
 src/coordinator.c |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/coordinator.c b/src/coordinator.c
index a09633a..fe7d092 100644
--- a/src/coordinator.c
+++ b/src/coordinator.c
< at >< at > -94,7 +94,8 < at >< at > static int mlme_start(uint16_t short_addr, uint16_t pan, uint8_t channel, uint8_
 nla_put_u8(msg, IEEE802154_ATTR_COORD_REALIGN, 0);
 #endif
 int err = nl_send_auto_complete(nl, msg);
-log_msg_nl_perror("nl_send_auto_complete", err);
+if (err < 0)
+log_msg_nl_perror("nl_send_auto_complete", err);
 return 0;
 }
 
< at >< at > -129,7 +130,8 < at >< at > static int coordinator_associate(struct genlmsghdr *ghdr, struct nlattr **attrs)
 
 int err = nl_send_auto_complete(nl, msg);
 
-log_msg_nl_perror("nl_send_auto_complete", err);
+if (err < 0)
+log_msg_nl_perror("nl_send_auto_complete", err);
 
 return 0;
 }
< at >< at > -408,7 +410,7 < at >< at > int main(int argc, char **argv)
 log_msg_nl_perror("genl_connect", err);
 
 family = genl_ctrl_resolve(nl, IEEE802154_NL_NAME);
-log_msg_nl_perror("genl_ctrl_resolve", NLE_NOMEM);
+//log_msg_nl_perror("genl_ctrl_resolve", NLE_NOMEM);
 
 nl_socket_add_membership(nl, nl_get_multicast_id(nl, IEEE802154_NL_NAME, IEEE802154_MCAST_COORD_NAME));

Unable to compile latest git revision of thelowpan-tools

Tony Cheneau — 2012-04-04T20:53:02

Good afternoon folks,

I tried compiling the lowpan-tools on Fedora 15 and CentOS 6.2 systems
but I
could not pass the "./configure" step (called by autogen.sh) and I
would be
grateful if anyone could help me figure out why. I cloned the git repo
and am
using the latest version available at the time I write these lines
(revision
6d4636d57f87a14).

Here is the last lines of the output of the ./configure:

I attached the corresponding (gzip'd) config.log to this mail if it can 
help.

The libnl3, as well as the corresponding development files, are
installed on my system as shown below (output of the Fedora 15):

Note that I cannot remove libnl (version 1) because it is a dependency
for a lot of packages, but I do not believe it should cause any trouble
(as I do not have the *-devel).

I tried to modify the configure.ac file in order to remove this test. I
believe this test has very small influence on the build (presence of
the
"-lm" flag), but I'm far from being an autotool guru, so I'm not
certain. Basically, I commented out the following lines that made the
"./configure" fail previously:
     AC_MSG_CHECKING([whether libnl requires additional libraries])
     _libnl_save_libs="$LIBS"
     LIBS="$NL_LIBS $LIBS"
     AC_LINK_IFELSE([AC_LANG_CALL([], [genl_connect])], libnl_add="none"
,
libnl_add="fail")
     if test "$libnl_add" = fail
     then
     LIBS="$NL_LIBS -lm $_libnl_save_libs"
     AC_LINK_IFELSE([AC_LANG_CALL([], [genl_connect])], libnl_add="-lm" 
,
libnl_add="fail")
     fi
     LIBS="$_libnl_save_libs"
     if test "$libnl_add" = fail
     then
     AC_MSG_RESULT(failure)
     dnlAC_MSG_RESULT([failed])
     AC_MSG_FAILURE([failed to link program with libnl])
     else if test "$libnl_add" = none
     then
     AC_MSG_RESULT([none required])
     else
     AC_MSG_RESULT([$libnl_add])
     NL_LIBS="$NL_LIBS $libnl_add"
     fi
     fi

The configure succeed, but the make fails with the following error:

I do not know where the linking errors come from (and I do not know how
to obtain the full compilation command that cause the error either).

Should I use a more recent version of libnl3 (git version?) or was I
wrong to believe that the git tree of lowpan-tools can be compiled? I
must admit that I'm a bit lost here.

Thank you in advance for all your advice and suggestions, any help will
be appreciated.

Regards,
       Tony Cheneau------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel

Linux.com Article

Christophe Aeschlimann — 2012-04-03T15:08:18

FYI:

https://www.linux.com/learn/tutorials/560384-how-linux-talks-to-the-internet-of-things-a-look-at-ieee-802154

Kind regards,

interest in "Linux wireless networking"mini-summit in Barcelona?

John W. Linville — 2012-03-28T13:49:44

Greetings,

We are planning a wireless mini-summit event in coordination with the
LinuxCon Europe 2012 in Barcelona this November.  We plan to include
Linux developers working on Bluetooth, NFC, and 802.11 networking.
I posted about it on the linux-wireless and linux-bluetooth lists
last week:

http://marc.info/?l=linux-wireless&m=133244480823096&w=2

Do you think that there would be any interest in participation from
the 802.15.4 crowd?  Would anyone like to give a talk/presentation?
Or to introduce a topic for overall discussion?

Let me know! :-)

John

Econotag Setup

Alan Ott — 2012-03-28T05:05:03

Hello,

I got an Econotag and I'm trying to get it working. The larger goal is
to get my driver for the MRF24J40 working. Starting with a supported
device it seems makes sense.

Since I don't have any kind of 802.15.4 analyzer, I'm somewhat in the
dark, and the more information I can get about the status of the network
the better. On the Econotag (and I did order it with
Linux-802.15.4-serial firmware, and it came in a bag that said "Linux"),
the website says I'm supposed to see an LED for send and receive. Is
this still true with the current firmware? If so, then I'm doing
something wrong because I don't see any indicators ever.

I do the following (using the latest linux-zigbee tools from git):
    izattach /dev/ttyUSB1   [1]
    iz listphy
    iz add wpan-phy12
    ip link set wpan0 address ca:fe:ca:fe:ca:fe:ca:fe   [2]
    ifconfig wpan0 up  [3]
    iz assoc wpan0 777 1 11 short

Doing this I'd expect at least one packet to go out, and I'd expect to
see an LED flash on the Econotag, but I don't.

I also tried using IP on it:
    ifconfig wpan0 inet 192.168.7.7
    ping 192.168.7.9

but I still get no LEDs blinking.

For reference, I'm running the 3.3.0-rc5 kernel with the linux-zigbee
modifications.

What am I missing here? It seems like there's something simple I'm not
doing. Is there a document that I haven't found yet?

Alan.

[1] I'm using the second ttyUSB device that comes up because using the
first one doesn't work on the ifconfig up step. I didn't see anything in
the documentation about which one to use, so I assume this is the right one.
[2] At this point if I run ifconfig wpan0, the address shows up as I
would expect.
[3] At this point if I run ifconfig wpan0, the address shows up as
FF-FF-FF-FF-FF-FF-FF-FF. That seems strange.


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure

6lowpan code and Contiki source

2012-03-23T13:30:28

Is anyone watching the Contiki 6lowpan source for bug patches to the
6lowpan code?  Problems found and patched there are likely in the
linux-zigbee code too since it is derived from Contiki. Contiki has
definitely fixed multiple problems in their code.