Random failure while communicating with KDC

[subrahmanya]

Even I had the issue when port number of KDC was not specified in krb5.conf
file. After debugging for sometime I also figured out the same. So I had to
mention port number as 88 after which frequency of the error has reduced
but I still get the error sometimes when the program is run in a loop or if
number of threads performing authentication is increased.


On Sun, Mar 2, 2014 at 7:37 PM, Sowmya Manjanatha
<sowmya_ambale at yahoo.com>wrote:

> ok.  I finally figured out the issue.
>
> The reason Windows was issuing a RST right after a write happened in
> service_tcp_fd was because we were sending kerberos authentication to port
> 445 while kdc is listening on port 88 not 445.  After tracing, it was samba
> sending the wrong port to kerberos.  I haven't still figured out where in
> samba is this getting set wrongly.
>
> But, I hardcoded the port for now to 88 where
> /var/cache/samba/smb_krb5/krb5.conf.<domain> gets created inside samba code
> and now the join seems to happen fine.
>
>
>
>
> On Friday, February 28, 2014 6:54 PM, Sowmya Manjanatha <
> sowmya_ambale at yahoo.com> wrote:
>
> I am wondering now after the whole saga :-) Has any one successfully been
> able to contact an ipv6 windows KDC ? or joined an ipv6 domain using
>
> "net ads join ...." command that uses krb5?
>
> Thanks for all the help again.  Very much appreciated.
>
>
> -Sowmya.
>
>
>
>
> On , Sowmya Manjanatha <sowmya_ambale at yahoo.com> wrote:
>
> Thanks again for your reply.  I gathered some more data per your
> suggestions.
>
> >From wireshark trace on the client also, client is not sending any data
> in between the ACK and RST.
>
>
> I also did another experiment to figure out where RST gets issued.
>
>
> I added a scanf("%c", &ch) right before "try writing" i.e. before writev
> is invoked and right after.  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.  So, looks like the AD server is not happy
> about something we are writing.
>
> What is being written here?   I am not quite familiar.  I have attached
> the wireshark traces from the client as bad3.cap, bad4.cap and bad5.cap
>
> bad3.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 happened.
> bad4.cap is right after the first keyboard input i.e. write happened but
> nothing else.
> bad5.cap is the rest until it fails and gives up.
>
>
> -Sowmya.
>
>
>
>
> On Friday, February 28, 2014 2:55 PM, Russ Allbery <eagle at eyrie.org>
> wrote:
>
> Sowmya Manjanatha <sowmya_ambale at yahoo.com> writes:
>
> > And, in fact, I did a wireshark tracing  on the AD server.  I see the
> > "TCP syn, syn-ack and then ack" all going through, a second later I see
> > a RST from the server but that is exactly after I see "abandoning
> > connection : Operation now in progress".
>
> That network pattern (SYN, SYN-ACK, ACK, RST) sounds like the server is
> immediately (well, one second later) closing the TCP session after it is
> established.  I'm not very familiar with the Windows side of things, but
> given the timing, that smells like a timeout on the server to me.  It
> seems like the server got a connection from the client, but then the
> client didn't send any data after a second, and
>  the server has a one
> second timeout on incoming connections.  So it closes the connection.
>
> This could happen if, for example, packet loss causes the server to think
> the connection is established but the client never sees the completion of
> the handshake for some reason.  But it didn't sound like that was
> consistent with the network packet trace you're seeing.  It could also
> happen if the client data is being sent but lost, so the server never sees
> it, and that would be consistent with the trace output you had earlier.
> I'm not sure why your network would allow the TCP handshake through but
> not the actual data, though... a misconfigured firewall that is set up to
> accept handshakes but not data packets, maybe?
>
> Does the client send any
>  data between the ACK and the RST?  Or is the RST
> the very next packet that's sent after the ACK?  It might be interesting
> to check both the client and the server.  If the client thinks it sent
> data but the server never sees it, that would be a very useful data point.
>
>
> > My only guess now is that connect or write is taking much longer for
> > ipv6.  Is there a way to wait for the Operation now in progress to go
> > away when we hit that.
>
> If the server is sending a RST, then the connection is dead and you won't
> be able to salvage it.  That's a TCP close.  The question now is why is
> the server closing the connection?  And if it's because of a timeout, why
> is the client not
>  sending any data?
>
> --
> Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/
> >
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>