30 Nov
2007
30 Nov
'07
11:28 p.m.
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
1 Dec
1 Dec
5:34 p.m.
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
8:41 p.m.
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(a)open-mesh.net
https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
2 Dec
2 Dec
4:32 a.m.
On Sat, Dec 01, 2007 at 06:34:54PM +0100, Marek Lindner wrote:
user reports for about 3
weeks
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 ?
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
5:39 a.m.
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
6:54 p.m.
Hello,
...
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
- 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 } 
3 Dec
3 Dec
5:47 p.m.
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
4 Dec
4 Dec
4:03 a.m.
Hi Axel
On Sun, Dec 02, 2007 at 07:54:24PM +0100, Axel Neumann wrote:
...
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
- 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 }
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
9:05 a.m.
Hi,
On Dienstag 04 Dezember 2007, Jan Hetges wrote:
Hi Axel
On Sun, Dec 02, 2007 at 07:54:24PM +0100, Axel Neumann wrote:
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
...
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
- 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 } 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 ;-) ---------->*===============>*--------->
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
10:01 a.m.
Hi,
On Sonntag 02 Dezember 2007, Jan Hetges wrote:
On Sat, Dec 01, 2007 at 06:34:54PM +0100, Marek
Lindner wrote:
user reports for about 3 weeks
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
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 ?
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
12:37 p.m.
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(a)open-mesh.net
https://list.open-mesh.net/mm/listinfo/b.a.t.m.a.n
1 p.m.
On Tue, Dec 04, 2007 at 10:05:46AM +0100, Axel Neumann wrote:
Hi,
On Dienstag 04 Dezember 2007, Jan Hetges wrote:
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 Axel
On Sun, Dec 02, 2007 at 07:54:24PM +0100, Axel Neumann wrote:
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
> - 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
no, i still do MASQUERADE also on Bs' bat0, because i was too lazy to
comment it out ;-) ---------->*===============>*--------->
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!
3:05 p.m.
Hi,
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
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
>
> 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 ;-) ---------->*===============>*--------->
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!
cheers
--Jan
6 Dec
6 Dec
3:18 a.m.
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
5656
days inactive
5662
days old
b.a.t.m.a.n@lists.open-mesh.org
13 comments
4 participants
participants (4)
-
Axel Neumann -
Jan Hetges -
Marek Lindner -
Predrag Balorda