Skip Menu |
 

Download (untitled) / with headers
text/plain 8.3KiB
From taylor@oswego.oswego.edu Wed Dec 11 15:34:22 1996
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id PAA16363 for <bugs@RT-11.MIT.EDU>; Wed, 11 Dec 1996 15:34:22 -0500
Received: from natasha.oswego.edu by MIT.EDU with SMTP
id AA21831; Wed, 11 Dec 96 15:34:19 EST
Received: from oswego.Oswego.EDU (localhost [127.0.0.1]) by natasha.oswego.edu (8.8.4/8.7.3) with ESMTP id PAA06921 for <krb5-bugs@athena.mit.edu>; Wed, 11 Dec 1996 15:34:05 -0500 (EST)
Message-Id: <199612112034.PAA06921@natasha.oswego.edu>
Date: Wed, 11 Dec 1996 15:34:03 -0500
From: "Paul R. Taylor" <taylor@oswego.oswego.edu>
To: krb5-bugs@MIT.EDU
Subject: ASN.1 botch? appears fixed in 1.0

Show quoted text
>Number: 293
>Category: krb5-libs
>Synopsis: ASN.1 botch? appears fixed in 1.0
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: tytso
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Wed Dec 11 15:35:01 EST 1996
>Last-Modified: Mon Mar 17 13:33:41 EST 1997
>Originator:
>Organization:
>Release:
>Environment:
>Description:
All:

I have run into an unusual problem with The Beta 7 release of Kerberos
Here are the server configurations:

SETUP
---------------------------------------------------------------------
Server 1:
Sparc Server 1000
Solaris 2.5 (with patches)
Kerberos V5 Beta 7
Compiler Sun C compiler
Server 2:
Sun Ultra 1/140 Server
Solaris 2.5.1 (with Patches)
Kerberos V5 Beta 7
Sun C Compiler
Server 3:
Sun Ultra 1/140 Server
Solaris 2.5.1 (with patches)
Kerberos V5 Beta 7
Gcc 2.7.2
Client 1:
Sparc Server 1000E
Solaris 2.5 (with patches)
Client 2:
Sun Ultra 1/140 server
Solaris 2.5.1 (with patches)
client 3:
Xyplex Terminal Server

Server 2 is a secondary for the realm served by Server 1
Server 3 is a server for a second realm.

PROBLEM
---------------------------------------------------------------------

Here is the situation that I have run into:
Client 1 communicate with Server 1, 2, or 3 flawlessly
everything works normally
Client 2 also communicates with all three servers flawlessly

However Client 3 has problems talking to
server 2 or server 3, everything works normally when talking
to server 1.

whenever client 3 tries to commnicate with
server 2 or 3 the KDC on the server loggs the message

krb5kdc: ASN.1 encoding ended unexpectedly - while dispatching

at least 3 times and communication between the client and
server fail.
----------------------------------------------------------------------

What I would like to know is:

is this a known problem with Sun Ultra machines?
Is there a workaround for this problem?

Is it possible for Server 1 to be the master/Primary for
both Realm 1 and Realm 2? If so how would I go about
setting this up?

Sincerely

Paul R. Taylor

--
Paul R. Taylor Assistant Director
PHONE: (315) 341-3055 12A Snygg Hall
FAX: (315) 341-3143 Instructional Computing Center
INTERNET: taylor@Oswego.EDU SUNY Oswego, Oswego,NY 13126


Show quoted text
>How-To-Repeat:
>Fix:
>Audit-Trail:

State-Changed-From-To: open-feedback
State-Changed-By: tytso
State-Changed-When: Fri Mar 7 16:30:32 1997
State-Changed-Why: Waiting for user input


From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: "Paul R. Taylor" <taylor@oswego.oswego.edu>
Cc: krb5-bugs@MIT.EDU
Subject: Re: pending/293: Kerberos V5 Beta 7
Date: Fri, 7 Mar 1997 16:30:26 -0500

Hi there,
Sorry for not getting back to you right away; we were busy
getting the 1.0 release out, and we're only now starting to handle bug
reports filed just before the 1.0 release.

whenever client 3 tries to commnicate with
server 2 or 3 the KDC on the server loggs the message

krb5kdc: ASN.1 encoding ended unexpectedly - while dispatching

is this a known problem with Sun Ultra machines?
Is there a workaround for this problem?

In answer to your questions, no this isn't a know problem with the Sun
Ultra's. We don't have acccess to a Sun Ultra here at MIT, so it's hard
for us to track down this problem.

Here are a couple of things to try, though:

(1) Does this problem still exist in the 1.0 release?

(2) What happens if you run kinit from a Sun Ultra, talking to a Sun
Ultra KDC?

(3) Does "make check" successfully complete when building on a Sun
Ultra? If you have dejagnu, tcl, and perl, "make check" will do a
pretty exhaustive set of self-tests.

If you're able to do any of these tests, we'd really appreciate them if
you could send any results back to us. We're using the GNATS bug
tracking software, so if you can reply keeping the above subject line,
that would be helpful. Thanks!!!

- Ted


From: "Paul R. Taylor" <taylor@oswego.oswego.edu>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: pending/293: Kerberos V5 Beta 7
Date: Fri, 07 Mar 1997 23:41:41 -0500

"Theodore Y. Ts'o" said:
-> Hi there,
-> Sorry for not getting back to you right away; we were busy
-> getting the 1.0 release out, and we're only now starting to handle bug
-> reports filed just before the 1.0 release.

I can understand where you are coming from there. It would have
at least been nice to have the message acknowledged even if it
was just a one-liner saying it was recieved and you would get
to it when time permitted.

In the mean time we have found Kerberos V5 1.0 release and it does
NOT suffer from the same problem... Something fixed it between
Beta 7 and 1.0 not sure what ...

-> whenever client 3 tries to commnicate with
-> server 2 or 3 the KDC on the server loggs the message
->
-> krb5kdc: ASN.1 encoding ended unexpectedly - while dispatching
->
-> is this a known problem with Sun Ultra machines?
-> Is there a workaround for this problem?
->
-> In answer to your questions, no this isn't a know problem with the Sun
-> Ultra's. We don't have acccess to a Sun Ultra here at MIT, so it's hard
-> for us to track down this problem.

I spent a Bunch of time testing and tracking on this, and not being
intimate with the code before hand really did not help. It appeared
that the problem arose when it tried to respond to a system had to
deal with a different byte ordered packet. (if the byte ordering was
the same things worked fine but if it was different it would
end up with the previous message.

-> Here are a couple of things to try, though:
->
-> (1) Does this problem still exist in the 1.0 release?

This release fixes the problem (as we saw it).

-> (2) What happens if you run kinit from a Sun Ultra, talking to a Sun
-> Ultra KDC?

Things worked fine there, basically any sun to sun communications
worked fine. but sun to non-sun (Xyplex for sure, and I suspect
also with Digital Vaxes (did not attempt to set up our VMS
Vaxes to test this out)).

-> (3) Does "make check" successfully complete when building on a Sun
-> Ultra? If you have dejagnu, tcl, and perl, "make check" will do a
-> pretty exhaustive set of self-tests.
->
-> If you're able to do any of these tests, we'd really appreciate them if
-> you could send any results back to us. We're using the GNATS bug
-> tracking software, so if you can reply keeping the above subject line,
-> that would be helpful. Thanks!!!

Thanks for getting back to me on this problem, After not hearing
anything for a week or so I made the incorrect assumption that
the question was delivered to a 'dead' address/list/newsgroup
and then a while later (a couple of weeks I could not even find
the pointer to the newsgroup type of listing that I originally
posted to.

Paul

Paul R. Taylor Assistant Director
PHONE: (315) 341-3055 12A Snygg Hall
FAX: (315) 341-3143 Instructional Computing Center
INTERNET: taylor@Oswego.EDU SUNY Oswego, Oswego,NY 13126

Responsible-Changed-From-To: gnats-admin->tytso
Responsible-Changed-By: tlyu
Responsible-Changed-When: Mon Mar 17 13:09:27 1997
Responsible-Changed-Why:

Refiled; we may want to close this out now.

State-Changed-From-To: feedback-closed
State-Changed-By: tytso
State-Changed-When: Mon Mar 17 13:33:14 1997
State-Changed-Why: problem solved in 1.0 release.


Show quoted text
>Unformatted: