Re: Announcing CUkiller

Jason Williams (
Fri, 29 Aug 1997 23:07:15 -0500 (CDT)

On Fri, 29 Aug 1997, Halvor Kise jr. wrote:
> CUKiller is a collection of some cgi-scripts that gives you a
> webinterface to terminate CU-SeeMe connections. This interface has been
> used on different reflectors (3.0b3, 4.0b4 and WP2.1). Only the last
> version for White Pine reflector 2.1 is available at the moment,
> but the others will be available soon.

At first..this sort of spooked me. I thought you were somehow simulating
killClient packets to boot people off the reflector. But this is just a
web interface to the reflector so you can boot people. I read the web
page on it and it looks like CUkiller was created out of the same basic
reason my reflector scanner was created: to monitor and control (thru
kill/deny) a reflector. My scanner takes a slightly different approach to
things. I don't want just any regular user being able to zap people from
my reflector (or any others). That's why there are only certain people
who have access to the password to do it. CUkiller uses perl to do it, I
use TCL and expect. It accomplishes pretty much the same thing, but my
reflector scanner does it on a more widespread basis. Instead of only
allowing killing to take place on one reflector, it can happen on all the
reflectors in my list.

A quote from the web page: "In a desperate attempt to save the reflector
we made a utility that could be shared by many regular users on the
reflector." ... That's a good way to do it...except that I'm leery of
letting virtually any regular having access to zap people. Granted,
CUkiller seems to also email the reflector operator each time someone is
killed, it's still way too easy for someone to say "I don't like this
guy..let's kill him off the reflector." It is very true though that the
person who runs it can't be there 24 hours a day and a lot goes on behind
the operator's back. That's why there's a need for "monitors" that can
control things. It appears CUkiller just uses the kill command on the
reflector. That's fine, but it doesn't offer a more permanent solution
for the true problem users (and I have seen some real losers that qualify
for that).
This problem relates to the next quote from the web page: "This interface
has been used on different reflectors (3.0b3, 4.0b4 and WP2.1)."
There's a lot of problems with the Cornell reflectors. One of the main
ones though is that there isn't a lot of remote configuration available
while the reflector is running. Specifically, you can't deny/allow
addresses without modifying the config file, and recycling the reflector.
That means the only thing you can do thru refmon is kill which usually
gives them the hint, but not always. For the mass majority of operators
still running any sort of Cornell version, they probably do it because
they don't know about Brian Godette's Enhanced Reflector
( It supports color video, multiple
conferences, and more importantly allows you to deny and allow IP
addresses thru refmon. It's by far a MUCH improved product over the
Cornell version and much more up to date and it's actually supported too
when Brian has the time. (And's free as well)
There's also the problem with the Cornell reflector (in 4.0b3 at least)
that you can only have ONE refmon line in the config file. This restricts
access to refmon to only one IP and I don't believe it can be an IP mask.
This means if you want others to be able to kill people from the
reflector, they have to use your script(CUkiller) to do it and the machine
CUkiller is on is the only one that can use refmon at all. It's either
that or EVERYONE with refmon can kill people on the reflector. Either
case, it's very restricting. Brian overcomes this bug in the Enhanced
Reflector by letting you use multiple refmon lines.

Basically.. the only people who can't use Brian Godette's reflector are
the ones that are currently running their reflector on an OS not supported
by Brian. If that's the case, give Brian an email and maybe you can get
the source to compile it (as is the case with the After5 reflector which
is running an old Cornell version on MkLinux on a Mac). Color is becoming
more and more popular (even though White Pine itself isn't) and I'm not
even sure White Pine 3.0 clients can connect at all to Cornell reflectors. reflector scanner
( is used by a few
reflectors to monitor and control the people which use it..all by using a
password and a simiiar (but much more bloated) cgi script. I'm always
willing to let other reflector operators use my script to maintain their
reflector. So far my scanner supports Enhanced Reflectors 1.06,
1.07b5/1.07b6, White Pine 2.0.1/2.0.3/2.0.4, White Pine 2.1, and White
Pine 3.0 reflectors. There aren't currently any plans to support Cornell
since the Enhanced Reflector is so much better and because there can only
be one refmon line in the config file. The Cornell refs just suffer too
much for low bandwidth users. Hope on a busy Cornell reflector with 20
people on it and you'll see what I mean. With no windows open, the
reflector still pumps 20-25kbps to you.

Sorry this got so long..but the CUkiller scripts are exactly what I've
been perfecting and extending on my ref scanner for about the last year so
I couldn't help but respond :)

BTW, it is nice to be able to look at the Perl code for that :) thanks :)

--    * Jason Williams -- Austin, Tx.  |     |       * University of Texas at Austin  | ___ |         * BS Computer Science             \_|_/
*************** **************|