batadv gw_mode client 0?

batadv gw_mode client 0?

[Rob Cowart]

Hi,

  We've been using batman with alfred and MQTT on raspbian for about 3 years.  We found it to be useful up to about 15 nodes, and then we'd saturate the wifi.  Then we downgraded the driver and we can get slightly over 30.  but something we found was all of our nodes were using gw_mode client 0, and we realized this isn't listed in the spec.  Do you know what it does in that case, does it use the default of 20?

Thanks,
Rov

Re: batadv gw_mode client 0?

[Sven Eckelmann]

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

On Monday, 15 June 2020 22:45:34 CEST Rob Cowart wrote:
[...]
>but something we found was all of our nodes were using gw_mode client 0, and we realized this isn't listed in the spec.  Do you know what it does in that case, does it use the default of 20?

I have no idea where "client 0" is coming from. This is not a valid output 
from batctl or the sysfs files. I must now assume that 0 refers to the 
selection class.

selection class 0 is not valid for B.A.T.M.A.N. IV and will also be rejected 
by the netlink and sysfs code for B.A.T.M.A.N. IV.

If you were really able to set this somehow(tm) then it should (mis)behave 
like gw class 2 (when I remember correctly).

Kind regards,
	Sven

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

Re: batadv gw_mode client 0?

[Sven Eckelmann]

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

On Wednesday, 24 June 2020 21:23:09 CEST Rob Cowart wrote:
[...]
>   I have another question regarding batman, is there a way to connect to the nodes using only batman?

batman-adv doesn't have any special TCP like protocol or remote shell access 
protocol. But you can either try to find the neighbors using link local IPv6 
and directly use this to connect to the remote:

    ping ff02::1%bat0
    # or
    ping ff02::1%wlan0

And if you see a couple of dups like this:

    $ ping ff02::1%wlan0
    PING ff02::1%wlan0 (ff02::1%22): 56 data bytes
    64 bytes from fe80::84ec:1cff:fea1:5629: seq=0 ttl=64 time=1.211 ms
    64 bytes from fe80::6c39:baff:fe1c:6d11: seq=0 ttl=64 time=7.107 ms (DUP!)

then you can just ssh to this node over IPv6 link local like this:

    ssh fe80::6c39:baff:fe1c:6d11%wlan0

Just make sure that you are actually add the interface name + "%" separator.

>   We have a situation where we've deployed batman V / alfred mesh networks (in several factories in Mexico, US and China) and then found dnsmasq is not up to the task of keeping our ips straight (with 20-30 nodes per mesh even) over months and years.  So we're trying to remotely change them all to static, but midway through the mesh (or whatever part of the mesh lets us ssh to the nodes) breaks down.  The nodes still show on batctl 
> pi@raspberrypi:~ $ sudo batctl n
> [B.A.T.M.A.N. adv 2018.4-23-g89ba2134-dirty, MainIF/MAC: wlan0/b8:27:eb:fb:4e:58 (bat0/d6:86:8d:7d:39:4d BATMAN_V)]
> IF             Neighbor              last-seen
> b8:27:eb:4e:73:6d   25.330s (        1.0) [     wlan0]
> b8:27:eb:ff:0e:b6   23.320s (        1.0) [     wlan0]
> b8:27:eb:08:13:37   18.850s (        1.0) [     wlan0]
> b8:27:eb:aa:1e:6d   37.010s (        1.0) [     wlan0]
> b8:27:eb:35:c6:77   63.590s (        1.0) [     wlan0]
> b8:27:eb:e9:34:41   18.280s (        1.0) [     wlan0]
> b8:27:eb:84:ca:90   30.560s (        1.0) [     wlan0]
> b8:27:eb:1e:eb:cd   27.410s (        1.0) [     wlan0]
> b8:27:eb:cb:80:34   23.100s (        1.0) [     wlan0]

Not sure what the ELP interval is here but the last seen is extremely high. I 
would guess that the lower link actually broke down and the neighbor entries
just  didn't time out yet.

> Also I was trying to figure out how to snoop what alfred is doing, since our MQTT goes over alfred over batman and that's what's not working...

There was a wireshark dissector written by some person [1]. But it might need 
some updating to get it working with newer wireshark versions.

> So if you started from scratch how would you architect, is there a way to use batman for everything?

But the combination mqtt with alfred sounds weird. Alfred just stores some 
very simple "facts" and distributes it slowly through the network. But MQTT is 
a messaging protocol and is often used for realtime message transport. So in 
most situations you would skip alfred and just use mqtt over whatever network 
you want. No special batman-adv stuff needed.

Kind regards,
	Sven

[1] https://github.com/basros/alfred-dissector

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

Re: batadv gw_mode client 0?

[Sven Eckelmann]

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

On Wednesday, 24 June 2020 21:43:18 CEST Rob Cowart wrote:
> >    ssh fe80::6c39:baff:fe1c:6d11%wlan0
> Yes we knew this, this is Standard Operating Procedure, but atm nothing responds on ping.

When nothing reacts to pings on wlan0 then your lower link is most likely 
broken. batman-adv can also not help here when the link on which it operates 
is "dead".

> > Not sure what the ELP interval is here but the last seen is extremely high. I 
> > would guess that the lower link actually broke down and the neighbor entries
> > just  didn't time out yet.
> How do I tell you what the ELP is?

Echo Location Protocol [1]. It is similar to the OGM messages in 
B.A.T.M.A.N. IV - but only used between single hop neighbors (and sometimes 
also as unicast instead of broadcast)

> we (my boss who tries to be a software engineer) have definitely messed a lot with the batctl settings.

The elp interval can be checked on recent batctl versions using:

    batctl hardif wlan0 elp_interval

Or on systems which are using sysfs for configuration:

    cat /sys/class/net/wlan/batman_adv/elp_interval


The OGM(2) interval can be checked using

    batctl meshif bat0 orig_interval

Or on systems which are using sysfs for configuration:


    cat /sys/class/net/bat0/mesh/orig_interval


Both values are in milliseconds


> pi@raspberrypi:~/xeco-master/enola-daemon $ sudo batctl s 

The ELP packets (and much more) are part of mgmt_tx/mgmt_tx_bytes/mgmt_rx/
mgmt_rx_bytes.


> pi@raspberrypi:~/xeco-master/enola-daemon $ sudo batctl td bat0
> 14:42:51.260179 IP6 fe80::4829:b9ff:fea5:8a76.16962 > fe80::d486:8dff:fe7d:394d.16962: UDP, length 218

ELP messages are not sent on top of bat0 but on the lower interface (wlan0 in 
your case). So you have would have to run "batctl td wlan0". Or create a pcap 
on wlan with tcpdump and open it in a recent version of wireshark.

Kind regards,
	Sven

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

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

Re: batadv gw_mode client 0?

[Sven Eckelmann]

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

On Wednesday, 24 June 2020 22:02:38 CEST Rob Cowart wrote:
[....]
> Is anything wrong with these?

Most likely not, but someone on the mailing list with deeper knowledge on 
B.A.T.M.A.N. V's echo location protocol could actually check whether non-
symmetric settings on different nodes could create problems or not. Or if 
having both ELP and OGM2 interval set to the same value could have negative 
side effects.


> Our gateway:
> 
> pi@raspberrypi:~/xeco-master/enola-daemon $ cat /sys/class/net/wlan0/batman_adv/elp_interval 
> 500
> pi@raspberrypi:~/xeco-master/enola-daemon $ cat /sys/class/net/bat0/mesh/orig_interval
> 1000
> 
> nodes:
> pi@raspberrypi:~ $ cat /sys/class/net/wlan0/batman_adv/elp_interval
> 30000
> pi@raspberrypi:~ $ cat /sys/class/net/bat0/mesh/orig_interval
> 30000
[...]

On Wednesday, 24 June 2020 21:23:09 CEST Rob Cowart wrote:
> IF             Neighbor              last-seen
> b8:27:eb:4e:73:6d   25.330s (        1.0) [     wlan0]
> b8:27:eb:ff:0e:b6   23.320s (        1.0) [     wlan0]
> b8:27:eb:08:13:37   18.850s (        1.0) [     wlan0]
> b8:27:eb:aa:1e:6d   37.010s (        1.0) [     wlan0]
> b8:27:eb:35:c6:77   63.590s (        1.0) [     wlan0]
> b8:27:eb:e9:34:41   18.280s (        1.0) [     wlan0]
> b8:27:eb:84:ca:90   30.560s (        1.0) [     wlan0]
> b8:27:eb:1e:eb:cd   27.410s (        1.0) [     wlan0]
> b8:27:eb:cb:80:34   23.100s (        1.0) [     wlan0]

Btw. it looks to me like B.A.T.M.A.N. V is a really bad choice for your setup. 
All links have the throughput value 1.0 Mbit/s. This sounds to me like the 
wifi driver doesn't provide the required expected_throughput. And so you have 
a REALLY, REALLY, REALLY bad metric when you are using 1.0 everywhere. So if 
you want to continue experimenting with B.A.T.M.A.N. V then you should try to 
get this fixed in your wifi driver or just switch to B.A.T.M.A.N. IV with 
increased multicast rate.


> Lots of stuff I don't understand here, looks like loopback is very busy?
 
Not sure what you mean here with loopback. I will just leave the whole output 
here in case somebody else on the mailing list wants to figure it out.
 
> pi@raspberrypi:~/xeco-master/enola-daemon $ sudo batctl td wlan0
> 15:01:52.075412 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 704843962, v 15, interval 500ms, length 20
> 15:01:52.076036 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.076507 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.076854 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.077456 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.077937 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.078028 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.078657 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.079155 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.079246 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.079894 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.080480 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.080965 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.081435 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.081904 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.081995 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.082435 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.082539 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.082957 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 15:01:52.415359 BAT b8:27:eb:fb:4e:58: OGM2 via neigh b8:27:eb:fb:4e:58, seq 500807384, throughput MAX, ttl 50, v 15, length 60, tvlv_len 40
> 	TVLV TTv1: OGM DIFF [.] ttvn=1 vlan_num=1 entry_num=0
> 		VLAN ID -1, crc 0xf0cfd284
> 	TVLV GWv1: down 10.0Mbps, up 2.0Mbps
> 	TVLV DATv1: enabled
> 15:01:52.423153 BAT b8:27:eb:fb:4e:58: OGM2 via neigh b8:27:eb:aa:1e:6d, seq 500807384, throughput 15.0Mbps, ttl 49, v 15, length 60, tvlv_len 40
> 	TVLV TTv1: OGM DIFF [.] ttvn=1 vlan_num=1 entry_num=0
> 		VLAN ID -1, crc 0xf0cfd284
> 	TVLV GWv1: down 10.0Mbps, up 2.0Mbps
> 	TVLV DATv1: enabled
> 15:01:52.424280 BAT b8:27:eb:fb:4e:58: OGM2 via neigh b8:27:eb:cb:80:34, seq 500807384, throughput 14.9Mbps, ttl 49, v 15, length 60, tvlv_len 40
> 	TVLV TTv1: OGM DIFF [.] ttvn=1 vlan_num=1 entry_num=0
> 		VLAN ID -1, crc 0xf0cfd284
> 	TVLV GWv1: down 10.0Mbps, up 2.0Mbps
> 	TVLV DATv1: enabled
> 15:01:52.428556 BAT b8:27:eb:fb:4e:58: OGM2 via neigh b8:27:eb:84:ca:90, seq 500807384, throughput 15.0Mbps, ttl 49, v 15, length 60, tvlv_len 40
> 	TVLV TTv1: OGM DIFF [.] ttvn=1 vlan_num=1 entry_num=0
> 		VLAN ID -1, crc 0xf0cfd284
> 	TVLV GWv1: down 10.0Mbps, up 2.0Mbps
> 	TVLV DATv1: enabled
> 15:01:52.575301 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 704843963, v 15, interval 500ms, length 20
> 15:01:52.575486 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200

Kind regards,
	Sven

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

Re: batadv gw_mode client 0?

[Rob Cowart]

> On Jun 24, 2020, at 3:13 PM, Sven Eckelmann <sven@narfation.org> wrote:
> 
> On Wednesday, 24 June 2020 22:02:38 CEST Rob Cowart wrote:
> [....]
>> Is anything wrong with these?
> 
> Most likely not, but someone on the mailing list with deeper knowledge on 
> B.A.T.M.A.N. V's echo location protocol could actually check whether non-
> symmetric settings on different nodes could create problems or not. Or if 
> having both ELP and OGM2 interval set to the same value could have negative 
> side effects.
> 
> 
>> Our gateway:
>> 
>> pi@raspberrypi:~/xeco-master/enola-daemon $ cat /sys/class/net/wlan0/batman_adv/elp_interval 
>> 500
>> pi@raspberrypi:~/xeco-master/enola-daemon $ cat /sys/class/net/bat0/mesh/orig_interval
>> 1000
>> 
>> nodes:
>> pi@raspberrypi:~ $ cat /sys/class/net/wlan0/batman_adv/elp_interval
>> 30000
>> pi@raspberrypi:~ $ cat /sys/class/net/bat0/mesh/orig_interval
>> 30000
> [...]
> 
> On Wednesday, 24 June 2020 21:23:09 CEST Rob Cowart wrote:
>> IF             Neighbor              last-seen
>> b8:27:eb:4e:73:6d   25.330s (        1.0) [     wlan0]
>> b8:27:eb:ff:0e:b6   23.320s (        1.0) [     wlan0]
>> b8:27:eb:08:13:37   18.850s (        1.0) [     wlan0]
>> b8:27:eb:aa:1e:6d   37.010s (        1.0) [     wlan0]
>> b8:27:eb:35:c6:77   63.590s (        1.0) [     wlan0]
>> b8:27:eb:e9:34:41   18.280s (        1.0) [     wlan0]
>> b8:27:eb:84:ca:90   30.560s (        1.0) [     wlan0]
>> b8:27:eb:1e:eb:cd   27.410s (        1.0) [     wlan0]
>> b8:27:eb:cb:80:34   23.100s (        1.0) [     wlan0]
> 
> Btw. it looks to me like B.A.T.M.A.N. V is a really bad choice for your setup. 
> All links have the throughput value 1.0 Mbit/s. This sounds to me like the 
> wifi driver doesn't provide the required expected_throughput. And so you have 
> a REALLY, REALLY, REALLY bad metric when you are using 1.0 everywhere. So if 
> you want to continue experimenting with B.A.T.M.A.N. V then you should try to 
> get this fixed in your wifi driver or just switch to B.A.T.M.A.N. IV with 
> increased multicast rate.
Are there any docs that talk about what B.A.T.M.A.N. V vs B.A.T.M.A.N. IV is good for?  The decision to upgrade was made before I got here, I'm not sure anyone understood that IV would still be supported/expected to be used. 
> 
> 
>> Lots of stuff I don't understand here, looks like loopback is very busy?
> 
> Not sure what you mean here with loopback. I will just leave the whole output 
> here in case somebody else on the mailing list wants to figure it out.
> 
>> pi@raspberrypi:~/xeco-master/enola-daemon $ sudo batctl td wlan0
>> 15:01:52.075412 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 704843962, v 15, interval 500ms, length 20
>> 15:01:52.076036 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.076507 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.076854 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.077456 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.077937 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.078028 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.078657 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.079155 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.079246 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.079894 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.080480 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.080965 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.081435 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.081904 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.081995 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.082435 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.082539 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.082957 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
>> 15:01:52.415359 BAT b8:27:eb:fb:4e:58: OGM2 via neigh b8:27:eb:fb:4e:58, seq 500807384, throughput MAX, ttl 50, v 15, length 60, tvlv_len 40
>> 	TVLV TTv1: OGM DIFF [.] ttvn=1 vlan_num=1 entry_num=0
>> 		VLAN ID -1, crc 0xf0cfd284
>> 	TVLV GWv1: down 10.0Mbps, up 2.0Mbps
>> 	TVLV DATv1: enabled
>> 15:01:52.423153 BAT b8:27:eb:fb:4e:58: OGM2 via neigh b8:27:eb:aa:1e:6d, seq 500807384, throughput 15.0Mbps, ttl 49, v 15, length 60, tvlv_len 40
>> 	TVLV TTv1: OGM DIFF [.] ttvn=1 vlan_num=1 entry_num=0
>> 		VLAN ID -1, crc 0xf0cfd284
>> 	TVLV GWv1: down 10.0Mbps, up 2.0Mbps
>> 	TVLV DATv1: enabled
>> 15:01:52.424280 BAT b8:27:eb:fb:4e:58: OGM2 via neigh b8:27:eb:cb:80:34, seq 500807384, throughput 14.9Mbps, ttl 49, v 15, length 60, tvlv_len 40
>> 	TVLV TTv1: OGM DIFF [.] ttvn=1 vlan_num=1 entry_num=0
>> 		VLAN ID -1, crc 0xf0cfd284
>> 	TVLV GWv1: down 10.0Mbps, up 2.0Mbps
>> 	TVLV DATv1: enabled
>> 15:01:52.428556 BAT b8:27:eb:fb:4e:58: OGM2 via neigh b8:27:eb:84:ca:90, seq 500807384, throughput 15.0Mbps, ttl 49, v 15, length 60, tvlv_len 40
>> 	TVLV TTv1: OGM DIFF [.] ttvn=1 vlan_num=1 entry_num=0
>> 		VLAN ID -1, crc 0xf0cfd284
>> 	TVLV GWv1: down 10.0Mbps, up 2.0Mbps
>> 	TVLV DATv1: enabled
>> 15:01:52.575301 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 704843963, v 15, interval 500ms, length 20
>> 15:01:52.575486 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> 
> Kind regards,
> 	Sven

Re: batadv gw_mode client 0?

[Mark Birss]

Hi

I don't want to hi-jack your initial conversation here.

I just recently been using BATMAN-adv over ethernet

So yes BATMAN_V shows link speed throughput 1000Mbps  for me instead
of #255 with BATMAN-VI

I wanted to ask about debugging also, what other debug if any options
are there that i can use ?

I have enabled


echo "CONFIG_BATMAN_ADV_DEBUG=y" >> .config
echo "CONFIG_BATMAN_ADV_DEBUGFS=y" >> .config
echo "CONFIG_BATMAN_ADV_BLA=y" >> .config
echo "CONFIG_BATMAN_ADV_DAT=y" >> .config
echo "CONFIG_BATMAN_ADV_MCAST=y" >> .config
echo "CONFIG_BATMAN_ADV_NC=n" >> .config
echo "CONFIG_BATMAN_ADV_BATMAN_V=y" >> .config
echo "CONFIG_BATMAN_ADV_SYSFS=y" >> .config
echo "CONFIG_BATMAN_ADV_TRACING=y" >> .config


echo 255 > /sys/class/net/bat0/mesh/log_level
cat /sys/kernel/debug/batman_adv/bat0/log



since i want to understand why on wifi mesh seems to crash for me ath10k


On Wed, Jun 24, 2020 at 10:42 PM Rob Cowart <rob.cowart@xecoenergy.com> wrote:
>
>
>
> > On Jun 24, 2020, at 3:13 PM, Sven Eckelmann <sven@narfation.org> wrote:
> >
> > On Wednesday, 24 June 2020 22:02:38 CEST Rob Cowart wrote:
> > [....]
> >> Is anything wrong with these?
> >
> > Most likely not, but someone on the mailing list with deeper knowledge on
> > B.A.T.M.A.N. V's echo location protocol could actually check whether non-
> > symmetric settings on different nodes could create problems or not. Or if
> > having both ELP and OGM2 interval set to the same value could have negative
> > side effects.
> >
> >
> >> Our gateway:
> >>
> >> pi@raspberrypi:~/xeco-master/enola-daemon $ cat /sys/class/net/wlan0/batman_adv/elp_interval
> >> 500
> >> pi@raspberrypi:~/xeco-master/enola-daemon $ cat /sys/class/net/bat0/mesh/orig_interval
> >> 1000
> >>
> >> nodes:
> >> pi@raspberrypi:~ $ cat /sys/class/net/wlan0/batman_adv/elp_interval
> >> 30000
> >> pi@raspberrypi:~ $ cat /sys/class/net/bat0/mesh/orig_interval
> >> 30000
> > [...]
> >
> > On Wednesday, 24 June 2020 21:23:09 CEST Rob Cowart wrote:
> >> IF             Neighbor              last-seen
> >> b8:27:eb:4e:73:6d   25.330s (        1.0) [     wlan0]
> >> b8:27:eb:ff:0e:b6   23.320s (        1.0) [     wlan0]
> >> b8:27:eb:08:13:37   18.850s (        1.0) [     wlan0]
> >> b8:27:eb:aa:1e:6d   37.010s (        1.0) [     wlan0]
> >> b8:27:eb:35:c6:77   63.590s (        1.0) [     wlan0]
> >> b8:27:eb:e9:34:41   18.280s (        1.0) [     wlan0]
> >> b8:27:eb:84:ca:90   30.560s (        1.0) [     wlan0]
> >> b8:27:eb:1e:eb:cd   27.410s (        1.0) [     wlan0]
> >> b8:27:eb:cb:80:34   23.100s (        1.0) [     wlan0]
> >
> > Btw. it looks to me like B.A.T.M.A.N. V is a really bad choice for your setup.
> > All links have the throughput value 1.0 Mbit/s. This sounds to me like the
> > wifi driver doesn't provide the required expected_throughput. And so you have
> > a REALLY, REALLY, REALLY bad metric when you are using 1.0 everywhere. So if
> > you want to continue experimenting with B.A.T.M.A.N. V then you should try to
> > get this fixed in your wifi driver or just switch to B.A.T.M.A.N. IV with
> > increased multicast rate.
> Are there any docs that talk about what B.A.T.M.A.N. V vs B.A.T.M.A.N. IV is good for?  The decision to upgrade was made before I got here, I'm not sure anyone understood that IV would still be supported/expected to be used.
> >
> >
> >> Lots of stuff I don't understand here, looks like loopback is very busy?
> >
> > Not sure what you mean here with loopback. I will just leave the whole output
> > here in case somebody else on the mailing list wants to figure it out.
> >
> >> pi@raspberrypi:~/xeco-master/enola-daemon $ sudo batctl td wlan0
> >> 15:01:52.075412 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 704843962, v 15, interval 500ms, length 20
> >> 15:01:52.076036 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.076507 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.076854 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.077456 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.077937 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.078028 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.078657 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.079155 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.079246 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.079894 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.080480 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.080965 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.081435 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.081904 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.081995 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.082435 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.082539 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.082957 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >> 15:01:52.415359 BAT b8:27:eb:fb:4e:58: OGM2 via neigh b8:27:eb:fb:4e:58, seq 500807384, throughput MAX, ttl 50, v 15, length 60, tvlv_len 40
> >>      TVLV TTv1: OGM DIFF [.] ttvn=1 vlan_num=1 entry_num=0
> >>              VLAN ID -1, crc 0xf0cfd284
> >>      TVLV GWv1: down 10.0Mbps, up 2.0Mbps
> >>      TVLV DATv1: enabled
> >> 15:01:52.423153 BAT b8:27:eb:fb:4e:58: OGM2 via neigh b8:27:eb:aa:1e:6d, seq 500807384, throughput 15.0Mbps, ttl 49, v 15, length 60, tvlv_len 40
> >>      TVLV TTv1: OGM DIFF [.] ttvn=1 vlan_num=1 entry_num=0
> >>              VLAN ID -1, crc 0xf0cfd284
> >>      TVLV GWv1: down 10.0Mbps, up 2.0Mbps
> >>      TVLV DATv1: enabled
> >> 15:01:52.424280 BAT b8:27:eb:fb:4e:58: OGM2 via neigh b8:27:eb:cb:80:34, seq 500807384, throughput 14.9Mbps, ttl 49, v 15, length 60, tvlv_len 40
> >>      TVLV TTv1: OGM DIFF [.] ttvn=1 vlan_num=1 entry_num=0
> >>              VLAN ID -1, crc 0xf0cfd284
> >>      TVLV GWv1: down 10.0Mbps, up 2.0Mbps
> >>      TVLV DATv1: enabled
> >> 15:01:52.428556 BAT b8:27:eb:fb:4e:58: OGM2 via neigh b8:27:eb:84:ca:90, seq 500807384, throughput 15.0Mbps, ttl 49, v 15, length 60, tvlv_len 40
> >>      TVLV TTv1: OGM DIFF [.] ttvn=1 vlan_num=1 entry_num=0
> >>              VLAN ID -1, crc 0xf0cfd284
> >>      TVLV GWv1: down 10.0Mbps, up 2.0Mbps
> >>      TVLV DATv1: enabled
> >> 15:01:52.575301 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 704843963, v 15, interval 500ms, length 20
> >> 15:01:52.575486 BAT b8:27:eb:fb:4e:58: ELP via iface b8:27:eb:fb:4e:58, seq 0, v 15, interval 0ms, length 200
> >
> > Kind regards,
> >       Sven

Re: batadv gw_mode client 0?

[Sven Eckelmann]

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

On Wednesday, 24 June 2020 23:01:30 CEST Mark Birss wrote:
> I don't want to hi-jack your initial conversation here.

Then don't do it and start a new thread.

Kind regards,
	Sven

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

Re: batadv gw_mode client 0?

[Sven Eckelmann]

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

On Wednesday, 24 June 2020 22:37:29 CEST Rob Cowart wrote:
> Are there any docs that talk about what B.A.T.M.A.N. V vs B.A.T.M.A.N. IV is good for?  The decision to upgrade was made before I got here, I'm not sure anyone understood that IV would still be supported/expected to be used.

There is a summary page about B.A.T.M.A.N. V [1] which you should read first. 
And you should definitely not use B.A.T.M.A.N. V when the "throughput based 
metric" is not able to retrieve any meaningful values for your link partners
and you are not able to give the routing protocol anything useful to work with.

And B.A.T.M.A.N. IV is still the default and cannot be compiled out. And the
configuration option for B.A.T.M.A.N. V still has following sentence at the 
end:

	  B.A.T.M.A.N. V is currently considered experimental and not
	  compatible to B.A.T.M.A.N. IV networks.

So while it is definitely less experimental than some years ago, it tends to 
still have problems to get useful throughput information from the drivers of 
the lower device(s).

But both protocol versions have their Pros and Cons - but with your current 
setup (with your current drivers), I have have big doubts that B.A.T.M.A.N. V 
has any benefits for you. But I could be wrong.

Kind regards,
	Sven

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

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

Re: batadv gw_mode client 0?

[Sven Eckelmann]

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

On Tuesday, 28 July 2020 01:07:09 CEST Rob Cowart wrote:
> So we have a new problem.  In BATMAN 2018 logging worked, but on BATMAN 2019 it doesn't - should I update to 2020?

What does this have to do with gw_mode client 0? At least you posted in the 
thread [0] with the subject "batadv gw_mode client 0". And you mail also has
the subject "batadv gw_mode client 0"

And please stop posting HTML messages [1]

> pi@raspberrypi:~ $ sudo batctl -v
> batctl 2019.4-1-g6046cf9 [batman-adv: 2019.4-9-g890c6748-dirty]
[...]
> pi@raspberrypi:~ $ sudo batctl log
> Error - no valid command or debug table specified: log

The log command was removed from batctl on purpose [2]. Please either get the 
data via trace-cmd [3] or build your batman-adv with DEBUGFS support and 
manually fetch the data from the deprecated log file
/sys/kernel/debug/batman_adv/log (tail -f, cat, ...).

Kind regards,
	Sven

[0] https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/thread/FG4ZGHSHFHISJUKZ4XQH56ACBV4ASSSZ/
[1] https://www.open-mesh.org/projects/open-mesh/wiki/MailingList
[2] https://www.open-mesh.org/news/90
[3] https://www.open-mesh.org/projects/batman-adv/wiki/Understand-your-batman-adv-network#Logging

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