Re: "Downing" interfaces on reboot cmd or a panic

On 8/25/2026 19:15, Warner Losh wrote:
>
> On Tue, Aug 25, 2026 at 3:29 PM Karl Denninger <[email protected]> wrote:
>
>     None of the above do.
>
>     "shutdown -r" does, as it calls back through the "stop" chain in
>     netif.  But a reboot command (or kernel panic) does not; the
>     latter obviously can't and the former doesn't go through any of
>     those nicities at all.
>
>     I've never seen this cause trouble on a LAN but when the machine
>     in question is an Internet gateway in some cases ONTs in
>     particular want to see the interface carrier disappear
>     specifically to tell it that the line was reset.  If it doesn't
>     then on machine restart it may not remain properly associated with
>     the ONT and thus you get no -- or partial -- connectivity.
>
>     On a cold boot this isn't an issue because the interface was never
>     up in the first place, but on restarts it can be.  I've got an ISP
>     here that sometimes will not restore connectivity properly in this
>     instance, but on a shutdown (or power cycle) it never has a
>     problem -- and it appears, from watching the interface LEDs, that
>     the lack of carrier-toggling is responsible. While an "attended"
>     restart is easy ("don't use reboot") what's not-so-much is if the
>     machine takes a panic while nobody is there to attend it and
>     connectivity does not come back up.
>
>     I'm curious if anyone has thought about how this might be better
>     handled (e.g. is this something that perhaps the startup sequence
>     should have a flag for and, if its present, then all interfaces
>     are "down"ed first as a protective measure to force carrier off
>     before being configured?)
>
>     Thoughts?
>
> Shouldn't the NIC drivers be doing this shutdown as part of their 
> newbus shutdown callbacks?
>
Probably.  Note that this specific instance where I'm running into it 
now is an "ix" device with a 1Gbe module in this slot, which then goes 
across a short cable to the ONT port.  I'm on 15.1-STABLE that is a 
nanobsd instance (updated with the last set of CVE notices) as I burn it 
to read-only-mounted media to ensure it will come back up after power 
events.

I don't believe that's related though and because of how my ISP sets 
allocations (it will give me back the same IPv4 and v6 delegations in 
nearly all instances provided I do not change the MAC address of the 
hardware connected to the ONT, although this is not guaranteed and it 
also wants the same transmitted DUID associated with said MAC or it gets 
VERY angry on IPv6 and will lock out my allocation entirely until I call 
them.  The other amusement is that for IPv6 it does not immediately, 
upon handing out the delegated /56 send a default route either; they 
send that on a timed basis so v4 comes up and then a few minutes later, 
although I have the v6 delegation immediately, the route shows up) 
swapping devices on that box or swapping the box itself for testing 
purposes is something that, absent a hardware failure, often leads to 
unpleasant surprises.

-- 
Karl Denninger
[email protected]
/The Market Ticker/
/[S/MIME encrypted email preferred]/