Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sometimes from Linux system I see the following weird behaviour:

I able to ping things and sometimes use some services, but networking is very bad.

For example, now I routed connection through my laptop (-j MASQUERADE) and observing the following thing: If I do little TCP connection (server sends few data to me), it proceeds:

# nc 86.57.151.3 80
GET /404
<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

/proc/net/ip_conntrack has tcp 6 431998 ESTABLISHED src=192.168.99.9 dst=86.57.151.3 sport=49104 dport=80 src=86.57.151.3 dst=93.125.21.218 sport= 80 dport=49104 [ASSURED] mark=0 use=2 before I typed "GET /404".

But when I do big connection:

root@localhost:~# nc 86.57.151.3 80
GET /

It stalls. Before I enter "GET /" it shows ESTABLISHED ASSURED, as usual, but after I press Return it goes to tcp 6 0 CLOSE_WAIT src=192.168.99.9 dst=86.57.151.3 sport=56991 dport=80 src=86.57.151.3 dst=93.125.21.218 sport=80 dpo rt=56991 [ASSURED] mark=0 use=2. No packet with is received. When I finally press Ctrl+C, it sends FIN to server, and Wireshard complains that server's FIN is "Out-of-order". Like if the reply packed dropped somewhere.

When I do the same nc 86.57.151.3 80/GET / from router, it works.

How to debug what is wrong?

share|improve this question
    
What is your latency? –  soandos Aug 19 '11 at 19:04
    
10 ftp.mgts.by (86.57.151.3) 29.143 ms 29.363 ms 32.788 ms –  Vi. Aug 19 '11 at 19:10
1  
MTUs: client system: wlan0 MTU:1500; router: wifi0: MTU:1500; ppp4: MTU:1492; One further router: all MTU's are 1500. –  Vi. Aug 19 '11 at 19:12
    
Strange: after setting all above mentioned MTUs to 1492 it seems started working. Why does MTU matter? Should it fragment things when needed? –  Vi. Aug 19 '11 at 19:19
2  
@Vi: It should. However, some netadmins foolishly block all ICMP packets for "security" reasons, which means ICMP "Fragmentation Needed" errors get blocked too, and the sender doesn't know the fragmentation is needed. See Path MTU Discovery and Filtering ICMP. –  grawity Aug 19 '11 at 20:33

1 Answer 1

up vote 4 down vote accepted

This is the problem with MTU and filtered ICMP messages somewhere.

Workaround is setting MTU on the client device or using TCP MSS clamping on router:

iptables -t mangle -A FORWARD -o ppp4 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.