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):