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 08
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/driver
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 heade
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: Phoe
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
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
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_x
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 everyth
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/
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
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/
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 |
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[IEEE
>> +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;
>> +}
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 a
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
*-
> 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
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
> 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.
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
> h
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 &
21 matches
Mail list logo
