[B.A.T.M.A.N.] Set preferred mesh backhaul link

[B.A.T.M.A.N.] Set preferred mesh backhaul link

[Carlito Nueno]

Hi,

I have two access points with 2.4GHz and 5GHz radios.

Node A and Node B

Both radios are mesh via batman-adv. I can see them with batctl if.

Node A is server - batctl gw server
Node B is client

So here is my problem:

When I check batctl gwl, it shows that it uses Node A's 2.4GHz
interface. How can I set it so that it prefers 5GHz as mesh backhaul?

Thanks!

Re: [B.A.T.M.A.N.] Set preferred mesh backhaul link

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 3109 bytes --]

On Mittwoch, 1. November 2017 20:07:52 CET Carlito Nueno wrote:
> Hi,
> 
> I have two access points with 2.4GHz and 5GHz radios.
> 
> Node A and Node B
> 
> Both radios are mesh via batman-adv. I can see them with batctl if.
> 
> Node A is server - batctl gw server
> Node B is client
> 
> So here is my problem:

Just a small remark here: The batctl gateway feature [1] is not relevant for 
the routing decisions. You have to look at `batctl o` to get some information 
about the available originators and their link qualities and `batctl tl`/
`batctl tg` to find which client mac address is associated with which 
originator.


> When I check batctl gwl, it shows that it uses Node A's 2.4GHz
> interface. How can I set it so that it prefers 5GHz as mesh backhaul?

There is no official way to do that when you we assume that both interfaces 
have the same transmission quality (TQ) and you are using the default 
(B.A.T.M.A.N. IV) routing algorithm.

In B.A.T.M.A.N. IV you could modify batadv_iv_ogm_calc_tq() to apply an extra 
penalty for the 2.4GHz link. For example by changing the line 
"batadv_ogm_packet->tq = combined_tq;" to something more like:

    if (if_incoming is 2.4GHz)
        /* apply 25% penalty -> keep only 75% of original tq -> 192 / 255 */
        batadv_ogm_packet->tq = (combined_tq * 192) / BATADV_TQ_MAX_VALUE;
    else
        batadv_ogm_packet->tq = combined_tq;

I don't know exactly what your goal is but your question could also be 
interpreted as "we don't want that 2.4GHz is used". In this case, please don't 
add the 2.4GHz interface to your batman-adv interface. But I would guess that 
you don't want to do that for another reason.


The other option would be to test B.A.T.M.A.N. V (which is not the default and 
considered experimental). In theory, B.A.T.M.A.N. V should automatically 
choose the link with the highest expected throughput (check `iw dev XXXX 
station dump` for the expected throughput towards a neighbor). I would guess 
that the 5GHz link is in your case the one with the highest throughput (but 
with roughly the same packet loss), right? And this is also the reason why 
you want to use it, correct?

But there is often ran into problems when you try to use current 802.11ac 
hardware with B.A.T.M.A.N. V. The closed source firmware of these chips 
doesn't export the expected throughput. Problem here is that the rate control 
algorithm has all the information to calculate it but the rate control 
algorithm is often hidden in this closed source firmware. Hence, the open 
source driver cannot export via cfg80211 to other components (like batman-adv 
or to iw & oonf via nl80211).

A prominent example here is QCA with ath10k. We've already tried to get in 
contact with their current open source team manager. But unfortunately, he 
doesn't even understand what expected throughput is and why we need it. So if 
there are other persons out there which have the same problem, maybe they can 
also try to get in contact with QCA to get this problem solved.

Kind regards,
	Sven

[1] https://www.open-mesh.org/projects/batman-adv/wiki/Gateways

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [B.A.T.M.A.N.] Set preferred mesh backhaul link

[Carlito Nueno]

Thanks Sven for a detailed reply.

I read about batman and tried to understand it's source. Like you
said, we are not going to use 2.4GHz with batman-adv.

Yes, 5GHz is highest throughput and hence the reason for using it as
mesh backhaul. For now, batman IV is stable on QCA 9880 ath10k.

I'll try to get in touch with QCA and see if I can help in this process.

On Thu, Nov 2, 2017 at 2:16 AM, Sven Eckelmann <sven@narfation.org> wrote:
> On Mittwoch, 1. November 2017 20:07:52 CET Carlito Nueno wrote:
>> Hi,
>>
>> I have two access points with 2.4GHz and 5GHz radios.
>>
>> Node A and Node B
>>
>> Both radios are mesh via batman-adv. I can see them with batctl if.
>>
>> Node A is server - batctl gw server
>> Node B is client
>>
>> So here is my problem:
>
> Just a small remark here: The batctl gateway feature [1] is not relevant for
> the routing decisions. You have to look at `batctl o` to get some information
> about the available originators and their link qualities and `batctl tl`/
> `batctl tg` to find which client mac address is associated with which
> originator.
>
>
>> When I check batctl gwl, it shows that it uses Node A's 2.4GHz
>> interface. How can I set it so that it prefers 5GHz as mesh backhaul?
>
> There is no official way to do that when you we assume that both interfaces
> have the same transmission quality (TQ) and you are using the default
> (B.A.T.M.A.N. IV) routing algorithm.
>
> In B.A.T.M.A.N. IV you could modify batadv_iv_ogm_calc_tq() to apply an extra
> penalty for the 2.4GHz link. For example by changing the line
> "batadv_ogm_packet->tq = combined_tq;" to something more like:
>
>     if (if_incoming is 2.4GHz)
>         /* apply 25% penalty -> keep only 75% of original tq -> 192 / 255 */
>         batadv_ogm_packet->tq = (combined_tq * 192) / BATADV_TQ_MAX_VALUE;
>     else
>         batadv_ogm_packet->tq = combined_tq;
>
> I don't know exactly what your goal is but your question could also be
> interpreted as "we don't want that 2.4GHz is used". In this case, please don't
> add the 2.4GHz interface to your batman-adv interface. But I would guess that
> you don't want to do that for another reason.
>
>
> The other option would be to test B.A.T.M.A.N. V (which is not the default and
> considered experimental). In theory, B.A.T.M.A.N. V should automatically
> choose the link with the highest expected throughput (check `iw dev XXXX
> station dump` for the expected throughput towards a neighbor). I would guess
> that the 5GHz link is in your case the one with the highest throughput (but
> with roughly the same packet loss), right? And this is also the reason why
> you want to use it, correct?
>
> But there is often ran into problems when you try to use current 802.11ac
> hardware with B.A.T.M.A.N. V. The closed source firmware of these chips
> doesn't export the expected throughput. Problem here is that the rate control
> algorithm has all the information to calculate it but the rate control
> algorithm is often hidden in this closed source firmware. Hence, the open
> source driver cannot export via cfg80211 to other components (like batman-adv
> or to iw & oonf via nl80211).
>
> A prominent example here is QCA with ath10k. We've already tried to get in
> contact with their current open source team manager. But unfortunately, he
> doesn't even understand what expected throughput is and why we need it. So if
> there are other persons out there which have the same problem, maybe they can
> also try to get in contact with QCA to get this problem solved.
>
> Kind regards,
>         Sven
>
> [1] https://www.open-mesh.org/projects/batman-adv/wiki/Gateways