Re: ACK and RST packets sent after successfully terminating TCP connection
Packet #9: client -- server: client requests TCP connection close (FIN+ACK) Packet #10: server -- client: server sends ACK approximately 0.6 seconds passes Packet #11: server -- client: server announces TCP window size of 0, indicating TCP receive buffers are exhausted and that the client should wait before doing anything more Packet #12: server -- client: identical re-sent ACK of packet #10 That is exactly the point: why is server sending any packets when connection was FIN'ned successfully by both sides? To my understanding of networking protocols, packets #11 and #12 should have never been sent. approximately 0.75 seconds passes Packet #5: server -- client: server announces TCP window size of 0, indicating TCP receive buffers are exhausted and that the client should wait before doing anything more Packet #6: server -- client: identical re-sent RST of packet #4 Packet #7: client -- server: confirms reset (RST+ACK) Actually, it seems server confirm SYN-ACK packet and not the RST (packet #7 is ack 2849043653 which is packet #2 - I'm running tcpdump with -S to see absolute sequence numbers). Whatever this client/server protocol is, it isn't normal/standard. It's not something like, for example, HTTP, SSH, or FTP; It's a custom protocol and one I haven't seen before. It is a custom protocol at the application layer, meaning that instead of HTTP payload it has a different (XML) payload, but everything below is (hopefully) standard. Do you see the above awkward behaviour (zero-sized TCP window packets followed by a retransmission of a prior packet) when using standardised protocols or software, such as Apache (HTTP), OpenSSH (SSH), or FTP? I'll see what I can find out. If not, then the client/server software is probably to blame. It may be operating on a raw socket level, populating IP and/or TCP portions of the packet itself rather than relying on socket(2) entirely. Client software is Java on Windows, but according to the pcaps, the client is not misbehaving. On the other hand, server software is Perl IO::Socket::INET which is pretty much a standard library and shouldn't be the problem as well. If it uses standard kernel socket(2) functionality with PF_INET and SOCK_STREAM, then I'd ask if the source is available publicly to be analysed to determine if this behaviour is intentional or not. If needed, posting the relevant code snippets shouldn't be a problem. Is there VPN and/or NAT involved between the client and server (re: NAT: particularly around the server)? No. Finally, is it possible to get ifconfig -a and netstat -m output from the server? Certainly. # ifconfig -a (inet addr anonymized) em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:0b:db:92:51:ec inet aaa.bbb.cc.dd netmask 0xff00 broadcast aaa.bbb.cc.255 media: Ethernet autoselect (1000baseTX full-duplex) status: active rl0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8VLAN_MTU ether 00:c0:df:06:4e:8c media: Ethernet autoselect status: no carrier plip0: flags=108810POINTOPOINT,SIMPLEX,MULTICAST,NEEDSGIANT metric 0 mtu 1500 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 # netstat -m 259/1526/1785 mbufs in use (current/cache/total) 256/1360/1616/25600 mbuf clusters in use (current/cache/total/max) 256/768 mbuf+clusters out of packet secondary zone in use (current/cache) 0/552/552/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 576K/5309K/5886K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/22/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 209 requests for I/O initiated by sendfile 0 calls to protocol drain routines Your help is really appreciated. Regards, -- Nino ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ACK and RST packets sent after successfully terminating TCP connection
Hi all, I'm reposting this from the freebsd-questions hoping for some answers. I feel there is something wrong here, but would really appreciate a second opinion before opening a bug report. The problematic part is marked with [what is this?]. - in case of successful connection: [begin handshake] 14:52:57.866040 IP client.example.net.6524 server.example.net.9002: S 813851098:813851098(0) win 8192 mss 1380,nop,wscale 2,nop,nop,sackOK 14:52:57.866057 IP server.example.net.9002 client.example.net.6524: S 3888621507:3888621507(0) ack 813851099 win 65535 mss 1380,nop,wscale 3,sackOK,eol 14:52:57.867143 IP client.example.net.6524 server.example.net.9002: . ack 3888621508 win 16560 [end handshake begin data] 14:52:57.868333 IP client.example.net.6524 server.example.net.9002: P 813851099:813852180(1081) ack 3888621508 win 16560 14:52:57.967858 IP server.example.net.9002 client.example.net.6524: . ack 813852180 win 8144 14:53:35.533165 IP server.example.net.9002 client.example.net.6524: P 3888621508:3888621542(34) ack 813852180 win 8144 [end data begin teardown] 14:53:35.564542 IP server.example.net.9002 client.example.net.6524: FP 3888621542:3888621675(133) ack 813852180 win 8280 14:53:35.566228 IP client.example.net.6524 server.example.net.9002: . ack 3888621676 win 16518 14:53:35.566289 IP client.example.net.6524 server.example.net.9002: F 813852180:813852180(0) ack 3888621676 win 16518 14:53:35.566318 IP server.example.net.9002 client.example.net.6524: . ack 813852181 win 8279 [end teardown] [what is this?] 14:53:36.172081 IP server.example.net.9002 client.example.net.6524: . ack 813852180 win 0 14:53:36.172101 IP server.example.net.9002 client.example.net.6524: . ack 813852181 win 8279 - in case of unsuccessful connection: [begin handshake] 14:53:00.411337 IP client.example.net.6547 server.example.net.9002: S 1055031875:1055031875(0) win 8192 mss 1380,nop,wscale 2,nop,nop,sackOK 14:53:00.411354 IP server.example.net.9002 client.example.net.6547: S 2849043653:2849043653(0) ack 1055031876 win 65535 mss 1380,nop,wscale 3,sackOK,eol 14:53:00.412242 IP client.example.net.6547 server.example.net.9002: . ack 2849043654 win 16560 [end handshake reset connection] 14:53:00.412251 IP server.example.net.9002 client.example.net.6547: R 2849043654:2849043654(0) win 0 [what is this?] 14:53:01.168076 IP server.example.net.9002 client.example.net.6547: . ack 1055031876 win 0 14:53:01.168100 IP server.example.net.9002 client.example.net.6547: R 2849043654:2849043654(0) win 0 14:53:01.168393 IP client.example.net.6547 server.example.net.9002: R 1055031876:1055031876(0) ack 2849043653 win 0 The server is running 7.2 GENERIC. Thanks, -- Nino ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ACK and RST packets sent after successfully terminating TCP connection
Hello Jeremy,
Is it possible for you to upload these captures somewhere on the web?
tcpdump -p -i {iface} -s 0 -n -w {somefile} should be sufficient.
You can find the two pcaps at http://drop.io/llwiy8o. IP addresses and
the data have been anonymized, everything else has been left intact.
There was no ICMP traffic between the hosts. Thanks for looking into
it!
Regards,
--
Nino
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ACK and RST packets sent after successfully terminating TCP connection
On Mon, Feb 15, 2010 at 10:07:32PM +0100, n j wrote:
Hello Jeremy,
Is it possible for you to upload these captures somewhere on the web?
tcpdump -p -i {iface} -s 0 -n -w {somefile} should be sufficient.
You can find the two pcaps at http://drop.io/llwiy8o. IP addresses and
the data have been anonymized, everything else has been left intact.
There was no ICMP traffic between the hosts. Thanks for looking into
it!
succ.pcap --
skipping obvious stuff
Packet #9: client -- server: client requests TCP connection close (FIN+ACK)
Packet #10: server -- client: server sends ACK
approximately 0.6 seconds passes
Packet #11: server -- client: server announces TCP window size of 0,
indicating TCP receive buffers are exhausted and that the
client should wait before doing anything more
Packet #12: server -- client: identical re-sent ACK of packet #10
fail.pcap --
skipping obvious stuff
Packet #3: client -- server: initial handshake; TCP ACK
Packet #4: server -- client: server sends TCP RST. Software on
server likely closed the socket/fd
approximately 0.75 seconds passes
Packet #5: server -- client: server announces TCP window size of 0,
indicating TCP receive buffers are exhausted and that the
client should wait before doing anything more
Packet #6: server -- client: identical re-sent RST of packet #4
Packet #7: client -- server: confirms reset (RST+ACK)
Whatever this client/server protocol is, it isn't normal/standard. It's
not something like, for example, HTTP, SSH, or FTP; It's a custom
protocol and one I haven't seen before.
Do you see the above awkward behaviour (zero-sized TCP window packets
followed by a retransmission of a prior packet) when using standardised
protocols or software, such as Apache (HTTP), OpenSSH (SSH), or FTP?
If not, then the client/server software is probably to blame. It may be
operating on a raw socket level, populating IP and/or TCP portions of
the packet itself rather than relying on socket(2) entirely.
If it uses standard kernel socket(2) functionality with PF_INET and
SOCK_STREAM, then I'd ask if the source is available publicly to be
analysed to determine if this behaviour is intentional or not.
Is there VPN and/or NAT involved between the client and server
(re: NAT: particularly around the server)?
Finally, is it possible to get ifconfig -a and netstat -m output
from the server?
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
