Page MenuHomeFreeBSD


Authored by kib on Sep 4 2019, 8:45 PM.



The ioctl(2) intended to provide more details about the cause of the down for the link.

Eventually we might define a comprehensive list of codes for the situations. But interface also allows the driver to provide free-form null-terminated ASCII string to provide arbitrary non-formalized information. Sample implementation exists for mlx5(4), where the string is fetched from firmware controlling the port.

Currently, the interface is only utilized by ifconfig(8) to provide the hint to user, if available.

Sample output:

# ifconfig mce0
        ether e4:1d:2d:e7:10:0a
        media: Ethernet autoselect <full-duplex,rxpause,txpause>
        status: no carrier (Negotiation failure)
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Diff Detail

rS FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

What about translation of text messages? Should we use an enum for this? Or provide both?

What about translation of text messages? Should we use an enum for this? Or provide both?

Translations are not planned, the string that comes from kernel typically is provided by hardware (firmware). I added some way to extend the interface in more automation-friendly way in the next revision.

Make the IFDOWNREASON interface capable of returning standard numeric reasons, but not define any yet.
Add vendor-specific escape.

193 ↗(On Diff #61829)

Should there be some filter or forced zero at on ifdr_msg ?

ifdr_msg[sizeof(ifdr_msg) - 1] = 0 ??

193 ↗(On Diff #61829)

Kernel must zero-terminate the string. Why would utility not trust the kernel ?

193 ↗(On Diff #61829)

OK, but what about non-printable characters? Is the kernel responsible to filter this? I don't trust hardware/firmware to provide correct strings :-)

193 ↗(On Diff #61829)

I am not sure, and I think it is premature to do anything about it until there is a driver that does emit something non-printable.

Even then, I think this is a problem of the driver, and not kernel/ifconfig.

kib edited the summary of this revision. (Show Details)

Sometimes I suffer from being unable to bring the interface to "administratively shutdown" state as opposed to "operative shutdown". It would be nice if ifconfig(8) "down" was able to update status of the interface with "admindown" string or similar, and "up" was able to auto-remove such note.

Such information can be useful for code responsible for recovering procedures trying to reset a driver or synthetic tunnel-like interface to differentiate faulty or disabled interfaces.

I mean, there may be different sources of such information and not only firmware/driver.

This revision is now accepted and ready to land.Sep 17 2019, 12:59 PM
This revision was automatically updated to reflect the committed changes.