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

Vadim Goncharov <[email protected]>
Newsgroups gmane.os.freebsd.devel.hackers
Message-ID <[email protected]>
On Tue, 25 Aug 2026 17:29:16 -0400
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?)

Don't know if it's in any way related, but my home alc0 toggles UP/DOWN
in dmesg at least twice during every boot (didn't check what happens
with carrier). So may be for some drivers it's already here :)


-- 
WBR, @nuclight
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.