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 packet dump your setup is definitely suboptimal in that correct MTU information is not being provided to either side of the connection. The result is that the 10.16 end is sending fragments which have to be reassembled at mimosa before immediately getting refragmented on its way to pleiadi. So if it was my network this would be the first issue I'd try to address, possibly through MSS clamping. 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. So I would like your help in tracking that down before you fix your network properly. For a start could you please send me the complete kern.log messages on mimosa from boot time to the point after a slow connection has occured. I'd also like to see /proc/net/snmp at that point. Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - 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
