It's possible that some network device may be intercepting the
conversation and "killing" the connection, though this would be a bit
odd way for it to happen. Especially not in a well-designed network.
A traditional "router" has no concept of TCP connections and wouldn't
do anything here. A firewall, VPN device, etc might but typically
they'll simply "absorb" traffic they don't like (instead of explicity
generating a RST), and stateful firewalls will usually allow return
traffic on a conversation if it allowed the conversation to be
initiated in the first place (so it's odd, but definitely not
impossible, that the SYN-ACK would be RST)
If you take a trace at the client side, to do you see it explicitly
generating the RST? If so, there's no network equipment involved with
your problem here (at least not generating the RST, though if something
is making modifications to traffic your client may not like what's
happening)
If so, sounds to me like your app started to open a connection but
failed, aborted, or in some other way was no longer active on the
socket that it initiated the connection on when SYN-ACK returned. Is
latency between these two sites particularly high? Does your app have
some extremely small connection timeout? Either way I'd expect to see
some immediate and negative result code from whatever you're using to
open the connection.
Otherwise, if the client doesn't see the SYN-ACK returned to it, your
problem sounds like it's in network hardware somewhere. Do you have a
firewall in the way? VPN device? Firewall features enabled in the
Cisco firewall?
Ian
On Aug 5, 2004, at 11:48 AM, Matt Kopf wrote:
Although I agree with this. These are both computers that we control,
and
the handshake is started with the start of our own application. It
works
just fine over the LAN, but when you take the computer to this remote
location that goes over the Cisco router you see the RST flag and the
application dies. So I am very sure that it is not a SYN scan in this
particular situation at least. At least I know what to keep my eyes
open for
though Thanks!
Matt
-----Original Message-----
From: ethereal-users-bounces@xxxxxxxxxxxx [mailto:ethereal-users-
bounces@xxxxxxxxxxxx] On Behalf Of Jim Hendrick
Sent: Wednesday, August 04, 2004 20:20
To: 'Ethereal user support'
Subject: RE: [Ethereal-users] RST flag question
Sounds like someone mapping your server with a classic SYN scan (look
at
nmap).
The "client" looks for open services this way. Sending a SYN, waiting
for a
SYN/ACK (indicating a listening service) and replying with a RST (not
causing the connection to be opened, which would get logged on the
server,
but letting the scanner (client) know that a service is alive and
reachable.
Later,
Jim
-----Original Message-----
From: ethereal-users-bounces@xxxxxxxxxxxx
[mailto:ethereal-users-bounces@xxxxxxxxxxxx] On Behalf Of Matt Kopf
Sent: Wednesday, August 04, 2004 4:26 PM
To: 'Ethereal user support'
Subject: [Ethereal-users] RST flag question
Doing some monitoring on a network link that goes over a Cisco router
I saw
many times where the computer on the other end will start the
handshake
process, the server answered and then a RST from the client. So the
question
is:
Can the router set the RST flag?
What would cause the OS (windows) to set the RST flag?
Thanks for the help.
Matt Kopf
_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users
_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.732 / Virus Database: 486 - Release Date: 07/29/2004
_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users
