On Jul 15, 2013, at 9:27 AM 7/15/13, Alexander Aring <alex.ar...@gmail.com>
wrote:
> Hi Ralph,
>
> thanks for your reply.
You're welcome, and thanks for your followup...
>
> On Fri, Jul 12, 2013 at 12:40:49PM +0000, Ralph Droms (rdroms) wrote:
>>
>> On Jul 12, 2013, at 7:33 AM 7/12/13, Alexander Aring <alex.ar...@gmail.com>
>> 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 <alex.ar...@gmail.com>
>>> ---
>>> 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
