Il 26/10/2011 21:43, Julian Anastasov ha scritto:
I looked at broken-spoofing-server.pcap and broken-spoofing-client.pcap It looks like that this packet comes after some packet that is dropped before server: IP 2.119.245.36.80> 88.38.77.130.39243: Flags [P.], seq 1449:1534, ack 602, win 438, options [nop,nop,TS val 17124611 ecr 56937089], length 85 May be the seq 1:1449 packet can not reach 2.119.245.36.80, that is why it does not go to client 88.38.77.130.39243. May be server is a virtual server or something like that. I guess someone before 2.119.245.36.80 is sending large packets and some MTU is low and may be due to missing ICMP the sender there can not learn the lower path MTU. May be client can use ip route add ... advmss 1400 to check if problem is fixed that way. May be there is some tunnel behind the server that uses lower MTU. Note that some 3.0.X kernels have problem that ICMP is not sent and this can cause PMTU problems.
SOLVED! Thanks Julian Anastasov. Niccolò -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
