Programming interface MAC filter without enabling PROMISC on an interface from user space.

[Bruce M. Simpson]

Tom Judge wrote:
>
> Ok, so if I can safely assume that the process sending/receiving the 
> LLDP frames should always be running would it be safe to use a helper 
> program to add the mac on system startup so it is always registered on 
> particular interfaces for the uptime of the system rather than having 
> the daemon add/remove the address on startup shutdown?
>   If not what problems would this create?

If the daemon doesn't unregister its use of the link layer group, the 
kernel will not clean up after it. It won't prevent kernel entities from 
joining the group -- they will just acquire another reference -- but 
other userland clients will not be able to join the group until 
SIOCDELMULTI is called by at least one client.

By the way, other processes can hijack this, but only if they have 
permission to use SIOCDELMULTI. I believe this requires root privileges.

I believe it should be possible to use mtest to clean up manually.

This is far from ideal and it really does want an API. NDIS, 
incidentally, can do all of what you describe.
>
> Personally I can't see why this approach would be a problem,  but I am 
> not a expert.  The address is defined in IEEE Std 802.1D-2004 as to 
> not be forwarded by bridges (which I interpret as it being link local 
> in a sense as switches/bridges are not allowed to forward the frame), 
> so I can't see it being a problem registered on multiple interfaces.

SIOCADDMULTI memberships are specific to the interface you request them 
on. I can't speak for the bridging code -- I don't think it does any 
special handling of multicast frames, however I'm not sure if it's smart 
enough not to forward this group. Like IN_LOCALGROUP() it might need its 
own 'don't forward this' clause.

later
BMS