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
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
Hi Phoebe,
On Mon, Mar 03, 2014 at 01:59:03PM +0100, Phoebe Buckheister wrote:
> 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 bl
Hi,
This patch is fine. Increment and set of DSN value should be done by
mac802154 layer.
But there is also a known issue with increment of DSN value while
6lowpan fragmentation.
On a fragmented packet 6lowpan calls dev_hard_header once, then many
times lowpan_fragment_xmit, depending on the num
On Mon, Mar 03, 2014 at 03:06:01PM +0100, Alexander Aring wrote:
> Hi,
>
> This patch is fine. Increment and set of DSN value should be done by
> mac802154 layer.
>
> But there is also a known issue with increment of DSN value while
> 6lowpan fragmentation.
>
> On a fragmented packet 6lowpan cal
> On a fragmented packet 6lowpan calls dev_hard_header once, then many
> times lowpan_fragment_xmit, depending on the number of fragments which
> is needed.
To me, the obvious answer would be "just don't do that". Each fragment
is a distinct packet, so it should not reuse a header that was created
On Mon, 3 Mar 2014 15:10:27 +0100
Alexander Aring wrote:
> Or maybe we can move the dev_hard_header call in lowpan_fragment_xmit
> and lowpan_xmit if this is possible. But then we doesn't know the mac
> header length in lowpan_skb_fragmentation. Strange...
You could have lowpan_fragment_xmit cre
On Mon, Mar 03, 2014 at 03:12:19PM +0100, Phoebe Buckheister wrote:
> > On a fragmented packet 6lowpan calls dev_hard_header once, then many
> > times lowpan_fragment_xmit, depending on the number of fragments which
> > is needed.
>
> To me, the obvious answer would be "just don't do that". Each f
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
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
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
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
From: Jean Sacren
Date: Sat, 1 Mar 2014 15:54:36 -0700
> The commit 9b2777d6089bc ("ieee802154: add TX power control to
> wpan_phy") introduced the new function at86rf212_set_txpower() with
> the questionable check of the return of __at86rf230_write() in the
> exit path:
>
> 1) Both at86rf212_s
From: Phoebe Buckheister
Date: Mon, 3 Mar 2014 16:30:03 +0100
> +/* 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
Please
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 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
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 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
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
23 matches
Mail list logo
