Hi, If this is the wrong list, I'd love to hear which is the right one for this query. :) I've recently moved from 2.4.20 + Free/SWAN 1.96 (inc. KLIPS) to 2.6.6 with FreeS/WAN 2.05 userspace, and kernel-native IPSec. It's all working very nicely save for one thing - traceroute. I am unable to reproduce the previous behaviour from 2.4.20 where I'd get gdh:/var/www# traceroute pod traceroute to pod.nation-net.com (213.2.4.33), 30 hops max, 38 byte packets 1 fw-ws.nation-net.com (194.200.209.247) 1.136 ms 0.618 ms 0.662 ms 2 fw-mcc.nation-net.com (213.2.4.61) 45.863 ms 44.909 ms 51.069 ms 3 pod.nation-net.com (213.2.4.33) 91.987 ms 57.187 ms 76.253 ms almost instantly. Now the behaviour is different depending on if I use traditional UDP or ICMP-based traceroute... UDP: gdh@gdh:~$ traceroute -w 2 pod traceroute to pod.nation-net.com (213.2.4.33), 30 hops max, 38 byte packets 1 194.200.209.247 (194.200.209.247) 1.098 ms 0.993 ms 0.910 ms 2 * * * 3 * * * [.... all the way up to hop 30...] ICMP: mop:/var/log# traceroute -I pod traceroute to pod.nation-net.com (213.2.4.33), 30 hops max, 38 byte packets 1 194.200.209.247 (194.200.209.247) 0.488 ms 3.062 ms 2.933 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 pod.nation-net.com (213.2.4.33) 19.962 ms 19.010 ms 18.452 ms And that's the right number of hops for the 'real' trace. I know the packets ARE all encrypted because I can see them with tcpdump from the remote 2.4.20 machine on eth0 (and I can see the unencrypted versions on ipsec0). Does this make sense to anyone? Cheers, Gavin. - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
