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

How to prioritize wired links? #993

Open
ggsnpdsn opened this issue Mar 29, 2023 · 8 comments
Open

How to prioritize wired links? #993

ggsnpdsn opened this issue Mar 29, 2023 · 8 comments

Comments

@ggsnpdsn
Copy link

I have four nodes running libremesh, connected one by one through a wired network, the first connected to the internet, and the fifth node moving around these four nodes. I find that I always access the internet through the path directly connected to the first node. I expect the fifth node to select the node with the strongest signal to access the internet. Do I need to set the batman adv parameter? How to change it?

@ilario
Copy link
Member

ilario commented Mar 30, 2023

Hi @ggsnpdsn !
How do you see that you "always access the internet through the path directly connected to the first node"?
I don't know if there is a smart way to have the routing protocols using the cable over the wifi. I hope they will do it when they see that the packets loss on the wifi is higher than the one on the cable...

@ggsnpdsn
Copy link
Author

Due to the poor performance of 802.11r testing, I want to use this solution as an alternative

@ilario
Copy link
Member

ilario commented Apr 7, 2023

Try removing this line:

uci:set("babeld", owrtInterfaceName, "type", "wireless")

@ilario
Copy link
Member

ilario commented Apr 13, 2023

@ggsnpdsn please let us know if the suggestion helps!
In the positive case, I think that we can replace that line with an option that allows the user to have it or not, but leaving it off by default.
I think that we have that line for cases in which the "ground routing" (see what it is on #443) is used, but I never heard anybody saying that they are using it.

@ggsnpdsn
Copy link
Author

The effect is not obvious, and the data flow will be interrupted. Sometimes it is interrupted for 2s, sometimes it is interrupted for 10s, and sometimes it may be 20s. The interruption time is not a fixed value, it is a random time

@ilario
Copy link
Member

ilario commented Apr 25, 2023

? Is this the effect of removing that line??

Another thing that you can try is to use BATMAN_V instead of BATMAN_IV, see #1014

@ggsnpdsn
Copy link
Author

? Is this the effect of removing that line??
YES
Another thing that you can try is to use BATMAN_V instead of BATMAN_IV, see #1014

BATMAN_V performance is worse, the problem still exists, and the forwarding rate is more unstable

@ilario
Copy link
Member

ilario commented Nov 7, 2024

For speeding up the routing decisions, please try decreasing the time between Batman-adv hello packets (Originator Messages OGM), as documented here:

option batadv_orig_interval '2000' # BATMAN-adv will send one Originator Message (OGM) packet every 2000 ms (2 s). This value should be ok for the static networks, in which the LibreMesh routers are not moving. If you have a LibreMesh node moving (e.g. in your backpack) consider decreasing this value. A smaller value means that BATMAN-adv will take less time for realizing which links are better, but will generate more background traffic on all the interfaces.

The current value is large as most networks are rather static.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants