[B.A.T.M.A.N.] Fail to create tunnels using br-lan

[B.A.T.M.A.N.] Fail to create tunnels using br-lan

[Carlos Rey-Moreno]

Hi everyone,

A student who is collaborating with me, Andrei, cc'ed, is carrying out
traffic performance analysis in a mesh network (which uses batman-adv)
in order to compare the benefits of introducing Simplemux [1].
Basically, simplemux multiplexes small packets in bigger packets and
compresses them to reduce overhead. These packets are then sent
through a tunnel to another end in the network.

So far, simplemux shows very positive results by creating the tunnel
in between two computers connected at each end of a multihop network
composed by a chain of 5 nodes.

The idea would be to test the performance benefits of simplemux when
the tunnels are created between the mesh nodes instead, so they could
aggregate, let's say, all the VoIP packets from different SIP clients
calling other SIP clients in the mesh or via the gateway.

The tunnels can be successfully created in OpenWRT, but it fails when
assigning the physical interface the tunnel should use. It works when
a physical interface is used, i.e. eth0, but fails with br-lan
provided it is a virtual interface.

# openvpn --mktun --dev tun0 --user root

# ifconfig tun0 up

# ./simplemux -i tun0 -e br-lan -M N -c 192.168.0.5

I was wondering if anyone in the list could point Andrei in the right direction.

Thank you very much in advance.

carlos

[1] https://github.com/Simplemux/simplemux

-- 
Carlos Rey-Moreno, PhD
PostDoctoral Fellow University of the Western Cape
Zenzeleni Networks: zenzeleni.net
https://www.youtube.com/watch?v=YxTPSWMX26M
Cel: +27 (0) 76 986 3633
Skype: carlos.reymoreno Twitter: Creym

Re: [B.A.T.M.A.N.] Fail to create tunnels using br-lan

[Antonio Quartulli]

On Mon, Dec 19, 2016 at 11:06:01AM +0100, Carlos Rey-Moreno wrote:
> Hi everyone,
> 
> A student who is collaborating with me, Andrei, cc'ed, is carrying out
> traffic performance analysis in a mesh network (which uses batman-adv)
> in order to compare the benefits of introducing Simplemux [1].
> Basically, simplemux multiplexes small packets in bigger packets and
> compresses them to reduce overhead. These packets are then sent
> through a tunnel to another end in the network.
> 
> So far, simplemux shows very positive results by creating the tunnel
> in between two computers connected at each end of a multihop network
> composed by a chain of 5 nodes.
> 
> The idea would be to test the performance benefits of simplemux when
> the tunnels are created between the mesh nodes instead, so they could
> aggregate, let's say, all the VoIP packets from different SIP clients
> calling other SIP clients in the mesh or via the gateway.
> 
> The tunnels can be successfully created in OpenWRT, but it fails when
> assigning the physical interface the tunnel should use. It works when
> a physical interface is used, i.e. eth0, but fails with br-lan
> provided it is a virtual interface.
> 
> # openvpn --mktun --dev tun0 --user root
> 
> # ifconfig tun0 up
> 
> # ./simplemux -i tun0 -e br-lan -M N -c 192.168.0.5
> 
> I was wondering if anyone in the list could point Andrei in the right direction.
> 
> Thank you very much in advance.

Dear Carlos,

this looks pretty much about OpenVPN (if I am not wrong). Are you sure you
posted it to the right mailing list?

Cheers,

-- 
Antonio Quartulli

Re: [B.A.T.M.A.N.] Fail to create tunnels using br-lan

[Carlos Rey-Moreno]

Dear Antonio, we will post it in the OpenVPN mailing list too, but I
was hoping that someone in the list had been able to establish tunnels
in between batmand-adv nodes using the br-lan interface.

best,

carlos

On 19 December 2016 at 11:10, Antonio Quartulli <a@unstable.cc> wrote:
> On Mon, Dec 19, 2016 at 11:06:01AM +0100, Carlos Rey-Moreno wrote:
>> Hi everyone,
>>
>> A student who is collaborating with me, Andrei, cc'ed, is carrying out
>> traffic performance analysis in a mesh network (which uses batman-adv)
>> in order to compare the benefits of introducing Simplemux [1].
>> Basically, simplemux multiplexes small packets in bigger packets and
>> compresses them to reduce overhead. These packets are then sent
>> through a tunnel to another end in the network.
>>
>> So far, simplemux shows very positive results by creating the tunnel
>> in between two computers connected at each end of a multihop network
>> composed by a chain of 5 nodes.
>>
>> The idea would be to test the performance benefits of simplemux when
>> the tunnels are created between the mesh nodes instead, so they could
>> aggregate, let's say, all the VoIP packets from different SIP clients
>> calling other SIP clients in the mesh or via the gateway.
>>
>> The tunnels can be successfully created in OpenWRT, but it fails when
>> assigning the physical interface the tunnel should use. It works when
>> a physical interface is used, i.e. eth0, but fails with br-lan
>> provided it is a virtual interface.
>>
>> # openvpn --mktun --dev tun0 --user root
>>
>> # ifconfig tun0 up
>>
>> # ./simplemux -i tun0 -e br-lan -M N -c 192.168.0.5
>>
>> I was wondering if anyone in the list could point Andrei in the right direction.
>>
>> Thank you very much in advance.
>
> Dear Carlos,
>
> this looks pretty much about OpenVPN (if I am not wrong). Are you sure you
> posted it to the right mailing list?
>
> Cheers,
>
> --
> Antonio Quartulli



-- 
Carlos Rey-Moreno, PhD
PostDoctoral Fellow University of the Western Cape
Zenzeleni Networks: zenzeleni.net
https://www.youtube.com/watch?v=YxTPSWMX26M
Cel: +27 (0) 76 986 3633
Skype: carlos.reymoreno Twitter: Creym

Re: [B.A.T.M.A.N.] Fail to create tunnels using br-lan

[Sven Eckelmann]

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

On Montag, 19. Dezember 2016 11:55:40 CET Carlos Rey-Moreno wrote:
> Dear Antonio, we will post it in the OpenVPN mailing list too, but I
> was hoping that someone in the list had been able to establish tunnels
> in between batmand-adv nodes using the br-lan interface.

Sorry, but we don't understand what your question has to do with batman-adv. 
In your example there is no actual reference to batman-adv. Only simplemux and 
OpenVPN is shown in the example. We don't know simplemux and cannot tell you 
why it may not work (is it the problematic tool? Not really clear in your 
question). The latter is known but seems to be used in L3 mode and therefore 
useless for bridges and batman-adv.

> The tunnels can be successfully created in OpenWRT, but it fails when
> assigning the physical interface the tunnel should use. It works when
> a physical interface is used,

So it fails and works at the same time with "physical interface"s? What 
exactly fails here? Is it batman-adv related? Doesn't look to me like it does.

Kind regards,
	Sven

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

Re: [B.A.T.M.A.N.] Fail to create tunnels using br-lan

[Sven Eckelmann]

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

On Donnerstag, 12. Januar 2017 20:27:34 CET Andrei Buciulea wrote:
[...]
> *> The tunnels can be successfully created in OpenWRT*I have created the
> tunnel and assigning the mesh devices an IP(192.168.100.5):
> The other one mesh device IP is: 192.168.100.4
> 
>       tun0      Link encap:UNSPEC  HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>                  inet addr:192.168.100.5  P-t-P:192.168.100.5
> Mask:255.255.255.0
>                  UP POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
[...]
> If anyone has any idea why it does not work I would be very grateful.

Sorry, but I still don't get what are you doing with layer 3 tunnel stuff and 
what batman-adv has to do with it (it is a layer 2 based protocol which 
requires layer 2 interfaces).

Kind regards,
	Sven

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

Re: [B.A.T.M.A.N.] Fail to create tunnels using br-lan

[Javier Simó]

Hello Sven

Thanks for your answer, I collaborate with Andrei, who asked the 
question, let me try to help to explain, though I suspect that your 
message did contain the answer somehow.

We know that batman-adv does multi-hop at L2. That is in fact the 
problem. We are trying to test how a network utility called simplemux 
may improve the performance in a mesh network using batman-adv. The idea 
behind simplemux is that aggregating all packets that node X wants to 
sent to node Y at any time, making them share the IP header and 
accessing the channel only once for the bundle, can dramatically improve 
the performance. Node X should take any packets in the TX  queue coming 
from different sources and probably going to different destinations but 
having the same next hop, and put them together in a bundle. That is 
what simplemux does. But actually simplemux operates on a tunnel that 
takes the packets sent through a physical interface in X and drives them 
to a physical interface of Y.

We don't know well how the tunnel manages the traffic, but possibly the 
problem is that it requires the packages coming up from the physical 
interface to the IP layer (what does not happen in batman-adv), which is 
actually what you say. In this case, may be we cannot do what we wanted 
to do :-(

Thanks a lot

Javier

El 13/01/17 a las 08:31, Sven Eckelmann escribió:
> On Donnerstag, 12. Januar 2017 20:27:34 CET Andrei Buciulea wrote:
> [...]
>> *> The tunnels can be successfully created in OpenWRT*I have created the
>> tunnel and assigning the mesh devices an IP(192.168.100.5):
>> The other one mesh device IP is: 192.168.100.4
>>
>>        tun0      Link encap:UNSPEC  HWaddr
>> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>>                   inet addr:192.168.100.5  P-t-P:192.168.100.5
>> Mask:255.255.255.0
>>                   UP POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
> [...]
>> If anyone has any idea why it does not work I would be very grateful.
> Sorry, but I still don't get what are you doing with layer 3 tunnel stuff and
> what batman-adv has to do with it (it is a layer 2 based protocol which
> requires layer 2 interfaces).
>
> Kind regards,
> 	Sven

-- 

---------------------------------------------------
Fco. Javier Simó Reigadas <javier.simo@urjc.es>
Subdirector de Ord. Docente
ETS de Ingeniería de Telecomunicación
D-204, Departamental III
Camino Del Molino, s/n - 28943 Fuenlabrada (Madrid)
Tel: 914888428, Fax: 914887500
Web personal: http://www.tsc.urjc.es/~javier.simo