Re: [lwip-devel] 6lowpan support in lwip

[Ivan Delamer]

I have tested it against a Contiki implementation, that's as far as I 
tested interoperability.

I'm not sure what you mean by "only FRAG1/FRAGN encoding", I believe 
that is how it is done, although there are different header 
encoding/compression methods. Some are deprecated and I believe I didn't 
implement those.

I did not implement the mesh routing header yet. Like Sergio mentioned, 
RPL/ROLL would be really important in many deployments. At the moment, 
you'd have to implement a static routing mechanism.

I have not used encryption in my tests, if not there, we need to add 
some header space in packets for the encryption header. That would 
reduce payload size.

I think it would be awesome if anybody contributes here. If you are 
unsure, it can be posted as a patch in Savannah for review. If you're 
confident, just commit.

@sergio: I have tested this, and I've had signals go through two 
concrete floors. Usually one masonry wall is no problem, although you'd 
need router nodes in each room to multi-hop through multiple 
walls/floors.

Cheers
Ivan


> Date: Wed, 24 Feb 2016 19:57:15 +0100
> From: "address@hidden" <address@hidden>
> To: lwip-devel <address@hidden>
> Subject: Re: [lwip-devel] 6lowpan support in lwip
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Ivan Delamer wrote:
> > I have done testing/development with Atmel ARM boards.
>
> Have you tested your implementation against itself (2 instances) or
> against other products, too? I'm just starting to read up on 6lowpan 
> and
> I'm slightly confused that you seem to have implemented only 
> FRAG1/FRAGN
> encoding and it works...
>
> Also, yet I failed to read from the RFCs which parts of the spec one
> needs to implement and which not. E.g. you don't have the mesh routing
> header implemented. Have you run your tests with or without 
> encryption?
> When encryption is enabled, how do we calculate the max. fragment 
> size?
>
> How do you want to proceed with the code? Dirk just committed it since
> it doesn't hurt (the way he restructured the input path). Do you plan 
> on
> continuing this? Is it OK if I give my 2 cent (e.g. splitting 
> functions,
> adding comments, changing literals to defines, etc.) or should we 
> review
> changes on savannah?
>
> Simon