Christian, Em Sáb, 2006-04-29 às 12:26 +0200, Christian Prähauser escreveu: > Mauro Carvalho Chehab wrote: > > Is it ok to apply at our tree? That message was meant to the original author of ULE support :) > > > > > Well, it fixes some important issues (see below), especially regarding > destination address (NPA) and ULE (optional) extension header > processing, which is broken in the current kernel versions. Ok. I'll apply at our tree and schedule it to 2.6.17. > > I would also opt for an attempt to rewrite the dvb networking (most of > which is in dvb_net.c) part of dvb-core, because from my point of view, > the ULE decaps code is overly complex. > > This is how Andrew Morton formulated it: > > This driver would have to be one of the ugliest-looking things in the > > kernel. You must have a strong stomach. > ;-) Ok, go ahead working on it. Please post your patches at dvb ML c/c to dvb maintainers ML. > > Regards, > Christian. > -- > README for dvb_net_ule_rfc4326.patch > ==================================== > > Description > ----------- > Fixed bugs in the Unidirectional Lightweight Encapsulation (ULE) code. > Also checked compliency with RFC 4326 (ULE). > > Changes in dvb_net.c > -------------------- > * Fixed check of SNDU length. > Explanation: > The SNDU length was not checked correctly, thus leaving the possibility > for a kernel panic if receiving malformed SNDUs. > Solution: > Now, the SNDU length is considered invalid if it is less then 5. The > reasoning for this is that an SNDU must always carry at least one byte > of payload and the CRC32 (4 Bytes). > > * Added check of return value from functions which handle mandatory > extension headers (e.g. ule_test_sndu) > > * Fixed handling of optional extension headers. > Explanation: > When processing optional extension headers, the length of the extension > header was not calculated correctly. > Also the next header type field was assumed to be after the optional > extension header. In fact, it is a part of it (always the last two bytes). > Solution: > The length calc. and next header type field access for optional ext. > headers have been fixed. > > * Added handling of extension header padding (optional extension header > with type 1) > > * Fixed check of destination address in presence of extension headers. > Explanation: > The destination address was assumed to be after any extension headers. > Thus, the extension headers were processed before comparing the > destination address with the actual address of the receiver. After that, > the total length of the ext. headers was removed from the buffer (skb) > also including the destination address. > Solution: > Now, the destination address (if present) is checked before processing > any extension headers. The destination address is saved in a local > buffer because it may be required for constructing the ethernet header. > > * Fixed/Improved filtering on destination address (if present in ULE SNDU) > (1) Now, everything is passed up the stack if in promiscious mode. > (2) The address of the receiver device and the broadcast address > (FF:FF:FF:FF:FF:FF) are always accepted. > (3) If in multicast mode, all addresses in the multicast address list > are accepted (in addition to 2). > (4) If in all-multicast mode, all multicast addresses are accepted (in > addition to 2). > > * Reduced timeout value for TS cells to 10 ms. > > * Fixed arguments for setting TS feed properties. > The documentation for DVB-API v3 and what is actually present in the > Linux kernel seem to be out of sync. > The set() function for TS feeds differs in the DVB API version 3 > document and the Linux kernel version: > int set(dmx ts feed t* feed, u16 pid, size_t callback length, size_t > circular buffer size, int descramble, struct timespec timeout); > Actually implemented in the 2.6.15 Kernel: > int dmx_ts_feed_set(struct dmx_ts_feed *ts_feed, u16 pid, int ts_type, > enum dmx_ts_pes pes_type, size_t circular_buffer_size, struct timespec > timeout); > > Patch Author > ------------ > Christian Praehauser > Paris Lodron University of Salzburg > > Signed-off-by: Christian Praehauser <cpraehaus@xxxxxxxxxxxxxx> > Cheers, Mauro. _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
