two-way-tunnel quirks
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
Quoted 7 lines
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
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
Quoted 23 lines · Marek Lindner
Quoted 6 lines
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
[email protected]
https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
Hi
Quoted 7 lines · Axel Neumann
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
Quoted 5 lines
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
Hi,
Quoted 6 lines
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
Quoted 8 lines · Marek Lindner
Quoted 7 lines
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.
Quoted 4 lines
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
Quoted 1 line
- Which revision was used ?
probably rv777, i'm running batmand-exp only since then
Quoted 1 line
- What exactely is your problem ?
web-browsers say something like "hotmail/msn/live.com dropped the connection"
Quoted 1 line
- 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
Hello,
...
Quoted 10 lines
Quoted 2 lines
- Can you describe it in way that i can reproduce it ?
A---B---C
A: your computer
B:
bmxd_rv804client node }}running 2-way-tunnelC:
bmxd_rv804gw 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
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
Hi Axel
Quoted 12 lines · Axel Neumann
...
Quoted 10 lines
Quoted 2 lines
- Can you describe it in way that i can reproduce it ?
A---B---C
A: your computer
B:
bmxd_rv804client node }}running 2-way-tunnelC:
bmxd_rv804gw node }
Quoted 5 lines
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
Quoted 3 lines
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 ;-)
Quoted 1 line
- 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
Hi,
Quoted 22 lines · Jan Hetges
Hi Axel
Quoted 12 lines · Axel Neumann
...
Quoted 9 lines
Quoted 1 line
- Can you describe it in way that i can reproduce it ?
A---B---C
A: your computer
B:
bmxd_rv804client node }}running 2-way-tunnelC:
bmxd_rv804gw node }Quoted 6 lines
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
Quoted 7 lines
MASQUERADE
Quoted 2 lines
for the one-way tunnel setup:
- you are only doing SNAT at Cs' upstream interfaceno, 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
Quoted 1 line
---------->*===============>*--------->
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
Quoted 8 lines
Quoted 2 lines
- 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
Quoted 49 lines · Axel Neumann
Hi,
Quoted 22 lines · Jan Hetges
Hi Axel
Quoted 12 lines · Axel Neumann
...
Quoted 9 lines
Quoted 1 line
- Can you describe it in way that i can reproduce it ?
A---B---C
A: your computer
B:
bmxd_rv804client node }}running 2-way-tunnelC:
bmxd_rv804gw node }Quoted 6 lines
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
interfaceQuoted 7 lines
MASQUERADE
Quoted 2 lines
for the one-way tunnel setup:
- you are only doing SNAT at Cs' upstream interfaceno, 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 InternetQuoted 1 line
---------->*===============>*--------->
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 (?) !
Quoted 7 lines
A B C
eth0 eth0 wlan0 wlan0 dsl0 Internet
<----------<?---------------<*---------<
de-MASQUERDE? de-MASQUERADEcatched 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
Hi,
Quoted 48 lines
Quoted 48 lines
Quoted 16 lines
Quoted 9 lines
Quoted 8 lines
A---B---C
A: your computer
B:
bmxd_rv804client node }}running 2-way-tunnelC:
bmxd_rv804gw node }Quoted 6 lines
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
interfaceQuoted 7 lines
MASQUERADE
Quoted 2 lines
for the one-way tunnel setup:
- you are only doing SNAT at Cs' upstream interfaceno, 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 InternetQuoted 1 line
---------->*===============>*--------->
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
Quoted 5 lines
Quoted 1 line
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
Quoted 4 lines
cheers
--Jan
Hi,
Quoted 31 lines · Jan Hetges
Quoted 7 lines · Marek Lindner
Quoted 6 lines
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.Quoted 5 lines
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
Quoted 1 line
- Which revision was used ?
probably rv777, i'm running batmand-exp only since then
Quoted 1 line
- What exactely is your problem ?
web-browsers say something like "hotmail/msn/live.com dropped the connection"
Quoted 1 line
- Can you describe it in way that i can reproduce it ?
A---B---C
A: your computer
Quoted 7 lines
B:
bmxd_rv804client node }}running 2-way-tunnelC:
bmxd_rv804gw 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
Quoted 4 lines
cheers
--Jan
Hi,
Quoted 4 lines
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
Quoted 12 lines
ciao,
axelQuoted 3 lines
cheers
--Jan
_______________________________________________
B.A.T.M.A.N mailing list
[email protected]
https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n