Macintosh OS X.2 question
philip.rinehart at yale.edu
Mon Dec 2 18:59:00 EST 2002
I don't think the problem I have is related to tcp/ip traffic. With a
tcp/ip dump I see the krb524 being sent via UDP to port 252. However,
after the initial connection, there is no traffic for approximately 15
seconds, then the acknowledgement from the tcp/ip traffic.
On Monday, December 2, 2002, at 05:07 PM, Ken Raeburn wrote:
> "Paul W. Nelson" <nelson at thursby.com> writes:
>> Kinit will pick up on the icmp message and skip the krb524 step, but
>> sometimes the icmp message gets filtered out by routers, especially
>> when NAT
>> is used.
>> It would be really nice to be able to skip this step, or devise a
>> method for
>> telling stuff like kinit that krb524 is not supported (in the config
>> Relying on icmp port not reachable messages is not the best especially
>> across the internet.
>> From a purist point of view, I could probably debate the idea that
> you're on the Internet if you're stuck behind a NAT box. And any
> router configuration that blocks icmp port-unreachable messages is
> broken. They're probably breaking path MTU discovery too.
> But having some means to indicate that krb524 is not supported would
> be helpful; I've forwarded that idea into our bug database for future
>> Also, I imagine a tcpdump trace will show that the krb524 request is
>> retransmitted. I can understand waiting 15-20 seconds for a response
>> if you
>> keep retransmitting the UDP request, but it doesn't make sense to
>> send only
>> one UDP datagram and then wait that long. If the datagram gets lost,
>> are just wasting your time waiting.
> In many situations that's probably true. But if you're far away from
> the KDC, or have an unusually slow or heavily loaded link between you
> and the KDC, it can take many seconds for traffic to get through. And
> if the KDC is heavily loaded, it may take a while to get around to
> processing your request.
> That said, the delays we use in the 1.2.x code branch are probably
> higher than they need to be. In the case of timeouts from every
> server, I think the delay period is something like 21 seconds per
> server address/port it tried to contact. But that should include
> three transmissions of the message, with delays of 1, 4, and 16
> In the upcoming 1.3 release, the send-to-kdc code in the krb5 library
> has been rewritten, and the krb524 code calls it. The new code
> supports TCP and IPv6 (which aren't used for krb524), and listens for
> a response from *any* server while it waits, not just the one most
> recently sent to. It also shortens the delays; current worst-case is
> 14 seconds plus one second per TCP server plus three seconds per UDP
> server. Yeah, it's kind of complicated, our approach is still "send,
> wait for a reply, send to next server, waiting for increasing periods
> before retransmitting", but the inter-pass delays grow more slowly and
> are between passes instead of after every transmission; this gives us
> more retransmits than before, less overall time, and better listening
> That's for the krb5 and krb524 code; so far, the old krb4 send-to-kdc
> code hasn't been rewritten.
> Anyways, these details aside, failure to reach a KDC or krb524 server
> probably is the cause of the original problem.
>> I think the retry: label in krb524/sendmsg.c is in the wrong place,
>> should be moved up a few lines so it is before the send call:
> The "retry" label is intended to set up a loop around the select()
> call, to deal with situations where select() returns an EINTR
> indication (for example, being interrupted by a signal). The larger
> loop around it is for retransmitting.
Academic Media & Technology
Cluster Support Services
philip.rinehart at yale.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 3957 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20021202/4723f066/attachment.bin
More information about the krbdev