[B.A.T.M.A.N.] B.A.T.M.A.N. port to ESP32

[B.A.T.M.A.N.] B.A.T.M.A.N. port to ESP32

[John Gorkos]

I'm working on a port of the BATMAN-ADV protocol to FreeRTOS,
specifically running on the ESP32 from EspressIF.

I'm currently sending and receiving what seem to be correctly formed OGM
messages from BATMAN IV.  For now, my goal is interoperability with
Raspberry Pis running BATMAN from stock Raspbian.

From the RasPi, I am able to see the ESP32 as a neighbor, but not as an
originator:
pi@pi-16:~ $ sudo batctl n
[B.A.T.M.A.N. adv 2017.3, MainIF/MAC: wlan0/b8:27:eb:a0:2a:53
(bat0/e6:46:65:5b:c4:c4 BATMAN_IV)]
IF             Neighbor              last-seen
        wlan0	  30:ae:a4:3b:9a:d4    0.090s
pi@pi-16:~ $ sudo batctl o
[B.A.T.M.A.N. adv 2017.3, MainIF/MAC: wlan0/b8:27:eb:a0:2a:53
(bat0/e6:46:65:5b:c4:c4 BATMAN_IV)]
   Originator        last-seen (#/255) Nexthop           [outgoingIF]

Can someone explain to me why this might be occurring, and what I'm
missing?  Currently, the code is doing two things:  sending a new OGM
with an incrementing sequence number every 1000 ms, and re-broadcasting
any received OGMs with a decremented TTL, modified TQ, and DirectLink
flag set whenever it receives them (also every 1000 ms or so).
Internally, I'm getting close to having the routing algorithm
implemented, but it looks like I'm doing something "wrong" in the eyes
of the BATMAN implementation on the Pis.  I'd be happy to provide packet
dumps on request.

Thank you in advance.
John Gorkos

Re: [B.A.T.M.A.N.] B.A.T.M.A.N. port to ESP32

[Sven Eckelmann]

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

On Montag, 1. Oktober 2018 20:01:25 CEST John Gorkos wrote:
[...]
> From the RasPi, I am able to see the ESP32 as a neighbor, but not as an
> originator:
[...]
> Can someone explain to me why this might be occurring, and what I'm
> missing?

Looks like no one answered here. Most likely because it could be everything. 
You are comparing two different concepts here - neighbors and originators. The 
neighbor list is a rather new feature [1] (compared to the actual 
B.A.T.M.A.N. IV implementation). So a good idea would be to download the 
newest batman-adv + batctl [2] and compile it with debugging enabled [3] to 
get more insight [4].

I also don't know what kind of batctl you are using in the moment. Let us just 
assume for a moment that the bug is not in batctl (just check whether the 
newest batctl receives the same info via netlink as the file in debugfs [5]). 
Just keep in mind that both originator output methods remove some originators 
from the list when they just look "invalid" [6,7].

Kind regards,
	Sven

[1] https://git.open-mesh.org/batman-adv.git/commit/fed2826b490ce1daaf039a87a5b2a3d04b8940da
[2] https://www.open-mesh.org/projects/open-mesh/wiki/Download
[3] https://www.open-mesh.org/projects/batman-adv/wiki/Faq#Log-file-doesnt-exists-in-debugfs
[4] https://www.open-mesh.org/projects/batman-adv/wiki/Understand-your-batman-adv-network#Logging
[5] https://www.open-mesh.org/projects/batman-adv/wiki/Understand-your-batman-adv-network#originator-table
[6] https://git.open-mesh.org/batman-adv.git/blob/6f6cc4f54909127b236069207fe5691d31c29b24:/net/batman-adv/bat_iv_ogm.c#l1804
[7] https://git.open-mesh.org/batman-adv.git/blob/6f6cc4f54909127b236069207fe5691d31c29b24:/net/batman-adv/bat_iv_ogm.c#l1963

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

Re: [B.A.T.M.A.N.] B.A.T.M.A.N. port to ESP32

[Linus Lüssing]

Hi John,

On Mon, Oct 01, 2018 at 11:01:25AM -0700, John Gorkos wrote:
> I'm working on a port of the BATMAN-ADV protocol to FreeRTOS,
> specifically running on the ESP32 from EspressIF.

Awesome! I've never seen batman-adv running on such a device. And
it looks like you are already quite close to being the first one
accomplishing this.

> [...]
> Can someone explain to me why this might be occurring, and what I'm
> missing?  Currently, the code is doing two things:  sending a new OGM
> with an incrementing sequence number every 1000 ms,

> and re-broadcasting any received OGMs with a decremented TTL, modified TQ, and DirectLink
> flag set whenever it receives them (also every 1000 ms or so).

This sounds wrong. You should not rebroadcast any OGM. You should
only rebroadcast from the best candidate. I'm wondering whether
this could cause issues. Or are you testing with a single
EspressIF and a single Pi only for now?

If so, then it's probably more likely that just some flags or addresses
got mixed up. Would it be possible for you to share a tcpdump capture
from the Pi? You can also check with "batctl log" whether the Pi
seems to recognize the ESP32 as an originator.

Also, have you tested with two Pis and no EspressIF? Are Pis
themselves forming a mesh just fine for you? Just to outrule that
the issue is on the Pi side.

Regards, Linus

Re: [B.A.T.M.A.N.] B.A.T.M.A.N. port to ESP32

[John Gorkos]

Thank you, Linux and Sven, for your responses.  My comments are in-line.

On 10/6/18 05:14, Linus Lüssing wrote:
> Hi John,
> 
> On Mon, Oct 01, 2018 at 11:01:25AM -0700, John Gorkos wrote:
>> I'm working on a port of the BATMAN-ADV protocol to FreeRTOS,
>> specifically running on the ESP32 from EspressIF.
> 
> Awesome! I've never seen batman-adv running on such a device. And
> it looks like you are already quite close to being the first one
> accomplishing this.
> 
Getting closer.  This weekend, I got the Raspi recognizing the ESP32 as
both an originator and a neigbor:

pi@pi-16:~ $ sudo batctl n
[B.A.T.M.A.N. adv 2017.3, MainIF/MAC: wlan0/b8:27:eb:a0:2a:53
(bat0/ca:bf:41:a6:af:81 BATMAN_IV)]
IF             Neighbor              last-seen
        wlan0	  02:ae:a4:3b:9a:d4    0.150s
pi@pi-16:~ $ sudo batctl o
[B.A.T.M.A.N. adv 2017.3, MainIF/MAC: wlan0/b8:27:eb:a0:2a:53
(bat0/ca:bf:41:a6:af:81 BATMAN_IV)]
   Originator        last-seen (#/255) Nexthop           [outgoingIF]
 * 02:ae:a4:3b:9a:d4    0.430s   (255) 02:ae:a4:3b:9a:d4 [     wlan0]


>> [...]
>> Can someone explain to me why this might be occurring, and what I'm
>> missing?  Currently, the code is doing two things:  sending a new OGM
>> with an incrementing sequence number every 1000 ms,
> 
>> and re-broadcasting any received OGMs with a decremented TTL, modified TQ, and DirectLink
>> flag set whenever it receives them (also every 1000 ms or so).
> 
> This sounds wrong. You should not rebroadcast any OGM. You should
> only rebroadcast from the best candidate. I'm wondering whether
> this could cause issues. Or are you testing with a single
> EspressIF and a single Pi only for now?
I must have a misunderstanding of the BATMAN IV OGM mechanism.  My
understanding is that ALL 1-hop (direct) neighbors will rebroadcast the
heard OGM, and beyond that, only best-hop candidates.  Right now, I am
just testing with a single pi and single ESP32, but I have an ample
supply of both.  I figured I'd crawl before I tried to walk.

> 
> If so, then it's probably more likely that just some flags or addresses
> got mixed up. Would it be possible for you to share a tcpdump capture
> from the Pi? You can also check with "batctl log" whether the Pi
> seems to recognize the ESP32 as an originator.
Raspbian comes with debugfs for Batman disabled, so I wound up
recompiling BATMAN for the pi with extra debugging enabled.  It's been
invaluable in tracking down where I'm wrong.
> 
> Also, have you tested with two Pis and no EspressIF? Are Pis
> themselves forming a mesh just fine for you? Just to outrule that
> the issue is on the Pi side.
> 
> Regards, Linus
> 

So, to be clear, I'm working on BATMAN IV and not BATMAN V.  Based on
the open-mesh docs, BATMAN V networks don't rebroadcast OGMs but instead
use the Echo Location Packets.  Am I reading that wrong?  If there's a
compelling reason to move to BATMAN V, I'd be happy to take a look at
it.  We don't anticipate more than 4 hops between links, very low
traffic (ESP32s really don't have the capacity to generate a lot of
traffic quickly) and no more than 20 or so devices in a mesh for starters.

Right now, I'm working on the unicast VLAN TVLV response for the VLAN
TVLV query sent by the Pi when my ESP32 first comes up and begins
announcing.  The Pi is quite insistent that it get an answer... :)

Thank you!
John Gorkos

Re: [B.A.T.M.A.N.] B.A.T.M.A.N. port to ESP32

[Sven Eckelmann]

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

On Montag, 8. Oktober 2018 18:43:37 CEST John Gorkos wrote:
[...]
> > This sounds wrong. You should not rebroadcast any OGM. You should
> > only rebroadcast from the best candidate. I'm wondering whether
> > this could cause issues. Or are you testing with a single
> > EspressIF and a single Pi only for now?
> I must have a misunderstanding of the BATMAN IV OGM mechanism.  My
> understanding is that ALL 1-hop (direct) neighbors will rebroadcast the
> heard OGM, and beyond that, only best-hop candidates.

Yes, single hop neighbors have special rules. But it is also important to 
check for the incoming+outgoing interface [1].

[...]
> So, to be clear, I'm working on BATMAN IV and not BATMAN V.  Based on
> the open-mesh docs, BATMAN V networks don't rebroadcast OGMs but instead
> use the Echo Location Packets.  Am I reading that wrong?

Yes, you are wrong. ELP are used in a link-local context (detecting neighbors 
and announcing itself to neighbors). OMG2 are used to inform the complete 
mesh.

> If there's a
> compelling reason to move to BATMAN V, I'd be happy to take a look at
> it.

B.A.T.M.A.N. V is using a different metric. IV is using one which is basically 
packet loss based for direct neighbors and V is using the expected throughput
for direct neighbors. Unfortunately, the ELP documentation [2] in the wiki is
outdated [3].

Kind regards,
	Sven

[1] https://git.open-mesh.org/batman-adv.git/blob/6f6cc4f54909127b236069207fe5691d31c29b24:/net/batman-adv/bat_iv_ogm.c#l1411
[2] https://www.open-mesh.org/projects/batman-adv/wiki/ELP
[3] https://www.open-mesh.org/issues/363

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