[5090] in Kerberos
Re: Kerberos 5 beta 4-3 on SGI Indy
daemon@ATHENA.MIT.EDU (Shawn Mamros)
Fri May 5 09:26:28 1995
To: kerberos@MIT.EDU
Date: Fri, 05 May 1995 09:08:32
From: mamros@ftp.com (Shawn Mamros)
Reply-To: mamros@ftp.com
boone@prep.net (Jon 'Iain' Boone) writes:
>1) The initial request for a tgt is only given 1 second for a response,
>after which another request is sent with 1 second timeout. After
>those two, two are sent with 4 second timeouts, then two with 16
>second timeouts. After the last request, one of the 6 responses
>that were sent is decrypted and then installed in the cache.
>
>This behavior is certainly broken and I'm in the process of figuring
>out why it does this and how to stop it.
It looks like the client simply isn't seeing the response(s) from the
server, so it's retransmitting the request using an exponential
backoff, as it should.
Now, why wouldn't it see the responses? Good question... If I remmber
right, you said in an earlier posting that you're using a serial line
(SLIP) connection between your client and server. Given that adding
debug messages seems to help the situation, it sounds to me like there
might be some subtle timing bug in the SLIP implementation on your
Kerberos client. Perhaps the initial one second timeout is too short,
and the client is starting to retransmit before the first response from
the server makes it back, and the client somehow misses the response.
(This is pure guesswork on my part; I'm not a SLIP expert and I don't play
one on TV, either...) You might want to try increasing the first timeout
value to, say, four seconds and see if that helps. All you have to do
is change SKDC_TIMEOUT_1 to 4 in <krb5/osconf.h> (it wouldn't hurt to
change SKDC_TIMEOUT_SHIFT to 1 while you're at it, so that you get the
same number of retries), recompile lib/krb5/os/osconfig.c, rebuild libkrb5.a
and relink kinit.
The other possibility is that the MTU of the SLIP line is too small for
the KDC reply (Kerberos V5 messages tend to be large enough that this
could be a possibility), resulting in UDP fragmentation that might mess
things up. If that's the case, the easiest alternative might be to
switch from SLIP to PPP...
-Shawn Mamros
E-mail to: mamros@ftp.com
