David Miller wrote:
> You're submitting 7 patches, one set is numbered 1-6 and this
> one has no number.
The unnumbered patch is independent from the rest. But yes, he
shouldn't have sent it in the same thread.
To provide a bit of context, 6LoWPAN support in the kernel is
currently in an embarras
This patch adds a helper function to parse the ipv6 header to a
6lowpan header in stream.
This function checks first if we can pull data with a specific
length from a skb. If this seems to be okay, we copy skb data to
a destination pointer and run skb_pull.
Signed-off-by: Alexander Aring
Reviewe
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
Reviewed-by: Werner
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
Reviewed-by: Werner Almesberger
---
net/ieee802154/6lowpan.c | 144 +
This patch simplify the handling to set fields inside of struct ipv6hdr
to zero. Instead of setting some memory regions with memset to zero we
initialize the whole ipv6hdr to zero.
This is a simplification for parsing the 6lowpan header for the upcomming
patches.
Signed-off-by: Alexander Aring
R
A link-local address isn't fe80::/10 it's fe80::/64
see http://tools.ietf.org/html/rfc4291#section-2.5.6
for more details.
Also fix a comment issue "local link" -> "link-local"
Signed-off-by: Alexander Aring
Reviewed-by: Werner Almesberger
---
v2:
- Add "net-next" tag
net/ieee802154/6lowpan.
The current implementation to uncompress addresses in a 6lowpan header
is completely broken.
This patch series fixes the parsing of addresses in a 6lowpan header.
It contains a major rewrite of the uncompress address function to parse
the address in a correct way.
Changes since v2:
- Add tags fo
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 a
Handle context based address when a unspecific address is specified.
For other context based address we print a warning and drop the packet
currently because we don't support it right now.
Signed-off-by: Alexander Aring
Reviewed-by: Werner Almesberger
---
net/ieee802154/6lowpan.c | 48 +
Hi,
I forgot a "net-next" in the subject, sry.
So this patch is for "net-next"
Regards
Alex
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get
On 08/14/2013 03:01 PM, Alexander Aring wrote:
> The current implementation to uncompress addresses in a 6lowpan header
> is completely broken.
>
> This patch series fixes the parsing of addresses in a 6lowpan header.
> It contains a major rewrite of the uncompress address function to parse
> the a
Hi Hannes,
On Wed, Aug 14, 2013 at 01:08:21PM +0200, Hannes Frederic Sowa wrote:
> On Wed, Aug 14, 2013 at 01:01:07PM +0200, Alexander Aring wrote:
> > diff --git a/net/ieee802154/6lowpan.h b/net/ieee802154/6lowpan.h
> > index 4b8f917..61f0ce9 100644
> > --- a/net/ieee802154/6lowpan.h
> > +++ b/ne
On 08/14/2013 03:49 PM, Hannes Frederic Sowa wrote:
> On Wed, Aug 14, 2013 at 01:01:45PM +0200, Alexander Aring wrote:
>> This patch adds a helper function to parse the ipv6 header to a
>> 6lowpan header in stream.
>>
>> This function checks first if we can pull data with a specific
>> length from
Hi Alex,
On Wed, Aug 14, 2013 at 03:23:48PM +0400, Alexander Smirnov wrote:
> On 08/14/2013 03:01 PM, Alexander Aring wrote:
> >The current implementation to uncompress addresses in a 6lowpan header
> >is completely broken.
> >
> >This patch series fixes the parsing of addresses in a 6lowpan heade
Hi Alex,
On Wed, Aug 14, 2013 at 03:55:21PM +0400, Alexander Smirnov wrote:
> On 08/14/2013 03:49 PM, Hannes Frederic Sowa wrote:
> >On Wed, Aug 14, 2013 at 01:01:45PM +0200, Alexander Aring wrote:
> >>This patch adds a helper function to parse the ipv6 header to a
> >>6lowpan header in stream.
>
Hi Hannes,
On Wed, Aug 14, 2013 at 02:47:54PM +0200, Hannes Frederic Sowa wrote:
> On Wed, Aug 14, 2013 at 02:45:47PM +0200, Alexander Aring wrote:
> > This was the old behaviour, we decide it to make it like this:
> >
> > fail = ...
> > fail |=
> >
> > if (fail)
> > ...
> >
> > We dis
From: Alexander Aring
Date: Wed, 14 Aug 2013 13:01:07 +0200
> A link-local address isn't fe80::/10 it's fe80::/64
> see http://tools.ietf.org/html/rfc4291#section-2.5.6
> for more details.
>
> Also fix a comment issue "local link" -> "link-local"
>
> Signed-off-by: Alexander Aring
> Reviewed-b
Hi David,
On Wed, Aug 14, 2013 at 12:53:46PM -0700, David Miller wrote:
> From: Alexander Aring
> Date: Wed, 14 Aug 2013 13:01:07 +0200
>
> > A link-local address isn't fe80::/10 it's fe80::/64
> > see http://tools.ietf.org/html/rfc4291#section-2.5.6
> > for more details.
> >
> > Also fix a com
From: Alexander Aring
Date: Wed, 14 Aug 2013 23:17:01 +0200
> Ok, please let me know what should I do to submit it properly.
What you don't understand is that just because patches aren't
related doesn't mean that their order of application doesn't
matter.
So you put all the patches into a full
Hi David,
On Wed, Aug 14, 2013 at 05:18:25PM -0700, David Miller wrote:
> From: Alexander Aring
> Date: Wed, 14 Aug 2013 23:17:01 +0200
>
> > Ok, please let me know what should I do to submit it properly.
>
> What you don't understand is that just because patches aren't
> related doesn't mean t
20 matches
Mail list logo
