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
>
