[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.