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
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, t
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 d
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 http://vge
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 PROTECTED]:/tm
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: icmp_
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 aga
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
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:
> http://marc.theaimsgroup.com/?l=linux-netdev&m=1143730
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 1
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-netdev&m=114373067423528&w=2
Yes that's enough, although proper PMTU would be
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 all
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: sam
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 w
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 Herber
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-netdev&m=114373067423528&w=2
--clamp-mss-to-pmtu should be the best o
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-netdev&m=114373067423528&w=2
--clamp-mss-to-pmtu should be the best option.
Cheers,
--
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 you
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 perhap
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 a
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 th
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
implementation
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
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
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 disc
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
>
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: He
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
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: icmp_seq=2 tt
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
172.16.
32 matches
Mail list logo
