gmane.linux.network.zigbee.devel

Federated Conference On Computer Science AndInformation Systems

Alexander Smirnov — 2013-05-20T09:38:25

Dear Alan,

due to you are a WSN expert, you probably will be interested in the
following event: http://fedcsis.org/

Even if it's not interesting for you, could you please share this with your
WSN contacts.

Thank you,
Alex
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel

[PATCH 1/2] mrf24j40: Avoid transmission whilereceiving a frame

David Hauweele — 2013-05-09T15:19:46

The transceiver may fail under heavy traffic when a frame is transmitted
while receiving another frame.

This patch uses a mutex to separate the transmission and reception of
frames along with a secondary working queue to avoid a deadlock while
waiting for the transmission interrupt.

Signed-off-by: David Hauweele <david-1EggE+PRa6vk1uMJSBkQmQ< at >public.gmane.org>
---
 drivers/net/ieee802154/mrf24j40.c |   22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ieee802154/mrf24j40.c b/drivers/net/ieee802154/mrf24j40.c
index ede3ce4..1e3ddf3 100644
--- a/drivers/net/ieee802154/mrf24j40.c
+++ b/drivers/net/ieee802154/mrf24j40.c
< at >< at > -82,8 +82,10 < at >< at > struct mrf24j40 {
 struct ieee802154_dev *dev;
 
 struct mutex buffer_mutex; /* only used to protect buf */
+struct mutex txrx_mutex; /* avoid transmission while receiving a frame */
 struct completion tx_complete;
 struct work_struct irqwork;
+struct work_struct rxwork;
 u8 *buf; /* 3 bytes. Used for SPI single-register transfers. */
 };
 
< at >< at > -353,6 +355,8 < at >< at > static int mrf24j40_tx(struct ieee802154_dev *dev, struct sk_buff *skb)
 /* Set TXNACKREQ if the ACK bit is set in the packet. */
 if (skb->data[0] & IEEE802154_FC_ACK_REQ)
 val |= 0x4;
+
+mutex_lock(&devrec->txrx_mutex);
 write_short_reg(devrec, REG_TXNCON, val);
 
 INIT_COMPLETION(devrec->tx_complete);
< at >< at > -361,6 +365,9 < at >< at > static int mrf24j40_tx(struct ieee802154_dev *dev, struct sk_buff *skb)
 ret = wait_for_completion_interruptible_timeout(
 &devrec->tx_complete,
 5 * HZ);
+
+mutex_unlock(&devrec->txrx_mutex);
+
 if (ret == -ERESTARTSYS)
 goto err;
 if (ret == 0) {
< at >< at > -535,6 +542,8 < at >< at > static int mrf24j40_handle_rx(struct mrf24j40 *devrec)
 int ret = 0;
 struct sk_buff *skb;
 
+mutex_lock(&devrec->txrx_mutex);
+
 /* Turn off reception of packets off the air. This prevents the
  * device from overwriting the buffer while we're reading it. */
 ret = read_short_reg(devrec, REG_BBREG1, &val);
< at >< at > -575,6 +584,8 < at >< at > out:
 val &= ~0x4; /* Clear RXDECINV */
 write_short_reg(devrec, REG_BBREG1, val);
 
+mutex_unlock(&devrec->txrx_mutex);
+
 return ret;
 }
 
< at >< at > -616,12 +627,19 < at >< at > static void mrf24j40_isrwork(struct work_struct *work)
 
 /* Check for Rx */
 if (intstat & 0x8)
-mrf24j40_handle_rx(devrec);
+schedule_work(&devrec->rxwork);
 
 out:
 enable_irq(devrec->spi->irq);
 }
 
+static void mrf24j40_rxwork(struct work_struct *work)
+{
+struct mrf24j40 *devrec = container_of(work, struct mrf24j40, rxwork);
+
+mrf24j40_handle_rx(devrec);
+}
+
 static int mrf24j40_probe(struct spi_device *spi)
 {
 int ret = -ENOMEM;
< at >< at > -648,8 +666,10 < at >< at > static int mrf24j40_probe(struct spi_device *spi)
 spi->max_speed_hz = MAX_SPI_SPEED_HZ;
 
 mutex_init(&devrec->buffer_mutex);
+mutex_init(&devrec->txrx_mutex);
 init_completion(&devrec->tx_complete);
 INIT_WORK(&devrec->irqwork, mrf24j40_isrwork);
+INIT_WORK(&devrec->rxwork, mrf24j40_rxwork);
 devrec->spi = spi;
 spi_set_drvdata(spi, devrec);

[PATCH v3 0/2] Enable izattach to change thebaudrate

Tony Cheneau — 2013-05-01T19:54:18

This is a small patch for the izattach (part of the linux-zigbee userspace
tools). It enables the user to select the baudrate when communicating with
their IEEE 802.15.4 serial device.

This is the 3rd version of these patches. Here is the list of changes since the
previous version:
- add "usage" text for the "-v" argument as well as the long argument "--version"
- fix indenting in a switch/case
- fix an issue where the "-v" argument would not be parsed properly

Thanks Alex for your review.

Regards,
    Tony

Tony Cheneau (2):
  izattach: remove extra whitespace
  izattach: enable custom baudrate

 src/serial.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 86 insertions(+), 23 deletions(-)

[RFC] at86rf230: add support forplatform-specific reset function

Werner Almesberger — 2013-04-30T01:27:56

The AT86RF231-based ATBEN board does not connect the /RST line and
uses power cycling to reset the transceiver. For this, I added a
platform-specific reset function to the at86rf230 driver.

Does this look okay ?

There are more parts involved in properly supporting that board.
I've described them in the following thread:
http://lists.en.qi-hardware.com/pipermail/discussion/2013-April/010123.html

- Werner

--------------------------------- cut here ---------------------------------

Some platforms may not connect the /RST line directly to a GPIO, or they
may not connect it at all and instead use power cycling to reset the
transceiver.

An example of the latter type is the ATBEN board on the Ben NanoNote.

This patch adds support for a platform-specific reset function to the
AT86RF230/1 driver. If the platform provides a reset function, "rstn"
is ignored and no GPIO is allocated for it.
---
 drivers/net/ieee802154/at86rf230.c |   45 +++++++++++++++++++++++++------------
 include/linux/spi/at86rf230.h      |    9 ++++++-
 2 files changed, 39 insertions(+), 15 deletions(-)

diff --git a/include/linux/spi/at86rf230.h b/include/linux/spi/at86rf230.h
index aa327a8..9fd1b29 100644
--- a/include/linux/spi/at86rf230.h
+++ b/include/linux/spi/at86rf230.h
< at >< at > -23,7 +23,7 < at >< at >
 #define AT86RF230_H
 
 struct at86rf230_platform_data {
-int rstn;
+int rstn;/* only used if "reset" (below) is NULL */
 int slp_tr;
 int dig2;
 
< at >< at > -40,6 +40,13 < at >< at > struct at86rf230_platform_data {
  * of the device to high active (the default value).
  */
 int irq_type;
+
+/* Platform-specific transceiver reset function, e.g., to use
+ * power cycling instead of the reset line. If "reset" is NULL,
+ * the driver resets the transceiver through the "rstn" GPIO.
+ */
+void (*reset)(void *reset_data);
+void *reset_data;
 };
 
 #endif
diff --git a/drivers/net/ieee802154/at86rf230.c b/drivers/net/ieee802154/at86rf230.c
index 6f10b49..7fa32f2 100644
--- a/drivers/net/ieee802154/at86rf230.c
+++ b/drivers/net/ieee802154/at86rf230.c
< at >< at > -834,6 +834,21 < at >< at > static void at86rf230_fill_data(struct spi_device *spi)
 lp->dig2 = pdata->dig2;
 }
 
+static void at86rf230_reset(struct at86rf230_local *lp)
+{
+struct at86rf230_platform_data *pdata = lp->spi->dev.platform_data;
+
+if (pdata->reset) {
+pdata->reset(pdata->reset_data);
+} else {
+msleep(1);
+gpio_set_value(lp->rstn, 0);
+msleep(1);
+gpio_set_value(lp->rstn, 1);
+}
+msleep(1);
+}
+
 static int at86rf230_probe(struct spi_device *spi)
 {
 struct at86rf230_platform_data *pdata;
< at >< at > -888,9 +903,11 < at >< at > static int at86rf230_probe(struct spi_device *spi)
 
 at86rf230_fill_data(spi);
 
-rc = gpio_request(lp->rstn, "rstn");
-if (rc)
-goto err_rstn;
+if (!pdata->reset) {
+rc = gpio_request(lp->rstn, "rstn");
+if (rc)
+goto err_rstn;
+}
 
 if (gpio_is_valid(lp->slp_tr)) {
 rc = gpio_request(lp->slp_tr, "slp_tr");
< at >< at > -898,9 +915,11 < at >< at > static int at86rf230_probe(struct spi_device *spi)
 goto err_slp_tr;
 }
 
-rc = gpio_direction_output(lp->rstn, 1);
-if (rc)
-goto err_gpio_dir;
+if (!pdata->reset) {
+rc = gpio_direction_output(lp->rstn, 1);
+if (rc)
+goto err_gpio_dir;
+}
 
 if (gpio_is_valid(lp->slp_tr)) {
 rc = gpio_direction_output(lp->slp_tr, 0);
< at >< at > -908,12 +927,7 < at >< at > static int at86rf230_probe(struct spi_device *spi)
 goto err_gpio_dir;
 }
 
-/* Reset */
-msleep(1);
-gpio_set_value(lp->rstn, 0);
-msleep(1);
-gpio_set_value(lp->rstn, 1);
-msleep(1);
+at86rf230_reset(lp);
 
 rc = at86rf230_read_subreg(lp, SR_MAN_ID_0, &man_id_0);
 if (rc)
< at >< at > -985,7 +999,8 < at >< at > err_gpio_dir:
 if (gpio_is_valid(lp->slp_tr))
 gpio_free(lp->slp_tr);
 err_slp_tr:
-gpio_free(lp->rstn);
+if (!pdata->reset)
+gpio_free(lp->rstn);
 err_rstn:
 spi_set_drvdata(spi, NULL);
 mutex_destroy(&lp->bmux);
< at >< at > -995,6 +1010,7 < at >< at > err_rstn:
 
 static int at86rf230_remove(struct spi_device *spi)
 {
+struct at86rf230_platform_data *pdata = spi->dev.platform_data;
 struct at86rf230_local *lp = spi_get_drvdata(spi);
 
 ieee802154_unregister_device(lp->dev);
< at >< at > -1004,7 +1020,8 < at >< at > static int at86rf230_remove(struct spi_device *spi)
 
 if (gpio_is_valid(lp->slp_tr))
 gpio_free(lp->slp_tr);
-gpio_free(lp->rstn);
+if (!pdata->reset)
+gpio_free(lp->rstn);
 
 spi_set_drvdata(spi, NULL);
 mutex_destroy(&lp->bmux);

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1

Netfilter and 6LowPan

João Paulo Bodanese — 2013-04-25T08:43:55

Hello,

Is it possible to use Netfilter to hook the packets on 6LowPan?

I tryied 2 different configurations:

1)
netfilter_ops.hook              =       main_hook;
netfilter_ops.pf                    =       PF_INET6;
netfilter_ops.hooknum       =       NF_IP6_PRE_ROUTING;
netfilter_ops.priority           =       NF_IP6_PRI_FIRST;

In this case no packet is hooked.

2)

       netfilter_ops.pf  = PF_IEEE802154

I got a crash on loading the module

...
[   28.608943] [<c047a908>] (nf_register_hook+0x38/0x84) from [<bf0da050>]
(filter_init+0x50/0x70 [netfilter])
[   28.619396] [<bf0da050>] (filter_init+0x50/0x70 [netfilter]) from
[<c0008878>] (do_one_initcall+0x90/0x160)
[   28.629827] [<c0008878>] (do_one_initcall+0x90/0x160) from [<c008822c>]
(load_module+0x1948/0x1bf8)
[   28.639496] [<c008822c>] (load_module+0x1948/0x1bf8) from [<c00885a8>]
(sys_init_module+0xcc/0xec)
[   28.649083] [<c00885a8>] (sys_init_module+0xcc/0xec) from [<c000d8c0>]
(ret_fast_syscall+0x0/0x30)


Thanks a lot,
João Paulo
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel

[PATCH v2 0/2] Enable izattach to change thebaudrate

Tony Cheneau — 2013-04-24T14:49:14

This is a small patch for the izattach (part of the linux-zigbee userspace
tools). It enables the user to select the baudrate when communicating with
their IEEE 802.15.4 serial device.

This is the 2nd version of these patches. Here is the list of changes since the
previous version:
- split the initial patch in two, extra whitespace fix has now its separate patch
- fix the issue where my text editor replaced the tab to 4 spaces

Thanks Alan for your review.

Regards,
    Tony

Tony Cheneau (2):
  izattach: remove extra whitespace
  izattach: enable custom baudrate

 src/serial.c | 107 ++++++++++++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 84 insertions(+), 23 deletions(-)

[PATCH 0/1] Enable izattach to change thebaudrate

Tony Cheneau — 2013-04-17T21:23:30

This is a small patch for the izattach (part of the linux-zigbee userspace
tools). It enables the user to select the baudrate when communicating with
their IEEE 802.15.4 serial device. To the best of my knowledge, the only device
making use of the izattach tool for the moment is the Redbee Econotag (whose
default speed is the same as the default speed of the izattach).  However is
easy to modify the Econotag firmware to increase the baudrate of the UART.
When that happens, izattach must also communicate at the same speed.

Comments are welcomed.

Regards,
    Tony

Tony Cheneau (1):
  izattach: enable custom baudrate

 src/serial.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++-------------
 1 file changed, 85 insertions(+), 24 deletions(-)

status of CCA / Energy Detect

George Nychis — 2013-04-16T17:15:46

I sent a mail to the list 2 years ago (eep! time flies) about whether CCA
is enabled and/or working on the Econotag boards:

http://www.mail-archive.com/linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org/msg00674.html

It seemed like Mariano had done some work to sort out CCA through work on
ContikiMAC. I was wondering what the status of this was now.

I also went through the mc1322x development document (
http://mc1322x.devl.org/files/MC1322xRM-r0.pdf) and 6.7.2 shows access to
registers to control energy detection and CCA. Ultimately, I want the
board I have to perform both energy detection and CCA. It is possible to
set the energy detection threshold, but I can't find any exposure to read
the current energy values from the board. So, I'm not sure how to ballpark
the threshold.

I'd greatly appreciate any heads up to working code before I set out to try
and work on this.

Thanks!
George
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel

[PATCH 0/3] Patches to 6lowpan.c to fixlink-local address uncompression

Ralph Droms — 2013-04-11T11:51:17

These patches fix link-local address uncompression, for both source
and destination addresses.

- Ralph

Ralph Droms (3):
  net/ieee802154: 6lowpan.c: Fixes for stateless address decompression
    to use MAC address
  net/ieee802154: 6lowpan.c: This patch fixes source address
    uncompression to send the MAC address to lowpan_uncompress_addr
  net/ieee802154: 6lowpan.c: This patch fixes destination address
    uncompression to send the MAC address to lowpan_uncompress_addr

 net/ieee802154/6lowpan.c |   53 +++++++++++++++++++++++++++------------------
 1 files changed, 32 insertions(+), 21 deletions(-)

Performance analysis of SPI drivers for ATBEN

Werner Almesberger — 2013-04-10T14:43:19

[ Also posted on the qi-hardware list. No cross-post, since few
people will be on both lists. ]

What this is all about
----------------------

The ATBEN board on the Ben NanoNote needs a bit-banging SPI driver.
There are several ways to implement this, ranging from reuse of the
generic spi-gpio driver to an optimized driver that's specific for
this platform.

I implemented several such approaches and measured their performance
in the Ben NanoNote. Below are my findings.

Comments welcome.

Cast and characters
-------------------

spi_atben_gpio: NanoNote-specific framework for setting up the
AT86RF230/1 with SPI-GPIO or one of the optimized drivers (below).
The name derives from spi_atben (see below) and should be changed
(maybe to atben_spi or atben_spi_gpio ?) since it is not an SPI
driver but merely a framework that provides configuration data and
performs miscellaneous platform setup.
https://github.com/wpwrak/ben-wpan-linux/blob/master/drivers/net/ieee802154/spi_atben_gpio.c

spi_atben: like spi_atben_gpio, but contains a highly optimized
SPI driver for the ATBEN configuration in the Ben NanoNote.
https://github.com/wpwrak/ben-wpan-linux/blob/master/drivers/net/ieee802154/spi_atben.c

spi-jz4740-gpio: SPI-GPIO driver optimized for the Jz4740. Uses the
optimized register accesses from spi_atben but pin assignment is not
restricted to ATBEN. The only limitation is that MOSI, MISO, and
SCLK must be on the same port.
https://github.com/wpwrak/ben-wpan-linux/blob/master/drivers/spi/spi-jz4740-gpio.c

spi-gpio-atben: task-specific SPI-GPIO driver using the #include
"spi-gpio.c" method. Replaces gpiolib functions with register
accesses specific to the ATBEN configuration in the Ben NanoNote.
Note that some of the code could be moved into Jz4740
architecture-specific GPIO support.
https://github.com/wpwrak/ben-wpan-linux/blob/master/drivers/spi/spi-gpio-atben.c

In the following sections, we abbreviate the stack configurations
as follows:

AbbreviationFrameworkTransportChip driver
--------------------------------------------------------
spi-gpiospi_atben_gpiospi-gpioat86rf230
spi-gpio-atbenspi_atben_gpiospi-gpio-atbenat86rf230
spi-jz4740-gpiospi_atben_gpiospi-jz4740-gpioat86rf230
spi_atbenspi_atbenat86rf230

Measurements
------------

Access time to AT86RF231 registers and buffer, in microseconds, on
an otherwise idle Ben NanoNote:

Driverread from 0x51read 120 bytes from buffer
||write 0x0a to 0x15write 1 byte to buffer (0x33)
|||read 1 byte from bufferwrite 120 bytes
|||||||
spi-gpio 81 851861696 971596
spi-gpio-atben 63 59123 498 65 437
spi-jz4740-gpio 10 8 21 280 10 231
spi_atben 10 7 21 280 10 230

Data rate for hypothetical buffer accesses of infinite length.
I.e., kbps = 1000*119*8/(t_write120-t_write1)

Driverbuffer read (kbps)buffer write (kbps)
---------------------------------------------------------
spi-gpio 630 635
spi-gpio-atben25492559
spi-jz4740-gpio36764308
spi_atben36764327

At the air interface, IEEE 802.15.4 has a data rate of 250 kbps.
The AT86RF231 transceiver also supports non-standard higher data
rates up to 2 Mbps.

Driver(s)Code size (lines)
--------------------------------------------------------
spi_atben_gpio 128
spi_atben_gpio + spi-gpio-atben 128+ 53
spi_atben_gpio + spi-jz4740-gpio 128+416
spi_atben 423

Computational cost
------------------

The high-level operations of sending and receiving produce the
following major low-level operations:

Operationregisterbufferwaitqueue
readwritereadwrite
----------------------------------------------------
reception1-1-1
transmission94-11

Using the measured data from above, we get the following total
computational overhead in microseconds, without considering the
waitqueue scheduling delay:

Driverreceptiontransmission
11201271120125 (bytes)
---------------------------------------------------------
spi-gpio 26717771866116626652727
spi-gpio-atben 186 561 583 86812401256
spi-jz4740-gpio 31 290 304 132 353 362

Note that the minimum frame length in IEEE 802.15.4 is 5 bytes.
The values for 125 (excluding CRC) and 127 (including CRC) bytes
are extrapolated.

According to [1], maximum-sized frames can be sent/received,
including CSMA/CA and acknowledgement, at a rate between one
every 4928 us and one every 7168 us.

We would therefore get the following maximum CPU load:

DriverReceptionTransmission
------------------------------------------
spi-gpio38%55%
spi-gpio-atben12%25%
spi-jz4740-gpio 6% 7%

Observations
------------

spi-gpio needs the smallest amount of new code but is also very
inefficient, making it questionable whether this configuration
would yield acceptable performance in regular use.

With spi-gpio-atben, only a small amount of code is added, but
buffer accesses become almost 4 times faster. Register reads and
writes are still fairly slow.

spi_atben and spi-jz4740-gpio both achieve the best performance
without significant differences between them. Both add a complete
SPI driver. Of the two, spi-jz4740-gpio is preferable, because it
uses the nearly universal spi_atben_gpio framework driver.

Conclusion
----------

I think performance trumps most other considerations in this case.
spi-gpio is clearly too inefficient. spi_atben_gpio with
spi-jz4740-gpio offers the best performance and has a low impact
on the system load (< 10%). In case this solution would be met
with strong resistance for some reason, spi-gpio-atben would offer
a compromise between performance and the amount of code.

References
----------

[1] http://www.jennic.com/files/support_files/JN-AN-1035%20Calculating%20802-15-4%20Data%20Rates-1v0.pdf

- Werner

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter

MAC address when using 6lowpan

Christophe Aeschlimann — 2013-04-09T12:45:27

Hi,

I was wondering something about the addressing in general with 6lowpan
over IEEE802.15.4.

Shouldn't the two following commands set the same address if we want the
6lowpan ipv6 link local compression/decompression to work correctly:

ip link set wpan0 address nn:nn:nn:nn:nn:nn:nn:nn
ip link set lowpan0 address nn:nn:nn:nn:nn:nn:nn:nn

Or is the wpan0 HW address not used when using 6lowpan and then it
doesn't matter.

Best regards,

Fix to transmit RFC 4944 compilant fragletsfrom 6lowpan.c

Ralph Droms (rdroms — 2013-04-05T19:16:04

Patch for outbound fraglets is attached.  Seems to interoperate with Contiki and Wireshark correctly reassembles the original datagram; tested with "ping6 -s 200".

- Ralph




------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel

[PATCH 0/2] changed irq handling and somecleanup for at86rf230

Sascha Herrmann — 2013-04-04T21:01:59

The first patch contains some cleanup for the at86rf230 driver. The
second patch changes the irq handling of the driver to avoid a
lockup caused by the irq handling of the driver.

Sascha Herrmann (2):
  at86rf230: remove unnecessary / dead code
  at86rf230: change irq handling to prevent lockups with edge type irq

 drivers/net/ieee802154/at86rf230.c |   31 +++++++++++++------------------
 1 file changed, 13 insertions(+), 18 deletions(-)

Announcing the first public release ofSimpleRPL

Tony Cheneau — 2013-04-03T22:02:30

Hello,

I'm glad to announce the first release of SimpleRPL, a Linux-based
implementation of the Routing Protocol for Low-Power and Lossy Networks 
(RPL).
This protocol has been developed at the IETF as an attempt to define a 
routing
protocol suitable for lossy and low bandwidth link-layer (such as IEEE
802.15.4). It operates on top of IPv6 using ICMPv6 messages. You can 
learn more
about it in RFC 6550.

This implementation is a fully functional (and hopefully fully 
compliant)
implementation of the standard.  I tested it on both wired and wireless 
links
and it ran just fine, although you might want to adjust some constant 
value (as
I picked the default values from the RFC and did not performed any fine 
tuning
to it). I could not test simpleRPL against the Contiki' implementation 
of RPL
(due to the current 6LoWPAN interrop issues between Linux and Contiki). 
The
GitHub project page provide more information concerning the limitations 
and
various design choices.

Once I'm confident it runs correctly (through your feedback), I'll 
announce it
to a wider audience.

The implementation is currently hosted on GitHub:
https://github.com/tcheneau/simpleRPL

Thanks in advance for all your feedback.

Regards,
     Tony

------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html

WSN 2013 call for papers

Alexander Smirnov — 2013-04-02T19:39:51

*Dear colleagues,

*
*I'd like to invite you to International Conference on Innovative Network
and Applications (iNetSApp) which will take place in Krakow in September
8-11, 2013.

*
*Please find the detailed agenda in attachments.

*
*Alex
*
------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel

[PATCH 0/2] ieee802154_mlme_ops cleanup andoops removal

Werner Almesberger — 2013-04-03T04:46:09

The second of these two patches makes operations optional which we
currently use as if they were optional but they were not. This caused
some uses of linux-zigbee user space tools to oops the kernel.

This is an update of the patch I posted last week, with EINVAL changed
to EOPNOTSUPP, and corrected reference counting on error.

The first one removes the unused get_bsn function, which was a small
obstacle for the other patch.

- Werner

Werner Almesberger (2):
  IEEE 802.15.4: remove get_bsn from "struct ieee802154_mlme_ops"
  ieee802154/nl-mac.c: make some MLME operations optional

 Documentation/networking/ieee802154.txt |    5 +++--
 drivers/net/ieee802154/fakehard.c       |   21 ---------------------
 include/net/ieee802154_netdev.h         |    5 ++++-
 net/ieee802154/nl-mac.c                 |   25 ++++++++++++++++++++-----
 4 files changed, 27 insertions(+), 29 deletions(-)

[PATCH 0/6] 802.15.4 and 6LoWPAN BufferingFixes

Alan Ott — 2013-04-02T18:47:55

These patches fix an issue in the 802.15.4 code where the output buffer
(which prior to this patchset is just a workqueue) can grow to an arbitrary
size.  This is basically fixed as follows:

1. Use netif_stop_queue() and netif_wake_queue() to stop and start the
transmit queue, preventing packets from piling up without bound on the
mac802154 workqueue.

2.  Increase the default tx_buffer_len for mac802154 (wpan) devices from 10
to 300, enabling Qdisc to work properly on the transmit queue.

Additionally the following related issues are fixed:

1. Handle dev_queue_xmit() return values properly in the 6LoWPAN code (and
return the proper errors to the higher layers).  This will cause the higher
layers to retry later if the mac802154 queue is full.

2. Fix the retry of transmit failures in mac802154.

Alan Ott (6):
  mac802154: Immediately retry sending failed packets
  mac802154: Move xmit_attemps to stack
  mac802154: Use netif flow control
  mac802154: Increase tx_buffer_len
  6lowpan: handle dev_queue_xmit error code properly
  6lowpan: return the dev_queue_xmit() return value from lowpan_xmit()

 net/ieee802154/6lowpan.c |  4 ++--
 net/mac802154/tx.c       | 34 ++++++++++++++++++++++++----------
 net/mac802154/wpan.c     |  2 +-
 3 files changed, 27 insertions(+), 13 deletions(-)

[RFC PATCH] ieee802154/nl-mac.c: make someMLME operations optional

Werner Almesberger — 2013-03-31T16:18:45

This makes documented use of "struct ieee802154_mlme_ops" follow current
use, in which some operations are regularly left out, making them NULL.
Since the calls do not check for NULL, any attempted use causes an oops.

This patch makes the following operations optional and returns EINVAL
if their use is attempted: assoc_req, assoc_resp, disassoc_req,
start_req, and scan_req.

The following operations are still required: get_phy, get_pan_id,
get_short_addr, and get_dsn.

I didn't touch the remaining get_bsn because it is currently not
called anywhere.

Signed-off-by: Werner Almesberger <werner-SEdMjqphH88wryQfseakQg< at >public.gmane.org>
---
 Documentation/networking/ieee802154.txt |    5 +++--
 include/net/ieee802154_netdev.h         |    4 ++++
 net/ieee802154/nl-mac.c                 |   10 ++++++++++
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 703cf43..67a9cb2 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
< at >< at > -71,8 +71,9 < at >< at > submits skb to qdisc), so if you need something from that cb later, you should
 store info in the skb->data on your own.
 
 To hook the MLME interface you have to populate the ml_priv field of your
-net_device with a pointer to struct ieee802154_mlme_ops instance. All fields are
-required.
+net_device with a pointer to struct ieee802154_mlme_ops instance. The fields
+assoc_req, assoc_resp, disassoc_req, start_req, and scan_req are optional.
+All other fields are required.
 
 We provide an example of simple HardMAC driver at drivers/ieee802154/fakehard.c
 
diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee802154_netdev.h
index d104c88..b9cb33d 100644
--- a/include/net/ieee802154_netdev.h
+++ b/include/net/ieee802154_netdev.h
< at >< at > -85,6 +85,8 < at >< at > struct wpan_phy;
  * Use wpan_wpy_put to put that reference.
  */
 struct ieee802154_mlme_ops {
+/* The following fields are optional (can be NULL). */
+
 int (*assoc_req)(struct net_device *dev,
 struct ieee802154_addr *addr,
 u8 channel, u8 page, u8 cap);
< at >< at > -101,6 +103,8 < at >< at > struct ieee802154_mlme_ops {
 int (*scan_req)(struct net_device *dev,
 u8 type, u32 channels, u8 page, u8 duration);
 
+/* The fields below are required. */
+
 struct wpan_phy *(*get_phy)(const struct net_device *dev);
 
 /*
diff --git a/net/ieee802154/nl-mac.c b/net/ieee802154/nl-mac.c
index 96bb08a..ca49e65 100644
--- a/net/ieee802154/nl-mac.c
+++ b/net/ieee802154/nl-mac.c
< at >< at > -327,6 +327,8 < at >< at > static int ieee802154_associate_req(struct sk_buff *skb,
 dev = ieee802154_nl_get_dev(info);
 if (!dev)
 return -ENODEV;
+if (!ieee802154_mlme_ops(dev)->assoc_req)
+return -EINVAL;
 
 if (info->attrs[IEEE802154_ATTR_COORD_HW_ADDR]) {
 addr.addr_type = IEEE802154_ADDR_LONG;
< at >< at > -369,6 +371,8 < at >< at > static int ieee802154_associate_resp(struct sk_buff *skb,
 dev = ieee802154_nl_get_dev(info);
 if (!dev)
 return -ENODEV;
+if (!ieee802154_mlme_ops(dev)->assoc_resp)
+return -EINVAL;
 
 addr.addr_type = IEEE802154_ADDR_LONG;
 nla_memcpy(addr.hwaddr, info->attrs[IEEE802154_ATTR_DEST_HW_ADDR],
< at >< at > -399,6 +403,8 < at >< at > static int ieee802154_disassociate_req(struct sk_buff *skb,
 dev = ieee802154_nl_get_dev(info);
 if (!dev)
 return -ENODEV;
+if (!ieee802154_mlme_ops(dev)->disassoc_req)
+return -EINVAL;
 
 if (info->attrs[IEEE802154_ATTR_DEST_HW_ADDR]) {
 addr.addr_type = IEEE802154_ADDR_LONG;
< at >< at > -448,6 +454,8 < at >< at > static int ieee802154_start_req(struct sk_buff *skb, struct genl_info *info)
 dev = ieee802154_nl_get_dev(info);
 if (!dev)
 return -ENODEV;
+if (!ieee802154_mlme_ops(dev)->start_req)
+return -EINVAL;
 
 addr.addr_type = IEEE802154_ADDR_SHORT;
 addr.short_addr = nla_get_u16(
< at >< at > -497,6 +505,8 < at >< at > static int ieee802154_scan_req(struct sk_buff *skb, struct genl_info *info)
 dev = ieee802154_nl_get_dev(info);
 if (!dev)
 return -ENODEV;
+if (!ieee802154_mlme_ops(dev)->scan_req)
+return -EINVAL;
 
 type = nla_get_u8(info->attrs[IEEE802154_ATTR_SCAN_TYPE]);
 channels = nla_get_u32(info->attrs[IEEE802154_ATTR_CHANNELS]);

[RFC PATCH] at86rf230: faster switching fromBUSY_TX to RX_ON

Sascha Herrmann — 2013-03-28T00:04:50

I had some issues with loosing incoming frames after sending frames
with the rf230. For example after sending a data request command, the
remote node will send a response directly after receiving this
command. Because the current implementation waits for the outgoing
frame to complete before the state change back to the RX_ON state is
requested most time the driver missed this replays with my setup.
With this patch I was able to receive this responses and even the
ACK frames to the outgoing frames where visible on the monitor
interface.

Requesting the state change back to RX_ON while the radio is in
state TX_BUSY is described, somewhat hidden, in the device datasheet
chapter "7.1.4.4 BUSY_TX and RX_ON states".

I would be happy about any comments :)

Thanks,
Sascha

Sascha Herrmann (1):
  at86rf230: request state change back to STATE_RX_ON while sending
    frame

 drivers/net/ieee802154/at86rf230.c |   44 +++++++++++++++++++++++++++---------
 1 file changed, 33 insertions(+), 11 deletions(-)

ieee802154: Source addr fix for dgram and somesmall at86rf230 driver enhancements

Stefan Schmidt — 2013-03-26T22:41:28

Hello.

Second version. Changes since version 1:
- Obey 80 chars rules
- Switch logging mode to vdbg to avoid noise
- Remove uneeded might_sleep()

Thanks Alan, Werner and Alex for the feedback.

I feel these are ready so I added DaveM and netdev to pick them up if they think
the same.

[PATCH 1/3] ieee802154/dgram: Pass source address in dgram_recvmsg

Patch from Stephen to fix the ieee802154 stack to actually put in the source
address in datagrams. This allows using recvfrom() from userspace. This is a
long standing bug. Actually I think it never worked. :)

[PATCH 2/3] ieee802154/at86rf230: Implement hardware address filter

Allows the to filter frames directly in the transceiver hardware. Useful for
normal operation mode and mandatory for automatic ACK and automatic retransmits.

[PATCH 3/3] ieee802154/at86rf230: Fix register names for RX_AACK_ON

Not needed right now but still a good idea to get in imho. Register names have
always been wrong but never used.

regards
Stefan Schmidt

------------------------------------------------------------------------------
Own the Future-Intel&reg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game 
on Steam. $5K grand prize plus 10 genre and skill prizes. 
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d

[PATCH v2 net-next 00/12] 6lowpan: Some morebug fixes

Tony Cheneau — 2013-03-26T03:59:20

Hello,

This patchset fixes serious bugs within the 6LoWPAN modules. I wrote a script
(available at [1]) to prove the issues are real.  One can try and see that
without these patches, most of the test fail (e.g. packet dropped by the
receiver or node crashing). With all patches applied, all tests succeed. The
tests themselves are very basic: sending ICMP packets, sending UDP packets,
sending TCP packets, varying size of the packets. This actually triggers some
6LoWPAN specific code, namely fragmentation, packet reassembly and header
compression.

This code passed the checkpatch.pl tool with a few warnings, that I believe
are OK. It should apply cleanly on the latest net-next.

Regards,
Tony Cheneau

[1]: https://github.com/tcheneau/linux802154-regression-tests

Tony Cheneau (12):
  6lowpan: lowpan_is_iid_16_bit_compressable() does not detect
    compressible address correctly
  6lowpan: next header is not properly set upon decompression of a UDP
    header.
  6lowpan: always enable link-layer acknowledgments
  mac802154: turn on ACK when enabled by the upper layers
  6lowpan: use short IEEE 802.15.4 addresses for broadcast destination
  6lowpan: fix first fragment (FRAG1) handling
  6lowpan: add debug messages for 6LoWPAN fragmentation
  6lowpan: store fragment tag values per device instead of net stack
    wide
  mac802154: re-introduce mac802154_dev_get_dsn()
  6lowpan: obtain IEEE802.15.4 sequence number from the MAC layer
  6lowpan: use the PANID provided by the device instead of a static
    value
  6lowpan: modify udp compression/uncompression to match the standard

 net/ieee802154/6lowpan.c  | 136 +++++++++++++++++++++++++++++++++++++---------
 net/ieee802154/6lowpan.h  |   7 ++-
 net/mac802154/mac802154.h |   1 +
 net/mac802154/mac_cmd.c   |   1 +
 net/mac802154/mib.c       |   9 +++
 net/mac802154/wpan.c      |   2 +
 6 files changed, 127 insertions(+), 29 deletions(-)