mirror of
https://github.com/openwrt/openwrt.git
synced 2026-10-26 10:09:29 +04:00
Gennaro Cimmino
174b87e3e8
The routes waiting on a gateway are keyed on the gateway address alone, so the neighbour that answers writes its MAC into every route that names that address, whichever link the route leaves by. The neighbour table is keyed on the device as well as the address, for the reason that one address on two links is two neighbours. Keep the device a route reaches its gateway on, and let a neighbour update touch only the routes that were resolved on it. The device is kept as an index and not a pointer: the work item runs long after the event and holds no reference to anything. A route whose gateway answers on the route's own nexthop device is unaffected, which is every route whose gateway is reachable the way the kernel was told it is. What changes is the route whose neighbour answers somewhere else: it took the MAC of whichever neighbour of that address answered last, and now it waits for the one on its own device, which is the neighbour the kernel forwards through. IPv4 gets there through a link-scope route for the gateway on a second device, through a second routing table, or through RTNH_F_ONLINK out of a device the gateway is not on - fib_check_nh_v4_gw() resolves the gateway with the nexthop device and table of the route being added, so each of those validates. Which switches run this at all: the RTL839x, whose L3 setup is not behind the RTL930x offload symbol, and an RTL930x built with that symbol, which none of the six subtarget configs sets. The RTL838x and RTL931x have no setup, so their notifiers return on the missing one. Assisted-by: Claude:claude-opus-5 Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net> Link: https://github.com/openwrt/openwrt/pull/25507 Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>