Hi Marco:
On Mon, Apr 24, 2006 at 09:23:00AM +, Marco Berizzi wrote:
What should I do? Mangling MSS with iptables --set-mss ?
Altering MSS to 1440 did the trick. See:
http://marc.theaimsgroup.com/?l=linux-netdevm=114373067423528w=2
Yes that's enough, although proper PMTU would be
On Mon, May 08, 2006 at 08:28:32AM +, Marco Berizzi wrote:
[EMAIL PROTECTED]:~# ping 10.49.59.23
PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data.
64 bytes from 10.49.59.23: icmp_seq=1 ttl=247 time=91.9 ms
64 bytes from 10.49.59.23: icmp_seq=2 ttl=247 time=49.3 ms
64 bytes from
Herbert Xu wrote:
Hi Marco:
Hi Herbert, I'm very happy hearing you.
On Mon, Apr 24, 2006 at 09:23:00AM +, Marco Berizzi wrote:
What should I do? Mangling MSS with iptables --set-mss ?
Altering MSS to 1440 did the trick. See:
Herbert Xu wrote:
On Mon, May 08, 2006 at 08:28:32AM +, Marco Berizzi wrote:
[EMAIL PROTECTED]:~# ping 10.49.59.23
PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data.
64 bytes from 10.49.59.23: icmp_seq=1 ttl=247 time=91.9 ms
64 bytes from 10.49.59.23: icmp_seq=2 ttl=247 time=49.3 ms
Herbert Xu wrote:
We can say these things for certain:
1) The path between mimosa and pleiadi has a packet loss problem. A small
burst of 10 or so fragments is enough to cause at least half of them to
be lost. This problem may be specific to IPsec traffic (ISPs often
discriminate
Marco Berizzi wrote:
Herbert Xu wrote:
On Mon, May 08, 2006 at 08:28:32AM +, Marco Berizzi wrote:
[EMAIL PROTECTED]:~# ping 10.49.59.23
PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data.
64 bytes from 10.49.59.23: icmp_seq=1 ttl=247 time=91.9 ms
64 bytes from 10.49.59.23:
Another tricky behaviour:
[EMAIL PROTECTED]:/tmp# telnet 10.49.59.23 3218
Trying 10.49.59.23...
Connected to 10.49.59.23.
Escape character is '^]'.
Connection closed by foreign host.
[EMAIL PROTECTED]:/tmp# tcpdump -p -n -v ip host 10.49.59.23 HERBERT-20060711
[1] 4797
[EMAIL
Running this on mimosa 'mitigates' the problem:
ip addr add 172.29.128.1/28 dev eth2
Connections are pretty slow but they aren't
reseted anymore.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tue, Jul 11, 2006 at 11:22:18AM +0200, Marco Berizzi wrote:
I'm able to connect to a sap server connected to the milano network
from a sapgui client connected to the venezia network. No problem.
If packet loss is a problem it should be also a problem with this tunnel.
Am I wrong?
It
On Tue, Jul 11, 2006 at 11:31:33AM +0200, Marco Berizzi wrote:
Me again. After a while here is:
[EMAIL PROTECTED]:/tmp# ping 10.49.59.23
PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data.
--- 10.49.59.23 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time
On Tue, Jul 11, 2006 at 12:32:45PM +0200, Marco Berizzi wrote:
Running this on mimosa 'mitigates' the problem:
ip addr add 172.29.128.1/28 dev eth2
Connections are pretty slow but they aren't
reseted anymore.
Hmm, I thought 172.29.128.1 was already a local address? What does
ip addr
Herbert Xu wrote:
However, the fact that the tcpdump causes more chunky packets to
make it through could be an indication that there is a bug somewhere
in our NAT/IPsec code or at least a suboptimal memory allocation
strategy that's somehow avoided when AF_PACKET pins the skb down.
JFYI:
On Tue, Jun 27, 2006 at 08:45:52AM +0200, Marco Berizzi wrote:
Herbert Xu wrote:
However, the fact that the tcpdump causes more chunky packets to
make it through could be an indication that there is a bug somewhere
in our NAT/IPsec code or at least a suboptimal memory allocation
strategy
Marco Berizzi wrote:
Marco Berizzi wrote:
Herbert Xu wrote:
However, the fact that the tcpdump causes more chunky packets to
make it through could be an indication that there is a bug somewhere
in our NAT/IPsec code or at least a suboptimal memory allocation
strategy that's somehow avoided
Marco Berizzi wrote:
Herbert Xu wrote:
However, the fact that the tcpdump causes more chunky packets to
make it through could be an indication that there is a bug somewhere
in our NAT/IPsec code or at least a suboptimal memory allocation
strategy that's somehow avoided when AF_PACKET pins the
Herbert Xu wrote:
However, the fact that the tcpdump causes more chunky packets to
make it through could be an indication that there is a bug somewhere
in our NAT/IPsec code or at least a suboptimal memory allocation
strategy that's somehow avoided when AF_PACKET pins the skb down.
Ciao
On Mon, Apr 24, 2006 at 09:23:00AM +, Marco Berizzi wrote:
What should I do? Mangling MSS with iptables --set-mss ?
Altering MSS to 1440 did the trick. See:
http://marc.theaimsgroup.com/?l=linux-netdevm=114373067423528w=2
--clamp-mss-to-pmtu should be the best option.
Cheers,
--
Visit
Herbert Xu wrote:
On Mon, Apr 24, 2006 at 09:23:00AM +, Marco Berizzi wrote:
What should I do? Mangling MSS with iptables --set-mss ?
Altering MSS to 1440 did the trick. See:
http://marc.theaimsgroup.com/?l=linux-netdevm=114373067423528w=2
--clamp-mss-to-pmtu should be the best
m I have forgotten to tell you that both mimosa pleiadi
are running 2.6.16.9 driven by openswan 2.4.5
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Marco Berizzi [EMAIL PROTECTED] wrote:
Is there any news about this issue?
Sorry for the delay, I've been travelling.
The fact that tcpdump with host 172.16.0.138 does not fix it tells
us that this is related to the NAT that you're doing to the 172.16
side of the network.
Looking at your
Marco Berizzi wrote:
Herbert Xu wrote:
Marco Berizzi [EMAIL PROTECTED] wrote:
Running 'tcpdump -p -n -v ip net 10.16.24.117' on mimosa
resolves the problem: sapgui clients can connect to sap
servers while tcpdump is running on mimosa.
Is this a bug?
Very strange. Could you perhaps move
Herbert Xu wrote:
Marco Berizzi [EMAIL PROTECTED] wrote:
Running 'tcpdump -p -n -v ip net 10.16.24.117' on mimosa
resolves the problem: sapgui clients can connect to sap
servers while tcpdump is running on mimosa.
Is this a bug?
Very strange. Could you perhaps move the tcpdump to another
Herbert Xu wrote:
Marco Berizzi [EMAIL PROTECTED] wrote:
Thanks a lot for the reply Herbert.
Is there a way to tell netkey to frag packets like klips
ignoring the DF bit?
Thinking about this again, there is actually a bug in our various tunneling
implementations when the user chooses to
John Heffner wrote:
Marco Berizzi wrote:
Herbert Xu wrote:
Marco Berizzi [EMAIL PROTECTED] wrote:
If I run 'ping 172.16.1.52 -M do -s 1472' from a 172.25.5.0
host I got this result:
PING 172.16.1.52 (172.16.1.52) 1472(1500) bytes of data.
1480 bytes from 172.16.1.52: icmp_seq=1 ttl=62
Marco Berizzi wrote:
Herbert Xu wrote:
Marco Berizzi [EMAIL PROTECTED] wrote:
Thanks a lot for the reply Herbert.
Is there a way to tell netkey to frag packets like klips
ignoring the DF bit?
Thinking about this again, there is actually a bug in our various
tunneling
implementations
Marco Berizzi [EMAIL PROTECTED] wrote:
Running 'tcpdump -p -n -v ip net 10.16.24.117' on mimosa
resolves the problem: sapgui clients can connect to sap
servers while tcpdump is running on mimosa.
Is this a bug?
Very strange. Could you perhaps move the tcpdump to another machine
so that we
Marco Berizzi wrote:
Herbert Xu wrote:
Marco Berizzi [EMAIL PROTECTED] wrote:
If I run 'ping 172.16.1.52 -M do -s 1472' from a 172.25.5.0
host I got this result:
PING 172.16.1.52 (172.16.1.52) 1472(1500) bytes of data.
1480 bytes from 172.16.1.52: icmp_seq=1 ttl=62 time=74.1 ms
1480
Marco Berizzi [EMAIL PROTECTED] wrote:
Thanks a lot for the reply Herbert.
Is there a way to tell netkey to frag packets like klips
ignoring the DF bit?
Thinking about this again, there is actually a bug in our various tunneling
implementations when the user chooses to disable PMTU
Herbert Xu wrote:
Marco Berizzi [EMAIL PROTECTED] wrote:
If I run 'ping 172.16.1.52 -M do -s 1472' from a 172.25.5.0
host I got this result:
PING 172.16.1.52 (172.16.1.52) 1472(1500) bytes of data.
1480 bytes from 172.16.1.52: icmp_seq=1 ttl=62 time=74.1 ms
1480 bytes from 172.16.1.52:
Marco Berizzi [EMAIL PROTECTED] wrote:
Thanks a lot for the reply Herbert.
Is there a way to tell netkey to frag packets like klips
ignoring the DF bit?
There is a netfilter module around which can zap the DF bit for you.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert
I have done a little test to try to understand how ipsec and
mtu play together.
Here is my simple network schema:
net 172.16.0.0--|2.6.16 box|--internet--|2.4-KLIPS|--net 172.25.5.0
+---ipsec tunnel--+
When I run 'ping 172.25.5.30 -M do -s 1472 -c 3' from a
31 matches
Mail list logo
