Macintosh OS X.2 question

[Philip Rinehart]

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 
>> file).
>> 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
> consideration.
>
>> Also, I imagine a tcpdump trace will show that the krb524 request is 
>> not
>> 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, 
>> you
>> 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
> seconds.
>
> 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
> behavior.
>
> 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, 
>> and
>> 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.
>
> Ken
>

-------------------------------
Philip Rinehart
Academic Media & Technology
Cluster Support Services
203-432-6573
philip.rinehart at yale.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3957 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20021202/9ba41d6b/attachment.bin