* [RFC bluetooth-next 3/4] 6lowpan: add nhc module for GHC UDP detection
From: Stefan Schmidt @ 2015-09-09 15:26 UTC (permalink / raw)
To: linux-wpan; +Cc: Alexander Aring, jukka.rissanen, Stefan Schmidt
In-Reply-To: <1441812393-32472-1-git-send-email-stefan@osg.samsung.com>
Signed-off-by: Stefan Schmidt <stefan@osg.samsung.com>
---
net/6lowpan/Kconfig | 5 +++++
net/6lowpan/Makefile | 1 +
net/6lowpan/ghc_udp.c | 27 +++++++++++++++++++++++++++
3 files changed, 33 insertions(+)
create mode 100644 net/6lowpan/ghc_udp.c
diff --git a/net/6lowpan/Kconfig b/net/6lowpan/Kconfig
index f541f50..67a786b 100644
--- a/net/6lowpan/Kconfig
+++ b/net/6lowpan/Kconfig
@@ -64,4 +64,9 @@ config 6LOWPAN_GHC_EXTENSION_HEADER
default y
---help---
+config 6LOWPAN_GHC_UDP
+ tristate "GHC UDP Support"
+ default y
+ ---help---
+
endif
diff --git a/net/6lowpan/Makefile b/net/6lowpan/Makefile
index 5320b76..4df6334 100644
--- a/net/6lowpan/Makefile
+++ b/net/6lowpan/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_6LOWPAN_NHC_UDP) += nhc_udp.o
#rfc7400 ghcs
obj-$(CONFIG_6LOWPAN_GHC_EXTENSION_HEADER) += ghc_extension_header.o
+obj-$(CONFIG_6LOWPAN_GHC_UDP) += ghc_udp.o
diff --git a/net/6lowpan/ghc_udp.c b/net/6lowpan/ghc_udp.c
new file mode 100644
index 0000000..2675683
--- /dev/null
+++ b/net/6lowpan/ghc_udp.c
@@ -0,0 +1,27 @@
+/*
+ * 6LoWPAN UDP compression according to RFC7400
+ *
+ * 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.
+ */
+
+#include "nhc.h"
+
+#define LOWPAN_GHC_UDP_IDLEN 1
+#define LOWPAN_GHC_UDP_ID_0 0xd0
+#define LOWPAN_GHC_UDP_MASK_0 0xf8
+
+static void udp_ghid_setup(struct lowpan_nhc *nhc)
+{
+ nhc->id[0] = LOWPAN_GHC_UDP_ID_0;
+ nhc->idmask[0] = LOWPAN_GHC_UDP_MASK_0;
+}
+
+LOWPAN_NHC(ghc_udp, "RFC7400 UDP", NEXTHDR_HOP, 0,
+ udp_ghid_setup, LOWPAN_GHC_UDP_IDLEN, NULL, NULL);
+
+module_lowpan_nhc(ghc_udp);
+MODULE_DESCRIPTION("6LoWPAN generic header RFC7400 UDP compression");
+MODULE_LICENSE("GPL");
--
2.4.3
^ permalink raw reply related
* [RFC bluetooth-next 2/4] 6lowpan: add nhc module for GHC extension header detection
From: Stefan Schmidt @ 2015-09-09 15:26 UTC (permalink / raw)
To: linux-wpan; +Cc: Alexander Aring, jukka.rissanen, Stefan Schmidt
In-Reply-To: <1441812393-32472-1-git-send-email-stefan@osg.samsung.com>
Signed-off-by: Stefan Schmidt <stefan@osg.samsung.com>
---
net/6lowpan/Kconfig | 5 +++++
net/6lowpan/Makefile | 3 +++
| 27 +++++++++++++++++++++++++++
3 files changed, 35 insertions(+)
create mode 100644 net/6lowpan/ghc_extension_header.c
diff --git a/net/6lowpan/Kconfig b/net/6lowpan/Kconfig
index 6af7a46..f541f50 100644
--- a/net/6lowpan/Kconfig
+++ b/net/6lowpan/Kconfig
@@ -59,4 +59,9 @@ config 6LOWPAN_NHC_UDP
---help---
6LoWPAN IPv6 UDP Header compression according to RFC6282.
+config 6LOWPAN_GHC_EXTENSION_HEADER
+ tristate "GHC Extension Header Support"
+ default y
+ ---help---
+
endif
diff --git a/net/6lowpan/Makefile b/net/6lowpan/Makefile
index c6ffc55..5320b76 100644
--- a/net/6lowpan/Makefile
+++ b/net/6lowpan/Makefile
@@ -10,3 +10,6 @@ obj-$(CONFIG_6LOWPAN_NHC_IPV6) += nhc_ipv6.o
obj-$(CONFIG_6LOWPAN_NHC_MOBILITY) += nhc_mobility.o
obj-$(CONFIG_6LOWPAN_NHC_ROUTING) += nhc_routing.o
obj-$(CONFIG_6LOWPAN_NHC_UDP) += nhc_udp.o
+
+#rfc7400 ghcs
+obj-$(CONFIG_6LOWPAN_GHC_EXTENSION_HEADER) += ghc_extension_header.o
--git a/net/6lowpan/ghc_extension_header.c b/net/6lowpan/ghc_extension_header.c
new file mode 100644
index 0000000..eeeabfa
--- /dev/null
+++ b/net/6lowpan/ghc_extension_header.c
@@ -0,0 +1,27 @@
+/*
+ * 6LoWPAN Extension Header compression according to RFC7400
+ *
+ * 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.
+ */
+
+#include "nhc.h"
+
+#define LOWPAN_GHC_EXTENSION_HEADER_IDLEN 1
+#define LOWPAN_GHC_EXTENSION_HEADER_ID_0 0xb0
+#define LOWPAN_GHC_EXTENSION_HEADER_MASK_0 0xf8
+
+static void ext_ghid_setup(struct lowpan_nhc *nhc)
+{
+ nhc->id[0] = LOWPAN_GHC_EXTENSION_HEADER_ID_0;
+ nhc->idmask[0] = LOWPAN_GHC_EXTENSION_HEADER_MASK_0;
+}
+
+LOWPAN_NHC(ghc_extension_header, "RFC7400 Extension Header", NEXTHDR_HOP, 0,
+ ext_ghid_setup, LOWPAN_GHC_EXTENSION_HEADER_IDLEN, NULL, NULL);
+
+module_lowpan_nhc(ghc_extension_header);
+MODULE_DESCRIPTION("6LoWPAN generic header RFC7400 Extension Header compression");
+MODULE_LICENSE("GPL");
--
2.4.3
^ permalink raw reply related
* [RFC bluetooth-next 1/4] 6lowpan: clarify Kconfig entries for upcoming GHC support
From: Stefan Schmidt @ 2015-09-09 15:26 UTC (permalink / raw)
To: linux-wpan; +Cc: Alexander Aring, jukka.rissanen, Stefan Schmidt
In-Reply-To: <1441812393-32472-1-git-send-email-stefan@osg.samsung.com>
Signed-off-by: Stefan Schmidt <stefan@osg.samsung.com>
---
net/6lowpan/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/6lowpan/Kconfig b/net/6lowpan/Kconfig
index 7fa0f38..6af7a46 100644
--- a/net/6lowpan/Kconfig
+++ b/net/6lowpan/Kconfig
@@ -6,11 +6,12 @@ menuconfig 6LOWPAN
"6LoWPAN" which is supported by IEEE 802.15.4 or Bluetooth stacks.
menuconfig 6LOWPAN_NHC
- tristate "Next Header Compression Support"
+ tristate "Next Header and Generic Header Compression Support"
depends on 6LOWPAN
default y
---help---
- Support for next header compression.
+ Support for next header and generic header compression defined in
+ RFC6282 and RFC7400.
if 6LOWPAN_NHC
--
2.4.3
^ permalink raw reply related
* [RFC bluetooth-next 0/4] GHC compression detection
From: Stefan Schmidt @ 2015-09-09 15:26 UTC (permalink / raw)
To: linux-wpan; +Cc: Alexander Aring, jukka.rissanen, Stefan Schmidt
Hello.
This is a first stab at RFC7400. So far we only hook into the NHC framework to
detect the three registered GHC types (extension header, UDP and ICMPv6).
This is aligned with how we detect the NHC frames.
TODO items:
o How to handle reserved and unassigned ranges in the HEADER TYPE?
o Implement compression/decompresion for GHC UDP
o Implement compression/decompresion for GHC ICMPv6
o How to handle 6CIO in IPv6 ND?
Stefan Schmidt (4):
6lowpan: clarify Kconfig entries for upcoming GHC support
6lowpan: add nhc module for GHC extension header detection
6lowpan: add nhc module for GHC UDP detection
6lowpan: add nhc module for GHC ICMPv6 detection
net/6lowpan/Kconfig | 20 ++++++++++++++++++--
net/6lowpan/Makefile | 5 +++++
net/6lowpan/ghc_extension_header.c | 27 +++++++++++++++++++++++++++
net/6lowpan/ghc_icmpv6.c | 27 +++++++++++++++++++++++++++
net/6lowpan/ghc_udp.c | 27 +++++++++++++++++++++++++++
5 files changed, 104 insertions(+), 2 deletions(-)
create mode 100644 net/6lowpan/ghc_extension_header.c
create mode 100644 net/6lowpan/ghc_icmpv6.c
create mode 100644 net/6lowpan/ghc_udp.c
regards
Stefan Schmidt
--
2.4.3
^ permalink raw reply
* Re: At86rf230 sleep state
From: Baptiste Clenet @ 2015-09-09 15:17 UTC (permalink / raw)
To: Alexander Aring; +Cc: linux-wpan
In-Reply-To: <20150909131315.GA13947@omega>
2015-09-09 15:13 GMT+02:00 Alexander Aring <alex.aring@gmail.com>:
> Hi,
>
> On Wed, Sep 09, 2015 at 02:26:27PM +0200, Baptiste Clenet wrote:
>> Hi,
>>
>> I looked at the at86rf230 driver on bluetooth-next branch and I saw the
>> two functions concerning the sleep state:
>>
>> at86rf230_sleep(struct at86rf230_local *lp)
>>
>> at86rf230_awake(struct at86rf230_local *lp)
>>
>>
>> I'm wondering if the transceiver can wake up from a received frame if
>> it is in SLEEP State? As far as I can see on the datasheet, it is not
>> able to. Am I wrong?
>>
>
> The transceiver can't. The transceiver need to be inside RX_AACK_ON state
> (or RX_ON, but we don't use this state).
>
> What we currently support for powersaving is when the subsystem doesn't
> use the transceiver then the transceiver goes into SLEEP state.
>
> This happens when:
>
> 1. After device probing.
> 2. When _ALL_ interfaces which belongs to the transceiver (phy) are
> down. -> Which is the state after probing. See 1.
> 3. When interfaces are up and you going into pm-suspend mode. (The
> interfaces are still up, but the transceiver will call "stop"
> callback before and this is the same like 2. -> It stops rx but when
> stopping rx you can also go into sleep). When "resume" occurs the
> subsystem call "start" callback and do a "awake" and acivate rx again.
>
> Addtional note: we need to awake the transceiver to access registers,
> there exists "direct or non-direct" nl802154 calls into the driver layer
> to set registers. This is why we add before and after register access an
> awake and sleep again. -> but this is very transceiver specifc, there
> exists also transceiver which has register access while sleeping.
>
Thank you for the answer! It is what I thought.
>
> This is currently the stuff we support for powersaving, this has nothing
> todo with 802.15.4 powersaving stuff like "beacon enabled mode". We
> currently doesn't support this kind of stuff and I have also no idea how
> it works and how we can implement this stuff for SoftMAC transceivers.
> :-)
>
Yes there is still some improvments to do :-)
> - Alex
--
Baptiste
^ permalink raw reply
* Re: At86rf230 sleep state
From: Alexander Aring @ 2015-09-09 13:13 UTC (permalink / raw)
To: Baptiste Clenet; +Cc: linux-wpan
In-Reply-To: <CAPpUg6MbD04CcGAkOfs=NB4hS_3nqt-v38edwsXCd1sF-_3R1w@mail.gmail.com>
Hi,
On Wed, Sep 09, 2015 at 02:26:27PM +0200, Baptiste Clenet wrote:
> Hi,
>
> I looked at the at86rf230 driver on bluetooth-next branch and I saw the
> two functions concerning the sleep state:
>
> at86rf230_sleep(struct at86rf230_local *lp)
>
> at86rf230_awake(struct at86rf230_local *lp)
>
>
> I'm wondering if the transceiver can wake up from a received frame if
> it is in SLEEP State? As far as I can see on the datasheet, it is not
> able to. Am I wrong?
>
The transceiver can't. The transceiver need to be inside RX_AACK_ON state
(or RX_ON, but we don't use this state).
What we currently support for powersaving is when the subsystem doesn't
use the transceiver then the transceiver goes into SLEEP state.
This happens when:
1. After device probing.
2. When _ALL_ interfaces which belongs to the transceiver (phy) are
down. -> Which is the state after probing. See 1.
3. When interfaces are up and you going into pm-suspend mode. (The
interfaces are still up, but the transceiver will call "stop"
callback before and this is the same like 2. -> It stops rx but when
stopping rx you can also go into sleep). When "resume" occurs the
subsystem call "start" callback and do a "awake" and acivate rx again.
Addtional note: we need to awake the transceiver to access registers,
there exists "direct or non-direct" nl802154 calls into the driver layer
to set registers. This is why we add before and after register access an
awake and sleep again. -> but this is very transceiver specifc, there
exists also transceiver which has register access while sleeping.
This is currently the stuff we support for powersaving, this has nothing
todo with 802.15.4 powersaving stuff like "beacon enabled mode". We
currently doesn't support this kind of stuff and I have also no idea how
it works and how we can implement this stuff for SoftMAC transceivers.
:-)
- Alex
^ permalink raw reply
* At86rf230 sleep state
From: Baptiste Clenet @ 2015-09-09 12:26 UTC (permalink / raw)
To: linux-wpan
Hi,
I looked at the at86rf230 driver on bluetooth-next branch and I saw the
two functions concerning the sleep state:
at86rf230_sleep(struct at86rf230_local *lp)
at86rf230_awake(struct at86rf230_local *lp)
I'm wondering if the transceiver can wake up from a received frame if
it is in SLEEP State? As far as I can see on the datasheet, it is not
able to. Am I wrong?
Alex Aring?
Cheers,
--
Baptiste
^ permalink raw reply
* Re: [PATCH bluetooth-next] atusb: add handling for different chipnames
From: Marcel Holtmann @ 2015-09-06 3:47 UTC (permalink / raw)
To: Alexander Aring; +Cc: linux-wpan, kernel, Stefan Schmidt
In-Reply-To: <1441448879-16511-1-git-send-email-alex.aring@gmail.com>
Hi Alex,
> This patch supports handling for printout different chipnames between
> atusb and rzusb. The rzusb contains an at86rf230 and atusb an at86rf231
> transceiver.
>
> Cc: Stefan Schmidt <stefan@osg.samsung.com>
> Signed-off-by: Alexander Aring <alex.aring@gmail.com>
> ---
> drivers/net/ieee802154/atusb.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* [PATCH bluetooth-next] atusb: add handling for different chipnames
From: Alexander Aring @ 2015-09-05 10:27 UTC (permalink / raw)
To: linux-wpan; +Cc: kernel, Alexander Aring, Stefan Schmidt
This patch supports handling for printout different chipnames between
atusb and rzusb. The rzusb contains an at86rf230 and atusb an at86rf231
transceiver.
Cc: Stefan Schmidt <stefan@osg.samsung.com>
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
---
drivers/net/ieee802154/atusb.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ieee802154/atusb.c b/drivers/net/ieee802154/atusb.c
index 80dfc72..199a94a 100644
--- a/drivers/net/ieee802154/atusb.c
+++ b/drivers/net/ieee802154/atusb.c
@@ -559,6 +559,7 @@ static int atusb_get_and_show_chip(struct atusb *atusb)
{
struct usb_device *usb_dev = atusb->usb_dev;
uint8_t man_id_0, man_id_1, part_num, version_num;
+ const char *chip;
man_id_0 = atusb_read_reg(atusb, RG_MAN_ID_0);
man_id_1 = atusb_read_reg(atusb, RG_MAN_ID_1);
@@ -574,14 +575,22 @@ static int atusb_get_and_show_chip(struct atusb *atusb)
man_id_1, man_id_0);
goto fail;
}
- if (part_num != 3 && part_num != 2) {
+
+ switch (part_num) {
+ case 2:
+ chip = "AT86RF230";
+ break;
+ case 3:
+ chip = "AT86RF231";
+ break;
+ default:
dev_err(&usb_dev->dev,
"unexpected transceiver, part 0x%02x version 0x%02x\n",
part_num, version_num);
goto fail;
}
- dev_info(&usb_dev->dev, "ATUSB: AT86RF231 version %d\n", version_num);
+ dev_info(&usb_dev->dev, "ATUSB: %s version %d\n", chip, version_num);
return 0;
--
2.5.1
^ permalink raw reply related
* Re: [PATCH wpan-tools 0/5] Various wpan-ping fixes
From: Stefan Schmidt @ 2015-09-04 9:49 UTC (permalink / raw)
To: linux-wpan; +Cc: Alexander Aring
In-Reply-To: <1441187577-12534-1-git-send-email-stefan@osg.samsung.com>
Hello.
On 02/09/15 11:52, Stefan Schmidt wrote:
> Hello.
>
> Nothing major. Just smaller fixes all over the place in wpan-ping. Mostly related to option
> handling.
>
> Stefan Schmidt (5):
> wpan-ping: align wpan-ping version with the general wpan-tools version
> wpan-ping: remove no longer used b option from getopt string
> wpan-ping: fix usage message and mention -h option
> wpan-ping: use correct define to fix getopt_long usage
> wpan-ping: fix segfault for accessing invalid address
>
> wpan-ping/wpan-ping.c | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
Pushed all of them to the repo.
regards
Stefan Schmidt
^ permalink raw reply
* Re: [PATCH wpan-misc 1/3] website: update rzusbstick firmware
From: Stefan Schmidt @ 2015-09-04 9:47 UTC (permalink / raw)
To: Alexander Aring, linux-wpan
In-Reply-To: <1441358231-22349-1-git-send-email-alex.aring@gmail.com>
Hello.
On 04/09/15 11:17, Alexander Aring wrote:
> Signed-off-by: Alexander Aring <alex.aring@gmail.com>
> ---
> website/index.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/website/index.txt b/website/index.txt
> index 907af61..9a4794f 100644
> --- a/website/index.txt
> +++ b/website/index.txt
> @@ -47,7 +47,7 @@ Supported Hardware
> |cc2520 |yes |cc2520 | SPI | http://de.aliexpress.com/item/CC2520-wireless-module-ZIGBEE-wireless-sensor-networking-module-with-SMA-external-antenna/1921436550.html[aliexpress]
> |cc2531 |no | | USB | http://de.aliexpress.com/item/free-shipping-FOR-ZigBee-CC2531-USB-dongle-protocol-analysis-port-capture-wireless-keyboard-and-mouse/32270975591.html[aliexpress]
> |mrf24j40 |yes |mrf24j40 | SPI | http://de.aliexpress.com/item/MRF24J40MA-I-RM-MRF24J40MA-I-MRF24J40MA-MRF24J40-MICROC-QFN-Import-original/32223258627.html[aliexpress]
> -|RZUSBstick |no, WIP |atusb | USB | http://www.element14.com/community/docs/DOC-67532/l/avr-rz-usb-stick-module[element14]
> +|RZUSBstick |experimental, http://wpan.cakelab.org/firmwares/rzusb.bin[WIP] |atusb | USB | http://www.element14.com/community/docs/DOC-67532/l/avr-rz-usb-stick-module[element14]
> |Xbee |no |https://github.com/joaopedrotaveira/linux-rpl/blob/master/mainline-3.12.y/0001-Added-XBee-driver-support.patch[out of tree]| ?? | https://www.sparkfun.com/pages/xbee_guide[sparkfun]
> |=============================================================
>
All three patches are looking good to me.
regards
Stefan Schmidt
^ permalink raw reply
* [PATCH wpan-misc 3/3] website: add iana entry
From: Alexander Aring @ 2015-09-04 9:17 UTC (permalink / raw)
To: linux-wpan; +Cc: Alexander Aring
In-Reply-To: <1441358231-22349-1-git-send-email-alex.aring@gmail.com>
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
---
website/index.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/website/index.txt b/website/index.txt
index b7b5311..e476d8a 100644
--- a/website/index.txt
+++ b/website/index.txt
@@ -206,4 +206,6 @@ Specifications
** http://datatracker.ietf.org/wg/6lo/documents/[IPv6 over Networks of Resource-constrained Nodes (6lo)]
** http://datatracker.ietf.org/wg/core/documents/[Constrained RESTful Environments (core)]
+* https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml[6LoWPAN IANA assignments]
+
// vim: set syntax=asciidoc:
--
2.5.1
^ permalink raw reply related
* [PATCH wpan-misc 2/3] website: update open tasks
From: Alexander Aring @ 2015-09-04 9:17 UTC (permalink / raw)
To: linux-wpan; +Cc: Alexander Aring
In-Reply-To: <1441358231-22349-1-git-send-email-alex.aring@gmail.com>
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
---
website/index.txt | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/website/index.txt b/website/index.txt
index 9a4794f..b7b5311 100644
--- a/website/index.txt
+++ b/website/index.txt
@@ -136,14 +136,12 @@ Open Tasks
* There is a lot of missing features for enum definition to some string definition in iwpan which can be lookup in 802.15.4 standard. Words say more than numbers...
** channel/page to frequency
** cca modes/opts
-** no aret mode for max_frame_retires -1
** etc
* Missing features which wireless has and wpan not. Since we based our implementation on wireless we should sync "good patches" from wireless branch.
** Whatever you want and find
* rework
** missing features in nl802154, crypto etc.
-** new frame parsing style in mac802154 and ieee802154 based on mac80211 frame parsing design. Draft is https://github.com/linux-wpan/linux-wpan-next/blob/wpan_rework_rfc/net/mac802154/rx.c[mac802154 rx] and
-https://github.com/linux-wpan/linux-wpan-next/blob/wpan_rework_rfc/net/ieee802154/6lowpan/rx.c[6LoWPAN]. Crypto need to be done at first, otherwise I can't test it.
+** new frame parsing style in mac802154 and ieee802154 based on mac80211 frame parsing design. Draft is https://github.com/linux-wpan/linux-wpan-next/blob/wpan_rework_rfc/net/mac802154/rx.c[mac802154 rx]. Crypto need to be done at first, otherwise I can't test it.
** remove cb context from dev_hard_header and introduce generic header generation functions like https://github.com/linux-wpan/linux-wpan-next/blob/wpan_rework_rfc/net/ieee802154/header_ops.c#L80[header_ops]. Here too, crypto need to be done at first.
* systemd
** add basic functionality for nl802154 and 6lowpan setup in systemd-networkd
@@ -152,7 +150,6 @@ https://github.com/linux-wpan/linux-wpan-next/blob/wpan_rework_rfc/net/ieee80215
* RPL? - not our job, need to go through ipv6 netdev community, but we should do something to have a "started" mainline solution.
* cleanup/fix 802.15.4 af raw/dgram socket code. We should use bluetooth socket code as example.
* In wireless exists a "station dump", we need something similar "node dump" with all neighbour nodes and their last LQI value, addresses, etc. information.
-* A wpan-phy is an own device class, we need pm suspend handling like in wireless http://lxr.free-electrons.com/source/net/wireless/sysfs.c#L154[callbacks which are in #ifdef CONFIG_PM].
Rework
~~~~~~
--
2.5.1
^ permalink raw reply related
* [PATCH wpan-misc 1/3] website: update rzusbstick firmware
From: Alexander Aring @ 2015-09-04 9:17 UTC (permalink / raw)
To: linux-wpan; +Cc: Alexander Aring
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
---
website/index.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/website/index.txt b/website/index.txt
index 907af61..9a4794f 100644
--- a/website/index.txt
+++ b/website/index.txt
@@ -47,7 +47,7 @@ Supported Hardware
|cc2520 |yes |cc2520 | SPI | http://de.aliexpress.com/item/CC2520-wireless-module-ZIGBEE-wireless-sensor-networking-module-with-SMA-external-antenna/1921436550.html[aliexpress]
|cc2531 |no | | USB | http://de.aliexpress.com/item/free-shipping-FOR-ZigBee-CC2531-USB-dongle-protocol-analysis-port-capture-wireless-keyboard-and-mouse/32270975591.html[aliexpress]
|mrf24j40 |yes |mrf24j40 | SPI | http://de.aliexpress.com/item/MRF24J40MA-I-RM-MRF24J40MA-I-MRF24J40MA-MRF24J40-MICROC-QFN-Import-original/32223258627.html[aliexpress]
-|RZUSBstick |no, WIP |atusb | USB | http://www.element14.com/community/docs/DOC-67532/l/avr-rz-usb-stick-module[element14]
+|RZUSBstick |experimental, http://wpan.cakelab.org/firmwares/rzusb.bin[WIP] |atusb | USB | http://www.element14.com/community/docs/DOC-67532/l/avr-rz-usb-stick-module[element14]
|Xbee |no |https://github.com/joaopedrotaveira/linux-rpl/blob/master/mainline-3.12.y/0001-Added-XBee-driver-support.patch[out of tree]| ?? | https://www.sparkfun.com/pages/xbee_guide[sparkfun]
|=============================================================
--
2.5.1
^ permalink raw reply related
* Re: [PATCH bluetooth-next] Doc fixes re-submit
From: Marcel Holtmann @ 2015-09-03 16:10 UTC (permalink / raw)
To: Stefan Schmidt; +Cc: linux-wpan, Alexander Aring
In-Reply-To: <1441290695-23307-1-git-send-email-stefan@osg.samsung.com>
Hi Stefan,
> Just re-submitting these two as they have not been picked up yet and I just
> realised that I did not add the correct patch prefixes for them so they might
> have been overlooked.
>
> Trivial stuff and Alex already acked them here on the list (ACK's already added
> to the new submission).
both patches have been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* [PATCH bluetooth-next 2/2] ieee802154: af_ieee802154: fix typo in comment.
From: Stefan Schmidt @ 2015-09-03 14:31 UTC (permalink / raw)
To: linux-wpan; +Cc: Alexander Aring, Stefan Schmidt
In-Reply-To: <1441290695-23307-1-git-send-email-stefan@osg.samsung.com>
Signed-off-by: Stefan Schmidt <stefan@osg.samsung.com>
Acked-by: Alexander Aring <alex.aring@gmail.com>
---
include/net/af_ieee802154.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/af_ieee802154.h b/include/net/af_ieee802154.h
index 7d38e2f..a5563d2 100644
--- a/include/net/af_ieee802154.h
+++ b/include/net/af_ieee802154.h
@@ -1,5 +1,5 @@
/*
- * IEEE 802.15.4 inteface for userspace
+ * IEEE 802.15.4 interface for userspace
*
* Copyright 2007, 2008 Siemens AG
*
--
2.4.3
^ permalink raw reply related
* [PATCH bluetooth-next 1/2] ieee802154: docs: fix project name to linux-wpan as well as some typos
From: Stefan Schmidt @ 2015-09-03 14:31 UTC (permalink / raw)
To: linux-wpan; +Cc: Alexander Aring, Stefan Schmidt
In-Reply-To: <1441290695-23307-1-git-send-email-stefan@osg.samsung.com>
Signed-off-by: Stefan Schmidt <stefan@osg.samsung.com>
Acked-by: Alexander Aring <alex.aring@gmail.com>
---
Documentation/networking/ieee802154.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 1700756..aa69ccc 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -7,11 +7,11 @@ Introduction
The IEEE 802.15.4 working group focuses on standardization of bottom
two layers: Medium Access Control (MAC) and Physical (PHY). And there
are mainly two options available for upper layers:
- - ZigBee - proprietary protocol from ZigBee Alliance
- - 6LowPAN - IPv6 networking over low rate personal area networks
+ - ZigBee - proprietary protocol from the ZigBee Alliance
+ - 6LoWPAN - IPv6 networking over low rate personal area networks
-The Linux-ZigBee project goal is to provide complete implementation
-of IEEE 802.15.4 and 6LoWPAN protocols. IEEE 802.15.4 is a stack
+The linux-wpan project goal is to provide a complete implementation
+of the IEEE 802.15.4 and 6LoWPAN protocols. IEEE 802.15.4 is a stack
of protocols for organizing Low-Rate Wireless Personal Area Networks.
The stack is composed of three main parts:
--
2.4.3
^ permalink raw reply related
* [PATCH bluetooth-next] Doc fixes re-submit
From: Stefan Schmidt @ 2015-09-03 14:31 UTC (permalink / raw)
To: linux-wpan; +Cc: Alexander Aring, Stefan Schmidt
Hello.
Just re-submitting these two as they have not been picked up yet and I just
realised that I did not add the correct patch prefixes for them so they might
have been overlooked.
Trivial stuff and Alex already acked them here on the list (ACK's already added
to the new submission).
regards
Stefan Schmidt
^ permalink raw reply
* Re: [PATCH bluetooth-next 0/4] at86rf230: trac debugfs support
From: Marcel Holtmann @ 2015-09-03 14:31 UTC (permalink / raw)
To: Alexander Aring; +Cc: linux-wpan, kernel
In-Reply-To: <1440704960-10515-1-git-send-email-alex.aring@gmail.com>
Hi Alex,
> this patch series based on:
>
> "[RFCv5 bluetooth-next 0/4] ieee802154: aret handling changes"
>
> and can be used for testing the ARET/NO ARET mode with ARET_ON state only.
> I add support for debugfs to check the trac status statistics.
>
> In the previously patch series I said that the at86rf2xx transceivers
> checks automatically if ack request is set or not in a 802.15.4 frame.
>
> There exists two cases:
>
> 1. When the ackrequest bit is set and using STATE_ARET_ON the transceiver
> will wait for an ack frame after transmit. If ack is received then
> the transceiver logic is "SUCCESS" otherwise "NO_ACK".
> 2. When the ackrequest bit isn't set and using the STATE_ARET_ON the
> transceiver will not wait for an ack frame and the transceiver logic
> is "SUCCESS".
>
> The transceiver logic is in this case the error code from transmit
> algorithmn.
>
> To the test (802.15.4 6LoWPAN):
>
> 1. Create some imagine 6LoWPAN node by using:
>
> ip -6 neigh add fe80::abcd lladdr 02:01:02:03:04:05:06:07 dev lowpan0
>
> This will create some neighbor discovery entry for some node which isn't
> there in your network. We wan't just test some 802.15.4 unicast addressing.
> This unicast addressing will not answer with an ACK frame, because there is
> no node with this address.
>
> 2. Set ackrequest bit to 0 by using:
>
> iwpan dev wpan0 set ackreq_default 0
>
> 3. Ping node:
>
> ping6 fe80::abcd%lowpan0
>
> 4. Check trac status stats.
>
> You will see that only "SUCCESS" will be increased, which is the behaviour
> on no aret functionality.
>
> 5. Do it again but with ackrequest bit to 1 by using:
>
> iwpan dev wpan0 set ackreq_default 1
>
> 6. Ping node again.
>
> ping6 fe80::abcd%lowpan0
>
> 7. Check the trac status again.
>
> Now, "SUCCESS" isn't increased (it could be for broadcast frames only). But
> now you will see that "NO ACK" is increased which is the trac status that
> no ack frames was received when using aret functionality.
>
>
> Some additional notes:
>
> I think the registration of debugfs failed when two at86rf230 will be probed,
> because the debugfs "at86rf230" already exists. Is there some way to add a
> number to it like the name "at86rf230%d"? Or we just leave it as it is, it's
> just a debugging feature and should be disabled then when using two at86rf230
> transceivers.
>
> - Alex
>
> changes since RFC becomes PATCH:
> - remove reserved trac value stats and print warning
> - print warning also on tx when trac status is not defined
> - print warning also on rx when trac status is not defined
> - add spi bus name to the debugfs entry of at86rf230
> - add patch for TRX_OFF for when tx_retries is above threshold
> - add patch for make a more detailed warning about edge triggered
> irq's.
>
> Alexander Aring (4):
> at86rf230: change trac status check behaviour
> at86rf230: interrupt tx with force trx_off
> at86rf230: add debugfs support
> at86rf230: detailed edge triggered irq warning
>
> drivers/net/ieee802154/Kconfig | 7 ++
> drivers/net/ieee802154/at86rf230.c | 195 ++++++++++++++++++++++++++++---------
> drivers/net/ieee802154/at86rf230.h | 8 ++
> 3 files changed, 163 insertions(+), 47 deletions(-)
all 4 patches have been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH bluetooth-next] ieee802154: 6lowpan: use correct ESC value for dispatch
From: Marcel Holtmann @ 2015-09-03 14:07 UTC (permalink / raw)
To: Stefan Schmidt; +Cc: linux-wpan, Alexander Aring
In-Reply-To: <1441284859-22191-1-git-send-email-stefan@osg.samsung.com>
Hi Stefan,
> The ESC dispatch value has some history and it originally was 0x7f in rfc4944
> (see section-5.1). With the release of rfc6282 this value got part of the
> LOWPAN_IPHC range and was no longer available for ESC. Instead 0x40 was used
> as replacement (see section-2 in rfc6282).
>
> We have been checking the dispatch byte in an order where IPHC would always be
> evaluated before ESC and thus we would never reach the ESC check as the IPHC
> range already covers this value.
>
> Signed-off-by: Stefan Schmidt <stefan@osg.samsung.com>
> ---
> net/ieee802154/6lowpan/rx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH bluetooth-next] ieee802154: 6lowpan: use correct ESC value for dispatch
From: Alexander Aring @ 2015-09-03 13:06 UTC (permalink / raw)
To: Stefan Schmidt; +Cc: linux-wpan
In-Reply-To: <1441284859-22191-1-git-send-email-stefan@osg.samsung.com>
On Thu, Sep 03, 2015 at 02:54:19PM +0200, Stefan Schmidt wrote:
> The ESC dispatch value has some history and it originally was 0x7f in rfc4944
> (see section-5.1). With the release of rfc6282 this value got part of the
> LOWPAN_IPHC range and was no longer available for ESC. Instead 0x40 was used
> as replacement (see section-2 in rfc6282).
>
> We have been checking the dispatch byte in an order where IPHC would always be
> evaluated before ESC and thus we would never reach the ESC check as the IPHC
> range already covers this value.
>
> Signed-off-by: Stefan Schmidt <stefan@osg.samsung.com>
Acked-by: Alexander Aring <alex.aring@gmail.com>
^ permalink raw reply
* [PATCH bluetooth-next] ieee802154: 6lowpan: use correct ESC value for dispatch
From: Stefan Schmidt @ 2015-09-03 12:54 UTC (permalink / raw)
To: linux-wpan; +Cc: Alexander Aring, Stefan Schmidt
The ESC dispatch value has some history and it originally was 0x7f in rfc4944
(see section-5.1). With the release of rfc6282 this value got part of the
LOWPAN_IPHC range and was no longer available for ESC. Instead 0x40 was used
as replacement (see section-2 in rfc6282).
We have been checking the dispatch byte in an order where IPHC would always be
evaluated before ESC and thus we would never reach the ESC check as the IPHC
range already covers this value.
Signed-off-by: Stefan Schmidt <stefan@osg.samsung.com>
---
net/ieee802154/6lowpan/rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ieee802154/6lowpan/rx.c b/net/ieee802154/6lowpan/rx.c
index 3c31980..b1fd47d 100644
--- a/net/ieee802154/6lowpan/rx.c
+++ b/net/ieee802154/6lowpan/rx.c
@@ -20,7 +20,7 @@
#define LOWPAN_DISPATCH_FRAG_MASK 0xf8
#define LOWPAN_DISPATCH_NALP 0x00
-#define LOWPAN_DISPATCH_ESC 0x7f
+#define LOWPAN_DISPATCH_ESC 0x40
#define LOWPAN_DISPATCH_HC1 0x42
#define LOWPAN_DISPATCH_DFF 0x43
#define LOWPAN_DISPATCH_BC0 0x50
--
2.4.3
^ permalink raw reply related
* Re: [PATCH bluetooth-next] ieee802154: 6lowpan: fix drop return value
From: Marcel Holtmann @ 2015-09-02 18:19 UTC (permalink / raw)
To: Alexander Aring; +Cc: linux-wpan, kernel
In-Reply-To: <1441217142-21315-1-git-send-email-alex.aring@gmail.com>
Hi Alex,
> This patch changes the return value of lowpan packet receive handler to
> the correct NET_RX_DROP instead RX_DROP.
>
> This issue was detected by sparse and reported from Marcel:
> net/ieee802154/6lowpan/rx.c:329:32: expected int
> net/ieee802154/6lowpan/rx.c:329:32: got restricted lowpan_rx_result ...
>
> Reported-by: Marcel Holtmann <marcel@holtmann.org>
> Signed-off-by: Alexander Aring <alex.aring@gmail.com>
> ---
> net/ieee802154/6lowpan/rx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* [PATCH bluetooth-next] ieee802154: 6lowpan: fix drop return value
From: Alexander Aring @ 2015-09-02 18:05 UTC (permalink / raw)
To: linux-wpan; +Cc: kernel, Alexander Aring
This patch changes the return value of lowpan packet receive handler to
the correct NET_RX_DROP instead RX_DROP.
This issue was detected by sparse and reported from Marcel:
net/ieee802154/6lowpan/rx.c:329:32: expected int
net/ieee802154/6lowpan/rx.c:329:32: got restricted lowpan_rx_result ...
Reported-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
---
net/ieee802154/6lowpan/rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ieee802154/6lowpan/rx.c b/net/ieee802154/6lowpan/rx.c
index 856052b..3c31980 100644
--- a/net/ieee802154/6lowpan/rx.c
+++ b/net/ieee802154/6lowpan/rx.c
@@ -326,7 +326,7 @@ static int lowpan_rcv(struct sk_buff *skb, struct net_device *wdev,
lowpan_is_iphc(*skb_network_header(skb))) {
skb = skb_unshare(skb, GFP_ATOMIC);
if (!skb)
- return RX_DROP;
+ return NET_RX_DROP;
}
return lowpan_invoke_rx_handlers(skb);
--
2.5.1
^ permalink raw reply related
* Re: [PATCH bluetooth-next 00/16] ieee802154: 6lowpan: cleanup and rework dispatch evaluation
From: Marcel Holtmann @ 2015-09-02 17:49 UTC (permalink / raw)
To: Alexander Aring; +Cc: linux-wpan, kernel, Jukka Rissanen
In-Reply-To: <1441196491-25013-1-git-send-email-alex.aring@gmail.com>
Hi Alex,
> this patch series contains a rework of 802.15.4 6LoWPAN receive handling.
> We need to check on some things before which never checked before, like
> is 802.15.4 dataframe, if we can access skb->data[0] (could be that skb->len
> is 0 then), etc.
>
> Also various bug fixes like the masking for fragmentation dispatch value which
> is currently wrong. Also we should again check the dispatch value after successful
> reassembly a fragment, we currently assume always a iphc header there. This is wrong
> it could also be a non-compressed header. This can occur if the compressed header is
> larger than lower interface MTU size, we doesn't react on this while transmit which
> is another issue. Nevertheless we also don't reach this case at worst-case compression
> currently.
>
> I introduced a complete new handling for the dispatch values based on mac80211
> receive handling mechanism.
>
> - Alex
>
> Cc: Jukka Rissanen <jukka.rissanen@linux.intel.com>
>
> changes since PATCH:
> - rebase to current bluetooth-next/master
> - remove unnecessary else branch in fragmentation handling
> - add more detailed "why" in the commit message of "ieee802154: 6lowpan:
> register packet layer while open"
> - replace magic numbers for getting dgram size high bytes by some defines.
> - Add the "Updated Last" date at iana code commentary for dispatch values.
> - Add Jukka into Cc: because we touch the 6LoWPAN generic branch. (Should only
> 802.15.4 related changes there, see "ieee820154: 6lowpan: dispatch
> evaluation rework"
> - Add several "Reviewed-by: Stefan Schmidt <stefan@osg.samsung.com>", thanks
> for giving some feedback.
>
> changes since v2:
> - I know there is some patch on net-next which occurs in merge conflicts, I
> will wait until this patch is in bluetooth-next before sending as PATCH.
> - fix the "ieee820154: 6lowpan: dispatch evaluation rework" by also doing
> dispatch evaluation on FRAG1. Also we do now FRAG1 uncompression (if iphc)
> on-the-fly. This is currently solved by doing special lltype handling
> in generic 6LoWPAN. Maybe we can introduce some "payload_len" parameter
> to the uncompression functions, to avoid the use of skb->cb.
> The complete patch looks different now, I fixup also some other patches into
> this patch.
> Also add skb_unshare on dispatches where we manipulate the skb data.
> Change address handling for fragmentation for parse again skb_mac_header instead
> using skb->cb which was filled from lower layer.
> - replace the removal of wdev running patch "ieee802154: 6lowpan: change if
> lowpan dev is running".
> - add lowpan_dff dispatch.
> - change reserved dispatch values to use ranges.
> - add "ieee802154: 6lowpan: register packet layer while open".
> - add "ieee802154: 6lowpan: remove check on null".
> - change order at "ieee802154: 6lowpan: trivial checks at" to check on
> "wdev->type != ARPHRD_IEEE802154" at first.
> - change "ieee802154: 6lowpan: check on valid 802.15.4 frame", we don't need
> to check on addr none. Dataframes which belongs to a "node" type should always
> have source and destination addresses. This need to be handled in the lower layers.
> - add "ieee802154: 6lowpan: remove tx full-size" which removes a ugly workaround
> to calculate the full size of iphc packet. We don't need it since we use FRAG1
> uncompression on the fly. Also change this behaviour for transmit and remove
> the ugly workaround functions.
>
> Alexander Aring (16):
> ieee802154: 6lowpan: change dev vars to wdev and ldev
> ieee802154: 6lowpan: register packet layer while open
> ieee802154: 6lowpan: remove check on null
> ieee802154: 6lowpan: remove set to zero
> ieee802154: 6lowpan: remove EXPORT_SYMBOL
> ieee802154: 6lowpan: change if lowpan dev is running
> ieee802154: 6lowpan: cleanup pull of iphc bytes
> ieee802154: 6lowpan: trivial checks at first
> ieee802154: 6lowpan: earlier skb->dev switch
> ieee820154: 6lowpan: dispatch evaluation rework
> ieee802154: 6lowpan: add generic lowpan header check
> ieee802154: 6lowpan: add handler for all dispatch values
> ieee802154: 6lowpan: add check for reserved dispatch
> ieee802154: 6lowpan: check on valid 802.15.4 frame
> ieee802154: 6lowpan: remove packet type to host
> ieee802154: 6lowpan: remove tx full-size calc workaround
>
> include/linux/ieee802154.h | 25 +++
> include/net/6lowpan.h | 144 +++------------
> include/net/mac802154.h | 15 ++
> net/6lowpan/iphc.c | 13 +-
> net/6lowpan/nhc_udp.c | 13 +-
> net/ieee802154/6lowpan/6lowpan_i.h | 14 +-
> net/ieee802154/6lowpan/core.c | 116 ++++++------
> net/ieee802154/6lowpan/reassembly.c | 157 +++++++++++-----
> net/ieee802154/6lowpan/rx.c | 352 ++++++++++++++++++++++++++++--------
> net/ieee802154/6lowpan/tx.c | 51 +++---
> 10 files changed, 572 insertions(+), 328 deletions(-)
all 16 patches have been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox