Bug #580

Announcing ethernet link state changes via route socket

Added by hasso almost 8 years ago. Updated over 7 years ago.

Status:ClosedStart date:
Priority:LowDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

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,

df-link-state.patch Magnifier (8.6 KB) hasso, 03/16/2007 08:20 AM

History

#1 Updated by dudu almost 8 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.

#2 Updated by sepherosa almost 8 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

#3 Updated by sepherosa almost 8 years ago

I think hasso's patch is fundamental parts for the knote
implementation you mentioned above.

Best Regards,
sephe

#4 Updated by dudu almost 8 years ago

Yes, I only read the patch after I finished writing my first mail :/

#5 Updated by hasso almost 8 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);
}

#6 Updated by hasso almost 8 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.

#7 Updated by dillon almost 8 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

#8 Updated by hasso almost 8 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,

#9 Updated by sepherosa almost 8 years ago

If there are no objections, I will commit this patch two days later.

Best Regards,
sephe

#10 Updated by bastyaelvtars almost 8 years ago

Does this make it possible for dhclient to re-send a request when link goes up (if there are DHCP'd interfaces)?

#11 Updated by dillon almost 8 years ago

:On 3/16/07, Hasso Tepper <> 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
<>

#12 Updated by sepherosa almost 8 years ago

Committed! Thanks!

Best Regards,
sephe

Also available in: Atom PDF