netdev - Re: [PATCH net-next v2 2/6] 6lowpan: fix fragmentation on sending side

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 25 Feb 2014 02:21:57 +0100
From:	Alexander Aring <alex.aring@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	alex.bluesman.smirnov@...il.com, dbaryshkov@...il.com,
	linux-zigbee-devel@...ts.sourceforge.net, netdev@...r.kernel.org,
	martin.townsend@...lon.com
Subject: Re: [PATCH net-next v2 2/6] 6lowpan: fix fragmentation on sending
 side

Hi David,

On Mon, Feb 24, 2014 at 06:52:13PM -0500, David Miller wrote:
> From: Alexander Aring <alex.aring@...il.com>
> Date: Fri, 21 Feb 2014 19:58:58 +0100
> 
> > +	err = lowpan_fragment_xmit(skb, head, header_length,
> > +				   frag_plen + lowpan_size, 0,
> > +				   LOWPAN_DISPATCH_FRAG1);
> >  	if (err) {
> >  		pr_debug("%s unable to send FRAG1 packet (tag: %d)",
> >  			 __func__, tag);
> >  		goto exit;
> >  	}
> >  
> > -	offset = LOWPAN_FRAG_SIZE;
> > +	offset = lowpan_size + frag_plen;
> > +	dgram_offset = mac_cb(skb)->frag_info.d_offset + frag_plen;
> 
> This isn't going to work.
> 
> Once you call dev_queue_xmit(), the skb control block can be reused by
> other layers.  In particular the device qdisc layer is going to
> scramble the control block on you.
> 
> Once a packet travels from one layer to another, SKB control block
> is likewise transferred.

thanks for your reply. If I understand it correctly so I can't be sure
that some other layer overwrites my skb control block with others
information.

In this case I can be sure we talking with ARPHRD_IEEE802154 devices only.
Which means I know that ARPHRD_IEEE802154 mac layer doesn't overwrites the
control block. Btw. at the moment the whole ieee802154 6lowpan implementation
is working on ARPHRD_IEEE802154 devices only, because the mac layer sets
many control block information for the upper layer. That's why we added
a check on this, see [1]. Simple put "The mac802154 layer and 6lowpan
layer share the same control block structure to make some 'layer
communication'".

The upper layer (6lowpan) use these information in control block which
is set by mac802154 layer. So we have a similar issue there.
The whole implementation is working only because the mac802154 and
6lowpan implementation share the control block information. A more
"correct" solution would be to drop the control block information and
evaluate the mac layer in 6lowpan also.

But you are right, that's a ugly solution. Anyway I can get the
mac_cb(skb)->frag_info.d_offset value when I evaluate the 6lowpan header
there aswell. So I will add a little helper function to get this information
and drop the unecessary information in mac_cb there.

Thanks.

- Alex

[1] http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/tree/net/ieee802154/6lowpan.c#n662
--
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