Programming interface MAC filter without enabling PROMISC on
an interface from user space.
Bruce M. Simpson
bms at FreeBSD.org
Mon Jan 14 10:48:19 PST 2008
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.
More information about the freebsd-net