Re: [Linux-zigbee-devel] [PATCH 3/5] 6lowpan: use _saddr and _daddr instead of skb data
Hi Ralph,
thanks for your reply.
On Fri, Jul 12, 2013 at 12:40:49PM +, Ralph Droms (rdroms) wrote:
>
> On Jul 12, 2013, at 7:33 AM 7/12/13, Alexander Aring
> wrote:
>
> > Pointers _saddr and _daddr points to source and destination address.
> > Use this for a link-layer compression to get these addresses.
> >
> > Signed-off-by: Alexander Aring
> > ---
> > net/ieee802154/6lowpan.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
> > index 4f35d9a..ec4bf29 100644
> > --- a/net/ieee802154/6lowpan.c
> > +++ b/net/ieee802154/6lowpan.c
> > @@ -919,7 +919,7 @@ lowpan_process_data(struct sk_buff *skb)
> > /* Source address uncompression */
> > pr_debug("source address stateless compression\n");
> > err = lowpan_uncompress_addr(skb, &hdr.saddr, lowpan_llprefix,
> > - lowpan_unc_llconf[tmp], skb->data);
> > + lowpan_unc_llconf[tmp], _saddr);
> > if (err)
> > goto drop;
> >
> > @@ -948,7 +948,7 @@ lowpan_process_data(struct sk_buff *skb)
> > } else {
> > pr_debug("dest: stateless compression\n");
> > err = lowpan_uncompress_addr(skb, &hdr.daddr, lowpan_llprefix,
> > - lowpan_unc_llconf[tmp], skb->data);
> > + lowpan_unc_llconf[tmp], _daddr);
> > if (err)
> > goto drop;
> > }
> > --
> > 1.8.3.2
> >
>
> Working from memory, this fix looks correct.
>
> As a heads up, check out the fragment reassembly code, which (if I recall
> correctly) needs to be fixed to copy _daddr and _saddr from th first fragment
> into the reassembly buffer.
>
yeah, I know what you mean. There was also a patch on this ml for that.
I will add this to the patch series, you will see.
> Also working from memory - sorry, I don't have easy access to the latest
> commits to net-next - you might want to consider a couple of comment fixes
> and renaming llconf for consistency with what the code is doing:
It's very hard to find out what the code is doing.. They do some information
in a Byte array for how long is the inline prefix and inline postfix data.
I have rewrite this function for stateless(without context based information)
iphc headers at the moment.
In the current code the CID inline data is never evaluate. I think context based
information is currently not supported(I write some patch to add some warnings
for that case if CID, SAC and DAC bit is set).
Regards
Alex
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [PATCH 3/5] 6lowpan: use _saddr and _daddr instead of skb data
On Jul 15, 2013, at 9:27 AM 7/15/13, Alexander Aring
wrote:
> Hi Ralph,
>
> thanks for your reply.
You're welcome, and thanks for your followup...
>
> On Fri, Jul 12, 2013 at 12:40:49PM +, Ralph Droms (rdroms) wrote:
>>
>> On Jul 12, 2013, at 7:33 AM 7/12/13, Alexander Aring
>> wrote:
>>
>>> Pointers _saddr and _daddr points to source and destination address.
>>> Use this for a link-layer compression to get these addresses.
>>>
>>> Signed-off-by: Alexander Aring
>>> ---
>>> net/ieee802154/6lowpan.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
>>> index 4f35d9a..ec4bf29 100644
>>> --- a/net/ieee802154/6lowpan.c
>>> +++ b/net/ieee802154/6lowpan.c
>>> @@ -919,7 +919,7 @@ lowpan_process_data(struct sk_buff *skb)
>>> /* Source address uncompression */
>>> pr_debug("source address stateless compression\n");
>>> err = lowpan_uncompress_addr(skb, &hdr.saddr, lowpan_llprefix,
>>> - lowpan_unc_llconf[tmp], skb->data);
>>> + lowpan_unc_llconf[tmp], _saddr);
>>> if (err)
>>> goto drop;
>>>
>>> @@ -948,7 +948,7 @@ lowpan_process_data(struct sk_buff *skb)
>>> } else {
>>> pr_debug("dest: stateless compression\n");
>>> err = lowpan_uncompress_addr(skb, &hdr.daddr, lowpan_llprefix,
>>> - lowpan_unc_llconf[tmp], skb->data);
>>> + lowpan_unc_llconf[tmp], _daddr);
>>> if (err)
>>> goto drop;
>>> }
>>> --
>>> 1.8.3.2
>>>
>>
>> Working from memory, this fix looks correct.
>>
>> As a heads up, check out the fragment reassembly code, which (if I recall
>> correctly) needs to be fixed to copy _daddr and _saddr from th first
>> fragment into the reassembly buffer.
>>
> yeah, I know what you mean. There was also a patch on this ml for that.
> I will add this to the patch series, you will see.
OK, I'll review that patch.
>
>> Also working from memory - sorry, I don't have easy access to the latest
>> commits to net-next - you might want to consider a couple of comment fixes
>> and renaming llconf for consistency with what the code is doing:
>
> It's very hard to find out what the code is doing.. They do some information
> in a Byte array for how long is the inline prefix and inline postfix data.
Right. And there is some additional special-casing, including (again, assuming
I'm recalling the details correctly) using 0 to represent 16. It's an
interesting observation that the various decompression mechanisms share the
construct of copying a prefix from somewhere, (optional) zero-fill and copying
an IID from somewhere. However, I found the resulting code somewhat opaque.
> I have rewrite this function for stateless(without context based information)
> iphc headers at the moment.
I wrote equivalent code for a different stack using a couple of switch
statements, with explicit code for each combination of SAC/SAM and M/DAC/DAM,
along with comments extracted from RFC 6282. Might not be quite as compact or
efficient but I found it clearer.
> In the current code the CID inline data is never evaluate. I think context
> based
> information is currently not supported(I write some patch to add some warnings
> for that case if CID, SAC and DAC bit is set).
The use of context-based compression and decompression seems to be "future
work". I don't recall any explicit API for setting CIDs that would be used in
compression/decompression. There may be a specification for an implicit
context 0 derived from a global prefix distributed by RPL. In any event, what
you've done to add warnings about context-based compression in a received
datagram and leave the implementation for later seems right to me for now.
>
> Regards
> Alex
- Ralph
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [PATCH 7/7] 6lowpan: lowpan_uncompress_addr with address_mode
I haven't tested these patches but they look OK to me.
One editorial comment - s/layer_addr/macaddr/ or s/layer_addr/lladdr/ with a
comment that lladdr stands for "link-layer address"
- Ralph
On Jul 14, 2013, at 7:29 PM 7/14/13, Alexander Aring
wrote:
> This patch drop the pre and postcount calculation from the
> lowpan_uncompress_addr function.
>
> We use instead a switch case over address_mode value, it's easier
> to understand what's going on there.
>
> Signed-off-by: Alexander Aring
> ---
> net/ieee802154/6lowpan.c | 123 ++-
> net/ieee802154/6lowpan.h | 8 +--
> 2 files changed, 62 insertions(+), 69 deletions(-)
>
> diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
> index 14e29d8..84f05c4 100644
> --- a/net/ieee802154/6lowpan.c
> +++ b/net/ieee802154/6lowpan.c
> @@ -67,30 +67,6 @@ static const u8 lowpan_ttl_values[] = {0, 1, 64, 255};
>
> static LIST_HEAD(lowpan_devices);
>
> -/*
> - * Uncompression of linklocal:
> - * 0 -> 16 bytes from packet
> - * 1 -> 2 bytes from prefix - bunch of zeroes and 8 from packet
> - * 2 -> 2 bytes from prefix - zeroes + 2 from packet
> - * 3 -> 2 bytes from prefix - infer 8 bytes from lladdr
> - *
> - * NOTE: => the uncompress function does change 0xf to 0x10
> - * NOTE: 0x00 => no-autoconfig => unspecified
> - */
> -static const u8 lowpan_unc_llconf[] = {0x0f, 0x28, 0x22, 0x20};
> -
> -/*
> - * Uncompression of ctx-based:
> - * 0 -> 0 bits from packet [unspecified / reserved]
> - * 1 -> 8 bytes from prefix - bunch of zeroes and 8 from packet
> - * 2 -> 8 bytes from prefix - zeroes + 2 from packet
> - * 3 -> 8 bytes from prefix - infer 8 bytes from lladdr
> - */
> -static const u8 lowpan_unc_ctxconf[] = {0x00, 0x88, 0x82, 0x80};
> -
> -/* Link local prefix */
> -static const u8 lowpan_llprefix[] = {0xfe, 0x80};
> -
> /* private device info */
> struct lowpan_dev_info {
> struct net_device *real_dev; /* real WPAN device ptr */
> @@ -182,50 +158,67 @@ lowpan_compress_addr_64(u8 **hc06_ptr, u8 shift, const
> struct in6_addr *ipaddr,
> return rol8(val, shift);
> }
>
> -static void
> -lowpan_uip_ds6_set_addr_iid(struct in6_addr *ipaddr, unsigned char *lladdr)
> -{
> - memcpy(&ipaddr->s6_addr[8], lladdr, IEEE802154_ADDR_LEN);
> - /* second bit-flip (Universe/Local) is done according RFC2464 */
> - ipaddr->s6_addr[8] ^= 0x02;
> -}
> -
> /*
> - * Uncompress addresses based on a prefix and a postfix with zeroes in
> - * between. If the postfix is zero in length it will use the link address
> - * to configure the IP address (autoconf style).
> - * pref_post_count takes a byte where the first nibble specify prefix count
> - * and the second postfix count (NOTE: 15/0xf => 16 bytes copy).
> + * Uncompress address function for source and
> + * destination address(non-multicast).
> + *
> + * address_mode is sam value or dam value.
> */
> static int
> -lowpan_uncompress_addr(struct sk_buff *skb, struct in6_addr *ipaddr,
> - u8 const *prefix, u8 pref_post_count, unsigned char *lladdr)
> +lowpan_uncompress_addr(struct sk_buff *skb,
> + struct in6_addr *ipaddr,
> + const u8 address_mode,
> + const u8 *layer_addr)
> {
> - u8 prefcount = pref_post_count >> 4;
> - u8 postcount = pref_post_count & 0x0f;
> -
> - /* full nibble 15 => 16 */
> - prefcount = (prefcount == 15 ? 16 : prefcount);
> - postcount = (postcount == 15 ? 16 : postcount);
> -
> - if (lladdr)
> - lowpan_raw_dump_inline(__func__, "linklocal address",
> - lladdr, IEEE802154_ADDR_LEN);
> - if (prefcount > 0)
> - memcpy(ipaddr, prefix, prefcount);
> -
> - if (postcount > 0) {
> - memcpy(&ipaddr->s6_addr[16 - postcount], skb->data, postcount);
> - skb_pull(skb, postcount);
> - } else if (prefcount > 0) {
> - if (lladdr == NULL)
> - return -EINVAL;
> -
> - /* no IID based configuration if no prefix and no data */
> - lowpan_uip_ds6_set_addr_iid(ipaddr, lladdr);
> + switch (address_mode) {
> + case LOWPAN_IPHC_ADDR_00:
> + /*
> + * for global link addresses
> + */
> + memcpy(ipaddr->s6_addr, skb->data, 16);
> + skb_pull(skb, 16);
> + break;
> + case LOWPAN_IPHC_ADDR_01:
> + /*
> + * fe:80:::::
> + */
> + memset(&ipaddr->s6_addr[0], 0xFE, 1);
> + memset(&ipaddr->s6_addr[1], 0x80, 1);
> + memcpy(&ipaddr->s6_addr[8], skb->data, 8);
> + skb_pull(skb, 8);
> + break;
> + case LOWPAN_IPHC_ADDR_02:
> + /*
> + * fe:80::ff:fe00:
> + */
> + memset(&ipaddr->s6_addr[0], 0xFE, 1);
> + memset(&ipaddr->s6_addr[1], 0x80, 1);
> +
Re: [Linux-zigbee-devel] [PATCH 6/7] 6lowpan: add function to uncompress multicast addr
I haven't tested these patches but they look OK to me, based on my experience
with similar code for a different stack.
- Ralph
On Jul 14, 2013, at 7:29 PM 7/14/13, Alexander Aring
wrote:
> Add function to uncompress multicast address.
> This function split the uncompress function for a multicast address
> in a seperate function.
>
> To uncompress a multicast address is different than a other
> non-multicasts addresses according to rfc6292.
>
> Signed-off-by: Alexander Aring
> ---
> net/ieee802154/6lowpan.c | 82 +---
> 1 file changed, 63 insertions(+), 19 deletions(-)
>
> diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
> index 569d541..14e29d8 100644
> --- a/net/ieee802154/6lowpan.c
> +++ b/net/ieee802154/6lowpan.c
> @@ -88,15 +88,6 @@ static const u8 lowpan_unc_llconf[] = {0x0f, 0x28, 0x22,
> 0x20};
> */
> static const u8 lowpan_unc_ctxconf[] = {0x00, 0x88, 0x82, 0x80};
>
> -/*
> - * Uncompression of ctx-base
> - * 0 -> 0 bits from packet
> - * 1 -> 2 bytes from prefix - bunch of zeroes 5 from packet
> - * 2 -> 2 bytes from prefix - zeroes + 3 from packet
> - * 3 -> 2 bytes from prefix - infer 1 bytes from lladdr
> - */
> -static const u8 lowpan_unc_mxconf[] = {0x0f, 0x25, 0x23, 0x21};
> -
> /* Link local prefix */
> static const u8 lowpan_llprefix[] = {0xfe, 0x80};
>
> @@ -240,6 +231,67 @@ lowpan_uncompress_addr(struct sk_buff *skb, struct
> in6_addr *ipaddr,
> return 0;
> }
>
> +/*
> + * Uncompress function for multicast destination address,
> + * when M bit is set.
> + */
> +static int
> +lowpan_uncompress_multicast_daddr(struct sk_buff *skb,
> + struct in6_addr *ipaddr,
> + const u8 dam)
> +{
> + switch (dam) {
> + case LOWPAN_IPHC_DAM_00:
> + /*
> + * 00: 128 bits. The full address
> + * is carried in-line.
> + */
> + memcpy(ipaddr->s6_addr, skb->data, 16);
> + skb_pull(skb, 16);
> + break;
> + case LOWPAN_IPHC_DAM_01:
> + /*
> + * 01: 48 bits. The address takes
> + * the form ffXX::00XX::.
> + */
> + memset(&ipaddr->s6_addr[0], 0xFF, 1);
> + memcpy(&ipaddr->s6_addr[1], skb->data, 1);
> + skb_pull(skb, 1);
> + memcpy(&ipaddr->s6_addr[11], skb->data, 5);
> + skb_pull(skb, 5);
> + break;
> + case LOWPAN_IPHC_DAM_10:
> + /*
> + * 10: 32 bits. The address takes
> + * the form ffXX::00XX:.
> + */
> + memset(&ipaddr->s6_addr[0], 0xFF, 1);
> + memcpy(&ipaddr->s6_addr[1], skb->data, 1);
> + skb_pull(skb, 1);
> + memcpy(&ipaddr->s6_addr[13], skb->data, 3);
> + skb_pull(skb, 3);
> + break;
> + case LOWPAN_IPHC_DAM_11:
> + /*
> + * 11: 8 bits. The address takes
> + * the form ff02::00XX.
> + */
> + memset(&ipaddr->s6_addr[0], 0xFF, 1);
> + memset(&ipaddr->s6_addr[1], 0x02, 1);
> + memcpy(&ipaddr->s6_addr[15], skb->data, 1);
> + skb_pull(skb, 1);
> + break;
> + default:
> + pr_debug("DAM value has a wrong value: 0x%x\n", dam);
> + return -EINVAL;
> + }
> +
> + pr_debug("Reconstructed ipv6 multicast addr is:\n");
> + lowpan_raw_dump_inline(NULL, NULL, ipaddr->s6_addr, 16);
> +
> + return 0;
> +}
> +
> static void
> lowpan_compress_udp_header(u8 **hc06_ptr, struct sk_buff *skb)
> {
> @@ -922,16 +974,8 @@ lowpan_process_data(struct sk_buff *skb)
> pr_debug("dest: context-based mcast compression\n");
> /* TODO: implement this */
> } else {
> - u8 prefix[] = {0xff, 0x02};
> -
> - pr_debug("dest: non context-based mcast compression\n");
> - if (0 < tmp && tmp < 3) {
> - if (lowpan_fetch_skb_u8(skb, &prefix[1]))
> - goto drop;
> - }
> -
> - err = lowpan_uncompress_addr(skb, &hdr.daddr, prefix,
> - lowpan_unc_mxconf[tmp], NULL);
> + err = lowpan_uncompress_multicast_daddr(
> + skb, &hdr.daddr, tmp);
> if (err)
> goto drop;
> }
> --
> 1.8.3.2
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id
Re: [Linux-zigbee-devel] [PATCH 7/7] 6lowpan: lowpan_uncompress_addr with address_mode
Hi Ralph, On Mon, Jul 15, 2013 at 10:18:35AM +, Ralph Droms (rdroms) wrote: > I haven't tested these patches but they look OK to me. > > One editorial comment - s/layer_addr/macaddr/ or s/layer_addr/lladdr/ with a > comment that lladdr stands for "link-layer address" > thanks for this hint. I will change it to lladdr because I read it several times in the source file. Regards Alex -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Announcing the first public release of SimpleRPL
Hi Werner, Thanks a lot for your email and your patches. I'm sorry it took me so long to reply. > Good news: I got it to talk to Contiki. While I'm not sure it's > working perfectly, a lot of things look right and pings between > the two systems pass nicely. This is a excellent news indeed! > I tried a two-node setup with a Contiki leaf and a Linux root, > and didn't experiment with any more complex topology. This is a very encouraging start. I'm working on a IEEE 802.15.4 PHY emulator. Once this is done, I should be able to build some complex topologies, mixing Contiki and Linux nodes. Also, are you sure that you meant to say "leaf" here? A leaf node in RPL is a node that implements a pretty limited subset of RPL. See Section 8.5 of RFC 6550 [1]. > There are two bugs left that complicate things. First, I had to > change the order of linker arguments to get RplIcmp to load > properly: > > > https://github.com/frtos-wpan/frtos-wpan/blob/master/patches/rplicmp-fix-shlib-dep.patch Applied. Thanks! Let me know if the commit message is OK with you [2]. If you find it easier/faster, please don't hesitate to send my a pull request next time. > The other bug seems to be in the Linux kernel: it assumes that an > ICMPv6 message is at least 8 bytes. The DODAG Information > Solicitation (DIS) Contiki sends is only 6 bytes, and I haven't > found anything in RFC 4443 and RFC 6550 that would disallow having > such a short ICMPv6 message. I agree with your interpretation of the RFC. It's a good catch. > The short RPL DIS is rejected by the kernel and thus never reaches > simpleRPL. simpleRPL eventually reveals its presence and the two > then start talking, but losing the DIS can delay node bringup > considerably (minutes if not hours instead of seconds). In my test environment setup, using KVM, the DIS seemed to work correctly. I'll have to investigate a bit more, after a few quick checks, it appears that a similar size limitation exists when sending ICMP packets (i.e. kernel would increase the size of DIS message before sending). > A tentative fix is here: > > https://github.com/wpwrak/ben-wpan-linux/commit/2532be747cc973b1a36f80bc773c6784ae9b0ffe This patch will cause some side effects. It seems that some other code relies on the union in the "struct icmp6hdr" (defined in uapi/linux/icmpv6.h) being filled correctly. I would need a refresher on the skb structure before I could improve your patch. > Thanks a lot for simpleRPL ! Thank you! Regards, Tony [1]: https://tools.ietf.org/html/rfc6550#section-8.5 [2]: https://github.com/tcheneau/RplIcmp/commit/8fd6125d82e30b4b5d92d0acaa2e2ff469e4cde4 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Announcing the first public release of SimpleRPL
On Mon, Jul 15, 2013 at 11:44 AM, Tony Cheneau wrote: > Hi Werner, > > Thanks a lot for your email and your patches. I'm sorry it took me so > long to reply. > >> Good news: I got it to talk to Contiki. While I'm not sure it's >> working perfectly, a lot of things look right and pings between >> the two systems pass nicely. > This is a excellent news indeed! I haven't tried running the code yet, but does it support routing between two network interfaces? For example could it route between 802.15.4 and Ethernet? That is one of the key features of the BATMAN implementation. BATMAN let you set up a wifi based mesh. You can connect any of those wifi mesh points with Ethernet and BATMAN will route over the Ethernet and assign it zero cost in the routing algorithm. The same model occurs in the 802.15.4. Suppose you had a whole building wired 802.15.4. Everything becomes one big subnet mesh. But now you add a 802.15.4/Ethernet router on each floor. Those Ethernet links can obviously save a lot of hops. Note that all of the 802.15.4 nodes make one big subnet. So those Ethernet jumps need to happen inside the RPL calculation otherwise you'd need to make one subnet per floor. -- Jon Smirl jonsm...@gmail.com -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Announcing the first public release of SimpleRPL
Hi Jon, [...] > I haven't tried running the code yet, but does it support routing > between two network interfaces? For example could it route between > 802.15.4 and Ethernet? That is one of the key features of the BATMAN > implementation. Yes, simpleRPL handle system with multiple network interfaces. I haven't tested a mix of IEEE 802.15.4 and Ethernet, but I don't see any reason why it would fail. I tested the two of link technologies independently, and I tested the multi-interface aspects using ethernet-only links (actually, it was my development platform). > BATMAN let you set up a wifi based mesh. You can connect any of those > wifi mesh points with Ethernet and BATMAN will route over the > Ethernet > and assign it zero cost in the routing algorithm. I used BATMAN a long time ago, and indeed, it was pretty straightforward to setup a network that would span over multiple network interfaces. SimpleRPL will not work in the way you describe (see more below), but RPL does encourage such a behavior. > The same model occurs in the 802.15.4. Suppose you had a whole > building wired 802.15.4. Everything becomes one big subnet mesh. But > now you add a 802.15.4/Ethernet router on each floor. Those Ethernet > links can obviously save a lot of hops. Note that all of the 802.15.4 > nodes make one big subnet. So those Ethernet jumps need to happen > inside the RPL calculation otherwise you'd need to make one subnet > per > floor. For the "calculation" part, each nodes computes a rank for its parent (depending on the objective function) in order to elect its preferred parent. Because simpleRPL can't obtain (yet) information from the underlying link layers (the linux kernel does not seem to export any indication on the link quality), the rank increase is fixed. This means that the path computation favors shorter paths. While this is OK for my own purpose, I can understand it could be an issue to some. For the case you indicated (mixing 15.4 and Ethernet), the fact that simpleRPL does not properly handle rank increases would mean that an ethernet link will always not be favored to a 15.4. I hope it answers you question. Regards, Tony -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Announcing the first public release of SimpleRPL
On Mon, Jul 15, 2013 at 1:24 PM, Tony Cheneau wrote: > Hi Jon, > > [...] > > >> I haven't tried running the code yet, but does it support routing >> between two network interfaces? For example could it route between >> 802.15.4 and Ethernet? That is one of the key features of the BATMAN >> implementation. > > Yes, simpleRPL handle system with multiple network interfaces. I haven't > tested a mix of IEEE 802.15.4 and Ethernet, but I don't see any reason why > it would fail. I tested the two of link technologies independently, and I > tested the multi-interface aspects using ethernet-only links (actually, it > was my development platform). One issue is six byte versus eight byte MAC addresses. I believe there is a Linux API that lets you determine the link type but it has been too long since I have used it. It will return ARPHRD_IEEE802154 or ARPHRD_IEEE802 (? for Ethernet), wifi ARPHRD_IEEE80211 > > >> BATMAN let you set up a wifi based mesh. You can connect any of those >> wifi mesh points with Ethernet and BATMAN will route over the Ethernet >> and assign it zero cost in the routing algorithm. > > I used BATMAN a long time ago, and indeed, it was pretty straightforward to > setup a network that would span over multiple network interfaces. SimpleRPL > will not work in the way you describe (see more below), but RPL does > encourage such a behavior. > > >> The same model occurs in the 802.15.4. Suppose you had a whole >> building wired 802.15.4. Everything becomes one big subnet mesh. But >> now you add a 802.15.4/Ethernet router on each floor. Those Ethernet >> links can obviously save a lot of hops. Note that all of the 802.15.4 >> nodes make one big subnet. So those Ethernet jumps need to happen >> inside the RPL calculation otherwise you'd need to make one subnet per >> floor. > > For the "calculation" part, each nodes computes a rank for its parent > (depending on the objective function) in order to elect its preferred > parent. Because simpleRPL can't obtain (yet) information from the underlying > link layers (the linux kernel does not seem to export any indication on the > link quality), the rank increase is fixed. This means that the path > computation favors shorter paths. While this is OK for my own purpose, I can > understand it could be an issue to some. For the case you indicated (mixing > 15.4 and Ethernet), the fact that simpleRPL does not properly handle rank > increases would mean that an ethernet link will always not be favored to a > 15.4. > > I hope it answers you question. > > Regards, > Tony -- Jon Smirl jonsm...@gmail.com -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] Announcing the first public release of SimpleRPL
>> Yes, simpleRPL handle system with multiple network interfaces. I >> haven't >> tested a mix of IEEE 802.15.4 and Ethernet, but I don't see any >> reason why >> it would fail. I tested the two of link technologies independently, >> and I >> tested the multi-interface aspects using ethernet-only links >> (actually, it >> was my development platform). > > One issue is six byte versus eight byte MAC addresses. It should not be an issue. RPL works at the IP layer. Hence, it's layer 2 agnostic. Or did I missed something? > I believe there is a Linux API that lets you determine the link type > but it has been too long since I have used it. It will return > ARPHRD_IEEE802154 or ARPHRD_IEEE802 (? for Ethernet), wifi > ARPHRD_IEEE80211 Regards, Tony -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [PATCH 3/5] 6lowpan: use _saddr and _daddr instead of skb data
Hi Ralph, thanks for your reply. > > Right. And there is some additional special-casing, including (again, > assuming I'm recalling the details correctly) using 0 to represent 16. It's > an interesting observation that the various decompression mechanisms share > the construct of copying a prefix from somewhere, (optional) zero-fill and > copying an IID from somewhere. However, I found the resulting code somewhat > opaque. > Another point is the case is SAM = 10b or DAM = 10b and M = 0. This case need a uncrompression to a address: fe:80::ff:fe00: and the current function don't set the ff:fe bits. It need a special handle in this function, but then we can't use the function for a multicast uncompression because a multicast address don't set these bits. We need something like (!lladdr && address_mode == 2) which !lladdr identifier that is currently a non-multicast uncompression. This looks very awful :( grml... It's very hard to hold this current idea with the pre and post array information Alex -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 10/11] 6lowpan: add warning for DAC bit
We don't handle the DAC bit currently, so I add a warning and drop the
package.
Signed-off-by: Alexander Aring
---
net/ieee802154/6lowpan.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 7062dad..80f6f7b 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -967,22 +967,24 @@ lowpan_process_data(struct sk_buff *skb)
/* Extract DAM to the tmp variable */
tmp = ((iphc1 & LOWPAN_IPHC_DAM_11) >> LOWPAN_IPHC_DAM_BIT) & 0x03;
- /* check for Multicast Compression */
- if (iphc1 & LOWPAN_IPHC_M) {
- if (iphc1 & LOWPAN_IPHC_DAC) {
- pr_debug("dest: context-based mcast compression\n");
- /* TODO: implement this */
- } else {
+ if (iphc1 & LOWPAN_IPHC_DAC) {
+ /* TODO: implement this */
+ netdev_warn(skb->dev, "DAC bit is set. Context-based not
implemented. Drop packet.\n");
+ goto drop;
+ } else {
+ /* check for Multicast Compression */
+ if (iphc1 & LOWPAN_IPHC_M) {
err = lowpan_uncompress_multicast_daddr(
skb, &hdr.daddr, tmp);
if (err)
goto drop;
+ } else {
+ pr_debug("dest: stateless compression\n");
+ err = lowpan_uncompress_addr(
+ skb, &hdr.daddr, tmp, _daddr);
+ if (err)
+ goto drop;
}
- } else {
- pr_debug("dest: stateless compression\n");
- err = lowpan_uncompress_addr(skb, &hdr.daddr, tmp, _daddr);
- if (err)
- goto drop;
}
/* UDP data uncompression */
--
1.8.3.2
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 03/11] 6lowpan: init 6lowpan header and ipv6hdr to zero
When we set it to zero, we can assume that the memory is already zero
while parsing.
Signed-off-by: Alexander Aring
---
net/ieee802154/6lowpan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 8e0fbb8..fd0a5bc 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -387,7 +387,7 @@ static int lowpan_header_create(struct sk_buff *skb,
struct ipv6hdr *hdr;
const u8 *saddr = _saddr;
const u8 *daddr = _daddr;
- u8 head[100];
+ u8 head[100] = {};
struct ieee802154_addr sa, da;
/* TODO:
@@ -723,7 +723,7 @@ frame_err:
static int
lowpan_process_data(struct sk_buff *skb)
{
- struct ipv6hdr hdr;
+ struct ipv6hdr hdr = {};
u8 tmp, iphc0, iphc1, num_context = 0;
u8 *_saddr, *_daddr;
int err;
--
1.8.3.2
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCHv3 00/11] minor fixes.
Version 3 of my patch series for the 6lowpan stack. There is also a known issue with the payload length on fragmentation which don't fix this series. I am working on it... v3: - add David Hauweele patch to fix fragmentation with link-local compressed addresses - add warnings for CID and DAC bit - handle SAC bit to :: address - rename layer_addr to lladdr in function lowpan_uncompress_addr v2: - add patch to add uncompress multicast addresses - add patch for new uncompress address function Alexander Aring (10): 6lowpan: fix small comment issue 6lowpan: fix return value with comment operator 6lowpan: init 6lowpan header and ipv6hdr to zero 6lowpan: remove setting some memory regions to zero 6lowpan: use _saddr and _daddr instead of skb data 6lowpan: add function to uncompress multicast addr 6lowpan: lowpan_uncompress_addr with address_mode 6lowpan: add warning for CID bit 6lowpan: add warning for DAC bit 6lowpan: handle SAC bit to :: address David Hauweele (1): 6lowpan: Fix fragmentation with link-local compressed addresses net/ieee802154/6lowpan.c | 268 +++ net/ieee802154/6lowpan.h | 8 +- 2 files changed, 159 insertions(+), 117 deletions(-) -- 1.8.3.2 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 09/11] 6lowpan: add warning for CID bit
We don't handle the CID bit currently, so I add a warning and drop the
package.
Signed-off-by: Alexander Aring
---
net/ieee802154/6lowpan.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 51fb55c..7062dad 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -772,7 +772,7 @@ static int
lowpan_process_data(struct sk_buff *skb)
{
struct ipv6hdr hdr = {};
- u8 tmp, iphc0, iphc1, num_context = 0;
+ u8 tmp, iphc0, iphc1;
u8 *_saddr, *_daddr;
int err;
@@ -884,9 +884,9 @@ lowpan_process_data(struct sk_buff *skb)
/* another if the CID flag is set */
if (iphc1 & LOWPAN_IPHC_CID) {
- pr_debug("CID flag is set, increase header with one\n");
- if (lowpan_fetch_skb_u8(skb, &num_context))
- goto drop;
+ /* TODO: implement this */
+ netdev_warn(skb->dev, "CID bit is set. Context-based not
implemented. Drop packet.\n");
+ goto drop;
}
hdr.version = 6;
--
1.8.3.2
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 02/11] 6lowpan: fix return value with comment operator
Signed-off-by: Alexander Aring --- net/ieee802154/6lowpan.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c index 1ec14ef..8e0fbb8 100644 --- a/net/ieee802154/6lowpan.c +++ b/net/ieee802154/6lowpan.c @@ -819,7 +819,8 @@ lowpan_process_data(struct sk_buff *skb) } spin_unlock_bh(&flist_lock); - return kfree_skb(skb), 0; + kfree_skb(skb); + return 0; } default: break; -- 1.8.3.2 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 05/11] 6lowpan: Fix fragmentation with link-local compressed addresses
From: David Hauweele 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 Signed-off-by: Alexander Aring --- net/ieee802154/6lowpan.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c index f3406dac..d503c61 100644 --- a/net/ieee802154/6lowpan.c +++ b/net/ieee802154/6lowpan.c @@ -698,6 +698,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.8.3.2 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 08/11] 6lowpan: lowpan_uncompress_addr with address_mode
This patch drop the pre and postcount calculation from the
lowpan_uncompress_addr function.
We use instead a switch case over address_mode value, it's easier
to understand what's going on there.
Signed-off-by: Alexander Aring
---
net/ieee802154/6lowpan.c | 123 ++-
net/ieee802154/6lowpan.h | 8 +--
2 files changed, 62 insertions(+), 69 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index f46c2fb..51fb55c 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -67,30 +67,6 @@ static const u8 lowpan_ttl_values[] = {0, 1, 64, 255};
static LIST_HEAD(lowpan_devices);
-/*
- * Uncompression of linklocal:
- * 0 -> 16 bytes from packet
- * 1 -> 2 bytes from prefix - bunch of zeroes and 8 from packet
- * 2 -> 2 bytes from prefix - zeroes + 2 from packet
- * 3 -> 2 bytes from prefix - infer 8 bytes from lladdr
- *
- * NOTE: => the uncompress function does change 0xf to 0x10
- * NOTE: 0x00 => no-autoconfig => unspecified
- */
-static const u8 lowpan_unc_llconf[] = {0x0f, 0x28, 0x22, 0x20};
-
-/*
- * Uncompression of ctx-based:
- * 0 -> 0 bits from packet [unspecified / reserved]
- * 1 -> 8 bytes from prefix - bunch of zeroes and 8 from packet
- * 2 -> 8 bytes from prefix - zeroes + 2 from packet
- * 3 -> 8 bytes from prefix - infer 8 bytes from lladdr
- */
-static const u8 lowpan_unc_ctxconf[] = {0x00, 0x88, 0x82, 0x80};
-
-/* Link local prefix */
-static const u8 lowpan_llprefix[] = {0xfe, 0x80};
-
/* private device info */
struct lowpan_dev_info {
struct net_device *real_dev; /* real WPAN device ptr */
@@ -182,50 +158,67 @@ lowpan_compress_addr_64(u8 **hc06_ptr, u8 shift, const
struct in6_addr *ipaddr,
return rol8(val, shift);
}
-static void
-lowpan_uip_ds6_set_addr_iid(struct in6_addr *ipaddr, unsigned char *lladdr)
-{
- memcpy(&ipaddr->s6_addr[8], lladdr, IEEE802154_ADDR_LEN);
- /* second bit-flip (Universe/Local) is done according RFC2464 */
- ipaddr->s6_addr[8] ^= 0x02;
-}
-
/*
- * Uncompress addresses based on a prefix and a postfix with zeroes in
- * between. If the postfix is zero in length it will use the link address
- * to configure the IP address (autoconf style).
- * pref_post_count takes a byte where the first nibble specify prefix count
- * and the second postfix count (NOTE: 15/0xf => 16 bytes copy).
+ * Uncompress address function for source and
+ * destination address(non-multicast).
+ *
+ * address_mode is sam value or dam value.
*/
static int
-lowpan_uncompress_addr(struct sk_buff *skb, struct in6_addr *ipaddr,
- u8 const *prefix, u8 pref_post_count, unsigned char *lladdr)
+lowpan_uncompress_addr(struct sk_buff *skb,
+ struct in6_addr *ipaddr,
+ const u8 address_mode,
+ const u8 *lladdr)
{
- u8 prefcount = pref_post_count >> 4;
- u8 postcount = pref_post_count & 0x0f;
-
- /* full nibble 15 => 16 */
- prefcount = (prefcount == 15 ? 16 : prefcount);
- postcount = (postcount == 15 ? 16 : postcount);
-
- if (lladdr)
- lowpan_raw_dump_inline(__func__, "linklocal address",
- lladdr, IEEE802154_ADDR_LEN);
- if (prefcount > 0)
- memcpy(ipaddr, prefix, prefcount);
-
- if (postcount > 0) {
- memcpy(&ipaddr->s6_addr[16 - postcount], skb->data, postcount);
- skb_pull(skb, postcount);
- } else if (prefcount > 0) {
- if (lladdr == NULL)
- return -EINVAL;
-
- /* no IID based configuration if no prefix and no data */
- lowpan_uip_ds6_set_addr_iid(ipaddr, lladdr);
+ switch (address_mode) {
+ case LOWPAN_IPHC_ADDR_00:
+ /*
+* for global link addresses
+*/
+ memcpy(ipaddr->s6_addr, skb->data, 16);
+ skb_pull(skb, 16);
+ break;
+ case LOWPAN_IPHC_ADDR_01:
+ /*
+* fe:80:::::
+*/
+ memset(&ipaddr->s6_addr[0], 0xFE, 1);
+ memset(&ipaddr->s6_addr[1], 0x80, 1);
+ memcpy(&ipaddr->s6_addr[8], skb->data, 8);
+ skb_pull(skb, 8);
+ break;
+ case LOWPAN_IPHC_ADDR_02:
+ /*
+* fe:80::ff:fe00:
+*/
+ memset(&ipaddr->s6_addr[0], 0xFE, 1);
+ memset(&ipaddr->s6_addr[1], 0x80, 1);
+ memset(&ipaddr->s6_addr[11], 0xFF, 1);
+ memset(&ipaddr->s6_addr[12], 0xFE, 1);
+ memcpy(&ipaddr->s6_addr[14], skb->data, 2);
+ skb_pull(skb, 2);
+ break;
+ case LOWPAN_IPHC_ADDR_03:
+ /*
+* fe:80:::::
+*\_/
+* lladdr
+
[Linux-zigbee-devel] [PATCH 07/11] 6lowpan: add function to uncompress multicast addr
Add function to uncompress multicast address.
This function split the uncompress function for a multicast address
in a seperate function.
To uncompress a multicast address is different than a other
non-multicasts addresses according to rfc6282.
Signed-off-by: Alexander Aring
---
net/ieee802154/6lowpan.c | 82 +---
1 file changed, 63 insertions(+), 19 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index fad517a..f46c2fb 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -88,15 +88,6 @@ static const u8 lowpan_unc_llconf[] = {0x0f, 0x28, 0x22,
0x20};
*/
static const u8 lowpan_unc_ctxconf[] = {0x00, 0x88, 0x82, 0x80};
-/*
- * Uncompression of ctx-base
- * 0 -> 0 bits from packet
- * 1 -> 2 bytes from prefix - bunch of zeroes 5 from packet
- * 2 -> 2 bytes from prefix - zeroes + 3 from packet
- * 3 -> 2 bytes from prefix - infer 1 bytes from lladdr
- */
-static const u8 lowpan_unc_mxconf[] = {0x0f, 0x25, 0x23, 0x21};
-
/* Link local prefix */
static const u8 lowpan_llprefix[] = {0xfe, 0x80};
@@ -240,6 +231,67 @@ lowpan_uncompress_addr(struct sk_buff *skb, struct
in6_addr *ipaddr,
return 0;
}
+/*
+ * Uncompress function for multicast destination address,
+ * when M bit is set.
+ */
+static int
+lowpan_uncompress_multicast_daddr(struct sk_buff *skb,
+ struct in6_addr *ipaddr,
+ const u8 dam)
+{
+ switch (dam) {
+ case LOWPAN_IPHC_DAM_00:
+ /*
+* 00: 128 bits. The full address
+* is carried in-line.
+*/
+ memcpy(ipaddr->s6_addr, skb->data, 16);
+ skb_pull(skb, 16);
+ break;
+ case LOWPAN_IPHC_DAM_01:
+ /*
+* 01: 48 bits. The address takes
+* the form ffXX::00XX::.
+*/
+ memset(&ipaddr->s6_addr[0], 0xFF, 1);
+ memcpy(&ipaddr->s6_addr[1], skb->data, 1);
+ skb_pull(skb, 1);
+ memcpy(&ipaddr->s6_addr[11], skb->data, 5);
+ skb_pull(skb, 5);
+ break;
+ case LOWPAN_IPHC_DAM_10:
+ /*
+* 10: 32 bits. The address takes
+* the form ffXX::00XX:.
+*/
+ memset(&ipaddr->s6_addr[0], 0xFF, 1);
+ memcpy(&ipaddr->s6_addr[1], skb->data, 1);
+ skb_pull(skb, 1);
+ memcpy(&ipaddr->s6_addr[13], skb->data, 3);
+ skb_pull(skb, 3);
+ break;
+ case LOWPAN_IPHC_DAM_11:
+ /*
+* 11: 8 bits. The address takes
+* the form ff02::00XX.
+*/
+ memset(&ipaddr->s6_addr[0], 0xFF, 1);
+ memset(&ipaddr->s6_addr[1], 0x02, 1);
+ memcpy(&ipaddr->s6_addr[15], skb->data, 1);
+ skb_pull(skb, 1);
+ break;
+ default:
+ pr_debug("DAM value has a wrong value: 0x%x\n", dam);
+ return -EINVAL;
+ }
+
+ pr_debug("Reconstructed ipv6 multicast addr is:\n");
+ lowpan_raw_dump_inline(NULL, NULL, ipaddr->s6_addr, 16);
+
+ return 0;
+}
+
static void
lowpan_compress_udp_header(u8 **hc06_ptr, struct sk_buff *skb)
{
@@ -929,16 +981,8 @@ lowpan_process_data(struct sk_buff *skb)
pr_debug("dest: context-based mcast compression\n");
/* TODO: implement this */
} else {
- u8 prefix[] = {0xff, 0x02};
-
- pr_debug("dest: non context-based mcast compression\n");
- if (0 < tmp && tmp < 3) {
- if (lowpan_fetch_skb_u8(skb, &prefix[1]))
- goto drop;
- }
-
- err = lowpan_uncompress_addr(skb, &hdr.daddr, prefix,
- lowpan_unc_mxconf[tmp], NULL);
+ err = lowpan_uncompress_multicast_daddr(
+ skb, &hdr.daddr, tmp);
if (err)
goto drop;
}
--
1.8.3.2
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 01/11] 6lowpan: fix small comment issue
Fix a little comment issue. Number 2 is 10 in bits and 1 is 01. Signed-off-by: Alexander Aring --- net/ieee802154/6lowpan.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c index 55e1fd5..1ec14ef 100644 --- a/net/ieee802154/6lowpan.c +++ b/net/ieee802154/6lowpan.c @@ -862,7 +862,7 @@ lowpan_process_data(struct sk_buff *skb) * Traffic class carried in-line * ECN + DSCP (1 byte), Flow Label is elided */ - case 1: /* 10b */ + case 1: /* 01b */ if (lowpan_fetch_skb_u8(skb, &tmp)) goto drop; @@ -875,7 +875,7 @@ lowpan_process_data(struct sk_buff *skb) * Flow Label carried in-line * ECN + 2-bit Pad + Flow Label (3 bytes), DSCP is elided */ - case 2: /* 01b */ + case 2: /* 10b */ if (lowpan_fetch_skb_u8(skb, &tmp)) goto drop; -- 1.8.3.2 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 11/11] 6lowpan: handle SAC bit to :: address
Some protocolls has a unspecific address as source address like
"Multicast Listener Report Message v2" or "Neighbor Soliciation"
decode the SAC bit as :: address.
The header create part set this bit when a :: address is used.
Signed-off-by: Alexander Aring
---
net/ieee802154/6lowpan.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 80f6f7b..197185c 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -958,11 +958,16 @@ lowpan_process_data(struct sk_buff *skb)
/* Extract SAM to the tmp variable */
tmp = ((iphc1 & LOWPAN_IPHC_SAM) >> LOWPAN_IPHC_SAM_BIT) & 0x03;
- /* Source address uncompression */
- pr_debug("source address stateless compression\n");
- err = lowpan_uncompress_addr(skb, &hdr.saddr, tmp, _saddr);
- if (err)
- goto drop;
+ if (iphc1 & LOWPAN_IPHC_SAC) {
+ /* TODO: implement this */
+ pr_debug("SAC bit is set. Set source address to: ::.\n");
+ } else {
+ /* Source address uncompression */
+ pr_debug("source address stateless compression\n");
+ err = lowpan_uncompress_addr(skb, &hdr.saddr, tmp, _saddr);
+ if (err)
+ goto drop;
+ }
/* Extract DAM to the tmp variable */
tmp = ((iphc1 & LOWPAN_IPHC_DAM_11) >> LOWPAN_IPHC_DAM_BIT) & 0x03;
--
1.8.3.2
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 09/11] 6lowpan: add warning for CID bit
We don't handle the CID bit currently, so I add a warning and drop the
package.
Signed-off-by: Alexander Aring
---
net/ieee802154/6lowpan.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 51fb55c..7062dad 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -772,7 +772,7 @@ static int
lowpan_process_data(struct sk_buff *skb)
{
struct ipv6hdr hdr = {};
- u8 tmp, iphc0, iphc1, num_context = 0;
+ u8 tmp, iphc0, iphc1;
u8 *_saddr, *_daddr;
int err;
@@ -884,9 +884,9 @@ lowpan_process_data(struct sk_buff *skb)
/* another if the CID flag is set */
if (iphc1 & LOWPAN_IPHC_CID) {
- pr_debug("CID flag is set, increase header with one\n");
- if (lowpan_fetch_skb_u8(skb, &num_context))
- goto drop;
+ /* TODO: implement this */
+ netdev_warn(skb->dev, "CID bit is set. Context-based not
implemented. Drop packet.\n");
+ goto drop;
}
hdr.version = 6;
--
1.8.3.2
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 07/11] 6lowpan: add function to uncompress multicast addr
Add function to uncompress multicast address.
This function split the uncompress function for a multicast address
in a seperate function.
To uncompress a multicast address is different than a other
non-multicasts addresses according to rfc6282.
Signed-off-by: Alexander Aring
---
net/ieee802154/6lowpan.c | 82 +---
1 file changed, 63 insertions(+), 19 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index fad517a..f46c2fb 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -88,15 +88,6 @@ static const u8 lowpan_unc_llconf[] = {0x0f, 0x28, 0x22,
0x20};
*/
static const u8 lowpan_unc_ctxconf[] = {0x00, 0x88, 0x82, 0x80};
-/*
- * Uncompression of ctx-base
- * 0 -> 0 bits from packet
- * 1 -> 2 bytes from prefix - bunch of zeroes 5 from packet
- * 2 -> 2 bytes from prefix - zeroes + 3 from packet
- * 3 -> 2 bytes from prefix - infer 1 bytes from lladdr
- */
-static const u8 lowpan_unc_mxconf[] = {0x0f, 0x25, 0x23, 0x21};
-
/* Link local prefix */
static const u8 lowpan_llprefix[] = {0xfe, 0x80};
@@ -240,6 +231,67 @@ lowpan_uncompress_addr(struct sk_buff *skb, struct
in6_addr *ipaddr,
return 0;
}
+/*
+ * Uncompress function for multicast destination address,
+ * when M bit is set.
+ */
+static int
+lowpan_uncompress_multicast_daddr(struct sk_buff *skb,
+ struct in6_addr *ipaddr,
+ const u8 dam)
+{
+ switch (dam) {
+ case LOWPAN_IPHC_DAM_00:
+ /*
+* 00: 128 bits. The full address
+* is carried in-line.
+*/
+ memcpy(ipaddr->s6_addr, skb->data, 16);
+ skb_pull(skb, 16);
+ break;
+ case LOWPAN_IPHC_DAM_01:
+ /*
+* 01: 48 bits. The address takes
+* the form ffXX::00XX::.
+*/
+ memset(&ipaddr->s6_addr[0], 0xFF, 1);
+ memcpy(&ipaddr->s6_addr[1], skb->data, 1);
+ skb_pull(skb, 1);
+ memcpy(&ipaddr->s6_addr[11], skb->data, 5);
+ skb_pull(skb, 5);
+ break;
+ case LOWPAN_IPHC_DAM_10:
+ /*
+* 10: 32 bits. The address takes
+* the form ffXX::00XX:.
+*/
+ memset(&ipaddr->s6_addr[0], 0xFF, 1);
+ memcpy(&ipaddr->s6_addr[1], skb->data, 1);
+ skb_pull(skb, 1);
+ memcpy(&ipaddr->s6_addr[13], skb->data, 3);
+ skb_pull(skb, 3);
+ break;
+ case LOWPAN_IPHC_DAM_11:
+ /*
+* 11: 8 bits. The address takes
+* the form ff02::00XX.
+*/
+ memset(&ipaddr->s6_addr[0], 0xFF, 1);
+ memset(&ipaddr->s6_addr[1], 0x02, 1);
+ memcpy(&ipaddr->s6_addr[15], skb->data, 1);
+ skb_pull(skb, 1);
+ break;
+ default:
+ pr_debug("DAM value has a wrong value: 0x%x\n", dam);
+ return -EINVAL;
+ }
+
+ pr_debug("Reconstructed ipv6 multicast addr is:\n");
+ lowpan_raw_dump_inline(NULL, NULL, ipaddr->s6_addr, 16);
+
+ return 0;
+}
+
static void
lowpan_compress_udp_header(u8 **hc06_ptr, struct sk_buff *skb)
{
@@ -929,16 +981,8 @@ lowpan_process_data(struct sk_buff *skb)
pr_debug("dest: context-based mcast compression\n");
/* TODO: implement this */
} else {
- u8 prefix[] = {0xff, 0x02};
-
- pr_debug("dest: non context-based mcast compression\n");
- if (0 < tmp && tmp < 3) {
- if (lowpan_fetch_skb_u8(skb, &prefix[1]))
- goto drop;
- }
-
- err = lowpan_uncompress_addr(skb, &hdr.daddr, prefix,
- lowpan_unc_mxconf[tmp], NULL);
+ err = lowpan_uncompress_multicast_daddr(
+ skb, &hdr.daddr, tmp);
if (err)
goto drop;
}
--
1.8.3.2
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 10/11] 6lowpan: add warning for DAC bit
We don't handle the DAC bit currently, so I add a warning and drop the
package.
Signed-off-by: Alexander Aring
---
net/ieee802154/6lowpan.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 7062dad..80f6f7b 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -967,22 +967,24 @@ lowpan_process_data(struct sk_buff *skb)
/* Extract DAM to the tmp variable */
tmp = ((iphc1 & LOWPAN_IPHC_DAM_11) >> LOWPAN_IPHC_DAM_BIT) & 0x03;
- /* check for Multicast Compression */
- if (iphc1 & LOWPAN_IPHC_M) {
- if (iphc1 & LOWPAN_IPHC_DAC) {
- pr_debug("dest: context-based mcast compression\n");
- /* TODO: implement this */
- } else {
+ if (iphc1 & LOWPAN_IPHC_DAC) {
+ /* TODO: implement this */
+ netdev_warn(skb->dev, "DAC bit is set. Context-based not
implemented. Drop packet.\n");
+ goto drop;
+ } else {
+ /* check for Multicast Compression */
+ if (iphc1 & LOWPAN_IPHC_M) {
err = lowpan_uncompress_multicast_daddr(
skb, &hdr.daddr, tmp);
if (err)
goto drop;
+ } else {
+ pr_debug("dest: stateless compression\n");
+ err = lowpan_uncompress_addr(
+ skb, &hdr.daddr, tmp, _daddr);
+ if (err)
+ goto drop;
}
- } else {
- pr_debug("dest: stateless compression\n");
- err = lowpan_uncompress_addr(skb, &hdr.daddr, tmp, _daddr);
- if (err)
- goto drop;
}
/* UDP data uncompression */
--
1.8.3.2
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 06/11] 6lowpan: use _saddr and _daddr instead of skb data
Pointers _saddr and _daddr points to source and destination address.
Use this for a link-layer compression to get these addresses.
Signed-off-by: Alexander Aring
---
net/ieee802154/6lowpan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index d503c61..fad517a 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -916,7 +916,7 @@ lowpan_process_data(struct sk_buff *skb)
/* Source address uncompression */
pr_debug("source address stateless compression\n");
err = lowpan_uncompress_addr(skb, &hdr.saddr, lowpan_llprefix,
- lowpan_unc_llconf[tmp], skb->data);
+ lowpan_unc_llconf[tmp], _saddr);
if (err)
goto drop;
@@ -945,7 +945,7 @@ lowpan_process_data(struct sk_buff *skb)
} else {
pr_debug("dest: stateless compression\n");
err = lowpan_uncompress_addr(skb, &hdr.daddr, lowpan_llprefix,
- lowpan_unc_llconf[tmp], skb->data);
+ lowpan_unc_llconf[tmp], _daddr);
if (err)
goto drop;
}
--
1.8.3.2
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 08/11] 6lowpan: lowpan_uncompress_addr with address_mode
This patch drop the pre and postcount calculation from the
lowpan_uncompress_addr function.
We use instead a switch case over address_mode value, it's easier
to understand what's going on there.
Signed-off-by: Alexander Aring
---
net/ieee802154/6lowpan.c | 123 ++-
net/ieee802154/6lowpan.h | 8 +--
2 files changed, 62 insertions(+), 69 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index f46c2fb..51fb55c 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -67,30 +67,6 @@ static const u8 lowpan_ttl_values[] = {0, 1, 64, 255};
static LIST_HEAD(lowpan_devices);
-/*
- * Uncompression of linklocal:
- * 0 -> 16 bytes from packet
- * 1 -> 2 bytes from prefix - bunch of zeroes and 8 from packet
- * 2 -> 2 bytes from prefix - zeroes + 2 from packet
- * 3 -> 2 bytes from prefix - infer 8 bytes from lladdr
- *
- * NOTE: => the uncompress function does change 0xf to 0x10
- * NOTE: 0x00 => no-autoconfig => unspecified
- */
-static const u8 lowpan_unc_llconf[] = {0x0f, 0x28, 0x22, 0x20};
-
-/*
- * Uncompression of ctx-based:
- * 0 -> 0 bits from packet [unspecified / reserved]
- * 1 -> 8 bytes from prefix - bunch of zeroes and 8 from packet
- * 2 -> 8 bytes from prefix - zeroes + 2 from packet
- * 3 -> 8 bytes from prefix - infer 8 bytes from lladdr
- */
-static const u8 lowpan_unc_ctxconf[] = {0x00, 0x88, 0x82, 0x80};
-
-/* Link local prefix */
-static const u8 lowpan_llprefix[] = {0xfe, 0x80};
-
/* private device info */
struct lowpan_dev_info {
struct net_device *real_dev; /* real WPAN device ptr */
@@ -182,50 +158,67 @@ lowpan_compress_addr_64(u8 **hc06_ptr, u8 shift, const
struct in6_addr *ipaddr,
return rol8(val, shift);
}
-static void
-lowpan_uip_ds6_set_addr_iid(struct in6_addr *ipaddr, unsigned char *lladdr)
-{
- memcpy(&ipaddr->s6_addr[8], lladdr, IEEE802154_ADDR_LEN);
- /* second bit-flip (Universe/Local) is done according RFC2464 */
- ipaddr->s6_addr[8] ^= 0x02;
-}
-
/*
- * Uncompress addresses based on a prefix and a postfix with zeroes in
- * between. If the postfix is zero in length it will use the link address
- * to configure the IP address (autoconf style).
- * pref_post_count takes a byte where the first nibble specify prefix count
- * and the second postfix count (NOTE: 15/0xf => 16 bytes copy).
+ * Uncompress address function for source and
+ * destination address(non-multicast).
+ *
+ * address_mode is sam value or dam value.
*/
static int
-lowpan_uncompress_addr(struct sk_buff *skb, struct in6_addr *ipaddr,
- u8 const *prefix, u8 pref_post_count, unsigned char *lladdr)
+lowpan_uncompress_addr(struct sk_buff *skb,
+ struct in6_addr *ipaddr,
+ const u8 address_mode,
+ const u8 *lladdr)
{
- u8 prefcount = pref_post_count >> 4;
- u8 postcount = pref_post_count & 0x0f;
-
- /* full nibble 15 => 16 */
- prefcount = (prefcount == 15 ? 16 : prefcount);
- postcount = (postcount == 15 ? 16 : postcount);
-
- if (lladdr)
- lowpan_raw_dump_inline(__func__, "linklocal address",
- lladdr, IEEE802154_ADDR_LEN);
- if (prefcount > 0)
- memcpy(ipaddr, prefix, prefcount);
-
- if (postcount > 0) {
- memcpy(&ipaddr->s6_addr[16 - postcount], skb->data, postcount);
- skb_pull(skb, postcount);
- } else if (prefcount > 0) {
- if (lladdr == NULL)
- return -EINVAL;
-
- /* no IID based configuration if no prefix and no data */
- lowpan_uip_ds6_set_addr_iid(ipaddr, lladdr);
+ switch (address_mode) {
+ case LOWPAN_IPHC_ADDR_00:
+ /*
+* for global link addresses
+*/
+ memcpy(ipaddr->s6_addr, skb->data, 16);
+ skb_pull(skb, 16);
+ break;
+ case LOWPAN_IPHC_ADDR_01:
+ /*
+* fe:80:::::
+*/
+ memset(&ipaddr->s6_addr[0], 0xFE, 1);
+ memset(&ipaddr->s6_addr[1], 0x80, 1);
+ memcpy(&ipaddr->s6_addr[8], skb->data, 8);
+ skb_pull(skb, 8);
+ break;
+ case LOWPAN_IPHC_ADDR_02:
+ /*
+* fe:80::ff:fe00:
+*/
+ memset(&ipaddr->s6_addr[0], 0xFE, 1);
+ memset(&ipaddr->s6_addr[1], 0x80, 1);
+ memset(&ipaddr->s6_addr[11], 0xFF, 1);
+ memset(&ipaddr->s6_addr[12], 0xFE, 1);
+ memcpy(&ipaddr->s6_addr[14], skb->data, 2);
+ skb_pull(skb, 2);
+ break;
+ case LOWPAN_IPHC_ADDR_03:
+ /*
+* fe:80:::::
+*\_/
+* lladdr
+
[Linux-zigbee-devel] [PATCH 03/11] 6lowpan: init 6lowpan header and ipv6hdr to zero
When we set it to zero, we can assume that the memory is already zero
while parsing.
Signed-off-by: Alexander Aring
---
net/ieee802154/6lowpan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index 8e0fbb8..fd0a5bc 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -387,7 +387,7 @@ static int lowpan_header_create(struct sk_buff *skb,
struct ipv6hdr *hdr;
const u8 *saddr = _saddr;
const u8 *daddr = _daddr;
- u8 head[100];
+ u8 head[100] = {};
struct ieee802154_addr sa, da;
/* TODO:
@@ -723,7 +723,7 @@ frame_err:
static int
lowpan_process_data(struct sk_buff *skb)
{
- struct ipv6hdr hdr;
+ struct ipv6hdr hdr = {};
u8 tmp, iphc0, iphc1, num_context = 0;
u8 *_saddr, *_daddr;
int err;
--
1.8.3.2
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 04/11] 6lowpan: remove setting some memory regions to zero
While we can assume that the memory is already be zero, we can drop some
memsets while parsing.
Signed-off-by: Alexander Aring
---
net/ieee802154/6lowpan.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c
index fd0a5bc..f3406dac 100644
--- a/net/ieee802154/6lowpan.c
+++ b/net/ieee802154/6lowpan.c
@@ -223,10 +223,6 @@ lowpan_uncompress_addr(struct sk_buff *skb, struct
in6_addr *ipaddr,
if (prefcount > 0)
memcpy(ipaddr, prefix, prefcount);
- if (prefcount + postcount < 16)
- memset(&ipaddr->s6_addr[prefcount], 0,
- 16 - (prefcount + postcount));
-
if (postcount > 0) {
memcpy(&ipaddr->s6_addr[16 - postcount], skb->data, postcount);
skb_pull(skb, postcount);
@@ -869,8 +865,6 @@ lowpan_process_data(struct sk_buff *skb)
hdr.priority = ((tmp >> 2) & 0x0f);
hdr.flow_lbl[0] = ((tmp << 6) & 0xC0) | ((tmp >> 2) & 0x30);
- hdr.flow_lbl[1] = 0;
- hdr.flow_lbl[2] = 0;
break;
/*
* Flow Label carried in-line
@@ -886,10 +880,6 @@ lowpan_process_data(struct sk_buff *skb)
break;
/* Traffic Class and Flow Label are elided */
case 3: /* 11b */
- hdr.priority = 0;
- hdr.flow_lbl[0] = 0;
- hdr.flow_lbl[1] = 0;
- hdr.flow_lbl[2] = 0;
break;
default:
break;
--
1.8.3.2
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
___
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 01/11] 6lowpan: fix small comment issue
Fix a little comment issue. Number 2 is 10 in bits and 1 is 01. Signed-off-by: Alexander Aring --- net/ieee802154/6lowpan.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c index 55e1fd5..1ec14ef 100644 --- a/net/ieee802154/6lowpan.c +++ b/net/ieee802154/6lowpan.c @@ -862,7 +862,7 @@ lowpan_process_data(struct sk_buff *skb) * Traffic class carried in-line * ECN + DSCP (1 byte), Flow Label is elided */ - case 1: /* 10b */ + case 1: /* 01b */ if (lowpan_fetch_skb_u8(skb, &tmp)) goto drop; @@ -875,7 +875,7 @@ lowpan_process_data(struct sk_buff *skb) * Flow Label carried in-line * ECN + 2-bit Pad + Flow Label (3 bytes), DSCP is elided */ - case 2: /* 01b */ + case 2: /* 10b */ if (lowpan_fetch_skb_u8(skb, &tmp)) goto drop; -- 1.8.3.2 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCHv4 00/11] minor fixes.
Version 3 of my patch series for the 6lowpan stack. There is also a known issue with the payload length on fragmentation which don't fix this series. I am working on it... v4: - Got a "Mail delivery failed" - I resend this patch series v3: - add David Hauweele patch to fix fragmentation with link-local compressed addresses - add warnings for CID and DAC bit - handle SAC bit to :: address - rename layer_addr to lladdr in function lowpan_uncompress_addr v2: - add patch to add uncompress multicast addresses - add patch for new uncompress address function Alexander Aring (10): 6lowpan: fix small comment issue 6lowpan: fix return value with comment operator 6lowpan: init 6lowpan header and ipv6hdr to zero 6lowpan: remove setting some memory regions to zero 6lowpan: use _saddr and _daddr instead of skb data 6lowpan: add function to uncompress multicast addr 6lowpan: lowpan_uncompress_addr with address_mode 6lowpan: add warning for CID bit 6lowpan: add warning for DAC bit 6lowpan: handle SAC bit to :: address David Hauweele (1): 6lowpan: Fix fragmentation with link-local compressed addresses net/ieee802154/6lowpan.c | 268 +++ net/ieee802154/6lowpan.h | 8 +- 2 files changed, 159 insertions(+), 117 deletions(-) -- 1.8.3.2 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 02/11] 6lowpan: fix return value with comment operator
Signed-off-by: Alexander Aring --- net/ieee802154/6lowpan.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c index 1ec14ef..8e0fbb8 100644 --- a/net/ieee802154/6lowpan.c +++ b/net/ieee802154/6lowpan.c @@ -819,7 +819,8 @@ lowpan_process_data(struct sk_buff *skb) } spin_unlock_bh(&flist_lock); - return kfree_skb(skb), 0; + kfree_skb(skb); + return 0; } default: break; -- 1.8.3.2 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
[Linux-zigbee-devel] [PATCH 05/11] 6lowpan: Fix fragmentation with link-local compressed addresses
From: David Hauweele 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 Signed-off-by: Alexander Aring --- net/ieee802154/6lowpan.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/net/ieee802154/6lowpan.c b/net/ieee802154/6lowpan.c index f3406dac..d503c61 100644 --- a/net/ieee802154/6lowpan.c +++ b/net/ieee802154/6lowpan.c @@ -698,6 +698,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.8.3.2 -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
Re: [Linux-zigbee-devel] [PATCHv4 00/11] minor fixes.
Seems, the mail server doesn't like me. On Mon, Jul 15, 2013 at 10:35:24PM +0200, Alexander Aring wrote: > Version 3 of my patch series for the 6lowpan stack. There is also a known > issue with the payload length on fragmentation which don't fix this series. > I am working on it... > > v4: > - Got a "Mail delivery failed" - I resend this patch series > > v3: > - add David Hauweele patch to fix fragmentation with link-local compressed >addresses > - add warnings for CID and DAC bit > - handle SAC bit to :: address > - rename layer_addr to lladdr in function lowpan_uncompress_addr > > v2: > - add patch to add uncompress multicast addresses > - add patch for new uncompress address function > > Alexander Aring (10): > 6lowpan: fix small comment issue > 6lowpan: fix return value with comment operator > 6lowpan: init 6lowpan header and ipv6hdr to zero > 6lowpan: remove setting some memory regions to zero > 6lowpan: use _saddr and _daddr instead of skb data > 6lowpan: add function to uncompress multicast addr > 6lowpan: lowpan_uncompress_addr with address_mode > 6lowpan: add warning for CID bit > 6lowpan: add warning for DAC bit > 6lowpan: handle SAC bit to :: address This patch isn't send, I got a "Mail delivery failed" for this, but the last time it was successful. Nevertheless use the patch from the last try to sending this patch series. Sorry for that. Alex -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk ___ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
