No subject

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