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.

Sign up for GitHub

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

Jump to bottom

batman-adv: per interface hop_penalty #2754

Open
herbetom opened this issue Jan 7, 2023 · 2 comments · May be fixed by #3454
Open

batman-adv: per interface hop_penalty #2754

herbetom opened this issue Jan 7, 2023 · 2 comments · May be fixed by #3454
Labels
0. type: feature-request

Comments

@herbetom
Copy link
Contributor

herbetom commented Jan 7, 2023

As a result of #1942 gluon.mesh_batman_adv.hop_penalty was implemented. This allows setting the hop penealty for the meshif (the complete node).

Apparently it's also possible to set an hop penealty for the hardif. Those are the interfaces where bat0 is the master interface:

        meshif <netdev> hop_penalty|hp             [penalty]            display or modify hop_penalty setting
        hardif <netdev> hop_penalty|hp             [penalty]            display or modify hop_penalty setting

Currently the hop penealty for all of those hardifs is 0:

# batctl interface
mesh-vpn: active
primary0: active
mesh1: active
mesh0: active
vx_mesh_other: active
# batctl mesh-vpn hop_penalty
0
# batctl primary0 hop_penalty
0
# batctl mesh1 hop_penalty
0
# batctl mesh0 hop_penalty
0
# batctl vx_mesh_other hop_penalty
0

I haven't yet played with this but could imagine scenarios where it could be helpful to set an higher hop penealty on an interface.
@maurerle
Copy link
Member

maurerle commented Jan 9, 2023 •
edited
Loading

I tried this out having it wired like this, using a v2022 firmware which uses BATMAN_V and wireguard as VPN:

Internet <--- LAN ---> gluon1 <--- WIFI-MESH --->  Gluon2
     ^-------------------- LAN ---------------------^
  1. I looked into batctl o on Gluon2 which showed that most links had the indicating star at mesh-vpn
  2. I then set batctl hardif mesh-vpn hop_penalty 100000 on Gluon2
  3. all routes to originators are turning towards the mesh0 except for the route to the supernode (which still shows a TP of 372 -> which is impossible as the test uplink has 40/5)
  4. on the map the link is still shown as "connected to supernode"
  5. the download speed is still as slow as Gluon2 can do (about 1MB/s) instead of >4MB/s of gluon1

I don't know if i need to tweak more, but that was just a quick test.

@maurerle
Copy link
Member

maurerle commented May 1, 2023 •
edited
Loading

I just retested this with BATMAN_IV and had the same result -> the TQ is reduced (from 255 to 14 using a hop_penalty of 240) in batctl o, yet its own mesh-vpn is still preferred even though it is slower (batctl gwl still shows the supernode as next-hop).
Thats also in line with the expected speed.
I had the same result if the WIFI-Mesh in aboves schematic outline is replaced with a wire.

@ecsv do you have a clue or can hint me into a direction?

It worked using BATMAN_IV after having the setup running for a few hours.
Now I am asking myself if I did not wait long enough in BATMAN_V

@maurerle maurerle linked a pull request Mar 16, 2025 that will close this issue
Draft
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
0. type: feature-request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

RFC: add hop penalty per hardif setting ffac/gluon
3 participants
@AiyionPrime @herbetom @maurerle