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
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
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
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:
- 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,
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
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
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
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 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
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
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
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
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
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
b.a.t.m.a.n@lists.open-mesh.org
-
Axel Neumann -
Jan Hetges -
Marek Lindner -
Predrag Balorda