[B.A.T.M.A.N.] two-way-tunnel quirks

[B.A.T.M.A.N.] two-way-tunnel quirks

[Jan Hetges]

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

Hi all
as i'm running bmxd-rv804 only ;-)
for almost two weeks now, almost without problems...
now i found an issue which i didn't relate with batman
first. I got several reports of users, hotmail/msn/live.com
not being accessible anymore... 
Yesterday i found out theres also problems with some pop server
not beeing accessible, but everything works fine directly at the
upstream gw, without any batmand involved.
reenableing the old one-way-tunnel solved all the problems.

cheers

  --Jan

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [B.A.T.M.A.N.] two-way-tunnel quirks

[Marek Lindner]

> now i found an issue which i didn't relate with batman
> first. I got several reports of users, hotmail/msn/live.com
> not being accessible anymore...
> Yesterday i found out theres also problems with some pop server
> not beeing accessible, but everything works fine directly at the
> upstream gw, without any batmand involved.

Unfortunately, it is too few information to do anything about it. Could you 
describe your experiences in more detail. Here some questions on the way:

- When did you notice the problem for the first time ?
- Which revision was used ?
- What exactely is your problem ?
- Can you describe it in way that i can reproduce it ?

Greetings,
Marek

Re: [B.A.T.M.A.N.] two-way-tunnel quirks

[Axel Neumann]

Hi,

perhaps this has something to do with the reduced maximum-transfer-unit (mtu) 
which ist left for the tunnel interfaces. Since the one-way-tunnel do only 
tunnel the upling-traffic but NOT tunnel the downlink traffic this is not a 
problem when trying to connect to a intractable www server.

Did I understand you correct, that these problems only occurs when surfing to 
a few webservers, but not to all webservers?

Can you try what happens if you reduce the mtu of the outgoing interface at 
the upstream gateway (e.g. ifconfig ethX mtu 1400). I think there might be 3 
possible results:
 1) everything remains as before, there is another reason
 2) the hotmai/msn/live.com or pop services are not reachable anymore from the 
upstream gw. Then we have at least a hint. 
 3) Now these services also work inside the mesh. Maybe the icmp messages 
which are supposed to communicate the path-mtu-problem were not correctly 
transmitted from the tunnel interface but succeed from the upstream gw 
interface to the server. 

ciao,
axel


On Samstag 01 Dezember 2007, Marek Lindner wrote:
> > now i found an issue which i didn't relate with batman
> > first. I got several reports of users, hotmail/msn/live.com
> > not being accessible anymore...
> > Yesterday i found out theres also problems with some pop server
> > not beeing accessible, but everything works fine directly at the
> > upstream gw, without any batmand involved.
>
> Unfortunately, it is too few information to do anything about it. Could you
> describe your experiences in more detail. Here some questions on the way:
>
> - When did you notice the problem for the first time ?
> - Which revision was used ?
> - What exactely is your problem ?
> - Can you describe it in way that i can reproduce it ?
>
> 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

Re: [B.A.T.M.A.N.] two-way-tunnel quirks

[Jan Hetges]

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

Hi
On Sat, Dec 01, 2007 at 09:41:59PM +0100, Axel Neumann wrote:
> perhaps this has something to do with the reduced maximum-transfer-unit (mtu) 
> which ist left for the tunnel interfaces. Since the one-way-tunnel do only 
> tunnel the upling-traffic but NOT tunnel the downlink traffic this is not a 
> problem when trying to connect to a intractable www server.
> 
> Did I understand you correct, that these problems only occurs when surfing to 
> a few webservers, but not to all webservers?
exactly
> 
> Can you try what happens if you reduce the mtu of the outgoing interface at 
> the upstream gateway (e.g. ifconfig ethX mtu 1400). I think there might be 3 
> possible results:
>  1) everything remains as before, there is another reason
ok, set mtu on upstream gw to 1400, and everything remains as before :-(
(didn't check at the upstream gw yet, but from inside the mesh i can
also access hotmail when 1-way-tunnel, and not access hotmail when
2-way-tunnel)
and tried another one with mtu 1200... still the same, seems not
related.

cheers

  --Jan


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [B.A.T.M.A.N.] two-way-tunnel quirks

[Marek Lindner]

Hi,

> ok, set mtu on upstream gw to 1400, and everything remains as before :-(
> (didn't check at the upstream gw yet, but from inside the mesh i can
> also access hotmail when 1-way-tunnel, and not access hotmail when
> 2-way-tunnel)
> and tried another one with mtu 1200... still the same, seems not
> related.

one more idea: Do you clamp the MSS on the batman gateway client ?
It is somehow related to the MTU problem.
You can try this iptables command:
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j 
TCPMSS --clamp-mss-to-pmtu

Regards,
Marek

Re: [B.A.T.M.A.N.] two-way-tunnel quirks

[Jan Hetges]

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

On Sat, Dec 01, 2007 at 06:34:54PM +0100, Marek Lindner wrote:
> 
> > now i found an issue which i didn't relate with batman
> > first. I got several reports of users, hotmail/msn/live.com
> > not being accessible anymore...
> > Yesterday i found out theres also problems with some pop server
> > not beeing accessible, but everything works fine directly at the
> > upstream gw, without any batmand involved.
> 
> Unfortunately, it is too few information to do anything about it. Could you 
> describe your experiences in more detail. Here some questions on the way:
> 
> - When did you notice the problem for the first time ?
user reports for about 3 weeks
> - Which revision was used ?
probably rv777, i'm running batmand-exp only since then
> - What exactely is your problem ?
web-browsers say something like "hotmail/msn/live.com dropped the
connection"
> - Can you describe it in way that i can reproduce it ?

  A---B---C

A: your computer

B: bmxd_rv804  client node      }
                                 }running 2-way-tunnel
C: bmxd_rv804    gw node        }

and now try to browse www.hotmail.com, but i'm not sure if
you can reproduce it, because the high latency (>640ms) of
our sat-uplink might be also involved 

cheers

  --Jan

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [B.A.T.M.A.N.] two-way-tunnel quirks

[Axel Neumann]

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

Hello,

...
>
> > - Can you describe it in way that i can reproduce it ?
>
>   A---B---C
>
> A: your computer
>
> B: bmxd_rv804  client node      }
>                                  }running 2-way-tunnel
> C: bmxd_rv804    gw node        }

I am just curious, can you confirm if the following correctly 
describes the HNA/SNAT of your setup:

for the two-way-tunnel setup:
 - you were doing SNAT at Cs' upstream interface AND at Bs' bat0 interface 

for the one-way tunnel setup:
 - you are only doing SNAT at Cs' upstream interface 
 - and additionally an HNA announcement by B for the address used by A

thanks,
axel

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

RE: [B.A.T.M.A.N.] two-way-tunnel quirks

[Predrag Balorda]

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

Batman-0.3 and batman-adv disappeared from the ftp server?

 

A major re-naming effort underway perhaps?

 

Pele

 

P.S. I've grabbed some sources just in case your ftp server is dying J


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

Re: [B.A.T.M.A.N.] two-way-tunnel quirks

[Jan Hetges]

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

Hi Axel
On Sun, Dec 02, 2007 at 07:54:24PM +0100, Axel Neumann wrote:
> ...
> >
> > > - Can you describe it in way that i can reproduce it ?
> >
> >   A---B---C
> >
> > A: your computer
> >
> > B: bmxd_rv804  client node      }
> >                                  }running 2-way-tunnel
> > C: bmxd_rv804    gw node        }
> 
> I am just curious, can you confirm if the following correctly 
> describes the HNA/SNAT of your setup:
> 
> for the two-way-tunnel setup:
>  - you were doing SNAT at Cs' upstream interface AND at Bs' bat0 interface 
MASQUERADE 
> 
> for the one-way tunnel setup:
>  - you are only doing SNAT at Cs' upstream interface
no, i still do MASQUERADE also on Bs' bat0, because i was too lazy to
comment it out ;-)
>  - and additionally an HNA announcement by B for the address used by A
yes, but also with 2-way-tunnel (because i want net internal routing)

cheers

  --Jan


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [B.A.T.M.A.N.] two-way-tunnel quirks

[Axel Neumann]

Hi,

On Dienstag 04 Dezember 2007, Jan Hetges wrote:
> Hi Axel
>
> On Sun, Dec 02, 2007 at 07:54:24PM +0100, Axel Neumann wrote:
> > ...
> >
> > > > - Can you describe it in way that i can reproduce it ?
> > >
> > >   A---B---C
> > >
> > > A: your computer
> > >
> > > B: bmxd_rv804  client node      }
> > >                                  }running 2-way-tunnel
> > > C: bmxd_rv804    gw node        }
> >
> > I am just curious, can you confirm if the following correctly
> > describes the HNA/SNAT of your setup:
> >
> > for the two-way-tunnel setup:
> >  - you were doing SNAT at Cs' upstream interface AND at Bs' bat0
> > interface
>
> MASQUERADE
>
> > for the one-way tunnel setup:
> >  - you are only doing SNAT at Cs' upstream interface
>
> no, i still do MASQUERADE also on Bs' bat0, because i was too lazy to
> comment it out ;-)

Interesting to know that this is possible, because (as I understand):

- Internet Uplink packets are MASQUERADEd (*) when being entunnelled at Bs' 
bat0 interface and a second time at your upstream GW interface

 A          B                C      
eth0    eth0 bat0        bat0 dsl0   Internet
 >---------->*===============>*--------->
        MASQUERADE       MASQUERADE


- Downlink packets are de-MASQUERADED (*) at Cs' upstream interface (dsl0).
But using one-way-tunnel, the Downlink packets are NOT routed via the 
bat-tunnel, therefore downlick packets will not come out of Bs' bat0 
interface and (I thought) would not be de-MASQERADEd (?) !

 A          B                C      
eth0    eth0 wlan0      wlan0 dsl0   Internet
 <----------<?---------------<*---------<
       de-MASQUERDE?   de-MASQUERADE 


catched my draft ? Please correct me if I misunderstood!

ciao
/axel 


>
> >  - and additionally an HNA announcement by B for the address used by A
>
> yes, but also with 2-way-tunnel (because i want net internal routing)
>
> cheers
>
>   --Jan

Re: [B.A.T.M.A.N.] two-way-tunnel quirks

[Jan Hetges]

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

On Tue, Dec 04, 2007 at 10:05:46AM +0100, Axel Neumann wrote:
> Hi,
> 
> On Dienstag 04 Dezember 2007, Jan Hetges wrote:
> > Hi Axel
> >
> > On Sun, Dec 02, 2007 at 07:54:24PM +0100, Axel Neumann wrote:
> > > ...
> > >
> > > > > - Can you describe it in way that i can reproduce it ?
> > > >
> > > >   A---B---C
> > > >
> > > > A: your computer
> > > >
> > > > B: bmxd_rv804  client node      }
> > > >                                  }running 2-way-tunnel
> > > > C: bmxd_rv804    gw node        }
> > >
> > > I am just curious, can you confirm if the following correctly
> > > describes the HNA/SNAT of your setup:
> > >
> > > for the two-way-tunnel setup:
> > >  - you were doing SNAT at Cs' upstream interface AND at Bs' bat0
> > > interface
> >
> > MASQUERADE
> >
> > > for the one-way tunnel setup:
> > >  - you are only doing SNAT at Cs' upstream interface
> >
> > no, i still do MASQUERADE also on Bs' bat0, because i was too lazy to
> > comment it out ;-)
> 
> Interesting to know that this is possible, because (as I understand):
> 
> - Internet Uplink packets are MASQUERADEd (*) when being entunnelled at Bs' 
> bat0 interface and a second time at your upstream GW interface
> 
>  A          B                C      
> eth0    eth0 bat0        bat0 dsl0   Internet
>  >---------->*===============>*--------->
>         MASQUERADE       MASQUERADE
> 
> 
> - Downlink packets are de-MASQUERADED (*) at Cs' upstream interface (dsl0).
> But using one-way-tunnel, the Downlink packets are NOT routed via the 
> bat-tunnel, therefore downlick packets will not come out of Bs' bat0 
> interface and (I thought) would not be de-MASQERADEd (?) !
> 
>  A          B                C      
> eth0    eth0 wlan0      wlan0 dsl0   Internet
>  <----------<?---------------<*---------<
>        de-MASQUERDE?   de-MASQUERADE 
> 
> 
> catched my draft ? Please correct me if I misunderstood!

completley correct, the thing is, if i understand right, the good old
one-way-tunnel doesn't do anything with virtual IPs, but just uses
the real IPs so it doesn't matter.

cheers

  --Jan


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [B.A.T.M.A.N.] two-way-tunnel quirks

[Axel Neumann]

Hi,

> > > > >
> > > > >   A---B---C
> > > > >
> > > > > A: your computer
> > > > >
> > > > > B: bmxd_rv804  client node      }
> > > > >                                  }running 2-way-tunnel
> > > > > C: bmxd_rv804    gw node        }
> > > >
> > > > I am just curious, can you confirm if the following correctly
> > > > describes the HNA/SNAT of your setup:
> > > >
> > > > for the two-way-tunnel setup:
> > > >  - you were doing SNAT at Cs' upstream interface AND at Bs' bat0
> > > > interface
> > >
> > > MASQUERADE
> > >
> > > > for the one-way tunnel setup:
> > > >  - you are only doing SNAT at Cs' upstream interface
> > >
> > > no, i still do MASQUERADE also on Bs' bat0, because i was too lazy to
> > > comment it out ;-)
> >
> > Interesting to know that this is possible, because (as I understand):
> >
> > - Internet Uplink packets are MASQUERADEd (*) when being entunnelled at
> > Bs' bat0 interface and a second time at your upstream GW interface
> >
> >  A          B                C
> > eth0    eth0 bat0        bat0 dsl0   Internet
> >
> >  >---------->*===============>*--------->
> >
> >         MASQUERADE       MASQUERADE
> >
> >
> > - Downlink packets are de-MASQUERADED (*) at Cs' upstream interface
> > (dsl0). But using one-way-tunnel, the Downlink packets are NOT routed via
> > the bat-tunnel, therefore downlick packets will not come out of Bs' bat0
> > interface and (I thought) would not be de-MASQERADEd (?) !
> >
> >  A          B                C
> > eth0    eth0 wlan0      wlan0 dsl0   Internet
> >  <----------<?---------------<*---------<
> >        de-MASQUERDE?   de-MASQUERADE
> >
> >
> > catched my draft ? Please correct me if I misunderstood!
>
> completley correct, the thing is, if i understand right, the good old
> one-way-tunnel doesn't do anything with virtual IPs, but just uses
> the real IPs so it doesn't matter.

It doesn't matter for B but it should matter for A

Assuming:

As' eth0  has IP 10.0.1.1
Bs' eth0  has IP 10.0.1.2
Bs' wlan0 has IP 10.0.0.2
with onw-way-tunnel 
Bs' bat0 also has IP 10.0.0.2

if A sends a packet along the default route the packet is routed into Bs' bat0 
and MASQUERADEd from 10.0.1.1 to 10.0.0.2 .

Now what happens when the packets comes back? I think,  in order to get 
delivered to A, it must be de-MASQUERADEd from 10.0.0.2 to 10.0.1.1

ciao
/axel

>
> cheers
>
>   --Jan

Re: [B.A.T.M.A.N.] two-way-tunnel quirks

[Axel Neumann]

Hi,

On Sonntag 02 Dezember 2007, Jan Hetges wrote:
> On Sat, Dec 01, 2007 at 06:34:54PM +0100, Marek Lindner wrote:
> > > now i found an issue which i didn't relate with batman
> > > first. I got several reports of users, hotmail/msn/live.com
> > > not being accessible anymore...
> > > Yesterday i found out theres also problems with some pop server
> > > not beeing accessible, but everything works fine directly at the
> > > upstream gw, without any batmand involved.
> >
> > Unfortunately, it is too few information to do anything about it. Could
> > you describe your experiences in more detail. Here some questions on the
> > way:
> >
> > - When did you notice the problem for the first time ?
>
> user reports for about 3 weeks
>
> > - Which revision was used ?
>
> probably rv777, i'm running batmand-exp only since then
>
> > - What exactely is your problem ?
>
> web-browsers say something like "hotmail/msn/live.com dropped the
> connection"
>
> > - Can you describe it in way that i can reproduce it ?
>
>   A---B---C
>
> A: your computer
>
> B: bmxd_rv804  client node      }
>                                  }running 2-way-tunnel
> C: bmxd_rv804    gw node        }
>
> and now try to browse www.hotmail.com, but i'm not sure if
> you can reproduce it, because the high latency (>640ms) of
> our sat-uplink might be also involved

theres nothing you cannot do with linux:

on my upstream server:
|isix:~# tc qdisc add dev eth5 root netem delay 800ms

on my notebook:
|smart linux # ping -n google.de
|PING google.de (216.239.59.104) 56(84) bytes of data.
|64 bytes from 216.239.59.104: icmp_seq=1 ttl=242 time=852 ms

the interesting:
|smart linux # ping -n msn.com
|PING msn.com (207.68.172.246) 56(84) bytes of data.
|--- msn.com ping statistics ---
|7 packets transmitted, 0 received, 100% packet loss, time 5998ms

|smart linux # ping -n live.com
|PING live.com (207.46.30.34) 56(84) bytes of data.
|--- live.com ping statistics ---
|7 packets transmitted, 0 received, 100% packet loss, time 5998ms

remove artificial delay again:
|isix:~# tc qdisc del dev eth5 root netem delay 800ms

still the problematic ones you mentioned do not reply to icmp pings.
|smart linux # ping -n live.com
|PING live.com (207.46.30.34) 56(84) bytes of data.
|--- live.com ping statistics ---
|4 packets transmitted, 0 received, 100% packet loss, time 2998ms


|smart linux # ping -n open-mesh.net
|PING open-mesh.net (88.198.145.69) 56(84) bytes of data.
|64 bytes from 88.198.145.69: icmp_seq=1 ttl=54 time=29.4 ms


Still I could not yet reproduce the problem but I am quite sure
that this has something to do with the msn&co.coms' reluctance to 
respond to icmp messages.

ciao,
axel

>
> cheers
>
>   --Jan

Re: [B.A.T.M.A.N.] two-way-tunnel quirks

[Axel Neumann]

Hi,

>
> Still I could not yet reproduce the problem but I am quite sure
> that this has something to do with the msn&co.coms' reluctance to
> respond to icmp messages.

Well, after a while my office colleague did.

Actually, it took me a while to understand that my experiments on our office 
server and his annoyance about an "unstable" imap account had something in 
common :-(

The only solution we found to circumvent such small-mtu paths was:
- avoid related web services OR (not so good)
- Use openvpn over the path with the reduced mtu. Seems like openvpn fragments 
and de-fragments the packets transparently between related end2end tun0 
interfaces. This even worked on his windows machine. 

Perhaps this might also become an outlook-item for the next batman tunnel 
implementation :-)

ciao,
axel

>
> ciao,
> axel
>
> > cheers
> >
> >   --Jan
>
> _______________________________________________
> 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