| Message ID | 1368987211-19826-1-git-send-email-david@hauweele.net |
|---|---|
| State | Changes Requested, archived |
| Delegated to: | David Miller |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <alex.aring@gmail.com>: > 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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <alex.aring@gmail.com>: > > 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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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;
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 <david@hauweele.net> --- net/ieee802154/6lowpan.c | 7 +++++++ 1 file changed, 7 insertions(+)