When a new 6lowpan fragment is received, a skbuff is allocated for
the reassembled packet. However when a 6lowpan packet compresses
link-local addresses based on link-layer addresses, the processing
function relies on the skb mac control block to find the related
link-layer address.
This patch copies the control block from the first fragment into
the newly allocated skb to keep a trace of the link-layer addresses
in case of a link-local compressed address.
Signed-off-by: David Hauweele <[email protected]>
---
net/ieee802154/6lowpan.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 55e1fd5..d9a41e2 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -702,6 +702,13 @@ lowpan_alloc_new_frame(struct sk_buff *skb, u16 len, u16 tag)
skb_reserve(frame->skb, sizeof(struct ipv6hdr));
skb_put(frame->skb, frame->length);
+ /*
+ * copy the first control block to keep a
+ * trace of the link-layer addresses in case
+ * of a link-local compressed address
+ */
+ memcpy(frame->skb->cb, skb->cb, sizeof(skb->cb));
+
init_timer(&frame->timer);
/* time out is the same as for ipv6 - 60 sec */
frame->timer.expires = jiffies + LOWPAN_FRAG_TIMEOUT;
--
1.7.10.4
Hi David,
can you use a link-layer address on the current net-next kernel?
I am asking because I can't use a link-layer address currently.
Your patch doesn't help to solve my problem with link-layer addresses.
To your patch:
We get the link-layer addresses from skb not from the allocated
frame->skb.
Here is the code:
_saddr = mac_cb(skb)->sa.hwaddr;
_daddr = mac_cb(skb)->da.hwaddr;
Here is skb != frame->skb so we don't need to copy it to frame->skb->cb
because we already the link-layer addresses from skb->cb.
Is there another place in the code where we get the link-layer addresses
from allocated "frame" structure?
Regards
Alex
Hello,
There is a patch which fixes link-local address uncompression:
http://permalink.gmane.org/gmane.linux.network.zigbee.devel/1717
I came across a similar solution but didn't submit it as another patch
already existed.
This patch instead focus on fragmented packet with link-local address
compression,
which is related but a different bug.
2013/5/19 Alexander Aring <[email protected]>:
> Hi David,
>
> can you use a link-layer address on the current net-next kernel?
>
> I am asking because I can't use a link-layer address currently.
> Your patch doesn't help to solve my problem with link-layer addresses.
>
>
> To your patch:
>
> We get the link-layer addresses from skb not from the allocated
> frame->skb.
>
> Here is the code:
>
> _saddr = mac_cb(skb)->sa.hwaddr;
> _daddr = mac_cb(skb)->da.hwaddr;
>
> Here is skb != frame->skb so we don't need to copy it to frame->skb->cb
> because we already the link-layer addresses from skb->cb.
>
> Is there another place in the code where we get the link-layer addresses
> from allocated "frame" structure?
frame->skb is used to reassemble the 6lowpan packet when new fragments
are received.
This is the 'fragments assembling' switch at the beginning of
lowpan_process_data().
It will reassemble fragments until the packet is successfully reassembled.
Once it is, skb is replaced:
dev_kfree_skb(skb);
skb = frame->skb;
kfree(frame);
And the process continues as with other 6lowpan packets.
In particular:
_saddr = mac_cb(skb)->sa.hwaddr;
_daddr = mac_cb(skb)->da.hwaddr;
Several lines later there are:
err = lowpan_uncompress_addr(skb, &hdr.saddr, lowpan_llprefix,
lowpan_unc_llconf[tmp], skb->data);
err = lowpan_uncompress_addr(skb, &hdr.daddr, lowpan_llprefix,
lowpan_unc_llconf[tmp], skb->data);
These two lines should use _saddr/_daddr instead of skb->data, which
fixes the link-local address uncompression.
I'm able to use link-layer addresses with these two patches and it works well.
>
> Regards
> Alex
Regards,
David
Hi David,
I will try to figure out why link-layer address doesn't work on my
setup.
On Mon, May 20, 2013 at 12:14:48AM +0200, David Hauweele wrote:
> Hello,
>
> There is a patch which fixes link-local address uncompression:
>
> http://permalink.gmane.org/gmane.linux.network.zigbee.devel/1717
>
> I came across a similar solution but didn't submit it as another patch
> already existed.
> This patch instead focus on fragmented packet with link-local address
> compression,
> which is related but a different bug.
>
> 2013/5/19 Alexander Aring <[email protected]>:
> > Hi David,
> >
> > can you use a link-layer address on the current net-next kernel?
> >
> > I am asking because I can't use a link-layer address currently.
> > Your patch doesn't help to solve my problem with link-layer addresses.
> >
> >
> > To your patch:
> >
> > We get the link-layer addresses from skb not from the allocated
> > frame->skb.
> >
> > Here is the code:
> >
> > _saddr = mac_cb(skb)->sa.hwaddr;
> > _daddr = mac_cb(skb)->da.hwaddr;
> >
> > Here is skb != frame->skb so we don't need to copy it to frame->skb->cb
> > because we already the link-layer addresses from skb->cb.
> >
> > Is there another place in the code where we get the link-layer addresses
> > from allocated "frame" structure?
>
> frame->skb is used to reassemble the 6lowpan packet when new fragments
> are received.
> This is the 'fragments assembling' switch at the beginning of
> lowpan_process_data().
> It will reassemble fragments until the packet is successfully reassembled.
> Once it is, skb is replaced:
>
> dev_kfree_skb(skb);
> skb = frame->skb;
> kfree(frame);
>
ah ok.
> And the process continues as with other 6lowpan packets.
>
> In particular:
>
> _saddr = mac_cb(skb)->sa.hwaddr;
> _daddr = mac_cb(skb)->da.hwaddr;
>
> Several lines later there are:
>
> err = lowpan_uncompress_addr(skb, &hdr.saddr, lowpan_llprefix,
> lowpan_unc_llconf[tmp], skb->data);
> err = lowpan_uncompress_addr(skb, &hdr.daddr, lowpan_llprefix,
> lowpan_unc_llconf[tmp], skb->data);
I think you mean uncompress and compress here.
>
> These two lines should use _saddr/_daddr instead of skb->data, which
I agree with that.
Regards
Alex