[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140514052742.GA10566@omega>
Date: Wed, 14 May 2014 07:27:45 +0200
From: Alexander Aring <alex.aring@...il.com>
To: Phoebe Buckheister <phoebe.buckheister@...m.fraunhofer.de>
Cc: netdev@...r.kernel.org, davem@...emloft.net,
linux-zigbee-devel@...ts.sourceforge.net
Subject: Re: [Linux-zigbee-devel] [PATCH net-next 2/5] 6lowpan: simplify/fix
payload length calculation
Hi Phoebe,
sorry I can't test your patches at the moment.
On Tue, May 13, 2014 at 07:24:03PM +0200, Phoebe Buckheister wrote:
> Instead of accounting for all fields of a packet we can think about,
> simply peek the header of a packet we're building and ask ieee802154 how
> many bytes of payload space we have. This also accounts for security
> headers, which were ignored previously.
>
> Signed-off-by: Phoebe Buckheister <phoebe.buckheister@...m.fraunhofer.de>
> ---
> net/ieee802154/6lowpan_rtnl.c | 24 ++++++++++++++++--------
> 1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/net/ieee802154/6lowpan_rtnl.c b/net/ieee802154/6lowpan_rtnl.c
> index 0f5a69e..3e11b46 100644
> --- a/net/ieee802154/6lowpan_rtnl.c
> +++ b/net/ieee802154/6lowpan_rtnl.c
> @@ -256,6 +256,19 @@ lowpan_fragment_xmit(struct sk_buff *skb, u8 *head,
> return dev_queue_xmit(frag);
> }
>
> +static int lowpan_fragment_plen(struct sk_buff *skb, int extra)
> +{
> + struct ieee802154_hdr hdr;
> +
> + ieee802154_hdr_peek(skb, &hdr);
> +
> + /* calc the nearest payload length(divided to 8) for a fragment with
> + * a given 802.15.4 hdr and additional lowpan headers which fits into
> + * IEEE802154_MTU
> + */
> + return round_down(ieee802154_max_payload(&hdr) - extra, 8);
> +}
Is there a change to use the skb_mac_header_length function here instead
of parsing the mac header? I mean we should already known the mac header
size from the wpan header_create function.
I am not sure when you have the information for the security headers...
maybe we don't have this available at the wpan header_create function.
But when this is true we should reset the skb_mac_header then.
This sounds also bad if the mac header is changed in lowpan device. I
don't know how the security stuff workds right now, sorry.
And maybe we should replace the skb->mac_len in the lowpan_skb_fragmentation
function. :-) This we could put on the todo list. For the global 6LoWPAN
cleanup code patch series.
- Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists