Subject: ULE Linux kernel code

From: Bernhard Collini-Nocker <[email-masked]>
Date: Fri, 14 Apr 2006 16:22:03 +0200

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: Gorry Fairhurst <[email-masked]>
Date: Mon, 17 Apr 2006 10:13:51 +0100

Great to hear some code refinements bringing the driver into alignment 
with RFC4326. Can I ask for a small clarification on point 5?

Gorry

>  byte of payload and the CRC32 (4 Bytes).
Seems correct to me.

> buffer because it may be required for constructing the ethernet header.
OK - that sounds much better.

> (4) If in all-multicast mode, all multicast addresses are accepted (in
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.

---

From: Christian Prähauser <[email-masked]>
Date: Mon, 17 Apr 2006 12:55:54 +0200

Hello Gorry!

> - 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.