["Abhik Sarkar" <sarkar.abhik@xxxxxxxxx>]

Since the RST comes immediately after a SYN, the source of the RST
could also be a firewall between 10.119.31.11 and 172.27.1.5 which has
been configured not to allow that kind of connection between those
hosts.

On Fri, Sep 19, 2008 at 9:53 PM, LaVallee, Craig (GE Healthcare)
<Craig.LaVallee@xxxxxx> wrote:
> 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
> _______________________________________________
> Wireshark-users mailing list
> Wireshark-users@xxxxxxxxxxxxx
> https://wireshark.org/mailman/listinfo/wireshark-users
>