[Linux-zigbee-devel] [PATCH 1/2] at86rf230: add help and 212 to Kconfig menu entry
Since commit e035b8addc544c2b4de2f8b0326ba7939abd9541 we support at86rf212 aswell. Signed-off-by: Alexander Aring --- drivers/net/ieee802154/Kconfig | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/net/ieee802154/Kconfig b/drivers/net/ieee802154/Kconfig index 08ae465..807ad1f 100644 --- a/drivers/net/ieee802154/Kconfig +++ b/drivers/net/ieee802154/Kconfig @@ -32,8 +32,14 @@ config IEEE802154_FAKELB config IEEE802154_AT86RF230 depends on IEEE802154_DRIVERS && MAC802154 -tristate "AT86RF230/231 transceiver driver" +tristate "AT86RF230/231/212 transceiver driver" depends on SPI + ---help--- + Say Y here to enable the at86rf230/231/212 SPI 802.15.4 wireless + controller. + + This driver can also be built as a module. To do so, say M here. + the module will be called 'at86rf230'. config IEEE802154_MRF24J40 tristate "Microchip MRF24J40 transceiver driver" -- 1.9.0 -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 2/2] ieee802154: fix whitespace issues in Kconfig
This patch fixes some whitespace issues in Kconfig files of IEEE 802.15.4 subsytem. Signed-off-by: Alexander Aring --- drivers/net/ieee802154/Kconfig | 28 ++-- net/ieee802154/Kconfig | 2 +- 2 files changed, 15 insertions(+), 15 deletions(-) diff --git a/drivers/net/ieee802154/Kconfig b/drivers/net/ieee802154/Kconfig index 807ad1f..9aa06ec 100644 --- a/drivers/net/ieee802154/Kconfig +++ b/drivers/net/ieee802154/Kconfig @@ -15,9 +15,9 @@ config IEEE802154_FAKEHARD depends on IEEE802154_DRIVERS ---help--- Say Y here to enable the fake driver that serves as an example - of HardMAC device driver. + of HardMAC device driver. - This driver can also be built as a module. To do so say M here. + This driver can also be built as a module. To do so say M here. The module will be called 'fakehard'. config IEEE802154_FAKELB @@ -31,9 +31,9 @@ config IEEE802154_FAKELB The module will be called 'fakelb'. config IEEE802154_AT86RF230 -depends on IEEE802154_DRIVERS && MAC802154 -tristate "AT86RF230/231/212 transceiver driver" -depends on SPI + depends on IEEE802154_DRIVERS && MAC802154 + tristate "AT86RF230/231/212 transceiver driver" + depends on SPI ---help--- Say Y here to enable the at86rf230/231/212 SPI 802.15.4 wireless controller. @@ -42,12 +42,12 @@ config IEEE802154_AT86RF230 the module will be called 'at86rf230'. config IEEE802154_MRF24J40 - tristate "Microchip MRF24J40 transceiver driver" - depends on IEEE802154_DRIVERS && MAC802154 - depends on SPI - ---help--- - Say Y here to enable the MRF24J20 SPI 802.15.4 wireless - controller. - - This driver can also be built as a module. To do so, say M here. - the module will be called 'mrf24j40'. + tristate "Microchip MRF24J40 transceiver driver" + depends on IEEE802154_DRIVERS && MAC802154 + depends on SPI + ---help--- + Say Y here to enable the MRF24J20 SPI 802.15.4 wireless + controller. + + This driver can also be built as a module. To do so, say M here. + the module will be called 'mrf24j40'. diff --git a/net/ieee802154/Kconfig b/net/ieee802154/Kconfig index 9c9879d..8af1330 100644 --- a/net/ieee802154/Kconfig +++ b/net/ieee802154/Kconfig @@ -15,7 +15,7 @@ config IEEE802154_6LOWPAN depends on IEEE802154 && IPV6 select 6LOWPAN_IPHC ---help--- - IPv6 compression over IEEE 802.15.4. + IPv6 compression over IEEE 802.15.4. config 6LOWPAN_IPHC tristate -- 1.9.0 -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [PATCH net-next v3 1/4] ieee802154: add generic header handling routines
Hi Phoebe,
On Mon, Mar 03, 2014 at 11:07:52PM +0100, Phoebe Buckheister wrote:
> Add a generic set of 802.15.4 header operations on sk_buffs: push header
> onto skb, pull header from skb, and peek address fields from the mac_hdr
> part of an skb.
>
> These routines support the full 802.15.4 header as described in the
> standard, including the security header. They are useful for everything
> that must create, modify or read 802.15.4 headers, which of course
> includes the wpan rx/tx path, but also 6lowpan. In the future,
> link-layer security will also require means to modify packet headers.
>
> Signed-off-by: Phoebe Buckheister
> Tested-by: Alexander Aring
> ---
> +static int
> +ieee802154_hdr_get_addrs(const u8 *buf, struct ieee802154_hdr *hdr)
> +{
> + int pos = 0;
> +
> + pos += ieee802154_hdr_get_addr(buf + pos,
> +IEEE802154_FC_DAMODE(hdr->fc),
> +false, &hdr->dest);
> + pos += ieee802154_hdr_get_addr(buf + pos,
> +IEEE802154_FC_SAMODE(hdr->fc),
> +hdr->fc & IEEE802154_FC_INTRA_PAN,
> +&hdr->source);
> +
> + if (hdr->fc && IEEE802154_FC_INTRA_PAN)
I think this should be:
if (hdr->fc & IEEE802154_FC_INTRA_PAN)
- Alex
--
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next v4 4/4] ieee802154: remove seq member of mac_cb
The seq member is only used to initialize the sequence number field of
the 802.15.4 header. This field has relevance only for low-level
functionality like frame acknowledgement and is of no importance to
upper layers. Upper layers should not be allowed to set this field at
all.
Signed-off-by: Phoebe Buckheister
Tested-by: Alexander Aring
---
include/net/ieee802154_netdev.h |1 -
net/ieee802154/6lowpan_rtnl.c |1 -
net/ieee802154/dgram.c |1 -
net/mac802154/wpan.c|2 +-
4 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee802154_netdev.h
index d23a300..cee7f22 100644
--- a/include/net/ieee802154_netdev.h
+++ b/include/net/ieee802154_netdev.h
@@ -85,7 +85,6 @@ struct ieee802154_frag_info {
struct ieee802154_mac_cb {
u8 lqi;
u8 flags;
- u8 seq;
struct ieee802154_frag_info frag_info;
};
diff --git a/net/ieee802154/6lowpan_rtnl.c b/net/ieee802154/6lowpan_rtnl.c
index b413e4e..7ebc300 100644
--- a/net/ieee802154/6lowpan_rtnl.c
+++ b/net/ieee802154/6lowpan_rtnl.c
@@ -117,7 +117,6 @@ static int lowpan_header_create(struct sk_buff *skb,
* this isn't implemented in mainline yet, so currently we assign 0xff
*/
mac_cb(skb)->flags = IEEE802154_FC_TYPE_DATA;
- mac_cb(skb)->seq = ieee802154_mlme_ops(dev)->get_dsn(dev);
/* prepare wpan address data */
sa.addr_type = IEEE802154_ADDR_LONG;
diff --git a/net/ieee802154/dgram.c b/net/ieee802154/dgram.c
index 5fcb817..6480510 100644
--- a/net/ieee802154/dgram.c
+++ b/net/ieee802154/dgram.c
@@ -253,7 +253,6 @@ static int dgram_sendmsg(struct kiocb *iocb, struct sock
*sk,
if (ro->want_ack)
mac_cb(skb)->flags |= MAC_CB_FLAG_ACKREQ;
- mac_cb(skb)->seq = ieee802154_mlme_ops(dev)->get_dsn(dev);
err = dev_hard_header(skb, dev, ETH_P_IEEE802154, &ro->dst_addr,
ro->bound ? &ro->src_addr : NULL, size);
if (err < 0)
diff --git a/net/mac802154/wpan.c b/net/mac802154/wpan.c
index 9077c6f..5845503 100644
--- a/net/mac802154/wpan.c
+++ b/net/mac802154/wpan.c
@@ -111,7 +111,7 @@ static int mac802154_header_create(struct sk_buff *skb,
return -EINVAL;
hdr.fc = mac_cb_type(skb);
- hdr.seq = mac_cb(skb)->seq;
+ hdr.seq = ieee802154_mlme_ops(dev)->get_dsn(dev);
if (mac_cb_is_ackreq(skb))
hdr.fc |= IEEE802154_FC_ACK_REQ;
if (mac_cb_is_secen(skb))
--
1.7.9.5
--
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next v4 2/4] mac802154: use new header ops in wpan devices
Replace the old header creation/parsing with the new header operations.
This reduces code duplication that existed between
mac802154_parse_frame_start and mac802154_header_parse. This also fixes
a bug that caused 802.15.4 frames with link layer security enabled to be
misparsed, leading to parts of the header being passed to upper layers
as data.
Signed-off-by: Phoebe Buckheister
Tested-by: Alexander Aring
---
include/net/ieee802154_netdev.h |6 -
net/mac802154/wpan.c| 318 ++-
2 files changed, 80 insertions(+), 244 deletions(-)
diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee802154_netdev.h
index c18a4f0..b24d3cb 100644
--- a/include/net/ieee802154_netdev.h
+++ b/include/net/ieee802154_netdev.h
@@ -100,7 +100,6 @@ static inline struct ieee802154_mac_cb *mac_cb(struct
sk_buff *skb)
#define MAC_CB_FLAG_ACKREQ (1 << 3)
#define MAC_CB_FLAG_SECEN (1 << 4)
-#define MAC_CB_FLAG_INTRAPAN (1 << 5)
static inline int mac_cb_is_ackreq(struct sk_buff *skb)
{
@@ -112,11 +111,6 @@ static inline int mac_cb_is_secen(struct sk_buff *skb)
return mac_cb(skb)->flags & MAC_CB_FLAG_SECEN;
}
-static inline int mac_cb_is_intrapan(struct sk_buff *skb)
-{
- return mac_cb(skb)->flags & MAC_CB_FLAG_INTRAPAN;
-}
-
static inline int mac_cb_type(struct sk_buff *skb)
{
return mac_cb(skb)->flags & MAC_CB_FLAG_TYPEMASK;
diff --git a/net/mac802154/wpan.c b/net/mac802154/wpan.c
index 372d8a2..ffadb2c 100644
--- a/net/mac802154/wpan.c
+++ b/net/mac802154/wpan.c
@@ -35,35 +35,6 @@
#include "mac802154.h"
-static inline int mac802154_fetch_skb_u8(struct sk_buff *skb, u8 *val)
-{
- if (unlikely(!pskb_may_pull(skb, 1)))
- return -EINVAL;
-
- *val = skb->data[0];
- skb_pull(skb, 1);
-
- return 0;
-}
-
-static inline int mac802154_fetch_skb_u16(struct sk_buff *skb, u16 *val)
-{
- if (unlikely(!pskb_may_pull(skb, 2)))
- return -EINVAL;
-
- *val = skb->data[0] | (skb->data[1] << 8);
- skb_pull(skb, 2);
-
- return 0;
-}
-
-static inline void mac802154_haddr_copy_swap(u8 *dest, const u8 *src)
-{
- int i;
- for (i = 0; i < IEEE802154_ADDR_LEN; i++)
- dest[IEEE802154_ADDR_LEN - i - 1] = src[i];
-}
-
static int
mac802154_wpan_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
{
@@ -128,25 +99,23 @@ static int mac802154_wpan_mac_addr(struct net_device *dev,
void *p)
static int mac802154_header_create(struct sk_buff *skb,
struct net_device *dev,
unsigned short type,
- const void *_daddr,
- const void *_saddr,
+ const void *daddr,
+ const void *saddr,
unsigned len)
{
- const struct ieee802154_addr *saddr = _saddr;
- const struct ieee802154_addr *daddr = _daddr;
- struct ieee802154_addr dev_addr;
struct mac802154_sub_if_data *priv = netdev_priv(dev);
- int pos = 2;
- u8 head[MAC802154_FRAME_HARD_HEADER_LEN];
- u16 fc;
+ struct ieee802154_hdr hdr;
+ int hlen;
if (!daddr)
return -EINVAL;
- head[pos++] = mac_cb(skb)->seq; /* DSN/BSN */
- fc = mac_cb_type(skb);
+ hdr.fc = mac_cb_type(skb);
+ hdr.seq = mac_cb(skb)->seq;
if (mac_cb_is_ackreq(skb))
- fc |= IEEE802154_FC_ACK_REQ;
+ hdr.fc |= IEEE802154_FC_ACK_REQ;
+ if (mac_cb_is_secen(skb))
+ hdr.fc |= IEEE802154_FC_SECEN;
if (!saddr) {
spin_lock_bh(&priv->mib_lock);
@@ -154,161 +123,46 @@ static int mac802154_header_create(struct sk_buff *skb,
if (priv->short_addr == IEEE802154_ADDR_BROADCAST ||
priv->short_addr == IEEE802154_ADDR_UNDEF ||
priv->pan_id == IEEE802154_PANID_BROADCAST) {
- dev_addr.addr_type = IEEE802154_ADDR_LONG;
- memcpy(dev_addr.hwaddr, dev->dev_addr,
+ hdr.source.addr_type = IEEE802154_ADDR_LONG;
+ memcpy(hdr.source.hwaddr, dev->dev_addr,
IEEE802154_ADDR_LEN);
} else {
- dev_addr.addr_type = IEEE802154_ADDR_SHORT;
- dev_addr.short_addr = priv->short_addr;
+ hdr.source.addr_type = IEEE802154_ADDR_SHORT;
+ hdr.source.short_addr = priv->short_addr;
}
- dev_addr.pan_id = priv->pan_id;
- saddr = &dev_addr;
+ hdr.source.pan_id = priv->pan_id;
spin_unlock_bh(&priv->mib_lock);
+ } else {
+ hdr.source = *(const struct ieee802154_addr *) saddr;
}
-
[Linux-zigbee-devel] [PATCH net-next v4 0/4] ieee802154: clean up header handling
This series of patches cleans up handling of 802.15.4 headers in ieee802154 and mac802154. Particularly, it introduces new functions to read and modify headers and removes the address fields in the skb cb block in favour of these functions. This set also fixes a bug that caused parts of an 802.15.4 header to be delivered to dgram sockets in userspace due to misparsed headers, and moves mac frame sequence number generation from upper layers into the netdev that actually handles them. --- Changes since v3: * turned a misplaced && into the & it was supposed to be Changes since v2: * Formatting Changes since v1: * Tested-by: Alexander Aring * trivial checkpatch issues. The "/*\n" in a copyright header was kept for consistency, some macro definition lines over 80 characters for readability Phoebe Buckheister (4): ieee802154: add generic header handling routines mac802154: use new header ops in wpan devices ieee802154: remove addresses from mac_cb ieee802154: remove seq member of mac_cb include/net/ieee802154.h| 15 ++ include/net/ieee802154_netdev.h | 52 +- include/net/mac802154.h |1 + net/ieee802154/6lowpan_rtnl.c | 13 +- net/ieee802154/Makefile |3 +- net/ieee802154/dgram.c |6 +- net/ieee802154/header_ops.c | 328 + net/ieee802154/reassembly.c |5 +- net/mac802154/wpan.c| 343 +++ 9 files changed, 495 insertions(+), 271 deletions(-) -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next v4 3/4] ieee802154: remove addresses from mac_cb
The mac802154 stack itself does not strictly require these fields: the
tx path never even touches them, and this patch modifies the rx path to
explicitly carry a parsed header.
One notable user of these fields was 6lowpan, which accessed them after
the skb had been passed to it through dev_queue_xmit. 6lowpan was
changed to peek the addresses from a given skb.
Signed-off-by: Phoebe Buckheister
Tested-by: Alexander Aring
---
include/net/ieee802154_netdev.h |2 --
net/ieee802154/6lowpan_rtnl.c | 12 -
net/ieee802154/dgram.c |5 +++-
net/ieee802154/reassembly.c |5 +++-
net/mac802154/wpan.c| 57 +++
5 files changed, 42 insertions(+), 39 deletions(-)
diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee802154_netdev.h
index b24d3cb..d23a300 100644
--- a/include/net/ieee802154_netdev.h
+++ b/include/net/ieee802154_netdev.h
@@ -84,8 +84,6 @@ struct ieee802154_frag_info {
*/
struct ieee802154_mac_cb {
u8 lqi;
- struct ieee802154_addr sa;
- struct ieee802154_addr da;
u8 flags;
u8 seq;
struct ieee802154_frag_info frag_info;
diff --git a/net/ieee802154/6lowpan_rtnl.c b/net/ieee802154/6lowpan_rtnl.c
index c7bd8b5..b413e4e 100644
--- a/net/ieee802154/6lowpan_rtnl.c
+++ b/net/ieee802154/6lowpan_rtnl.c
@@ -52,6 +52,7 @@
#include
#include
#include
+#include
#include
#include "reassembly.h"
@@ -171,7 +172,7 @@ static int lowpan_give_skb_to_devices(struct sk_buff *skb,
static int process_data(struct sk_buff *skb)
{
u8 iphc0, iphc1;
- const struct ieee802154_addr *_saddr, *_daddr;
+ struct ieee802154_hdr hdr;
raw_dump_table(__func__, "raw skb data dump", skb->data, skb->len);
/* at least two bytes will be used for the encoding */
@@ -184,12 +185,11 @@ static int process_data(struct sk_buff *skb)
if (lowpan_fetch_skb_u8(skb, &iphc1))
goto drop;
- _saddr = &mac_cb(skb)->sa;
- _daddr = &mac_cb(skb)->da;
+ ieee802154_hdr_peek_addrs(skb, &hdr);
- return lowpan_process_data(skb, skb->dev, (u8 *)_saddr->hwaddr,
- _saddr->addr_type, IEEE802154_ADDR_LEN,
- (u8 *)_daddr->hwaddr, _daddr->addr_type,
+ return lowpan_process_data(skb, skb->dev, hdr.source.hwaddr,
+ hdr.source.addr_type, IEEE802154_ADDR_LEN,
+ hdr.dest.hwaddr, hdr.dest.addr_type,
IEEE802154_ADDR_LEN, iphc0, iphc1,
lowpan_give_skb_to_devices);
diff --git a/net/ieee802154/dgram.c b/net/ieee802154/dgram.c
index 1846c1f..5fcb817 100644
--- a/net/ieee802154/dgram.c
+++ b/net/ieee802154/dgram.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
@@ -291,6 +292,7 @@ static int dgram_recvmsg(struct kiocb *iocb, struct sock
*sk,
size_t copied = 0;
int err = -EOPNOTSUPP;
struct sk_buff *skb;
+ struct ieee802154_hdr hdr;
DECLARE_SOCKADDR(struct sockaddr_ieee802154 *, saddr, msg->msg_name);
skb = skb_recv_datagram(sk, flags, noblock, &err);
@@ -311,8 +313,9 @@ static int dgram_recvmsg(struct kiocb *iocb, struct sock
*sk,
sock_recv_ts_and_drops(msg, sk, skb);
if (saddr) {
+ ieee802154_hdr_peek_addrs(skb, &hdr);
saddr->family = AF_IEEE802154;
- saddr->addr = mac_cb(skb)->sa;
+ saddr->addr = hdr.source;
*addr_len = sizeof(*saddr);
}
diff --git a/net/ieee802154/reassembly.c b/net/ieee802154/reassembly.c
index eb5995e..6885886 100644
--- a/net/ieee802154/reassembly.c
+++ b/net/ieee802154/reassembly.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include
#include
@@ -354,6 +355,7 @@ int lowpan_frag_rcv(struct sk_buff *skb, const u8 frag_type)
struct lowpan_frag_queue *fq;
struct net *net = dev_net(skb->dev);
struct ieee802154_frag_info *frag_info = &mac_cb(skb)->frag_info;
+ struct ieee802154_hdr hdr;
int err;
err = lowpan_get_frag_info(skb, frag_type, frag_info);
@@ -365,7 +367,8 @@ int lowpan_frag_rcv(struct sk_buff *skb, const u8 frag_type)
inet_frag_evictor(&net->ieee802154_lowpan.frags, &lowpan_frags, false);
- fq = fq_find(net, frag_info, &mac_cb(skb)->sa, &mac_cb(skb)->da);
+ ieee802154_hdr_peek_addrs(skb, &hdr);
+ fq = fq_find(net, frag_info, &hdr.source, &hdr.dest);
if (fq != NULL) {
int ret;
spin_lock(&fq->q.lock);
diff --git a/net/mac802154/wpan.c b/net/mac802154/wpan.c
index ffadb2c..9077c6f 100644
--- a/net/mac802154/wpan.c
+++ b/net/mac802154/wpan.c
@@ -246,15 +246,16 @@ static int mac802154_process_data(struct net_device *dev,
struct sk_buff *skb)
}
static int
-mac802154_subif_frame(struct mac802154_sub_if_data *sdata, s
[Linux-zigbee-devel] [PATCH net-next v4 1/4] ieee802154: add generic header handling routines
Add a generic set of 802.15.4 header operations on sk_buffs: push header
onto skb, pull header from skb, and peek address fields from the mac_hdr
part of an skb.
These routines support the full 802.15.4 header as described in the
standard, including the security header. They are useful for everything
that must create, modify or read 802.15.4 headers, which of course
includes the wpan rx/tx path, but also 6lowpan. In the future,
link-layer security will also require means to modify packet headers.
Signed-off-by: Phoebe Buckheister
Tested-by: Alexander Aring
---
include/net/ieee802154.h| 15 ++
include/net/ieee802154_netdev.h | 43 +
include/net/mac802154.h |1 +
net/ieee802154/Makefile |3 +-
net/ieee802154/header_ops.c | 328 +++
5 files changed, 389 insertions(+), 1 deletion(-)
create mode 100644 net/ieee802154/header_ops.c
diff --git a/include/net/ieee802154.h b/include/net/ieee802154.h
index ee59f8b..b968a19 100644
--- a/include/net/ieee802154.h
+++ b/include/net/ieee802154.h
@@ -52,12 +52,27 @@
#define IEEE802154_FC_DAMODE_SHIFT 10
#define IEEE802154_FC_DAMODE_MASK (3 << IEEE802154_FC_DAMODE_SHIFT)
+#define IEEE802154_FC_VERSION_SHIFT12
+#define IEEE802154_FC_VERSION_MASK (3 << IEEE802154_FC_VERSION_SHIFT)
+#define IEEE802154_FC_VERSION(x) ((x & IEEE802154_FC_VERSION_MASK) >>
IEEE802154_FC_VERSION_SHIFT)
+
#define IEEE802154_FC_SAMODE(x)\
(((x) & IEEE802154_FC_SAMODE_MASK) >> IEEE802154_FC_SAMODE_SHIFT)
#define IEEE802154_FC_DAMODE(x)\
(((x) & IEEE802154_FC_DAMODE_MASK) >> IEEE802154_FC_DAMODE_SHIFT)
+#define IEEE802154_SCF_SECLEVEL_MASK 7
+#define IEEE802154_SCF_SECLEVEL(x) (x &
IEEE802154_SCF_SECLEVEL_MASK)
+#define IEEE802154_SCF_KEY_ID_MODE_SHIFT 3
+#define IEEE802154_SCF_KEY_ID_MODE_MASK(3 <<
IEEE802154_SCF_KEY_ID_MODE_SHIFT)
+#define IEEE802154_SCF_KEY_ID_MODE(x) \
+ ((x & IEEE802154_SCF_KEY_ID_MODE_MASK) >>
IEEE802154_SCF_KEY_ID_MODE_SHIFT)
+
+#define IEEE802154_SCF_KEY_IMPLICIT0
+#define IEEE802154_SCF_KEY_INDEX 1
+#define IEEE802154_SCF_KEY_SHORT_INDEX 2
+#define IEEE802154_SCF_KEY_HW_INDEX3
/* MAC footer size */
#define IEEE802154_MFR_SIZE2 /* 2 octets */
diff --git a/include/net/ieee802154_netdev.h b/include/net/ieee802154_netdev.h
index 97b2e34..c18a4f0 100644
--- a/include/net/ieee802154_netdev.h
+++ b/include/net/ieee802154_netdev.h
@@ -28,6 +28,49 @@
#define IEEE802154_NETDEVICE_H
#include
+#include
+#include
+
+struct ieee802154_sechdr {
+ u8 sc;
+ u32 frame_ctr;
+ union {
+ struct {
+ u16 pan_id;
+ u16 short_addr;
+ } pan;
+ u8 hw[IEEE802154_ADDR_LEN];
+ } key_source;
+ u8 key_id;
+};
+
+struct ieee802154_hdr {
+ u16 fc;
+ u8 seq;
+ struct ieee802154_addr source;
+ struct ieee802154_addr dest;
+ struct ieee802154_sechdr sec;
+};
+
+/* pushes hdr onto the skb. fields of hdr->fc that can be calculated from
+ * the contents of hdr will be, and the actual value of those bits in
+ * hdr->fc will be ignored. this includes the INTRA_PAN bit and the frame
+ * version, if SECEN is set.
+ */
+int ieee802154_hdr_push(struct sk_buff *skb, const struct ieee802154_hdr *hdr);
+
+/* pulls the entire 802.15.4 header off of the skb, including the security
+ * header, and performs pan id decompression
+ */
+int ieee802154_hdr_pull(struct sk_buff *skb, struct ieee802154_hdr *hdr);
+
+/* parses the address fields in a given skb and stores them into hdr,
+ * performing pan id decompression and length checks to be suitable for use in
+ * header_ops.parse
+ */
+int ieee802154_hdr_peek_addrs(const struct sk_buff *skb,
+ struct ieee802154_hdr *hdr);
+
struct ieee802154_frag_info {
__be16 d_tag;
diff --git a/include/net/mac802154.h b/include/net/mac802154.h
index 8ca3d04..ceee5ea 100644
--- a/include/net/mac802154.h
+++ b/include/net/mac802154.h
@@ -20,6 +20,7 @@
#define NET_MAC802154_H
#include
+#include
/* General MAC frame format:
* 2 bytes: Frame Control
diff --git a/net/ieee802154/Makefile b/net/ieee802154/Makefile
index b113fc4..5db61ba 100644
--- a/net/ieee802154/Makefile
+++ b/net/ieee802154/Makefile
@@ -3,5 +3,6 @@ obj-$(CONFIG_IEEE802154_6LOWPAN) += 6lowpan.o
obj-$(CONFIG_6LOWPAN_IPHC) += 6lowpan_iphc.o
6lowpan-y := 6lowpan_rtnl.o reassembly.o
-ieee802154-y := netlink.o nl-mac.o nl-phy.o nl_policy.o wpan-class.o
+ieee802154-y := netlink.o nl-mac.o nl-phy.o nl_policy.o wpan-class.o \
+header_ops.o
af_802154-y := af_ieee802154.o raw.o dgram.o
diff --git a/net/ieee802154/header_ops.c b/net/ieee802154/header_ops.c
new file mode 100644
index 000..557fd24
--- /dev/null
+++ b/net/ieee802154/header_ops.c
[Linux-zigbee-devel] [PATCH net-next v2 2/2] ieee802154: fix whitespace issues in Kconfig
This patch fixes some whitespace issues in Kconfig files of IEEE 802.15.4 subsytem. Signed-off-by: Alexander Aring --- drivers/net/ieee802154/Kconfig | 26 +- net/ieee802154/Kconfig | 2 +- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/drivers/net/ieee802154/Kconfig b/drivers/net/ieee802154/Kconfig index 16e9331..9aa06ec 100644 --- a/drivers/net/ieee802154/Kconfig +++ b/drivers/net/ieee802154/Kconfig @@ -15,9 +15,9 @@ config IEEE802154_FAKEHARD depends on IEEE802154_DRIVERS ---help--- Say Y here to enable the fake driver that serves as an example - of HardMAC device driver. + of HardMAC device driver. - This driver can also be built as a module. To do so say M here. + This driver can also be built as a module. To do so say M here. The module will be called 'fakehard'. config IEEE802154_FAKELB @@ -31,9 +31,9 @@ config IEEE802154_FAKELB The module will be called 'fakelb'. config IEEE802154_AT86RF230 -depends on IEEE802154_DRIVERS && MAC802154 + depends on IEEE802154_DRIVERS && MAC802154 tristate "AT86RF230/231/212 transceiver driver" -depends on SPI + depends on SPI ---help--- Say Y here to enable the at86rf230/231/212 SPI 802.15.4 wireless controller. @@ -42,12 +42,12 @@ config IEEE802154_AT86RF230 the module will be called 'at86rf230'. config IEEE802154_MRF24J40 - tristate "Microchip MRF24J40 transceiver driver" - depends on IEEE802154_DRIVERS && MAC802154 - depends on SPI - ---help--- - Say Y here to enable the MRF24J20 SPI 802.15.4 wireless - controller. - - This driver can also be built as a module. To do so, say M here. - the module will be called 'mrf24j40'. + tristate "Microchip MRF24J40 transceiver driver" + depends on IEEE802154_DRIVERS && MAC802154 + depends on SPI + ---help--- + Say Y here to enable the MRF24J20 SPI 802.15.4 wireless + controller. + + This driver can also be built as a module. To do so, say M here. + the module will be called 'mrf24j40'. diff --git a/net/ieee802154/Kconfig b/net/ieee802154/Kconfig index 9c9879d..8af1330 100644 --- a/net/ieee802154/Kconfig +++ b/net/ieee802154/Kconfig @@ -15,7 +15,7 @@ config IEEE802154_6LOWPAN depends on IEEE802154 && IPV6 select 6LOWPAN_IPHC ---help--- - IPv6 compression over IEEE 802.15.4. + IPv6 compression over IEEE 802.15.4. config 6LOWPAN_IPHC tristate -- 1.9.0 -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next v2 0/2] ieee802154: Kconfig fixes
Hi, this patch series fix some issues with Kconfig in the ieee802154 subsystem. changes since v2: - Add commit summary in commit msg of patch 1/2. - move one line whitespace fix of at86rf230 entry from patch 2/2 to 1/2. Alexander Aring (2): at86rf230: add help and 212 to Kconfig menu entry ieee802154: fix whitespace issues in Kconfig drivers/net/ieee802154/Kconfig | 34 -- net/ieee802154/Kconfig | 2 +- 2 files changed, 21 insertions(+), 15 deletions(-) -- 1.9.0 -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH net-next v2 1/2] at86rf230: add help and 212 to Kconfig menu entry
Since commit 8fad346f366a72978ea942abd06bd501ebd39c22 (ieee802154: add basic support for RF212 to at86rf230 driver) we support at86rf212 as well. Signed-off-by: Alexander Aring --- drivers/net/ieee802154/Kconfig | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/net/ieee802154/Kconfig b/drivers/net/ieee802154/Kconfig index 08ae465..16e9331 100644 --- a/drivers/net/ieee802154/Kconfig +++ b/drivers/net/ieee802154/Kconfig @@ -32,8 +32,14 @@ config IEEE802154_FAKELB config IEEE802154_AT86RF230 depends on IEEE802154_DRIVERS && MAC802154 -tristate "AT86RF230/231 transceiver driver" + tristate "AT86RF230/231/212 transceiver driver" depends on SPI + ---help--- + Say Y here to enable the at86rf230/231/212 SPI 802.15.4 wireless + controller. + + This driver can also be built as a module. To do so, say M here. + the module will be called 'at86rf230'. config IEEE802154_MRF24J40 tristate "Microchip MRF24J40 transceiver driver" -- 1.9.0 -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [PATCH 1/2] at86rf230: add help and 212 to Kconfig menu entry
Hello. On 03/04/2014 01:22 PM, Alexander Aring wrote: > Since commit e035b8addc544c2b4de2f8b0326ba7939abd9541 we support at86rf212 Please also specify that commit's summary line in parens. > aswell. As well. > Signed-off-by: Alexander Aring > --- > drivers/net/ieee802154/Kconfig | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > diff --git a/drivers/net/ieee802154/Kconfig b/drivers/net/ieee802154/Kconfig > index 08ae465..807ad1f 100644 > --- a/drivers/net/ieee802154/Kconfig > +++ b/drivers/net/ieee802154/Kconfig > @@ -32,8 +32,14 @@ config IEEE802154_FAKELB > > config IEEE802154_AT86RF230 > depends on IEEE802154_DRIVERS && MAC802154 > -tristate "AT86RF230/231 transceiver driver" > +tristate "AT86RF230/231/212 transceiver driver" You need to indent with tab here. > depends on SPI > + ---help--- > + Say Y here to enable the at86rf230/231/212 SPI 802.15.4 wireless > + controller. > + > + This driver can also be built as a module. To do so, say M here. > + the module will be called 'at86rf230'. WBR, Sergei -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [PATCH net-next v4 1/4] ieee802154: add generic header handling routines
From: Phoebe Buckheister
Date: Tue, 4 Mar 2014 15:34:45 +0100
> +struct ieee802154_sechdr {
> + u8 sc;
> + u32 frame_ctr;
> + union {
> + struct {
> + u16 pan_id;
> + u16 short_addr;
> + } pan;
> + u8 hw[IEEE802154_ADDR_LEN];
> + } key_source;
> + u8 key_id;
> +};
> +
> +struct ieee802154_hdr {
> + u16 fc;
> + u8 seq;
> + struct ieee802154_addr source;
> + struct ieee802154_addr dest;
> + struct ieee802154_sechdr sec;
> +};
You're going to have to address endianness both in these structure
definitions and the code.
For types larger than u8 you'll need to use __be16, __le16, __be32,
__le32 etc. as appropriate.
When setting/loading values, you'll need to use cpu_to_be16(),
cpu_to_le16() etc. as appropriate.
--
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [PATCH net-next v4 1/4] ieee802154: add generic header handling routines
>> +struct ieee802154_sechdr {
>> +u8 sc;
>> +u32 frame_ctr;
>> +union {
>> +struct {
>> +u16 pan_id;
>> +u16 short_addr;
>> +} pan;
>> +u8 hw[IEEE802154_ADDR_LEN];
>> +} key_source;
>> +u8 key_id;
>> +};
>> +
>> +struct ieee802154_hdr {
>> +u16 fc;
>> +u8 seq;
>> +struct ieee802154_addr source;
>> +struct ieee802154_addr dest;
>> +struct ieee802154_sechdr sec;
>> +};
>
> You're going to have to address endianness both in these structure
> definitions and the code.
>
> For types larger than u8 you'll need to use __be16, __le16, __be32,
> __le32 etc. as appropriate.
>
> When setting/loading values, you'll need to use cpu_to_be16(),
> cpu_to_le16() etc. as appropriate.
The intention here was to explicitly not do that, and have this
representation of the header be completely in host byte order. This is due
to the fact that an easily accessible (i.e. no bitshifts/pointer
arithmetic all over the place) representation will differ wildly from the
actual packet MAC header contents, so I went with host byte order there
instead. The header operations will convert them to/from the correct byte
order for the actual MAC header.
I see some value in being able to memcpy() to/from those fields directly
when building/reading headers, but I also think that not having to do
endianness conversion everywhere for a struct that cannot ever be a valid
header as is outweighs this.
If explicit endianness is required for this case nonetheless, I will of
course change it.
--
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [PATCH net-next v4 1/4] ieee802154: add generic header handling routines
From: "Phoebe Buckheister" Date: Tue, 4 Mar 2014 23:16:31 +0100 > I see some value in being able to memcpy() to/from those fields directly > when building/reading headers, but I also think that not having to do > endianness conversion everywhere for a struct that cannot ever be a valid > header as is outweighs this. Why have an intermediate copy when that's not necessary at all? It seems like pure overhead to be. Furthermore, cpu's have byte-shifting load and store instructions which will be used if you make use of the 'p' versions of the endian swap functions, such as cpu_to_le16p(). So it's going to cost basically nothing. -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] IZ problems
HI I have recently found about linx-zigbee so I wanted to run it on my PC but I am getting this error " could not get multicast group ID: no such file or directory " Every time that I execute the command iz. can anyone help me to get trough this issue? thanks in advance. Sincerely *---Rafik Harzi* Student at National School of Computer Studies - Tunisia Phone : 00216 20 912 872 -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [PATCH net-next v4 1/4] ieee802154: add generic header handling routines
> Why have an intermediate copy when that's not necessary at all? It > seems like pure overhead to be. > > Furthermore, cpu's have byte-shifting load and store instructions > which will be used if you make use of the 'p' versions of the endian > swap functions, such as cpu_to_le16p(). > > So it's going to cost basically nothing. I didn't mean the runtime cost of any conversion that might happen, I was thinking about how much these conversions would affect the code that uses these header structs. While for the u16/u32 fields this might be not much, it will be more for the hardware address fields since these are stored as the little endian encoding of u64 field you get when reading the u8[8] as a __be64. If I understand you correctly, these fields would also have to be in network byte order in the header struct, introducing copy-and-swaps in every upper layer that uses those addresses and making address matching harder since memcmp won't work anymore. What would be better here? Explicit endianness on all fields for consistency and thus __le64 for EUI64 members with copy-swap functions to convert those addresses into u8[8] where required, explicit endianness on everything except addresses, or keeping it as is? I'm honestly not sure. I want to note here that struct ieee802154_addr, which holds the address information and is also used by BSD socket calls, has always used host byte order for its own fields. This might itself be a huge mistake, but it is relevant to this discussion. -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [PATCH net-next v4 1/4] ieee802154: add generic header handling routines
From: "Phoebe Buckheister" Date: Tue, 4 Mar 2014 23:49:33 +0100 > I didn't mean the runtime cost of any conversion that might happen, I was > thinking about how much these conversions would affect the code that uses > these header structs. While for the u16/u32 fields this might be not much, > it will be more for the hardware address fields since these are stored as > the little endian encoding of u64 field you get when reading the u8[8] as > a __be64. If I understand you correctly, these fields would also have to > be in network byte order in the header struct, introducing copy-and-swaps > in every upper layer that uses those addresses and making address matching > harder since memcmp won't work anymore. SUre it would, store the addresses in your internal data structures as a __be64 too. That's what IPV4/IPV6 do, we store addresses and ports in the socket in network byte order. Comparisons just work. -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [PATCH net-next v4 1/4] ieee802154: add generic header handling routines
> SUre it would, store the addresses in your internal data structures > as a __be64 too. That's what IPV4/IPV6 do, we store addresses and > ports in the socket in network byte order. Comparisons just work. That's the thing - there are so many different byte orders floating around at the moment. Network byte order is little endian. Hardware addresses are big endian in the network layer and 6lowpan though, and our sockaddrs are host byte order for some parts and big endian for others. It's a real mess. The solution in my patch seemed the cleanest option to me. Storing *everything* in network byte order would require a small adaption layer at every interaction with userspace to fix byte ordering, but that's doable. 6lowpan would have to do an extra byteswap for the address that I currently do in the header ops. I'll change everything that might come in contact with the network to __le variants and add explicit swaps where required. -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [PATCH net-next v4 1/4] ieee802154: add generic header handling routines
From: "Phoebe Buckheister" Date: Wed, 5 Mar 2014 02:01:52 +0100 > That's the thing - there are so many different byte orders floating around > at the moment. Network byte order is little endian. Hardware addresses are > big endian in the network layer and 6lowpan though, and our sockaddrs are > host byte order for some parts and big endian for others. It's a real > mess. The solution in my patch seemed the cleanest option to me. > > Storing *everything* in network byte order would require a small adaption > layer at every interaction with userspace to fix byte ordering, but that's > doable. 6lowpan would have to do an extra byteswap for the address that I > currently do in the header ops. That's an odd choice, since ipv4/ipv6 universally put things in network byte order in the sockaddrs. But since it's been made already, you want to still use network byte order internally in the stack. Because you're going to process more packets than you are going to be handling user sockaddrs. Translate the values to network byte order on bind() etc. calls and just be done with it. -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [PATCH net-next v2 0/2] ieee802154: Kconfig fixes
From: Alexander Aring Date: Tue, 4 Mar 2014 19:01:16 +0100 > this patch series fix some issues with Kconfig in the ieee802154 subsystem. Series applied, thank you. -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
