Hi Alex, On ma, 2014-09-01 at 13:38 +0200, Alexander Aring wrote: > Hi, > > On Mon, Sep 01, 2014 at 01:36:14PM +0300, Jukka Rissanen wrote: > > Hi Alex, > > > > I saw your RFC mail (9 Aug) about generic compression layer. Was there > > any functionality changes by this RFC or was it just refactoring the > > code? > > > > It's not just refactoring. The point is that there are many of RFC's > outside which declare a next header compession format (like UDP). UDP is > the only one next header compression which we currenlty support. If we > don't add a layer to add a new header compression format, all people > hack this into the iphc.c file. I don't know what you think about this > but I really don't like that. > > This code adds a layer for this and supports all other known next header > compression formats in the way that we drop the packets afterwards > instead of deliver garabage to next layer (IPv6). > > The layer avoids that everybody hacks static code into iphc file. Ok, sounds like a plan. > > Please let me know if this is okay for you, then I will send a v2 with > changes. Sure, just send new version. > > > Anyway, looks ok to me although I just browsed quickly through the code, > > did not really review it :) Just wondering do we need more > > subdirectories under 6lowpan or could we just put everything into > > 6lowpan dir (just to keep it simple)? No big preference here thou. > > > > Don't know, but there is a unkown number of possible next header compression > formats outside, we should split it in a new subdirectorie. What I > actually mean, don't hack every next header compression format in a > single file. I was not really thinking that all the stuff would be in single file. I was just pondering is there really a need for sub-directory, after all the number of files in net/6lowpan directory is currently very small so one option could be to put the nhc files directly into 6lowpan directory (and perhaps adding them nhc_ prefix). Anyway, this is minor thing and I am fine with having sub-directories. > > For address compression/uncompression this is fine, there is no unknown > numbers of compression ways. > > I know only IPHC and HC1. HC1 should be support for receiving side and > it's obsolete, but this is rfc 4944 so it's only related to 802.15.4. > > Some or later we need to add support for this, but this should not used > by bluetooth 6LoWPAN. > > > I saw the mail from Varka Bhadram (6 Aug) about RFC 6775 support. That > > looked interesting. Did you get the code from him (if yes, could you > > also send it to me)? Do you know why this guy have not send this stuff > > to upstream? > > > > The 802.15.4 mac layer has some neighbor discovery issues which are not > solved currently. It's about two kinds of mac addresses, for bluetooth > it should be fine. A small description about this problem is here [1]. > > We need some way to trigger 6LoWPAN/Layer 2 data across the IPv6 layer > and this isn't easy. Everything what we do on runtime decisions makes > the IPv6 stack slower and we should avoid that. Yep, agreed. > > > > I currently working on a big rework of the 802.15.4 layer and will try > to bring this mainline at end of this month. Our mac layer is currenlty > in an not useable state. :( > > I don't have time to make some effort after IPv6, currently I work on > the rework and will solve the two kind mac addresses issues with the > neighbor discovery cache, then we are in some state which we don't have > some broken support of functionality. > > > Maybe simple talk with Varka about what he did there, because I don't > really know what he exactly did there. The code what I saw isn't > mainline able. [0] What I know that RFC 6775 and the actually > implementation need to handle the two kinds of mac addresses (which is > broken currenlty) and need support of context based address compression. > > I don't have time to add support for this. I need to rescue the 802.15.4 > layer. Sorry! Maybe after that... or maybe somebody will do this work. > It sounds for me crazy to support RFC6775 which has dependencies on > other functionality which we doesn't support right now. For bluetooth > the mac layer works great, we only needs support for context based > address compression then. Ok. Currently I am also busy with some other stuff but I try to find some time to investigate the RFC6775 more. Cannot really promise any dates etc. > > > I CC the new mailinglist for IEEE 802.15.4/IEEE 802.15.4 6LoWPAN > "linux-wpan" and bluetooth. We should not talk about this under the > hood. > > - Alex > > [0] https://www.mail-archive.com/linux-zigbee-devel%40lists.sourceforge.net/msg02018.html > [1] http://www.spinics.net/lists/netdev/msg291767.html Cheers, Jukka -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
