On 03/11/2013 02:03 PM, Tony Cheneau wrote:
> Hi,
>
> Sorry for the delay, I wanted to check the code first. See my answer
> inline.
>
> Le 2013-03-05 21:20, Alan Ott a écrit :
>> On 03/05/2013 02:38 PM, Ralph Droms (rdroms) wrote:
>>> On Mar 5, 2013, at 10:59 AM 3/5/13, Wolf-Bastian Pöttner
>>> w
Hi,
Sorry for the delay, I wanted to check the code first. See my answer
inline.
Le 2013-03-05 21:20, Alan Ott a écrit :
On 03/05/2013 02:38 PM, Ralph Droms (rdroms) wrote:
On Mar 5, 2013, at 10:59 AM 3/5/13, Wolf-Bastian Pöttner
wrote:
Hi!
Am 20.02.2013 um 03:00 schrieb Ralph Droms (rd
Tony - thanks for the confirmation.
I'm at IETF 86 this week and booked pretty solid. I expect to get back to my
fragmentation code this weekend and will follow up with questions or patches.
- Ralph
On Mar 11, 2013, at 2:03 PM 3/11/13, Tony Cheneau
wrote:
> Hi,
>
> Sorry for the delay, I w
On 03/05/2013 02:38 PM, Ralph Droms (rdroms) wrote:
> On Mar 5, 2013, at 10:59 AM 3/5/13, Wolf-Bastian Pöttner
> wrote:
>
>> Hi!
>>
>> Am 20.02.2013 um 03:00 schrieb Ralph Droms (rdroms) :
>>
>>> What I want to do is update the header compression and fragmentation code
>>> so it interoperates us
On 02/19/2013 06:19 PM, Alan Ott wrote:
> You have to change the compression type to IPV6 on the Contiki side, but
> that just handles sending. You have to also make a mod to make Contiki
> to _accept_ compressed packets (because changing the compression type to
> IPV6 on the contiki side remove
On Mar 5, 2013, at 10:59 AM 3/5/13, Wolf-Bastian Pöttner
wrote:
> Hi!
>
> Am 20.02.2013 um 03:00 schrieb Ralph Droms (rdroms) :
>
>> What I want to do is update the header compression and fragmentation code so
>> it interoperates using header compression. I think I have code for header
>>
Hi!
Am 20.02.2013 um 03:00 schrieb Ralph Droms (rdroms) :
> What I want to do is update the header compression and fragmentation code so
> it interoperates using header compression. I think I have code for header
> compression and send-side fragmentation. I still need to work on the
> receiv
On Feb 19, 2013, at 6:19 PM 2/19/13, Alan Ott
wrote:
> On 02/12/2013 07:37 AM, Tony Cheneau wrote:
>> I want to provide a quick reply to your mail as I won't have time to provide
>> an elaborated answer.
>>
>> You are right, the current stack does not interroperate correctly with other
>> st
On 02/12/2013 07:37 AM, Tony Cheneau wrote:
> I want to provide a quick reply to your mail as I won't have time to
> provide an elaborated answer.
>
> You are right, the current stack does not interroperate correctly with
> other stack right now. If I'm not mistaken, Alan made just enough
> modi
Thanks, Tony. I've cloned net-next and will start working against that version
of 6lowpan.c, etc.
I'll be happy to contribute any fixes I develop if I can figure out how to
prepare and submit them.
- Ralph
On Feb 12, 2013, at 10:37 AM 2/12/13, Tony Cheneau
wrote:
> Hello Ralph,
>
> I want
Hello Ralph,
I want to provide a quick reply to your mail as I won't have time to
provide an elaborated answer.
You are right, the current stack does not interroperate correctly with
other stack right now. If I'm not mistaken, Alan made just enough
modifications to the stack so that it can c
I'm working on fragmentation in 6lowpan.c. I've fixed a problem with the
offset computation. According to RFC 6282, the offset in the fragmentation
head is supposed to give the lotion of the fragment data in the original
(uncompressed) datagram. 6lowpan.c computes the offset from the compress
I'm trying to bring up the linux-zigbee stack and I'm running into problems
with 6lowpan.c I'm concerned about tracking down and fixing these problems,
because they seem pretty fundamental and, as far as i can tell, would prevent
this stack from interoperating with other RFC-compliant stacks.
13 matches
Mail list logo
