libremesh / lime-packages

LibreMesh packages configuring OpenWrt for wireless mesh networking
https://libremesh.org/
GNU Affero General Public License v3.0
281 stars 96 forks source link

anygw routing issue #1078

Closed pony1k closed 9 months ago

pony1k commented 9 months ago

I was wondering why I could not reach one router with it's ipv4-address configured on br-lan, but could reach it using its link local ipv6 address. When I looked at the routers main routing table, it looked like this:

root@tdw8970:~# ip route
default via 10.13.0.43 dev wlan0-mesh_17 proto babel onlink
10.13.0.0/24 dev anygw proto kernel scope link src 10.13.0.1
10.13.0.0/24 dev br-lan proto kernel scope link src 10.13.0.4
10.43.1.0/24 via 10.13.0.43 dev wlan0-mesh_17 proto babel onlink
10.44.1.0/24 via 10.13.0.5 dev lan2_17 proto babel onlink

Usually it looks like this:

root@tdw8970:~# ip route
default via 10.13.0.43 dev wlan0-mesh_17 proto babel onlink
10.13.0.0/24 dev br-lan proto kernel scope link src 10.13.0.4
10.13.0.0/24 dev anygw proto kernel scope link src 10.13.0.1
10.43.1.0/24 via 10.13.0.43 dev wlan0-mesh_17 proto babel onlink
10.44.1.0/24 via 10.13.0.5 dev lan2_17 proto babel onlink

(The order of the 10.13.0.0/24 routes is swapped) I think that all I had done was booting the router. Maybe I did some vi /etc/config/lime-node and some lime config and some lime apply, but nothing special, really. One way to artificially produce this condition is to remove the address on br-lan and add it back. Anyway, the kernel always seems to choose the first one, and if it has dev anygw, anygw ether address is used and the packet does not arrive. If the router in question is the gateway to the internet, the internet stops. Uci configuration does not seem to allow to not add a prefix route, but it gives us the option metric. I propose we use it to give the prefix route of anygw a higher metric, like so:

config interface 'lm_net_br_lan_anygw_if'
        option proto 'static'             
        option device 'anygw'          
        option auto '1'                  
        option netmask '255.255.255.0'    
        option ipaddr '10.13.0.1'      
        option ip6addr 'fd0d:fe46:8ce8::1/64'
        option metric '2147483647'

Then the routing table looks like this:

default via 10.13.0.43 dev wlan0-mesh_17 proto babel onlink 
10.13.0.0/24 dev br-lan proto kernel scope link src 10.13.0.4 
10.13.0.0/24 dev anygw proto static scope link metric 2147483647 
10.43.1.0/24 via 10.13.0.43 dev wlan0-mesh_17 proto babel onlink 

The kernel will always choose the route with dev br-lan and the problem does no longer occur.

ilario commented 9 months ago

The proposed solution sounds good to me! @G10h4ck @spiccinini @altergui any better proposal?

G10h4ck commented 9 months ago

@pony1k I suppose you tested it and worked fine, in that case it seems good to me to, and may explain a few erratically network breakage, that would not happen anymore with this change