[1921] in SIPB-AFS-requests
running /usr/local/etc/elcsd on charon,rtfm,rosebud,ronald-ann
daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Thu Apr 6 05:13:10 1995
From: mhpower@MIT.EDU
To: charon-maintainers@MIT.EDU, rtfm-maintainers@MIT.EDU, sipb-afsreq@MIT.EDU
Date: Thu, 06 Apr 95 05:10:17 EDT
There's a problem with the version of /etc/elcsd in the release: it
listens for tcp connections on port 704, but if it gets one for some
reason, it goes into a loop using up lots of cpu time. To choose a
random example, it might get such a connection is if someone accessed
the machine using the satan tcp_scan program (e.g., "tcp_scan hostname
704", or if they used some range of ports that included 704).
As far as I can tell, there's no need for elcsd to listen for tcp
connections unless the LOGREM bit (from /usr/include/elcsd.h) is set
in /etc/elscd.conf. I patched elcsd so that it only listens for tcp
connections in that case. I'm not really sure what the distribution
conditions are for elcsd.c, but since it's an Ultrix program, I
figured I should put it in the athena cell and limit access to people
in system:source-access. If you have such access, you can get the
source in /mit/mhpower/src/elscd. If you know whether it's appropriate
to have this anywhere in the sipb cell, please let me know. I've
sent a patch to bugs (transaction [13407] in the meeting on menelaus).
The new binary is running from /usr/local/etc/elcsd on charon, rtfm,
rosebud and ronald-ann. Also, I modified /etc/rc on these machines to
start /usr/local/etc/elcsd rather than /etc/elscd at boot time.
If the LOGREM bit is set in /etc/elscd.conf (e.g., the number 5 on
line 6 is changed to 7), this version of elcsd will listen for tcp
connections, but won't go into the cpu-bound loop if it gets one.
Matt
