Re: ULE linux kernel code

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

The case of D=0 is indeed the default - I think the intention was that 
both modes would work, and I welcome this initiative to update the 
implementation!


(I'll also reply to the earlier email)

Gorry


Bernhard Collini-Nocker wrote:

> 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