> > > Link state changes are generally not logged by the kernel. > > > Only lmc(4) and sppp(4) tend to fill the syslog with "useless" status > > > messages. The other interfaces I use seem to "behave". > > well, in general I agree with you, but I think that the special nature > of WAN lines warrants special treatment, too.
Then the entire idea is to improve the drivers to erradicate this special treatment that makes them believe that they should syslog of kernel printf us to death. That is not the solution you want. > > > If link state changes need to be logged than it should be done in an > > > interface independent way so that all interface will profit from it. > > I already try to log it using ifstated, but that doesn't work too well, > and also doesn't give sufficient detail about the cause of the problem. Of course not. So you want kernel printfs instead? And then someone of course will want to use serial consoles, and not do any measurement to see how serial console printf's work... polled. > Not useful enough to hold the resulting logs under the nose of a > carrier's tech supporter. > I could also track bgpd's "lost connection to peer" messages, but that > doesn't help me too much either - was it line failure, remote end's > reboot, network overload, misconfiguration on either (which?) end, etc. > pp ? Fixing this will require a framework. Not just kernel printf.
