Greg, Thanks, you are right, in the case of service_tcp_fd(), the state is re-analyzed after a poll() and set up as new with cm_get_ssflags(). I double checked my setup and found out a port configuration issue with my KDC. I fixed it and TCP is working fine now.
-- Oli. On Mon, Apr 2, 2012 at 6:23 PM, Greg Hudson <[email protected]> wrote: > On 04/02/2012 11:30 AM, Oli Mlist wrote: > > - at the end of start_connection(), there is an ssflags local variable > into > > which the SSF_READ flag is being set (among others), and this state is > > saved through cm_add_fd(). > > - for TCP sockets, the service_tcp_fd() function is called, running a > state > > machine. > > - inside service_tcp_fd(), for the CONNECTING state, a check is made for > > the SSF_READ flag. If this flag is set, a comment tells the KDC is > sending > > data to us, which is interpreted as an error, so the TCP socket is > > disconnected by the client. As seen above, this SSF_READ flag had been > > explicitly set at the end of start_connection(). > > The flags to service_tcp_fd() come from cm_get_ssflags(), which > processes the revents member of the pollfd, not the events member which > was set in cm_add_fd(). So, poll() is saying that a read on the TCP > socket wouldn't block, implying that there is either data to be read or > a socket error to be processed, neither of which happens during a > successful exchange. > > > Thanks to let me know if this is indeed a but or whether I am missing > > something, > > I put together a simple test case and was able to communicate with a KDC > over TCP. > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
