Date: Tue, 03 Dec 2024 16:31:33 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 283102] Dumpon to network cannot handle renamed interfaces properly Message-ID: <bug-283102-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283102 Bug ID: 283102 Summary: Dumpon to network cannot handle renamed interfaces properly Product: Base System Version: 13.4-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: grembo@FreeBSD.org This used to panic, which was fixed in #273715. There's still an issue that the admin basically has to decide if dumpon should work when enabled on boot or when it's enabled on the running system, as dumpdev is set before interface renaming happens. Example: ifconfig_vtnet0_name="uplink" ifconfig_uplink="inet 192.168.255.3/24" defaultrouter="192.168.255.1" vlans_uplink="vlanone vlantwo" create_args_vlanone="vlan 1001" ifconfig_vlanone="inet 10.1.1.1/24" create_args_vlantwo="vlan 1002" ifconfig_vlantwo="inet 10.1.2.1/24" dumpdev="uplink" dumpon_flags="-k /root/netdump_public.pem -i 0 -c 192.168.255.3 -s 192.168.255.1 -g 192.168.255.1" The example above will not work when started during boot (for which dumpdev="vtnet0" would be required), but will after the system is running. Not sure if this is a "kern" issue or more of a userland rc script issue (depending on where it is fixed). It might be possible to track renamed devices well enough, so that dumpdev=vtnet0 would always work). I tested this last over a year ago, but I'm quite confident this is still the status quo. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-283102-227>