[OpenAFS] Re: aklog claims it can't contact KDC, but KDC is issuing tickets

[Ken Hornstein]

>Yeah, I suspect so as well.  It is pretty strange though that kinit
>works yet aklog doesn't.  That has me sort of confused.  If the NAT's
>UDP implementation is wonky, shouldn't I generally expect kinit to
>fail first?

You would think ... but here's a possible failure mode.  The NAT has a bug
in it where it maps UDP request/responses to the same local ephemeral port.
kinit (the first contact with the KDC) uses ephemeral port A, and the NAT
remembers that.  The request from aklog would use a different ephemeral
port number, but the NAT would map it to the ephermeral port number used by
kinit ... and aklog would never see the reply.  That is just a guess.
This is why I suggested you have the user try running "kvno".

Also, didn't you say cross-realm was involved?  It could be possible that
there is a firewall blocking access to your KDC (well, more likely blocking
the replies).

>> aklog doesn't contain internal logic to go to the level you want.
>
>Bummer.  This treads a bit close to complaining, but doesn't stuff
>like this qualify as "providing useful error reporting"?  Maybe I'm
>coddled by languages with exceptions.

You would have to talk to the Kerberos library people about that one.
FWIW, I have never been happy with the error reporting provided by the
Kerberos library.

>Unfortunately the NAT in question is at somebody's home -- I don't
>have physical access to that location, nor does anybody who is
>comfortable using these tools (in fact, I doubt that even tcpdump is
>installed on any machine at that location).

If the user in question is using MacOS X, it ships with tcpdump.  In
fact, most OSes today provide some sort of packet sniffing tools.  I have
had users run tcpdump in the past for me to diagnose problems like this;
it's generally not too bad as long as you give them an exact command line
to run.

--Ken