Re: [PATCH net-next 3/4] 6lowpan: the two bytes of u16 tag needs to be stored/accessed the other way around
From: Alexander Smirnov <hidden>
Date: 2012-06-12 18:07:12
2012/6/11 Tony Cheneau [off-list ref]:
quoted hunk ↗ jump to hunk
Or else, tag values, as displayed with a trafic analyser, such a Wireshark, are not properly displayed (e.g. 0x01 00 insted of 0x00 01, and so on). --- net/ieee802154/6lowpan.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c index af4f29b..af2f12e 100644 --- a/net/ieee802154/6lowpan.c +++ b/net/ieee802154/6lowpan.c@@ -307,7 +307,7 @@ static u16 lowpan_fetch_skb_u16(struct sk_buff *skb)BUG_ON(!pskb_may_pull(skb, 2)); - ret = skb->data[0] | (skb->data[1] << 8); + ret = (skb->data[0] << 8) | skb->data[1];
This function aimed to obtain u16 from skb, why did you change the byte-order here instead of 'tag' variable byte-shifting? Will this code work properly on the both little and big-endian machines? Please rework this to keep order properly for all the architectures.
quoted hunk ↗ jump to hunk
skb_pull(skb, 2); return ret; }@@ -1002,8 +1002,8 @@ lowpan_skb_fragmentation(struct sk_buff *skb)/* first fragment header */ head[0] = LOWPAN_DISPATCH_FRAG1 | (payload_length & 0x7); head[1] = (payload_length >> 3) & 0xff; - head[2] = tag & 0xff; - head[3] = tag >> 8; + head[2] = tag >> 8; + head[3] = tag & 0xff; err = lowpan_fragment_xmit(skb, head, header_length, 0, 0); -- 1.7.3.4
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/