Re: Recover in case of node fail

Don't contact me directly about batman-adv. At least Cc
b.a.t.m.a.n@...
On Wednesday 22 July 2015 18:56:41 Carlos Meralto wrote:
[...]
> And with this command i can ping at layer 3. It is not possible in
> batman-adv? I want to measure the recovery time and so I'm doing a
> continuous
> ping. With batctl -p it is possible?
This was not what I said. ICMP ping should work perfectly fine. I just
suggested that you try `batctl -R` for debugging so you can see the hops
batman-adv uses during a batman-adv native ping.
Kind regards,
Sven

encapsulated ethernet frame format

Hi,
I was trying to understand how batman-adv encapsulates ethernet frames.
Batman dissector of wireshark, shows an ethernet II section, then a
batman section, then again an ethernet II section. Is this
rappresentation respects the original capsulated header format? I
couldn't find a scheme that shows fields of an encapsulated header in
the documentation. So with wireshark, it tells me something like that:
-----------------------------------------------------------------------
Dst.Mac|Src.Mac|Type|Packt Type|Version|TTL|Seq.No|Dst.Mac|Src.Mac|Type
-----------------------------------------------------------------------
\___________________/\____________________________/\__________________/
First Ethernet Batman Section Second Ethernet
II Section II Section
Why there are two times destination and source mac addresses? I want to
retrieve mac addresses of originators of packets by working on raw
packet data. But i'm a little bit confused with this scheme. Sorry if
it's a banal question, i don't have much experience with networking.
Thanks for any help.

Recover in case of node fail

Hi guys,
I'm trying to make a study of various protocols for WMN and one of
them is BATMAN. One the tests is the time to recovery in case of node
fail.
I have a topology with 4 routers with 2 possible paths:
A-B-C
A-D-C
For the test i'm doing a continuous ping from A to C (level 3 ping)
and shut down the router that forward the message (i.e B or C). In
this test BATMAN can't recover the PING. But when i cancel the ping
and check the Originators table (batctl o) the route is refreshed. And
when i try to ping again it works.
Is any limitation in BATMAN for recovery in a continuous PING?
Has anyone done this type of test and values obtained?
Thanks in advance.
Best Regards

Re: Batman advanced receiving packets on bat0 with same source and destination address and performance issues

Hi Simon
I hope I can make it a bit clearer and not more confusing. ;)
I just saw that my drawing looks different in the mail then what is
intended. It seems that the Linksys router and the gateway are
connected via WiFi, which is not the case. The client and gateway are
connected via WiFi.
The Linksys router serves as a DHCP server. There are cables from the
router to the gateway and to the client. Both are connected to the
main port of the Nanostation. The gateway/client notation means the
batman-adv gateway feature notation.
The gateway has one Vlan in the switch configuration, defined for both
ports. So main port and secondary port are reached by eth0.1. This
interface is bridged with the bat0 interface.
This is what I found on both, the OpenWRT page and batman-adv page as
a standard configuration if I want to add the ethernet ports to the
mesh.
The client has two Vlans, one for each port. Eth0.2 is the main port
and eth0.1 is the secondary port. The secondary port is bridged to the
bat0 interface and the main port is not. This seems to be the problem.
When I tcpdump on the main port (eth0.2), I can see the batman-adv ARP
replies broadcasting, which I would not expect to see as this
interface is not bridged to bat0. What I would expect is nothing from
batman-adv at all. The broadcast is every 10 seconds.
I continuously ping both devices from my laptop that is connected to
the client. For both devices, pings are lost. For the gateway more
than for the client. For the client it is usually 1-3 and for the
gateway from 1 up to 10-15. This does not happen regularly. It ranges
from around 30 to 120 seconds. When I lose pings, the SSH session is