From owner-ipdvb@erg.abdn.ac.uk Fri Apr 14 10:35:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUPOM-00050T-Vb for ipdvb-archive@ietf.org; Fri, 14 Apr 2006 10:35:22 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUPOM-0003nb-Hr for ipdvb-archive@ietf.org; Fri, 14 Apr 2006 10:35:22 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k3EEMFME015192 for ; Fri, 14 Apr 2006 15:22:15 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k3EEME0B015191 for ipdvb-subscribed-users; Fri, 14 Apr 2006 15:22:14 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from puma.cosy.sbg.ac.at (puma.cosy.sbg.ac.at [141.201.2.23]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k3EEM5B1015174 for ; Fri, 14 Apr 2006 15:22:05 +0100 (BST) Received: from [127.0.0.1] (milbe.cosy.sbg.ac.at [141.201.2.21]) by puma.cosy.sbg.ac.at (Postfix) with ESMTP id 86AA22282A7; Fri, 14 Apr 2006 16:17:54 +0200 (CEST) Message-ID: <443FB00B.7050904@cosy.sbg.ac.at> Date: Fri, 14 Apr 2006 16:22:03 +0200 From: Bernhard Collini-Nocker User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk Cc: Christian Praehauser , Bernhard Collini-Nocker Subject: ULE Linux kernel code X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Dear all, this is to inform you about recent finding and changes to the Linux Kernel ULE code, which we are about to submit soon. Please let us know whether you have any questions and/or comments. 1. 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). 2. Added check of return value from functions which handle mandatory extension headers (e.g. ule_test_sndu) 3. 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. 4. 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. 5. 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). 6. Reduced timeout value for TS cells to 10 ms. 7. 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 t imespec timeout); Regards, Bernhard and Christian From owner-ipdvb@erg.abdn.ac.uk Mon Apr 17 05:21:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVPuw-0000i7-E3 for ipdvb-archive@ietf.org; Mon, 17 Apr 2006 05:21:10 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVPuw-0002SM-0K for ipdvb-archive@ietf.org; Mon, 17 Apr 2006 05:21:10 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k3H9E2kA019439 for ; Mon, 17 Apr 2006 10:14:02 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k3H9E2rC019438 for ipdvb-subscribed-users; Mon, 17 Apr 2006 10:14:02 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from [139.133.207.151] (dhcp-207-151.erg.abdn.ac.uk [139.133.207.151]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k3H9DpIJ019412; Mon, 17 Apr 2006 10:13:51 +0100 (BST) Message-ID: <44435C4F.3020403@erg.abdn.ac.uk> Date: Mon, 17 Apr 2006 10:13:51 +0100 From: Gorry Fairhurst Organization: University of Aberdeen, UK User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipdvb@erg.abdn.ac.uk CC: Christian Praehauser , Bernhard Collini-Nocker Subject: Re: ULE Linux kernel code References: <443FB00B.7050904@cosy.sbg.ac.at> In-Reply-To: <443FB00B.7050904@cosy.sbg.ac.at> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Great to hear some code refinements bringing the driver into alignment with RFC4326. Can I ask for a small clarification on point 5? Gorry Bernhard Collini-Nocker wrote: > Dear all, > > this is to inform you about recent finding and changes to the Linux > Kernel ULE code, which we are about to submit soon. Please let us know > whether you have any questions and/or comments. > > 1. 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). > Seems correct to me. > 2. Added check of return value from functions which handle mandatory > extension headers (e.g. ule_test_sndu) > > 3. 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. > > 4. 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. > OK - that sounds much better. > 5. 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). > How is the multicast address list populated? - Do you also pass all IPv4 packets with the prefix 224.0.0.x? - Is this by configuration only, or via routing protocols or IGMP/MLD? > 6. Reduced timeout value for TS cells to 10 ms. > In the absence of a MIB for ULE, I guess this is fixed. > 7. 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 t > imespec timeout); > > > Regards, > Bernhard and Christian > > From owner-ipdvb@erg.abdn.ac.uk Mon Apr 17 07:00:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVRT9-0004hw-IL for ipdvb-archive@ietf.org; Mon, 17 Apr 2006 07:00:35 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVRT7-00074M-Uf for ipdvb-archive@ietf.org; Mon, 17 Apr 2006 07:00:35 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k3HAu3vZ027251 for ; Mon, 17 Apr 2006 11:56:03 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k3HAu3xr027250 for ipdvb-subscribed-users; Mon, 17 Apr 2006 11:56:03 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from elsnet.at (elsnet.at [62.218.246.20]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k3HAttKc027230; Mon, 17 Apr 2006 11:55:55 +0100 (BST) Received: from [127.0.0.1] [62.218.246.241] by elsnet.at with ESMTP (SMTPD32-8.05) id A7A7EC400D6; Mon, 17 Apr 2006 13:10:31 +0200 Received: from [127.0.0.1] ([127.0.0.1]) by [127.0.0.1] with ESMTP (SpamPal v1.583) sender ; 17 Apr 2006 12:55:54 +0200 Message-ID: <44437439.6000703@cosy.sbg.ac.at> Date: Mon, 17 Apr 2006 12:55:54 +0200 From: =?ISO-8859-1?Q?Christian_Pr=E4hauser?= User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk CC: ipdvb@erg.abdn.ac.uk Subject: Re: ULE Linux kernel code References: <443FB00B.7050904@cosy.sbg.ac.at> <44435C4F.3020403@erg.abdn.ac.uk> In-Reply-To: <44435C4F.3020403@erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hello Gorry! Gorry Fairhurst wrote: > >> 5. 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). >> > How is the multicast address list populated? > - Do you also pass all IPv4 packets with the prefix 224.0.0.x? > - Is this by configuration only, or via routing protocols or IGMP/MLD? > Basically, the ULE decapsulator in the dvb-core module checks the same list of multicast addresses which is also used by the MPE part. This list is completely managed by the OS (net/core/dev_mcast.c), so we just accept the mc addresses which have been joined. This is, if we're in "multicast" mode. In "all-multicast" mode, we accept every mc address. When the dvb net interface is activated, the "all-hosts" group (224.0.0.1) is automatically joined. We're currently checking the differences from draft-03 of ULE up to the final RFC in order to verify that the decaps code is complient with RFC 4326. Kind regards, Christian Praehauser. From owner-ipdvb@erg.abdn.ac.uk Thu Apr 27 10:53:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7s2-0002gi-8U for ipdvb-archive@ietf.org; Thu, 27 Apr 2006 10:53:30 -0400 Received: from dee.erg.abdn.ac.uk ([139.133.204.82] helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ7s0-0001MB-QU for ipdvb-archive@ietf.org; Thu, 27 Apr 2006 10:53:30 -0400 Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k3REiiP0017082 for ; Thu, 27 Apr 2006 15:44:44 +0100 (BST) Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id k3REiine017081 for ipdvb-subscribed-users; Thu, 27 Apr 2006 15:44:44 +0100 (BST) X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f Received: from smtp3.clb.oleane.net (smtp3.clb.oleane.net [213.56.31.19]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k3REib3u017058 for ; Thu, 27 Apr 2006 15:44:37 +0100 (BST) Received: from Pavillonquatre ([194.3.133.88]) by smtp3.clb.oleane.net with ESMTP id k3REiVKb028957 for ; Thu, 27 Apr 2006 16:44:32 +0200 Message-Id: <200604271444.k3REiVKb028957@smtp3.clb.oleane.net> From: "Chantal Ladouce" To: Subject: TVoDSL International Conference 2007 - Paris - France Date: Thu, 27 Apr 2006 16:43:23 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A9_01C66A19.B32E7210" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZqCO9nGTi70GDwQEuJ9nJ/FoZt4g== X-ERG-MailScanner: Found to be clean, Found to be clean X-Spam-Status: No, No Sender: owner-ipdvb@erg.abdn.ac.uk Precedence: bulk Reply-To: ipdvb@erg.abdn.ac.uk X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01C66A19.B32E7210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The fourth edition of the TVoDSL International Conference and the Triple Play Showcase will stand in Paris next January 23 to 26, 2007. With the opening of a second exhibition floor and the launch of the Mobile TV World Congress, TVoDSL will confirm his rank of very first worldwide rendez-vous in the IPTV realm. A call for proposals has been launched for the TVoDSL conference. All details at: http://www.upperside.fr/tvodsl2007/tvodsl2007intro.htm ------=_NextPart_000_00A9_01C66A19.B32E7210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The fourth edition of the TVoDSL International = Conference and the Triple Play Showcase will stand in Paris next January 23 to 26, = 2007.

With the opening of a second exhibition floor = and the launch of the Mobile TV World Congress, TVoDSL will = confirm his rank of very first worldwide rendez-vous in the = IPTV realm.

 

A call for = proposals has been launched for the TVoDSL conference.

=

 

All details = at:

=

http://www.upperside.fr/tvodsl2007/tvodsl2007intro.htm

=

 

------=_NextPart_000_00A9_01C66A19.B32E7210--