[OpenAFS] connection timeouts

[Jeffrey Hutzelman]

On Monday, May 22, 2006 12:52:06 PM +0300 Juha J=E4ykk=E4 <juolja@utu.fi> =
wrote:

>> - Output of 'cmdebug <client-ip-addr>'
>
> Produced nothing at all. (Since this, and the next, line stated
> "client-ip", I assumed they should be run on the server and the last on
> the client. Hope I was correct! =3D) )

"nothing" is reasonable output from this command.  Any output would have=20
described the state of currently-held locks within the cache manager; if=20
the problem had been some sort of deadlock, this would have help to=20
identify it.

It doesn't matter where you run cmdebug or rxdebug; they query the thing=20
you name on the command line and print some debugging data.


>> - Output of 'rxdebug <client-ip-addr> 7001'
>
> Trying 130.232.104.188 (port 7001):
> Free packets: 130, packet reclaims: 0, calls: 17469, used FDs: 64
> not waiting for packets.
> 0 calls waiting for a thread
> 1 threads are idle
> Done.

Also fairly normal


>> - Output of 'rxdebug <fileserver-ip-addr>'
>
> lagrange:~# rxdebug dirac.tfy.utu.fi
> Trying 130.232.105.174 (port 7000):
> Free packets: 582, packet reclaims: 81, calls: 94967, used FDs: 64
> not waiting for packets.
> 0 calls waiting for a thread
> 11 threads are idle
> Connection from host 130.232.104.188, port 7001, Cuid 83aaa7c0/4dff9bc,
> error 19270409 serial 6,  natMTU 1444, flags pktCksum, security index 2,
> server conn rxkad: level clear, flags pktCksum
>   Received 0 bytes in 0 packets
>   Sent 0 bytes in 0 packets
>     call 0: # 182, state precall, mode: error

You've seen Derrick's comment on this connection.  The call is in state=20
precall mode error, with an error code that means the tickets are expired.=20
This was probably not the case when you were actually seeing a problem, so=20
it doesn't give us much.  You should collect the same data again next time=20
you see the problem.

As Derrick mentions, you should use tcpdump -s 1500 -x, which will print=20
full dumps of the contents of each packet.  A couple of more -v's wouldn't=20
hurt, either, though tcpdump's ability to decode AFS packets is a bit=20
limited.


> Connection from host 130.232.105.162, port 7001, Cuid b06eb0e7/118cd340
>   serial 1074,  natMTU 1444, security index 0, client conn
>     call 0: # 537, state dally, mode: receiving, flags: receive_done
>     call 1: # 0, state not initialized
>     call 2: # 0, state not initialized
>     call 3: # 0, state not initialized

This connection is irrelevant to this issue.  I probably should have told=20
you to use the '-nodally' switch to rxdebug, which would have suppressed=20
this connection.

-- Jeff