Hi Alex, On 08/09/14 19:55, Alexander Aring wrote: > Hi Martin, > > On Mon, Sep 08, 2014 at 08:36:52PM +0200, Alexander Aring wrote: >> Hi Martin, >> >> On Mon, Sep 08, 2014 at 07:13:02PM +0100, Martin Townsend wrote: >> ... >>>>> Hi, >>>>> >>>>> I'll respin and include the memory leak fix and this patch and a couple of >>>>> others I have and send as a series to bluetooth. What bluetooth git >>>>> repository should I base the series on? >>>>> >>>> What's the state about to fix this bad issue? :-) >>>> >>>> I didn't saw any new patches because of this. >>>> >>>> - Alex >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in >>>> the body of a message to majord...@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> Sorry for the delay, been on hols for a few days, I will create the patches >>> tomorrow if I get time. >>> >>> I have also implemented Generic Header Compression[0] which is still in >>> draft at the moment but I can't imagine it will change much before being >>> released. I'm going to integrate it into our linux repository this week. >>> Would you be interested in putting it in linux-wpan or linux-wpan-next or >>> would you prefer to wait until it gets it RFC status? >>> >> no, for me it's okay to have this mainline. I heard that a draft becomes >> no RFC when nobody implements it. >> > I thought more about that, you mean the receiving part only? So the > uncompression. The point is that we don't have no interface for an user > that can decide if he like to use UDP compression like RFC 6282 or UDP > compression like GHC. This is only relevant for the transmit part. So > compression is optionally. (We should have some interface to make this > configurable by user -> adding this to the nhc layer, later). I've implemented compression and decompression. You are right in that we need a mechanism of configuring what gets compressed by what method. > On the uncompression part, means the receiving part we can support both. > UDP RFC 6282 or UDP like GHC, the next header id value should be > different there. That means currently we can receive every packets but > transmit only RFC6282 compression formats. > > So for receiving this, it's okay. But for compression, since we don't > have some interface to make this configurable we should use RFC 6282. So I will ensure UDP is compressed by 6282. Then I was going to start out by just compressing ICMPv6 with GHC and monitor how much data is saved by using GHC. Later on we will implement a mechanism of configuring what gets compressed and by which compression method.
The GHC spec states that a device indicates it's GHC capability using a 6LoWPAN Capability Indication Option (6CIO), this is an ND option. As far as I can see there is no type assigned yet by IANA so I was wondering if we should have this as an experimental configuration item in the kernel? > > Same opinion here? We can talk about that point. > > - Alex - Martin ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
