[35811] in Kerberos
Re: Random failure while communicating with KDC
daemon@ATHENA.MIT.EDU (Sowmya Manjanatha)
Sun Mar 2 18:22:12 2014
Message-ID: <1393631072.21885.YahooMailNeo@web141706.mail.bf1.yahoo.com>
Date: Fri, 28 Feb 2014 15:44:32 -0800 (PST)
From: Sowmya Manjanatha <sowmya_ambale@yahoo.com>
To: Russ Allbery <eagle@eyrie.org>
In-Reply-To: <8738j3108c.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="-215313040-1708113933-1393631072=:21885"
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Reply-To: Sowmya Manjanatha <sowmya_ambale@yahoo.com>
Errors-To: kerberos-bounces@mit.edu
---215313040-1708113933-1393631072=:21885
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Thanks again for your reply.=A0 I gathered some more data per your suggesti=
ons.=0A=0AFrom wireshark trace on the client also, client is not sending an=
y data in between the ACK and RST.=0A=0A=0AI also did another experiment to=
figure out where RST gets issued.=A0 =0A=0A=0AI added a scanf("%c", &ch) r=
ight before "try writing" i.e. before writev is invoked and right after.=A0=
On the first stop, I noticed that RST was not issued but the moment I hit =
a key and we stopped again where write just went through the RST was issued=
.=A0 So, looks like the AD server is not happy about something we are writi=
ng.=0A=0AWhat is being written here?=A0=A0 I am not quite familiar.=A0 I ha=
ve attached the wireshark traces from the client as bad3.cap, bad4.cap and =
bad5.cap=0A=0Abad3.cap is up until only the connection to 445 is made, bad4=
.cap is at the first stop for input from keyboard i.e. write hadn't happene=
d.=0Abad4.cap is right after the first keyboard input i.e. write happened b=
ut nothing else.=0Abad5.cap is the rest until it fails and gives up. =0A=0A=
=0A-Sowmya.=0A=0A=0A=0A=0AOn Friday, February 28, 2014 2:55 PM, Russ Allber=
y <eagle@eyrie.org> wrote:=0A =0ASowmya Manjanatha <sowmya_ambale@yahoo.com=
> writes:=0A=0A> And, in fact, I did a wireshark tracing=A0 on the AD serve=
r.=A0 I see the=0A> "TCP syn, syn-ack and then ack" all going through, a se=
cond later I see=0A> a RST from the server but that is exactly after I see =
"abandoning=0A> connection : Operation now in progress".=0A=0AThat network =
pattern (SYN, SYN-ACK, ACK, RST) sounds like the server is=0Aimmediately (w=
ell, one second later) closing the TCP session after it is=0Aestablished.=
=A0 I'm not very familiar with the Windows side of things, but=0Agiven the =
timing, that smells like a timeout on the server to me.=A0 It=0Aseems like =
the server got a connection from the client, but then the=0Aclient didn't s=
end any data after a second, and the server has a one=0Asecond timeout on i=
ncoming connections.=A0 So it closes the connection.=0A=0AThis could happen=
if, for example, packet loss causes the server to think=0Athe connection i=
s established but the client never sees the completion of=0Athe handshake f=
or some reason.=A0 But it didn't sound like that was=0Aconsistent with the =
network packet trace you're seeing.=A0 It could also=0Ahappen if the client=
data is being sent but lost, so the server never sees=0Ait, and that would=
be consistent with the trace output you had earlier.=0AI'm not sure why yo=
ur network would allow the TCP handshake through but=0Anot the actual data,=
though... a misconfigured firewall that is set up to=0Aaccept handshakes b=
ut not data packets, maybe?=0A=0ADoes the client send any data between the =
ACK and the RST?=A0 Or is the RST=0Athe very next packet that's sent after =
the ACK?=A0 It might be interesting=0Ato check both the client and the serv=
er.=A0 If the client thinks it sent=0Adata but the server never sees it, th=
at would be a very useful data point.=0A=0A=0A> My only guess now is that c=
onnect or write is taking much longer for=0A> ipv6.=A0 Is there a way to wa=
it for the Operation now in progress to go=0A> away when we hit that.=0A=0A=
If the server is sending a RST, then the connection is dead and you won't=
=0Abe able to salvage it.=A0 That's a TCP close.=A0 The question now is why=
is=0Athe server closing the connection?=A0 And if it's because of a timeou=
t, why=0Ais the client not sending any data?=0A=0A-- =0ARuss Allbery (eagle=
@eyrie.org)=A0 =A0 =A0 =A0 =A0 =A0 =A0 <http://www.eyrie.org/~eagle/=0A>
---215313040-1708113933-1393631072=:21885
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
---215313040-1708113933-1393631072=:21885--
