[2202] in Kerberos_V5_Development
Re: Win16/Win32
daemon@ATHENA.MIT.EDU (Doug Engert)
Wed Feb 5 13:59:13 1997
Date: Wed, 5 Feb 1997 12:55:40 -0600
From: Doug Engert <DEEngert@anl.gov>
To: "Richard Basch" <basch@lehman.com>
Cc: deengert@anl.gov, tytso@MIT.EDU, krbdev@MIT.EDU
In-Reply-To: <199702050311.WAA16095@badger.lehman.com>
I thing I have tracked down the krb5 219 message. It is coming from
the gethostbyname routine.
krb5.exe in the cns.c code has a blocking_hook_proc which is passed to
winsock so the application can still get messages while long running
socket calls are running.
But it appears that when it gets called, it does not have access to
its data segment which has a "static DWORD blocking_end_time" and the
test:
+110 if (GetTickCount() > blocking_end_time) {
+111 WSACancelBlockingCall();
+112 return FALSE;
+113 }
is looking at garbage, and causes the request to be canceled.
Since the test should be looking for a request taking over 30 seconds,
and there is a test for the Escape key being pressed, I have taken this
test out to get it to work.
I found this out be trying different combinations of the krb5-1.0
cns.exe and its krb5_16.dll, and the krb5-nt-alpha1 + our patches and
its krb5.exe and krb5_16.dll on a Windows 3.1 system.
The krb5.exe would always fail, if it was the first one run after
windows was started. The older cns.exe would always work, with either
dll. If the cns.exe was run, and got a ticket, the ticket destroyed,
and then the krb5.exe run, it would work. It looks like on Windows 3.1
there is some caching of the gethostbyname request, so the
gethostbyname could return the inforamtion without ever having to use
the blocking_hook_proc. If I tried another realm, the krb5.exe would
fail, nice the KDC's information was not cached.
As a test, I added a MessageBox(0,"Blocking Hook","Failed",MB_OK);
to the above test, and sure enough, it was called, but the box
only had the OK button. There was no text. This reinforces the
assumption that data segment is wrong, since the strings for the
MessageBox could not be found either.
Someone who is more familiar with the cns.c code need to look at this
closer, as it may be a problem in the WIN32, and in the krb5-1.0
release as well, it might just be lucky, that the value of
whatever the test is looking it is < GetTickTime().
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
