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

[Marcus Watts]

Ken Hornstein <kenh@cmf.nrl.navy.mil> replied to Adam:
> >Just got some results back.  Most importantly, I got the ktrace.out
> >(MacOS equivalent of truss/strace dump) from the user.  I'm going to
> >analyze it this afternoon.  Getting a traceroute packet dump is going
> >to be more of a challenge since MacOS doesn't ship with traceroute
> >(argh!).
> 
> Do you really want a traceroute packet dump, or a tcpdump packet dump?
> In my experience, the system call tracer won't be very much help; I am
> sure all it will tell you was that it sent packets to your KDC, but it
> never saw any replies.  You already know that.

traceroute is going to be of limited value here.  traceroute
is good at telling what routers a working connection might
traverse on the outbound path.  What you want to know here is how udp packets
fail to get returned.  Traceroute (done both directions) may help you to
identify where a nat or firewall rule is that you care about, but it won't
tell you where udp packets are actually getting dropped.

ktrace will admittedly have a low signal to noise ratio.  However, it
should say which IP address kinit/aklog tried to reach
and will definitely have what files kinit/aklog read to decide
to go after those IP addresses.  Since we're talking MacOS
here, those files do have unobvious pathnames - presence of files like
	/Users/mdw/Library/Preferences/edu.mit.Kerberos
can have interesting consequences, and this stuff might change
between binaries (since they're probably built by different people.)

I think tcpdump is likely to be the most interesting thing to
start with.  That will identify which ip addresses & ports matter
which will help in going after the nat configuration.

Of course, without physical access or a knowledgeable user,
a nat problem may be difficult to solve.

					-Marcus