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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: Sowmya Manjanatha <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/ > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
