[squid-users] fake_auth exiting with signal 11

Hi!

  This is my first experiencing with writing to English-speaking
  mailing list, so, please excuse me for possible mistakes.

  I have SQUID-2.5.DEVEL (squid-head-200112130001) installed as a usual
  proxy at Freebsd 4.4-RELEASE. This proxy controls http at Windows
  2000 environment (about 20 workstations and one Windows2000-based
  domain controller). We don't need "true" authentication, we just
  want to log user activities. Squid is running in daemon mode.

  Fake_auth parameters are:

auth_param ntlm program /usr/local/squid/libexec/fakeauth_auth
auth_param ntlm children 30

  The problem is that fake_auth crashes with signal 11 PERIODICALLY,
  with this sort of diagnostics ( -X squid option):

Dec 22 12:30:59 proxy ntlmGetString: insane: l:0 o:64
Dec 22 12:30:59 proxy ntlmGetString: insane: l:0 o:64
Dec 22 12:30:59 proxy /kernel: pid 9694 (fakeauth_auth), uid 1000: exited on signal 11
Dec 22 12:30:59 proxy 2001/12/22 12:30:59| ctx: exit level 0
Dec 22 12:30:59 proxy squid[9661]: ctx: exit level 0
Dec 22 12:30:59 proxy 2001/12/22 12:30:59| ctx: exit level 20
Dec 22 12:30:59 proxy squid[9661]: storeDirWriteCleanLogs: Starting...
Dec 22 12:30:59 proxy 2001/12/22 12:30:59| WARNING: Closing open FD 73
Dec 22 12:30:59 proxy squid[9661]: WARNING: Closing open FD 73
Dec 22 12:30:59 proxy 2001/12/22 12:30:59| Finished. Wrote 9460 entries.
Dec 22 12:30:59 proxy squid[9661]: Finished. Wrote 9460 entries.
Dec 22 12:30:59 proxy 2001/12/22 12:30:59| Took 0.2 seconds (52313.2 entries/sec).
Dec 22 12:30:59 proxy squid[9661]: Took 0.2 seconds (52313.2 entries/sec).
Dec 22 12:30:59 proxy squid[9661]: authenticateNTLMHandleReply: called with no result string
Dec 22 12:30:59 proxy FATAL: authenticateNTLMHandleReply: called with no result string Squid Cache (Version 2
.5-DEVEL): Terminated abnormally.

           About suspicious periodicity of this event:

bash-2.05$ cat /var/log/messages|more|grep "signal 11"
Dec 26 10:31:04 proxy /kernel: pid 12299 (fakeauth_auth), uid 1000: exited on signal 11
Dec 26 11:17:28 proxy /kernel: pid 16391 (fakeauth_auth), uid 1000: exited on signal 11
Dec 26 11:31:02 proxy /kernel: pid 16579 (fakeauth_auth), uid 1000: exited on signal 11
Dec 26 11:31:07 proxy /kernel: pid 16682 (fakeauth_auth), uid 1000: exited on signal 11
Dec 26 12:31:02 proxy /kernel: pid 16747 (fakeauth_auth), uid 1000: exited on signal 11
Dec 26 12:31:08 proxy /kernel: pid 16978 (fakeauth_auth), uid 1000: exited on signal 11
Dec 26 12:32:17 proxy /kernel: pid 17043 (fakeauth_auth), uid 1000: exited on signal 11
Dec 26 12:32:26 proxy /kernel: pid 17116 (fakeauth_auth), uid 1000: exited on signal 11
Dec 26 12:35:33 proxy /kernel: pid 17181 (fakeauth_auth), uid 1000: exited on signal 11
Dec 26 13:31:02 proxy /kernel: pid 17255 (fakeauth_auth), uid 1000: exited on signal 11

bash-2.05$ zcat /var/log/messages.0.gz|more|grep "signal 11"
Dec 24 19:31:05 proxy /kernel: pid 7031 (fakeauth_auth), uid 1000: exited on signal 11
Dec 24 19:31:12 proxy /kernel: pid 8113 (fakeauth_auth), uid 1000: exited on signal 11
Dec 24 19:31:17 proxy /kernel: pid 8178 (fakeauth_auth), uid 1000: exited on signal 11
Dec 25 10:31:02 proxy /kernel: pid 8243 (fakeauth_auth), uid 1000: exited on signal 11
Dec 25 10:31:09 proxy /kernel: pid 11352 (fakeauth_auth), uid 1000: exited on signal 11
Dec 25 11:19:11 proxy /kernel: pid 11417 (fakeauth_auth), uid 1000: exited on signal 11
Dec 25 11:31:03 proxy /kernel: pid 11609 (fakeauth_auth), uid 1000: exited on signal 11
Dec 25 11:31:09 proxy /kernel: pid 11708 (fakeauth_auth), uid 1000: exited on signal 11
Dec 25 12:31:03 proxy /kernel: pid 11773 (fakeauth_auth), uid 1000: exited on signal 11
Dec 25 12:31:09 proxy /kernel: pid 12008 (fakeauth_auth), uid 1000: exited on signal 11
Dec 25 13:31:03 proxy /kernel: pid 12073 (fakeauth_auth), uid 1000: exited on signal 11

bash-2.05$ zcat /var/log/messages.1.gz|more|grep "signal 11"
Dec 23 19:31:06 proxy /kernel: pid 295 (fakeauth_auth), uid 1000: exited on signal 11
Dec 24 10:31:02 proxy /kernel: pid 2969 (fakeauth_auth), uid 1000: exited on signal 11
Dec 24 10:31:08 proxy /kernel: pid 6028 (fakeauth_auth), uid 1000: exited on signal 11
Dec 24 11:23:26 proxy /kernel: pid 6093 (fakeauth_auth), uid 1000: exited on signal 11
Dec 24 11:31:02 proxy /kernel: pid 6296 (fakeauth_auth), uid 1000: exited on signal 11
Dec 24 11:31:08 proxy /kernel: pid 6384 (fakeauth_auth), uid 1000: exited on signal 11
Dec 24 12:01:04 proxy /kernel: pid 6449 (fakeauth_auth), uid 1000: exited on signal 11
Dec 24 12:31:02 proxy /kernel: pid 6596 (fakeauth_auth), uid 1000: exited on signal 11
Dec 24 12:31:08 proxy /kernel: pid 6740 (fakeauth_auth), uid 1000: exited on signal 11
Dec 24 13:31:02 proxy /kernel: pid 6805 (fakeauth_auth), uid 1000: exited on signal 11

And, finally, at Sunday (only one "http-user" at work)

bash-2.05$ zcat /var/log/messages.2.gz|more|grep "signal 11"
Dec 22 12:30:59 proxy /kernel: pid 9694 (fakeauth_auth), uid 1000: exited on signal 11
Dec 22 19:31:02 proxy /kernel: pid 13648 (fakeauth_auth), uid 1000: exited on signal 11

    From one hand the tandem "squid - fake_auth" is all that we
    need now. This exeption situation is controlled by the parent process, reloading
    the child, when it terminates abnormally. From the other hand, i
    must find network event, that caused fake_auth crash. We are
    waiting the ranging of our network to the number of about one hundred
    http-clients. And i need the interpretation of that "ntlmGetString: insane: l:0 o:64"
    diagnostics. What is this "insane" packet?

    Unfortunately, i'm not familiar with the C-programming, but with
    my understanding of the "fakeauth_auth.c" there is some kind of
    stub for the situation with the packet length less or equivalent
    to zero:

    ............
    /* Sanity checks. XXX values arbitrarialy chosen */
    if (l <= 0 || l >= 32 || o >= 256) {
        fprintf(stderr, "ntlmGetString: insane: l:%d o:%d\n", l, o);
        return (NULL);
    ............

    As far as i need THIS auth module to function properly
    without any potential vulnerabilities to the network
    events, i would be very thankful to get any workaround to this
    problem...

-- 
Best regards,
 George                          mailto:squid-mailing@altervita.com.ru