Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

anygw routing issue #1078

Closed
pony1k opened this issue Feb 7, 2024 · 2 comments · Fixed by #1079
Closed

anygw routing issue #1078

pony1k opened this issue Feb 7, 2024 · 2 comments · Fixed by #1079

Comments

@pony1k
Copy link
Contributor

pony1k commented Feb 7, 2024

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
Copy link
Member

ilario commented Feb 8, 2024

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

pony1k added a commit to pony1k/lime-packages that referenced this issue Feb 8, 2024
Make sure anygw is not used for communication with hosts in the same
network.
Fixes libremesh#1078
@G10h4ck
Copy link
Member

G10h4ck commented Feb 8, 2024

@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

pony1k added a commit to pony1k/lime-packages that referenced this issue Feb 8, 2024
Make sure anygw is not used for communication with hosts in the same
network.
Fixes libremesh#1078
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants