[B.A.T.M.A.N.] Tunnel problems...

[B.A.T.M.A.N.] Tunnel problems...

[Brett Maurer]

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

I'm a new BATMAN fan. Thanks to all who contribute.

 

I'm having a problem with bat0. It seems to be disconnecting and I cannot
find the cause. My configuration is as follows:

 

Version:

0.3 beta rv731

 

Scenario:

 

A-----B-----GW-----PC

 

A - is on 104.0.0.3 ath0 with -s 10.0.0.10

B - is on 104.0.0.2 ath0 with -s 10.0.0.10

GW - is on 104.0.0.1 ath0 and 10.0.0.1 eth0

PC - is on 10.0.0.10

 

All IP addresses are static.

 

I can see A routing through B to GW fine. The tunnel bat0 on A and B seems
unstable though. I'm looking at VIS packets arriving at PC. It arrives for
about 30 sec then stops for a while. It is not clear why the tunnel keeps
disconnecting. 

 

If anyone can offer some advice, I'd much appreciate it.


[-- Attachment #2: Type: text/html, Size: 4877 bytes --]

Re: [B.A.T.M.A.N.] Tunnel problems...

[Axel Neumann]

Hello,

On Donnerstag 18 Oktober 2007, Brett Maurer wrote:
> I'm having a problem with bat0. It seems to be disconnecting and I cannot
> find the cause. My configuration is as follows:
> Version:
> 0.3 beta rv731

Are you sure the tunnel interface is called bat0. Because in 0.3-beta-rv731 it 
should be called gate0. - but in batmand-exp  it is called bat0. 
> Scenario:
> A-----B-----GW-----PC
> A - is on 104.0.0.3 ath0 with -s 10.0.0.10
> B - is on 104.0.0.2 ath0 with -s 10.0.0.10
> GW - is on 104.0.0.1 ath0 and 10.0.0.1 eth0
>
> PC - is on 10.0.0.10
> I can see A routing through B to GW fine. The tunnel bat0 on A and B seems
> unstable though. I'm looking at VIS packets arriving at PC. It arrives for
> about 30 sec then stops for a while. It is not clear why the tunnel keeps
> disconnecting.

The current client-GW-tunnel implementation is observing the traffic from the 
client point of view.
The client suspects a GW as unresponsive (black-hole) if data is send through 
the tunnel from the client to the GW but no data is send the other way around 
(tunnelled from the GW to the client).

Then the client waits for a while and if still no data arrives through the 
tunnel, a timeout hits and automatically disconnects the client from the GW - 
hoping that other available GW are more responsive.
This can be observed using debug-leve-3 on the client side.

The problem is that the mechanism assumes a bidirectional communication 
between the mesh client node and a distant node behind the GW. Unfortunately, 
this is not the case with your scenario when sending vis packets to a 
visualization server.
In batmand-exp there is a --no-unresp-gw-check directive which disables this 
feature. For node A  try:
 batmand --no-unresp-gw-check -r 3 -s 10.0.0.10 ath0

ciao
/axel

>
>
>
> If anyone can offer some advice, I'd much appreciate it.

Re: [B.A.T.M.A.N.] Tunnel problems...

[Marek Lindner]

Hi,

> I can see A routing through B to GW fine. The tunnel bat0 on A and B seems
> unstable though. I'm looking at VIS packets arriving at PC. It arrives for
> about 30 sec then stops for a while. It is not clear why the tunnel keeps
> disconnecting.

thank you for reporting this bug. As Axel already pointed out the blackhole 
detection falsely kicks your gateway connection. Therefore I added a check 
for services that don't send data back as the vis server and snmp. If you 
know more services to ignore please let us know.

Could you re-test with the latest revision ?

Regards,
Marek

Re: [B.A.T.M.A.N.] Tunnel problems...

[a.anselmi]

Hi Marek,

maybe my fault... but I can't process rv733 ipk

-- Antonio

> Hi,
>
>> I can see A routing through B to GW fine. The tunnel bat0 on A and B
>> seems
>> unstable though. I'm looking at VIS packets arriving at PC. It arrives
>> for
>> about 30 sec then stops for a while. It is not clear why the tunnel
>> keeps
>> disconnecting.
>
> thank you for reporting this bug. As Axel already pointed out the
> blackhole
> detection falsely kicks your gateway connection. Therefore I added a check
> for services that don't send data back as the vis server and snmp. If you
> know more services to ignore please let us know.
>
> Could you re-test with the latest revision ?
>
> Regards,
> Marek
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>

Re: [B.A.T.M.A.N.] Tunnel problems...

[Marek Lindner]

Hi,

> maybe my fault... but I can't process rv733 ipk

what do you mean ? On a WRT a "ipkg install 
http://downloads.open-mesh.net/batman/development/wrt-freifunk/batmand_0.3-beta-rv733_mipsel-wr-elf-32-lsb-dynamic.ipk"
does fine. On mips you use the statically linked binary which is not an ipk.

Greetings,
Marek

Re: [B.A.T.M.A.N.] Tunnel problems...

[a.anselmi]

Hi,

I download from:
http://downloads.open-mesh.net/batman/development/fonera-kamikaze/
and there all is ipk.

However now it installs :)
ciao
-- Antonio

> Hi,
>
>> maybe my fault... but I can't process rv733 ipk
>
> what do you mean ? On a WRT a "ipkg install
> http://downloads.open-mesh.net/batman/development/wrt-freifunk/batmand_0.3-beta-rv733_mipsel-wr-elf-32-lsb-dynamic.ipk"
> does fine. On mips you use the statically linked binary which is not an
> ipk.
>
> Greetings,
> Marek
>
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@open-mesh.net
> https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>