debugnet(4): Infer non-server connection parameters

[cem]

Summary

Loosen requirements for connecting to debugnet-type servers. Only require a
destination address; the rest can theoretically be inferred from the routing
table. (If the routing table is potentially damaged, one can always specify
the parameters explicitly with the same option flags as before.

Relax corresponding constraints in netdump(4) and move ifp validation to
debugnet connection time.

Submitted by: John Reimer <john.reimer AT emc.com> (earlier version)

Test Plan

testvm# sysctl debug.kdb.panic=1
debug.kdb.panic:panic: kdb_sysctl_panic
...
KDB: enter: panic
[ thread pid 697 tid 100102 ]
Stopped at      kdb_enter.part.5+0x27:  movq    $0,0x139348e(%rip)
db> netdump -s x.y.z.d debugnet: overwriting mbuf zone pointers
debugnet_connect: Destination address is on link.
debugnet_connect: Connecting to x.y.z.d:20023 from a.b.c.d:20024 on vtnet0
debugnet_connect: searching for server MAC...
debugnet_handle_arp: got server MAC address aa:bb:cc:dd:ee:ff
netdumping to x.y.z.d (aa:bb:cc:dd:ee:ff)
Dumping 96 out of 475 MB:..17% ..34%..50%..67% ..84%..100%
netdump finished.
debugnet: restoring mbuf zone pointers

Dump complete

[cem]

Rebase on lexer API change.

[markj]

sys/netinet/netdump/netdump_client.c

414

This check doesn't really make sense for a DDB-invoked netdump. The panicking thread may well be in a non-default vnet, in which case we should switch to vnet0 for the purpose of the lookup, like you do for the routing table lookup above. For configuration coming from dumpon I think it still makes sense for now to reject the request when running in vnet0.

[cem]

sys/netinet/netdump/netdump_client.c

414

Let's discuss on D21460 instead.

[markj]

sys/netinet/netdump/netdump_client.c

414

For posterity: I meant to write "when _not_ running in vnet0."