[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

KerberosV - how to use UDP without errors?



On Thu, Jun 24, 1999 at 02:17:10PM +0100, Matt Kern wrote:
> Hi, Brian.
> 
> > Phew! What a relief - now I don't have to do it ;-)
> 
> If I fail I'll be sure to pass everything on to you :)

Err... If I haven't already given up!

I have found this irratating problem, with kerberos V - kinit doesn't work
on a remote computer to the KDC, it only seems to work on the KDC. I
have straced and tcpdumped it and everything looks fine at the program
level, but the kernel rejects a valid(??) UDP packet for no good reason
(that I can see).

Anyone who knows UDP should be able to solve this... (I thought I did).

Well, Anyway here is the problem:

1. After typing in the password into kinit, a message is sent to the
KDC (following is from strace):

send(5, ..., 157, 0) = 157
select(6, [5], NULL, NULL, {1, 0})

I believe the client is now patiently waiting for a response.

2. The server gets message and sends the reply.

3. The client computer returns an icmp packet (as seen by tcpdump),
"port unreachable error". WHY???? Why doesn't return the same error
when connecting to localhost?

4. The server gets and displays the error when it trys to receive
the response.

5. The client times out and trys to retransmit again.

6. The server detects that the message has been replayed and issues
replayed error messages.

7. 5 and 6 repeat until I push Ctrl+X at kinit.

This is the log from KDC:
Jun 26 20:23:15 snoopy krb5kdc[9691](info): AS_REQ 192.168.87.134(88): ISSUE: authtime 930392595, bam@CHOCBIT.ORG.AU for krbtgt/CHOCBIT.ORG.AU@CHOCBIT.ORG.AU
krb5kdc: Connection refused - while receiving from network
Jun 26 20:23:16 snoopy krb5kdc[9691](info): DISPATCH: replay found and re-transmitted
krb5kdc: Connection refused - while receiving from network

This is the tcpdump:
20:26:25.814454 dewey.chocbit.org.au.1942 > snoopy.apana.org.au.kerberos: v5
20:26:25.834454 snoopy.chocbit.org.au.kerberos > dewey.chocbit.org.au.1942: v5
20:26:25.834454 dewey.chocbit.org.au > snoopy.chocbit.org.au: icmp: dewey.chocbit.org.au udp port 1942 unreachable [tos 0xc0]
20:26:26.814454 dewey.chocbit.org.au.1943 > snoopy.apana.org.au.kerberos4: v5
20:26:26.824454 snoopy.chocbit.org.au.kerberos4 > dewey.chocbit.org.au.1943: v5
20:26:26.824454 dewey.chocbit.org.au > snoopy.chocbit.org.au: icmp: dewey.chocbit.org.au udp port 1943 unreachable [tos 0xc0]
20:26:27.824454 dewey.chocbit.org.au.1942 > snoopy.apana.org.au.kerberos: v5
20:26:27.834454 snoopy.chocbit.org.au.kerberos > dewey.chocbit.org.au.1942: v5
20:26:27.834454 dewey.chocbit.org.au > snoopy.chocbit.org.au: icmp: dewey.chocbit.org.au udp port 1942 unreachable [tos 0xc0]

Arrgghh! this is driving me crazy - under what circumstances does the
linux kernel bounce UDP packets with this error?

Here is the strace of kinit that works (ie on localhost). Same code, etc

socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sin_family=AF_INET, sin_port=htons(88), sin_addr=inet_addr("202.12.87.129")}, 16) = 0
send(4, "j\201\3070\201\304\241\3\2\1\5\242"..., 202, 0) = 202
select(5, [4], NULL, NULL, {1, 0})      = 1 (in [4], left {0, 950000})
recv(4, "k\202\2h0\202\2d\240\3\2\1\5\241"..., 4096, 0) = 620
close(4)                                = 0

What is even more weird, was is the following:

client          server       works?
-------------------------------------
version4        version4     YES
version4        version5     NO!!!!
version5        version5     NO

ie the problem at the client end only started when I upgraded the
server!!!!!! I am afraid I cannot understand why??? Is the server
sending something in the packet that the client doesn't understand?

My server is Linux 2.2.6 and the client is 2.0.36.

(UDP dead on the computer??? Maybe I should try rebooting... However
DNS works fine.)

Please tell me if I have missed any important information.

> This is a well written page that manages to get across the mechanics
> without giving the reader suicidal urges.

Not true - that web page doesn't document this problem ;-).

-- 
Brian May <bam@snoopy.apana.org.au>

Attachment: pgp3hnhgaVR3k.pgp
Description: PGP signature


Reply to: