Re: ULE linux kernel code

[Bernhard Collini-Nocker <bnocker@cosy.sbg.ac.at>]

Hi Gorry,

Gorry Fairhurst wrote:
> Thanks Bernhard, 
> 
> The Spec probably was not intended to be implemented this way, so I'd

well, yes and no. Yes, because it results in an atypical behaviour at
the receiver side. No, because it is "intended" (maybe this is too
strong worded and "recommended" is more accurate) to operate
IP-multicast over ULE without SNDU DestAddr.

> suggest we need to look at this seriously. First, can I check one subtle
> question below.
> 
> On 9/2/06 14:24, "Bernhard Collini-Nocker" <bnocker@cosy.sbg.ac.at> wrote:
> 
> 
>>Dear all,
>>
>>a while ago we have noticed that the ULE code in the recent Linux 2.6
>>kernels (from 2.6.10 onwards, when ULE with optional headers was added)
>>implements a "non-obvious" handling of IP-multicast and IP-broadcast
>>packets in the one case when D bit (SNDU Destination Address Absent
>>flag) is not set (equals 0), or in other words when a SNDU Destination
>>Address (NPA/MAC) address is present. Instead of applying the filter
>>only on unicast addresses the filtering is applied on ALL packets.
> 
> Are broadcast packets (MAC ff:ff:ff:ff:ff:ff) also caught by this filter?

The code says YES (in case I did not miss something important somewhere
else :-), read yourself
(excerpt from linux-2.6.15.3/drivers/media/dvb/dvb-core/dvb_net.c)

if (!priv->ule_dbit) {
     /* The destination MAC address is the next data in the skb. */
     if (memcmp( priv->ule_skb->data, dev->dev_addr, ETH_ALEN )) {
          /* MAC addresses don't match.  Drop SNDU. */
          // printk( KERN_WARNING "Dropping SNDU, MAC address.\n" );
          dev_kfree_skb( priv->ule_skb );
          goto sndu_done;
     }
     if (! priv->ule_bridged) {
          skb_push( priv->ule_skb, ETH_ALEN + 2 );
          ethh = (struct ethhdr *)priv->ule_skb->data;
          memcpy( ethh->h_dest, ethh->h_source, ETH_ALEN );
          memset( ethh->h_source, 0, ETH_ALEN );
          ethh->h_proto = htons( priv->ule_sndu_type );
     } else {
          /* Skip the Receiver destination MAC address. */
          skb_pull( priv->ule_skb, ETH_ALEN );
     }
} else {


> - or are they currently always forwarded?

NO. This is likely to be ok, since Broadcast should remain link-local?

>>Consequently multicast/broadcast packets (whose SNDU DestAddr does not
>>match the one set interface hardware address) are discarded in the
>>driver. This kind of stringent filtering, however, may confuse
>>operators/users.
> 
> 
> <snip>.

Yours,
Bernhard