[Bug 274824] if_bridge / if_epair: unable to delete an arp entry after deleting associated route
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 274824] if_bridge / if_epair: unable to delete an arp entry after deleting associated route"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 274824] if_bridge / if_epair: unable to delete an arp entry after deleting associated route"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 274824] if_bridge / if_epair: unable to delete an arp entry after deleting associated route"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 274824] if_bridge / if_epair: unable to delete an arp entry after deleting associated route"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 274824] if_bridge / if_epair: unable to delete an arp entry after deleting associated route"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 274824] if_bridge / if_epair: unable to delete an arp entry after deleting associated route"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 31 Oct 2023 04:00:23 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274824
Bug ID: 274824
Summary: if_bridge / if_epair: unable to delete an arp entry
after deleting associated route
Product: Base System
Version: 13.2-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: bugs@FreeBSD.org
Reporter: pat@patmaddox.com
Created attachment 246014
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=246014&action=edit
demonstrate the buggy behavior in this PR
1. Create a bridge interface
2. Add a route to an IP address using `-iface bridge`
3. Add an arp entry for that IP
4. Delete the route
5. Delete the arp entry.
Expected result: arp entry is deleted
Actual result: "arp: writing to routing socket: No such file or directory"
The attached script (requires root) demonstrates the behavior. You can run it
as:
./arp_bug.sh bridge
./arp_bug.sh epair
./arp_bug.sh <iface>
Some notes:
- epair and bridge behave the same - the `sleep` calls are not necessary for
them
- my `wlan0` doesn't fail under the same condition. It does seem to have a race
condition, which is why I added `sleep`. It fails with the same error message,
but after the route has been re-added.
I'm not certain I've diagnosed this correctly, but I've done my best - and the
script should demonstrate it.
--
You are receiving this mail because:
You are the assignee for the bug.