Wireshark-users: Re: [Wireshark-users] RSK ACK
From: "LaVallee, Craig (GE Healthcare)" <Craig.LaVallee@xxxxxx>
Date: Fri, 19 Sep 2008 13:53:48 -0400
Guy, He sends a SYN is frame 15 No. Time Source Destination Protocol Info 15 79869.707890 10.119.31.11 172.27.1.5 TCP 4783 > 9100 [SYN] Seq=0 Len=0 MSS=1460 Frame 15 (62 bytes on wire, 62 bytes captured) Arrival Time: Aug 21, 2008 07:55:01.568045000 [Time delta from previous packet: 5.757693000 seconds] [Time since reference or first frame: 79869.707890000 seconds] Frame Number: 15 Packet Length: 62 bytes Capture Length: 62 bytes [Frame is marked: False] [Protocols in frame: eth:ip:tcp] [Coloring Rule Name: TCP SYN/FIN] [Coloring Rule String: tcp.flags & 0x02 || tcp.flags.fin == 1] Ethernet II, Src: Cisco_8e:23:02 (00:06:d7:8e:23:02), Dst: Intel_bc:27:a5 (00:04:23:bc:27:a5) Destination: Intel_bc:27:a5 (00:04:23:bc:27:a5) Source: Cisco_8e:23:02 (00:06:d7:8e:23:02) Type: IP (0x0800) Internet Protocol, Src: 10.119.31.11 (10.119.31.11), Dst: 172.27.1.5 (172.27.1.5) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) Total Length: 48 Identification: 0x65a8 (26024) Flags: 0x04 (Don't Fragment) Fragment offset: 0 Time to live: 127 Protocol: TCP (0x06) Header checksum: 0xbf7d [correct] Source: 10.119.31.11 (10.119.31.11) Destination: 172.27.1.5 (172.27.1.5) Transmission Control Protocol, Src Port: 4783 (4783), Dst Port: 9100 (9100), Seq: 0, Len: 0 Source port: 4783 (4783) Destination port: 9100 (9100) Sequence number: 0 (relative sequence number) Header length: 28 bytes Flags: 0x02 (SYN) 0... .... = Congestion Window Reduced (CWR): Not set .0.. .... = ECN-Echo: Not set ..0. .... = Urgent: Not set ...0 .... = Acknowledgment: Not set .... 0... = Push: Not set .... .0.. = Reset: Not set .... ..1. = Syn: Set .... ...0 = Fin: Not set Window size: 32768 Checksum: 0x43e8 [validation disabled] [Good Checksum: False] [Bad Checksum: False] Options: (8 bytes) gGE Healthcare IT GE Healthcare Integrated IT Solutions Craig La Vallee GE Healthcare Information Technologies Escalation Lead, Application & Network Technologies T 330 653-5119 C 330 573-0853 Craig.LaVallee@xxxxxx -----Original Message----- From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris Sent: Friday, September 19, 2008 1:47 PM To: Community support list for Wireshark Subject: Re: [Wireshark-users] RSK ACK On Sep 19, 2008, at 10:12 AM, LaVallee, Craig (GE Healthcare) wrote: > Who is causing the reset? 172.27.1.5 is, obviously, as it's the one issuing the RST. :-) As for *why* it's causing it, that's another matter. Perhaps 172.27.1.5 rebooted while a connection was open, and, after the reboot, 10.119.31.11 tried sending another packet on that connection, and got an RST back because, after the reboot, 172.27.1.5 didn't know about the connection any more. What happened in the packets before packet 16? _______________________________________________ Wireshark-users mailing list Wireshark-users@xxxxxxxxxxxxx https://wireshark.org/mailman/listinfo/wireshark-users
- Follow-Ups:
- Re: [Wireshark-users] RSK ACK
- From: Abhik Sarkar
- Re: [Wireshark-users] RSK ACK
- References:
- [Wireshark-users] RSK ACK
- From: LaVallee, Craig (GE Healthcare)
- Re: [Wireshark-users] RSK ACK
- From: Guy Harris
- [Wireshark-users] RSK ACK
- Prev by Date: Re: [Wireshark-users] RSK ACK
- Next by Date: Re: [Wireshark-users] SNTP Protocol
- Previous by thread: Re: [Wireshark-users] RSK ACK
- Next by thread: Re: [Wireshark-users] RSK ACK
- Index(es):