Date: Wed, 8 Oct 1997 19:34:43 -0200 (EDT) From: Joao Carlos Mendes Luis <jonny@coppe.ufrj.br> To: joerg_wunsch@uriah.heep.sax.de Cc: hackers@FreeBSD.ORG, jonny@coppe.ufrj.br Subject: Re: TCP problem Message-ID: <199710082134.TAA24677@gaia.coppe.ufrj.br> In-Reply-To: <19971008084717.VY20773@uriah.heep.sax.de> from J Wunsch at "Oct 8, 97 08:47:17 am"
next in thread | previous in thread | raw e-mail | index | archive | help
#define quoting(J Wunsch) // > 22:49:35.574865 146.164.5.200.2038 > 146.164.53.91.19: S 1153321686:1153321686(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp[|tcp]> (DF) [tos 0x10] (ttl 64, id 38631) // // Btw., you should run tcpdump with a larger snaplen (-s 200 for // example). The "|tcp" above means you don't see the complete packet // options displayed. Probably not very important here, though. This happens with any kind of TCP connection. I used chargen just for demonstration purposes. // > 22:49:35.576498 146.164.53.91.19 > 146.164.5.200.2038: S 2381730138:2381730138(0) ack 1153321687 win 31744 <mss 1460> (ttl 63, id 13086) // > 22:49:35.576825 146.164.5.200.2038 > 146.164.53.91.19: . ack 1 win 164 (DF) [tos 0x10] (ttl 64, id 38632) // // What looks interesting to me is that, while the SYN packet offered a // window of 64 K, the first data packet only offers 164 bytes. And: // // > 22:49:35.614489 146.164.53.91.19 > 146.164.5.200.2038: P 1:75(74) ack 1 win 31744 (DF) [tos 0x10] (ttl 63, id 13088) // > 22:49:35.804015 146.164.5.200.2038 > 146.164.53.91.19: . ack 75 win 90 (DF) [tos 0x10] (ttl 64, id 38638) // > 22:49:36.646712 146.164.53.91.19 > 146.164.5.200.2038: P 75:165(90) ack 1 win 31744 [tos 0x10] (ttl 63, id 13091) // > 22:49:36.804033 146.164.5.200.2038 > 146.164.53.91.19: . ack 165 win 0 (DF) [tos 0x10] (ttl 64, id 38646) // // ...none of these bytes are claimed to be delivered to the application, ???? The application in case was telnet, and it has received the data. // so the window goes 0 for some reason. You see it stopping always at the // same point since it's probably always offering exactly the same 164 bytes // in the first data packet. // // You might get some hints out of `netstat -s', perhaps. Looking for mbuf leakage as David suggested or nothing in particular ? // What makes me wonder is why it's offering a 64 KB window in the first // SYN at all? If i try it here, it only offers 16 KB. Did you // manipulate the TCP-related kernel variables? I remember there was Uh, er, yes... :) I wanted to test some parameters in order to push network performance since this machine is a mid-sized squid server that I'm using to project bigger ones. /usr/sbin/sysctl -w kern.somaxconn=1024 /usr/sbin/sysctl -w kern.maxsockbuf=1048576 /usr/sbin/sysctl -w net.inet.tcp.sendspace=65536 /usr/sbin/sysctl -w net.inet.tcp.recvspace=65536 /usr/sbin/sysctl -w net.inet.tcp.always_keepalive=1 But the problem in question does not always happen. And when it happens, it only happens with the Linux machine. It continues working perfectly with other machines. // another bug report yesterday where increasing some TCP parameter // yielded an unusable connection. I think Bill has fixed something in // this area yesterday. Has this been integrated to RELENG_2_2 ? Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710082134.TAA24677>