On Monday, February 21, 2005 08:20:49 AM -0500 "John W. Sopko Jr." <[EMAIL PROTECTED]> wrote:

This posting got delayed for a few days, some email issue, thought you
may not have seen it, I have run out of things to try to get
kinit to get k4 tgt's to work. That is why I was asking for the Red Hat
Source the other day to see if there may be some issue with our
source. I have tried kinit to port 750 and 88 with no luck. Probably
not related but when the kas server starts on our Red Hat linux,
it reports this in the /usr/afs/logs/AuthLog:

kerberos4/udp port=60930
kerberos5/udp port=22528

kerberos4/udp port=750
kerberos5/udp port=88

Looks like a byte-order problem. It's been a very long time (say, AFS 3.3a or so) since I've had a kaserver running on a little-endian system, but I'm pretty sure it was listening on the right ports back then. It's possible it's listening on the correct ports, but reporting the wrong ones in the log. If you run 'lsof -i -p XXX' where XXX is the kaserver's pid, it should be pretty obvious which ports it's actually listening on. Either way, you should file an appropriate bug if you've not already done so.



I cranked up debugging on the kaserver with "kill -TSTP" it shows the
following if I give it a good passwd or a bad passwd:

Fri Feb 18 10:43:22 2005 sopko,krbtgt.CS.UNC.EDU:auth from d810298

Also I get the same response as shown below from tcpdump if I
type in the good passwd or a bad passwd.

This makes it seem likely that the kaserver is indeed listening on the correct port, and you actually have some other problem. Unfortunately, your tcpdump output is fairly useless because with no switches, tcpdump shows very limited information. You should try more switches, like:


# tcpdump -s 1500 -vv port 7004 or port 750 or port 88

That will increase the packet length that tcpdump captures, and increase the verbosity of its output. You can also add -x if you want to see the raw packets.


At the moment, I'm not sure what the problem is here. It would probably help to know where your kinit came from, what version it is, etc.



-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA

_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to