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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
