Random failure while communicating with KDC

[subrahmanya]

Hi Ben,

KDC is running in windows 2008 and client in Linux 64. Following is the
code which I had marked in red.

case CONNECTING:
       if (ssflags & SSF_READ) {
           /* Bad -- the KDC shouldn't be sending to us first.  */
           e = EINVAL /* ?? */;
       kill_conn:
           TRACE_SENDTO_KDC_TCP_DISCONNECT(context, conn);
           kill_conn(conn, selstate, e);
           if (e == EINVAL) {
               closesocket(conn->fd);
               conn->fd = INVALID_SOCKET;
           }
           return e == 0;
       }

Thanks
Subrahmanya


On Tue, Feb 25, 2014 at 5:58 AM, Benjamin Kaduk <kaduk at mit.edu> wrote:

> On Mon, 24 Feb 2014, subrahmanya wrote:
>
>  Hi
>>
>> We are randomly facing an issue while authenticating with KDC. KDC is
>> hosted in one machine.
>>
>> I enabled logging in MIT code and also added some more tracing. I observed
>> that EINVAL is printed as value of 'e'. And, looking at other log messages
>> it seems in the failure scenario the code path mentioned in RED below is
>> being executed.
>>
>
> The message delivered to the list contains only a text/plain component;
> there is no color information.
>
>
>  service_tcp_fd(krb5_context context, struct conn_state *conn,
>>               struct select_state *selstate, int ssflags)
>> {
>>    int e = 0;
>>    ssize_t nwritten, nread;
>>
>>    if (!(ssflags & (SSF_READ|SSF_WRITE|SSF_EXCEPTION)))
>>        abort();
>>    switch (conn->state) {
>>        SOCKET_WRITEV_TEMP tmp;
>>
>>    case CONNECTING:
>>        if (ssflags & SSF_READ) {
>>            /* Bad -- the KDC shouldn't be sending to us first.  */
>>            e = EINVAL /* ?? */;
>>        kill_conn:
>>            TRACE_SENDTO_KDC_TCP_DISCONNECT(context, conn);
>>            kill_conn(conn, selstate, e);
>>            if (e == EINVAL) {
>>                closesocket(conn->fd);
>>                conn->fd = INVALID_SOCKET;
>>            }
>>            return e == 0;
>>        }
>>
>> As per the comment in the above code while in "CONNECTING" state SSF_READ
>> flag should never get set (which means select should never return that
>> socket is ready for READ?). But in our case it seems we are finding the
>> flag being set to SSF_READ. Does anyone know what could be the reason for
>> this issue? How could I get it working?
>>
>
> What operating system is the client running that is seeing these errors?
>
> -Ben Kaduk
>