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/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283102 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 sho= uld work when enabled on boot or when it's enabled on the running system, as dumpdev is set before interface renaming happens. Example:=20 ifconfig_vtnet0_name=3D"uplink" ifconfig_uplink=3D"inet 192.168.255.3/24" defaultrouter=3D"192.168.255.1" vlans_uplink=3D"vlanone vlantwo" create_args_vlanone=3D"vlan 1001" ifconfig_vlanone=3D"inet 10.1.1.1/24" create_args_vlantwo=3D"vlan 1002" ifconfig_vlantwo=3D"inet 10.1.2.1/24" dumpdev=3D"uplink" dumpon_flags=3D"-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=3D"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 dev= ices well enough, so that dumpdev=3Dvtnet0 would always work). I tested this last over a year ago, but I'm quite confident this is still t= he status quo. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-283102-227>