Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

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