Bug #580
closedAnnouncing ethernet link state changes via route socket
0%
Description
Announcing link state changes to the userspace via route socket is critical
to get routing related applications to work correctly - routing protocols
are most important, but other applications might benefit from it as well.
This code is adapted from OpenBSD and is only the first basic step in path
to get correct support. Only em(4) is tested because I don't have hardware
to test others, although bge(4) might get my attention as well in the
future.
There is one fundamental problem I'd like to get feedback about from
developers - how to make various kernel stuff react on link state changes?
For example various interfaces which are somehow attached to the interface
(bridges, carp, vlans etc) should react. Ideally routing table should react
as well (yes, no BSD or Linux kernel does that yet, but they should).
Personally I like the idea of the hooks OpenBSD uses, but as I'm not very
familiar of DragonFlyBSD, my personal opinion might be very far from good
solution ;).
regards,
Files
Updated by dudu almost 18 years ago
There's been an IRC conversation recently regarding that. FreeBSD
defines a EVFILT_NETDEV filter, which can have one of the following
event bits set: NOTE_LINKUP, NOTE_LINKDOWN, NOTE_LINKINV. It's a quite
clean interface. I don't know why OpenBSD chose to do it diferently.
Updated by sepherosa almost 18 years ago
Yah.
I think your changes do affect all mii aware NICs (almost all modern NICs :)
I think bridge's link state change support has already been in place,
but is commented out.
For current vlan implementation, I am afraid you will have to go
through all vlan ifaces to locate vlan ifaces backed by the specific
state changing NIC.
BTW, this patch looks OK to me.
Best Regards,
sephe
Updated by sepherosa almost 18 years ago
I think hasso's patch is fundamental parts for the knote
implementation you mentioned above.
Best Regards,
sephe
Updated by dudu almost 18 years ago
Yes, I only read the patch after I finished writing my first mail :/
Updated by hasso almost 18 years ago
After reading some code and discussion in IRC ...
These are different things. AFAICS EVFILT_NETDEV is just another event
notifying mechanism. Does anybody uses these link events in FreeBSD at all?
All BSD's do related work in if_link_state_change(), only FreeBSD schedules
it for later processing to avoid various locking issues (how we should do
regarding this?) and all actual work is done in the do_link_state_change().
So, in this regard OpenBSD and FreeBSD are not different.
What OpenBSD does it that it allows various subsystems register various
callbacks to the interfaces and the code in if.c is shorter and simpler.
This is coding issue, not the behavioural one. For example instead of the
mass of ifdefs etc if_link_state_change() looks trivial:
void
if_link_state_change(struct ifnet *ifp)
{
rt_ifmsg(ifp);
dohooks(ifp->if_linkstatehooks, 0);
}
Updated by hasso almost 18 years ago
So, I don't have modern NICs, seems ;(.
I will look at bridge stuff later probably.
Let's change the VLAN implementation as well then. VLAN stuff is close to
top in my priority list anyway.
Thanks.
Updated by dillon almost 18 years ago
:Announcing link state changes to the userspace via route socket is critical
:to get routing related applications to work correctly - routing protocols
:are most important, but other applications might benefit from it as well.
:
:This code is adapted from OpenBSD and is only the first basic step in path
:to get correct support. Only em(4) is tested because I don't have hardware
:to test others, although bge(4) might get my attention as well in the
:future.
:
:There is one fundamental problem I'd like to get feedback about from
:developers - how to make various kernel stuff react on link state changes?
:For example various interfaces which are somehow attached to the interface
:(bridges, carp, vlans etc) should react. Ideally routing table should react
:as well (yes, no BSD or Linux kernel does that yet, but they should).
:Personally I like the idea of the hooks OpenBSD uses, but as I'm not very
:familiar of DragonFlyBSD, my personal opinion might be very far from good
:solution ;).
:
:regards,
:
:--
:Hasso Tepper
It won't build straight out of the box since a number of other
drivers are still using the existing if_link_state_change() function
call. I kinda prefer the if_link_state_change(ifp, state) API
rather then the ifp->if_link_state = ...; if_link_state_change(ifp) API.
I agree with the work, though... I'd like to see this in DragonFly
once it gets cleaned up a bit.
There seem to be a few other changes mixed into your patch. What's
the baudrate part of the patch? (I like it, I'm just not sure how
its related to the linkstate work).
-Matt
Updated by hasso almost 18 years ago
It builds for me, there is no existing if_link_state_change(ifp, state) call
in DragonFly. FreeBSD has it, but all cases in DragonFly are either
commented out in DragonFly or #defined to void(0). I don't agree with
FreeBSD though. It's not only about link up/down, but also about interface
speed changes. With my patch this case is handled as well (as it is in
OpenBSD and NetBSD).
This is about the case to call if_link_state_change(ifp) if interface speed
(baudrate) changes.
regards,
Updated by sepherosa almost 18 years ago
If there are no objections, I will commit this patch two days later.
Best Regards,
sephe
Updated by bastyaelvtars almost 18 years ago
Does this make it possible for dhclient to re-send a request when link goes up (if there are DHCP'd interfaces)?
Updated by dillon almost 18 years ago
:On 3/16/07, Hasso Tepper <hasso@estpak.ee> wrote:
:> Announcing link state changes to the userspace via route socket is critical
:> to get routing related applications to work correctly - routing protocols
:> are most important, but other applications might benefit from it as well.
:
:If there are no objections, I will commit this patch two days later.
:
:Best Regards,
:sephe
:
:--
:Live Free or Die
Sounds good, I'm all for it.
-Matt
Matthew Dillon
<dillon@backplane.com>