Page MenuHomeFreeBSD

netdump: check the support status of the interface
ClosedPublic

Authored by mhorne on Thu, May 12, 3:47 PM.

Details

Summary

If the interface does not support debugnet we should bail early, rather
than having the user find this out at the time of the panic. dumpon(8)
already expects this return value and will print a helpful error message.

Test Plan

With this patch:

# dumpon -s 192.168.1.107 -c 192.168.1.112 dwc0
dumpon: Unable to configure netdump because the interface driver does not yet support netdump.

Diff Detail

Repository
R10 FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

Seems very reasonable to me. Thanks!

This revision is now accepted and ready to land.Thu, May 12, 3:54 PM

Hmmm I note that dumpon(8) also expects to receive ENXIO if the interface is not up, so we could add that check here too.

The question becomes: should we deny attempts to configure netdump on a downed interface that might later be brought up? I don't think there's anything to prevent the reverse. Most likely I will just leave it.

Hmmm I note that dumpon(8) also expects to receive ENXIO if the interface is not up, so we could add that check here too.

Where do we do that today? I see the ENXIO check in dumpon but can't see the corresponding IFF_UP check in the kernel.

The question becomes: should we deny attempts to configure netdump on a downed interface that might later be brought up? I don't think there's anything to prevent the reverse. Most likely I will just leave it.

Yes I think it's better to be permissive and assume the user knows what they're doing here. Maybe it'd be appropriate for dumpon(8) to print a warning in that case.

Hmmm I note that dumpon(8) also expects to receive ENXIO if the interface is not up, so we could add that check here too.

Where do we do that today? I see the ENXIO check in dumpon but can't see the corresponding IFF_UP check in the kernel.

In debugnet_connect() we check the IFF_UP flag. Obviously, failing the check at that point means we cannot continue.

The question becomes: should we deny attempts to configure netdump on a downed interface that might later be brought up? I don't think there's anything to prevent the reverse. Most likely I will just leave it.

Yes I think it's better to be permissive and assume the user knows what they're doing here. Maybe it'd be appropriate for dumpon(8) to print a warning in that case.

If this is fairly trivial to implement I will do it.