lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ