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 <[email protected]>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 < > [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 > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
