Random failure while communicating with KDC

[Sowmya Manjanatha]

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/
>