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.
Details
Details
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
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.