1902 lines
79 KiB
Plaintext
1902 lines
79 KiB
Plaintext
|
||
The available patches for 2.8*mu servers are:
|
||
|
||
Tp8 = TimeStampPre8 - A protocol which disallows netsplit ops and channel
|
||
desynchs.
|
||
|
||
Bquiet - does not allow a person who is banned to speak over the channel
|
||
|
||
Silence - Cuts off flooding at local server
|
||
|
||
Anc = Anti-Nick collide - *Intentional* nick collides are impossible with
|
||
this wonderful patch.
|
||
|
||
W = Wallops - lets you send messages to other IRC ops
|
||
|
||
ban = BanInformation - Lets you see who did a ban and when, as well
|
||
|
||
sw = /stats w - lets you gather statistics on average client connects
|
||
|
||
To = TopicInformation - Lets you see who set the topic for a channel and when
|
||
|
||
S = Signon Time - Tells you when a local user signed onto IRC
|
||
|
||
Cl = Client connect - Notifies opers on your server of client connects/
|
||
disconnects (with disconnect reason)
|
||
|
||
TT = Trace Times - displays the time (in secs) since your server last heard
|
||
anything from a client/server, when you do /trace.
|
||
|
||
KL = K-line comments - Allows you to modify the lame "no ghosts allowed" default
|
||
comment to whatever you wish, or alternately, display a
|
||
file to a rejected client.
|
||
|
||
OF = Oper fail patch - displays a warning to current ops when someone fails
|
||
in entering the right oper password.
|
||
|
||
MC = Mixed case patch - useful for those pesky clone bots and hacked logins;
|
||
disallows userids which have mixed case or control chars
|
||
|
||
N = Note - allows you keep a "note" for other users, amongst other things
|
||
|
||
-----------------------------------------------------------------------------
|
||
Explanations for these patches follow.....
|
||
|
||
Help on patches written by Mandar Mirashi (mmmirash@mailhost.ecn.uoknor.edu)
|
||
Mmmm on IRC.
|
||
|
||
|
||
=============================================================================
|
||
TIMESTAMP
|
||
=============================================================================
|
||
Author: Carlo, carlo@sg.tn.tudelft.nl, Run on IRC.
|
||
Info on TS protocol:
|
||
|
||
TSpre7
|
||
|
||
------
|
||
Effects of the TS protocol:
|
||
|
||
> No mode wars possible.
|
||
When you take someones op there are three possibilities:
|
||
- You were too late (You was already de-opped on your server).
|
||
- You take it (On the *whole* net).
|
||
- You start taking it (on your server, but it is 'bounced' (ie your mode
|
||
change is cancelled); This occurs when you try to do mode change
|
||
direct after a net re-connection in a situation were you hacked op by
|
||
net-break riding.
|
||
> No desynchronisation possible.
|
||
> No unnecessary MODE msg send. You can't send 'double' mode's that don't
|
||
make sense. Servers don't send unnecessary MODE's either.
|
||
> Hacking op is from now on *only* possible by admins that hacked their
|
||
servercode, and therefor easier to prosecute. Also you can 'hack' op still
|
||
exactly like now (by riding net break) on an *opless* channel.
|
||
> The protocol is fully compatible with older servers: It is invisible
|
||
and it works with old servers like this: Every 'block' of direct connected
|
||
2.8.x.TS servers will stay synchronized, Hacking op is impossible by means
|
||
of riding a net break between two TS-servers on channels that were created
|
||
within that block. In all other cases the same happens as without TS.
|
||
|
||
Here follow technical details implemented in TSpre7:
|
||
|
||
------
|
||
|
||
Reference: 2.8.14/15.TSpre7
|
||
Full list of TS-MODE-Change protocol:
|
||
|
||
-Mode changes (originating by clients) are refused only:
|
||
1) from a client that is directly connected and has no chan ops on
|
||
the channel on its server.
|
||
2) when not being a change of the internal state of a server (Well, refused
|
||
is to strong, propagation of the mode is just unnecessary and thus not
|
||
done).
|
||
3) from someone flagged as de-opped-by-server. (flag is reset when this
|
||
person is opped again by anyone) (The server detecting this mode change
|
||
cancels the mode change, by bouncing it upstream, thus keeping the net
|
||
synchronized).
|
||
|
||
-An extra parameter is added behind MODE changes *done* by servers, sended
|
||
*to* other servers. It is a Universal Time in ascii seconds. This extra
|
||
parameter is NOT sended when it is 0 (can happen with old servers on the
|
||
net), 0 means <NONE> rather then Jan 1st 1970 :).
|
||
This parameter is the creationtime of the channel being: the universal time at
|
||
which the channel was created by a *local* client; or the non-zero received
|
||
creation time from an other server (as parameter with a mode change) that
|
||
was earlier then its own; or equal 0 when the channel was created by
|
||
a non-local client and no MODE with TS was received (yet).
|
||
|
||
-Of the channel_flags is 1 bit more used: CHFL_DEOPPED, set when de-opped
|
||
by a server (compare CHFL_CHANOP, set when channel operator). It's reset
|
||
when opped. (And starts reset on joining (creation?) of a channel, this
|
||
will be changed to 'set' on join, when all servers have TS; making detection
|
||
of op hacking by admins a bit easier).
|
||
|
||
-Timestamps (sended by TS-servers) are handled as follows:
|
||
Received TS Own TS Bounced/Propagated
|
||
equal equal propagated
|
||
later >0,earlier if ops: bounced with own TS
|
||
if no ops: propagated with own TS
|
||
(own TS is sended upstream too, to make sure
|
||
TS stays synchronized).
|
||
earlier later TS copied, propagated
|
||
none any propagated, own TS sended.
|
||
>0 none if ops: propagated, no TS sended, own TS stays 0.
|
||
if no ops: TS copied, propagated.
|
||
|
||
-A mode change +/-o nick (+/- v) from a person that is deopped by a server
|
||
results in a -/+o nick back up stream (and is not propagated) if it was
|
||
an attempt to change the internal state of the receiving server.
|
||
|
||
-kick is handled as mode -o, internal state 'not on channel' being 'already
|
||
de-opped'. Bounce includes JOIN and restoring o and v flags.
|
||
(Effect: You don't even *see* the kick on one side, on the other side
|
||
the person joins again and gets his flags back from the bouncing server).
|
||
|
||
-A received TimeStamp that claims a creation time *earlier* then that
|
||
this server dissapeared from the net results in a HACK: notice (with
|
||
time difference in seconds). Bye OPER.. (This meaning, to hack op
|
||
on an existing channel that was created 15 minutes before you disconnected
|
||
your server, you will have generated a HACK notice: Clock set back at least
|
||
900 seconds by <nick>.) (Not yet implemented, prob. in pre8).
|
||
|
||
|
||
TSpre8
|
||
|
||
|
||
From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl>
|
||
Subject: *** IMPORTANT; RFC
|
||
To: wastelanders@rush.cc.edu (New Wastelanders MailingList)
|
||
Date: Thu, 14 Apr 94 18:03:38 METDST
|
||
Mailer: Elm [revision: 66.33]
|
||
Status: RO
|
||
|
||
Hi, please read this carefully and respond if you think it will result
|
||
in INCORRECT behaviour under any circumstances:
|
||
|
||
Here follow technical details implemented in TSpre8:
|
||
|
||
------
|
||
|
||
Reference: 2.8.17.TSpre8
|
||
Full list of TS-MODE-Change protocol:
|
||
|
||
-Mode changes (originating by clients) are refused only:
|
||
1) from a client that is directly connected and has no chan ops on
|
||
the channel on its server.
|
||
2) when not being a change of the internal state of a server (Well, refused
|
||
is to strong, propagation of the mode is just unnecessary and thus not
|
||
done).
|
||
3) from someone flagged as de-opped-by-server. (flag is reset when this
|
||
person is opped again by anyone) (The server detecting this mode change
|
||
cancels the mode change, by bouncing it upstream, thus keeping the net
|
||
synchronized).
|
||
4) When a '0' as timestamp is received, originating from a server (see below).
|
||
Then the whole mode is ignored, a HACK notice is sent to all ops and the
|
||
string is propagated as received.
|
||
|
||
-An extra parameter is added behind MODE changes *done* by servers, sent
|
||
*to* other servers *containing* a +o, -o, +v or -v.
|
||
It is a Universal Time in ascii seconds.
|
||
Whenever a HACK is detected, a HACK: notice is sent to all local opers,
|
||
and the full MODE is propagated with a '0' as timestamp, generating
|
||
a HACK notice on all other servers.
|
||
Otherwise this parameter is the creationtime of the channel being: the
|
||
universal time at which the channel was created by a *local* client;
|
||
or the non-zero received creation time from an other server (as parameter
|
||
with a mode change) that was earlier then its own; or equal 0 when the
|
||
channel was created by a non-local client and no MODE with TS was received
|
||
(yet).
|
||
|
||
-Of the channel_flags is 1 bit more used: CHFL_DEOPPED, set when de-opped
|
||
by a server (compare CHFL_CHANOP, set when channel operator). It's reset
|
||
when opped. It starts *set* on joining (creation?) of a channel, making
|
||
detection of op hacking by admins a bit easier.
|
||
|
||
-Timestamps (sent by TS-servers) are handled as follows:
|
||
Received TS Own TS Bounced/Propagated
|
||
equal equal propagated
|
||
later >0,earlier if ops: bounced with own TS
|
||
if no ops: TS copied, propagated
|
||
earlier later TS copied, propagated
|
||
0 or none any HACK generated, 0 propagated, own TS is kept
|
||
>0 none TS copied, propagated.
|
||
|
||
-A mode change +/-o nick (+/- v) from a person that is deopped by a server
|
||
results in a -/+o nick back up stream (and is not propagated) if it was
|
||
an attempt to change the internal state of the receiving server.
|
||
|
||
-kick is handled as mode -o, internal state 'not on channel' being 'already
|
||
de-opped'. Bounce includes JOIN and restoring o and v flags.
|
||
(Effect: You don't even *see* the kick on one side, on the other side
|
||
the person joins again and gets his flags back from the bouncing server).
|
||
|
||
-A received TimeStamp that claims a creation time *earlier* then that
|
||
this server dissapeared from the net results in a HACK: notice (with
|
||
time difference in seconds). Bye OPER.. (This meaning, to hack op
|
||
on an existing channel that was created 15 minutes before you disconnected
|
||
your server, you will have generated a HACK notice: Clock set back at least
|
||
900 seconds by <nick>.)
|
||
|
||
|
||
|
||
|
||
From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl>
|
||
Subject: TSpre8 can work! :)
|
||
To: wastelanders@rush.cc.edu (New Wastelanders MailingList)
|
||
Date: Wed, 20 Apr 94 11:44:39 METDST
|
||
Mailer: Elm [revision: 66.33]
|
||
Status: RO
|
||
|
||
Well... it took me a few days (a night and some dreams actually), but
|
||
I think I found a solution for the problem I mentioned during the meeting :)
|
||
|
||
Let me first repeat the problem:
|
||
|
||
- I stated that TSpre8 would prevent op hacking by admins, but... later
|
||
I realized that that was impossible the way wanted it :(
|
||
My idea was at first: Simply generate a HACK notice when a server
|
||
comes on the net with a creation time earlier then when it did split off
|
||
(and earlier then my own creation time). This sounds nice, but in
|
||
even this simple case it doesn't work:
|
||
|
||
Server A and B, users a and b:
|
||
|
||
A -- B
|
||
|
|
||
@a TS=100
|
||
|
||
Split at t=200
|
||
|
||
A B
|
||
|
|
||
@a
|
||
|
||
b joins at t=300
|
||
|
||
A(TS=100) B(TS=300)
|
||
| |
|
||
@a @b
|
||
|
||
Net joins:
|
||
|
||
A -- B
|
||
| |
|
||
a b
|
||
|
||
Both are de-opped: b because he sends a TS of 300 with is greater (later)
|
||
then 100 (correctly: he used the netbreak). And a is deopped with a
|
||
HACK notice by B, because he introduces 1) a TS earlier then the existing
|
||
TS (100<300) and 2) the 100 is earlier then the time the split occured.
|
||
|
||
The reason why this goes wrong is simply because B *forgets* the channel
|
||
AND the TS of 100, after the split... If B would *keep* in memory that
|
||
the channel existed on A and with what TS, it would be possible, but only
|
||
at cost of a lot of extra memory usage...
|
||
|
||
Now my new idea :) It allows hacking, but only in not so very interesting
|
||
cases... And at least it makes it extremely difficult for a newbee, so we
|
||
might at least catch 99% before they understand how it works :)
|
||
|
||
(This explanation should not be on a public ftp site anymore after a while :)
|
||
|
||
New rules:
|
||
|
||
- Servers that are OFF the net for more then one day are forgotten.
|
||
- New servers (or forgotten servers), are always bounced except on channels
|
||
that have no ops (when they create a channel of their own thus :) unless
|
||
the receiving server is younger then one day and the introduced TS is
|
||
earlier then the start up time (minus 10 minutes :/) of the receiving server.
|
||
'Birthdays' of those servers are also kept.
|
||
- A server that splitted off while a channel already existed, and thus
|
||
has a creation time earlier then the "received squit time" of that
|
||
server, is not allowed to introduce an earlier timestamp then the
|
||
creationtime of the channel (HACK), and also not an equal TS when
|
||
younger then one day.
|
||
- A server introducing a server with an earlier "time of received squit"
|
||
inherrits that time as its own "time of received squit".
|
||
|
||
This allows to hack op on a channel that didn't exist when you splitted
|
||
(not interesting). You also can't keep a server off the net till you need
|
||
it (a telnet connection), because those can't do anything for one day long,
|
||
unless they send the TS *equal* to the existing TS (The only exception :(),
|
||
having to connect between two and one days before the hack, break between
|
||
zero and one day before the hack but before the channel existed, connect
|
||
and hack with equal TS.
|
||
|
||
What do you think? Just for fun? :)
|
||
|
||
Apart from that it would be suspicious when someone connects/breaks every
|
||
24 hours a "test" server, channels that exist longer then one day are
|
||
unhackable.
|
||
|
||
The "disadvantages" are: servers that break off the net for *longer* then
|
||
one day, but keep a channel up with an op, on *both sides of the net, will
|
||
be completely de-opped after reconnection.
|
||
|
||
*** IMPORTANT:
|
||
|
||
I am absolutely not sure ;) if there aren't any other disadvantages or
|
||
unwanted effects :) Please, think this over and mail me if you find some
|
||
objection...
|
||
|
||
Run
|
||
|
||
|
||
|
||
|
||
From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl>
|
||
Subject: 2.8.19.U3 RELEASED
|
||
To: wastelanders@rush.cc.edu (New Wastelanders MailingList)
|
||
Date: Sun, 22 May 94 14:15:41 METDST
|
||
Cc: carlo@sg.tn.tudelft.nl
|
||
Mailer: Elm [revision: 66.33]
|
||
Status: RO
|
||
|
||
Hi all :)
|
||
|
||
Proud to present: 2.8.19.U3 :)
|
||
|
||
I have spend *enormous* amounts of time in TESTING this version,
|
||
and I really hope it is completely bug free, but the changes are
|
||
very big, so maybe persons who only want to upgrade/compile ONCE
|
||
should wait a little longer then the compile cracks we have here ;)
|
||
|
||
For real testing we need the HUBs though! So please, don't hesitate,
|
||
Delft (a HUB) is running it already for a long time, also linked to
|
||
other 2.8.19.U3 test servers.
|
||
|
||
Before I'll tell about whats new in U3, I want to especially thank
|
||
President for the tremendous help in testing TSpre8 -- I would never
|
||
have been able bring up the stength to go through the difficult
|
||
periods without him being there to listen to my technical complaints ;)
|
||
|
||
=======================================================================
|
||
|
||
NEW in .U3
|
||
----------
|
||
|
||
First all, TSpre8.
|
||
|
||
It did not become what I hoped/expected to be possible :(
|
||
Hacking will still be possible, but at least it will be a LOT
|
||
more difficult when you don't know what you are doing, and I think
|
||
we WILL catch (new) admins that think they can abuse their powers
|
||
to be GOD on "their" channel.
|
||
|
||
Especially, nobody will be able to hack *anything* with a normal nick.
|
||
And because server modes are more obvious a hack, this alone is a
|
||
step forward against admin hacking prevention imho.
|
||
|
||
The .patch file is
|
||
-rw------- 1 carlo users 65142 May 22 01:29 irc2.8.19-TSpre8.patch
|
||
big.
|
||
|
||
I'll now brows through it and mentions changes in the order they appear
|
||
in the .patch file, arbitrary order thus ;)
|
||
|
||
Zombies
|
||
-------
|
||
|
||
As mentioned before on 'wastelanders', I changed the internal way a KICK
|
||
is handled, to be able to stop illegal -hacked- kicks from *outside* the
|
||
channel. This has no effect on server-server protocol nor on server-client
|
||
protocol. But because this way it is possible to keep (a little) memory
|
||
for channels you're not on (being kicked from) I thought it would be no
|
||
more then logical to stop people from joining the usual 10 ten channels
|
||
at the same time, *including* the ones you are kicked from (because they
|
||
occupy memory). This memory is released when you 1) Try to rejoin (so with
|
||
all people having a auto-rejoin-on kick NOTHING changed at all), or 2)
|
||
when you do a part - this is new and only intended to use when you do
|
||
NOT have auto-rejoin, when you do not even WANT to rejoin, or try, assuming
|
||
you might not be banned, when you have been kicked like this of a lot of
|
||
channels and all together are "on" 10 channels so you NEED to leave one
|
||
before you can join another... For this rare case, you must know on
|
||
*which* channels you "are", therefor this is visible when you do a
|
||
/names, or /who or /whois to yourself. It is never visible for others.
|
||
Example:
|
||
|
||
12:07 * Run (Daryl@sg.tn.tudelft.nl) has joined channel #wasteland
|
||
*** Mode change "+o Run" on channel #wasteland by Wasted
|
||
*** #wasteland : created Fri May 13 17:08:34 1994
|
||
<Macro> Hi Run !
|
||
*** You have been kicked off channel #wasteland by Run (Test)
|
||
*** Run is Daryl@sg.tn.tudelft.nl (/msg Run profile)
|
||
*** on channels: !#wasteland
|
||
*** on irc via server Delft.NL.EU.undernet.org (Runaway Server
|
||
+[130.161.188.188])
|
||
*** Run is away: Writting E-mail
|
||
*** Run is an IRC Operator
|
||
*** Run has been idle for 642 seconds.
|
||
|
||
As you can see, the channel is marked with a '!' to show you are NOT
|
||
not that channel... Both, a part #wasteland as well as a join (being
|
||
not able to actually join because of ban, invite-only, key or limit), will
|
||
remove you from this channel. The part will be sent back to (only) you, and
|
||
everything has turned out to be 100% compatible with ircii protocol.
|
||
Finally, of course the channel is removed when everyone is kicked and/or
|
||
left the channel (a channel with only zombies is removed immedeately).
|
||
|
||
#define RPL_CREATIONTIME 329
|
||
--------------------------------
|
||
|
||
A new numeric is sent when you ask for a MODE of a channel, by doing
|
||
/MODE #channel
|
||
without parameters.
|
||
The reply is the same as before, but followed by a new numeric 329:
|
||
|
||
/MODE #wasteland
|
||
Delft.NL.EU.undernet.org 324 Run #wasteland +t
|
||
Delft.NL.EU.undernet.org 329 Run #wasteland 768845314
|
||
|
||
To supress this, you'll have to add something like:
|
||
ON ^329 *
|
||
to your .ircrc file. If you want to see this new numeric, you would
|
||
add
|
||
On ^329 "*" echo *** $1 : created $stime($2)
|
||
|
||
It turns out that ircii clients ask for this mode when you join a
|
||
channel, therefor you will see the creationtime when you join a channel,
|
||
I'll leave it as an exercise to suppress this, but still being able to
|
||
see it when you specifically ask for it :)
|
||
|
||
New ircd.conf line
|
||
------------------
|
||
|
||
This is IMPORTANT :
|
||
In order for Uworld to work you MUST add those lines to your ircd.conf file:
|
||
|
||
U:Uworld.undernet.org::*
|
||
U:Underworld.nl::*
|
||
|
||
The later to allow the backup Underworld.nl to still function.
|
||
If you forget this, or do it wrong, your server might refuse to accept
|
||
certain mode changes from Uworld.undernet.org and start *bouncing*
|
||
modes done by lusers that got op from it. The name of servers allowed
|
||
to hack have to be agreed upon totally, by all admins. If one admin
|
||
removes his U: line, the service will not work always correctly.
|
||
|
||
When a server does a mode change that is detected to be a hack, you
|
||
will see -as an oper, or +s luser- this notice:
|
||
|
||
-> *uworld* opcom MODE #wasteland +o Mmmm
|
||
!Uworld.undernet.org! Run is using Uworld to : MODE #wasteland +o Mmmm
|
||
*** Notice -- HACK: Uworld.undernet.org MODE #wasteland +o Mmmm
|
||
*** Mode change "+o Mmmm" on channel #wasteland by Uworld.undernet.org
|
||
|
||
Normally, this HACK notice would NOT take effect! You still *see* the
|
||
HACK notice for the U: line server(s) but then they DO take effect.
|
||
|
||
Every other message (some including the word HACK) do also take effect,
|
||
and are only a warning that someone is MAYBE hacking...
|
||
I didn't see it occur yet.
|
||
|
||
Removed bugs
|
||
------------
|
||
|
||
I did find some bugs in TSpre7, never thought that was possible :)
|
||
I forgot what it exactly was, but under (very rare) circumstances it
|
||
could be pretty serious :/
|
||
|
||
One rather important thing is that now the TimeStamp is sent during a
|
||
net re.join when there are no ops. Before it was possible to create
|
||
a partly TimeStamp less net on an opless channel. TSpre8 garantees
|
||
that the TS is synchronized on the whole net at any time.
|
||
|
||
Other messages
|
||
--------------
|
||
|
||
Apart from the (true) HACK notice, you can get a:
|
||
|
||
BOUNCE or HACK: notice, which does take effect and is most probably
|
||
just a bounce of a mode done by an attacker: someone immedeately after
|
||
a net re.join with his net.ride ops trying to de-op the others.
|
||
I don't think this will happen often because it will be clear to all lusers
|
||
that it is useless to try.
|
||
|
||
NET.RIDE on opless #channel notice, you'll see this if someone does
|
||
really abuses a net break to get ops on some opless channel. The mode
|
||
does take effect however.
|
||
|
||
FULL bounce of modes
|
||
--------------------
|
||
|
||
When before someone would ride a net break, and try something, ONLY
|
||
his +/- o/v modes. Other modes like +mlk 1 \\|/\|/ would still take
|
||
effect. With TSpre8 this changed... All modes (except bans) are bounced
|
||
when someone rides a net break. Also the bouncing is more compact, while
|
||
with TSpre7 every o and v mode took one line, now all modes are kept into
|
||
one line.
|
||
|
||
More allowed
|
||
------------
|
||
|
||
Before you was (how lame) not allowed to mix things like k, o and v...
|
||
Now you are allowed, why not? Also you can use up to six parameters,
|
||
really gives you a power kick ;)
|
||
|
||
*** Mode change "+vvvvvv flux epa Skip Run Mmmm gyn" on channel #wasteland by
|
||
+Run
|
||
|
||
User friendly mask fixing
|
||
-------------------------
|
||
|
||
The lame way Avalon fixes a mask (for a ban) is like this:
|
||
|
||
/mode * +bb *.tudelft.nl Daryl@sg*.tn.tudelft.nl
|
||
|
||
becomes:
|
||
|
||
*** Mode change "+bb *.tudelft!*@* Daryl!*@sg*.tn.tudelft.nl" on channel
|
||
+#wasteland by Run
|
||
|
||
The same on a TSpre8 server gives:
|
||
|
||
*** Mode change "+b *!*@*.tudelft.nl" on channel #wasteland by Run
|
||
|
||
While just Daryl@sg*.tn.tudelft.nl results in:
|
||
|
||
*** Mode change "+b *!Daryl@sg*.tn.tudelft.nl" on channel #wasteland by Run
|
||
|
||
which what one would expect!
|
||
|
||
|
||
----------------------------------------------------------------
|
||
|
||
Goodluck with compiling,
|
||
|
||
Run
|
||
|
||
PS If you encounter any problems, realize it is VERY unlikely that
|
||
it is .U3, but if you really think so, then first try to compile
|
||
plain 2.8.19. If you succeed, save the Makefile the include/config.h
|
||
and the include/setup.h. Unpack .U3, replace those files and recompile.
|
||
With this I assume you don't put your ircd.conf inside the source
|
||
directories of course, that would still have the paths set wrong then.
|
||
|
||
A smart move is to make patch file once for your Makefile/config.h :
|
||
First ONLY edit the Makefile and config.h (or copy the them from a
|
||
working source tree to a empty directory), and then make a diff with:
|
||
diff -rc irc2.8.19.clean irc2.8.19.my.makefile > Makefile.config.h.patch
|
||
|
||
That really speeds up upgrading with later versions.
|
||
(irc2.8.19.my.makefile only needs to contain
|
||
irc2.8.19.my.makefile/Makefile
|
||
irc2.8.19.my.makefile/include/config.h )
|
||
Of course, keep the include/setup.h seperately.
|
||
|
||
### KILL for Mmm. Mmmm (stop it lamer (unnecessary flooding of alexbot))
|
||
|
||
|
||
=============================================================================
|
||
BQUIET
|
||
=============================================================================
|
||
Author: Carlo, carlo@sg.tn.tudelft.nl, Run on IRC.
|
||
Helpful ideas by: Aaron, agifford@sci.dixie.edu, Karll on IRC
|
||
|
||
|
||
In order to fight flooding, and as discussed on wastelanders, banning
|
||
someone on a channel will now also stop him from doing anything visible
|
||
on the channel. This allows to let someone see what you think of him
|
||
without even kicking him, he will leave by himself.
|
||
He will still be able to appologise by private msgs of course and then
|
||
he can be de-banned. A ban is this way a short cut for +m+vvvv everyone
|
||
excpet the flooder. Note that even NICK floods are stopped: When you are
|
||
on a channel where you are banned, you are not allowed to change your nick.
|
||
|
||
=============================================================================
|
||
SILENCE
|
||
=============================================================================
|
||
Author: Carlo, carlo@sg.tn.tudelft.nl, Run on IRC.
|
||
Helpful ideas by: Aaron, agifford@sci.dixie.edu, Karll on IRC
|
||
|
||
My solution to flooders with clone bots etc :)
|
||
Let the user that GETS flooded decide he doesn't want that and stop
|
||
the flooder right at his own server (the server of the flooder).
|
||
This is a new command, and the clients will need unfortunately a few
|
||
lines in their .ircrc before it can work.
|
||
Moreover, before this works, ALL servers must have .U3.
|
||
|
||
The lines I use at the moment are:
|
||
|
||
ALIAS SILENCE QUOTE SILENCE
|
||
ALIAS SILE QUOTE SILENCE
|
||
ON ^RAW_IRC "% SILENCE %" echo *** $*
|
||
|
||
It turns out that some auto-rejoin on kick lines, like Davemans toolbox,
|
||
disables the use of ON RAW_IRC, or at least makes it work incorrectly.
|
||
You should disable this auto-rejoin line and you could add the one I use
|
||
instead:
|
||
|
||
ON ^RAW_IRC "% KICK % % *" {
|
||
IF ([$3]==[$N]) {
|
||
//QUOTE JOIN $2
|
||
ECHO $MID(11 5 $STIME($TIME())) * You have been kicked off channel $2 by $LEFT($INDEX(! $0) $0) \($MID(1 256 $4-)\) } {
|
||
ECHO $MID(11 5 $STIME($TIME())) * $3 has been kicked off channel $2 by $LEFT($INDEX(! $0) $0) \($MID(1 256 $4-)\) }
|
||
}
|
||
|
||
which are 6 lines, not 8.
|
||
|
||
The way the silence patch works is as follows:
|
||
|
||
When you add a silence mask (using the same user friendly mask fixing)
|
||
like:
|
||
|
||
/SILENCE Tsunami*@
|
||
|
||
It will echo back to you how it is added:
|
||
|
||
*** Run!Daryl@sg.tn.tudelft.nl SILENCE +*!Tsunami*@*
|
||
|
||
Note that there is a '+' infront of the mask now.
|
||
You can also type:
|
||
|
||
/SILENCE +bot*
|
||
|
||
*** Run!Daryl@sg.tn.tudelft.nl SILENCE +bot*!*@*
|
||
|
||
If you want to silence one particular nick, you must add the '+', because
|
||
when you do:
|
||
|
||
/SILENCE nick
|
||
|
||
and 'nick' exists, you will get the silence list of nick. Just using
|
||
/SILENCE gives your own silence list:
|
||
|
||
*** Run bot*!*@*
|
||
*** Run *!Tsunami*@*
|
||
*** End of Silence List
|
||
|
||
However, check the silence list of someone ELSE make only really sense
|
||
when you already did sent a message to this person. Because a silence
|
||
mask only propagates to the server of the flooder when it is actually
|
||
necessary. For instance: You can add up to 5 silence masks and delete them
|
||
again and it will only be local to your own server. Only when someone
|
||
would message you, matching a mask, the mask propagates to the server of
|
||
the flooder. And stays there till you signoff, or till you delete it.
|
||
If you delete a mask, it follows the same path as the +masks...
|
||
|
||
As a result of this, +s lusers and opers will see the message:
|
||
|
||
*** SILENCE : Unknown command (from Lausanne.CH.EU.UnderNet.org)
|
||
|
||
When someone from *behind* a non .U3 server sends you a message
|
||
(Lausanne is this case). So, you will STILL be flooded ;) UNTIL ALL
|
||
servers are upgraded... (Or must do -s, but at least the net is flooded).
|
||
|
||
|
||
To: wastelanders@rush.cc.edu
|
||
From: agifford@sci.dixie.edu (Aaron Gifford)
|
||
Subject: HELP with HELP for SILENCE
|
||
Status: RO
|
||
|
||
Hey, here's a VERY VERY VERY rough draft of a HELP entry for SILENCE,
|
||
assuming it becomes a new command for ircII and not a replacement for
|
||
IGNORE either via new code, or aliases like:
|
||
ALIAS SILENCE { QUOTE SILENCE $* }
|
||
|
||
Anyway, PLEASE PLEASE PLEASE alter, modify, correct, add, hack-up, etc this
|
||
rough draft and send me your alterations. I just typed this up VERY
|
||
quickly because StGeorge is now running irc2.8.19.U3.1. The bug I mention
|
||
in the file will hopefully disappear very soon, so that text will have to
|
||
do likewise and vanish. :)
|
||
|
||
Here it is, draft #1 HELP for SILENCE:
|
||
|
||
Usage: SILENCE [<nick>]
|
||
SILENCE [+|-<pattern>]
|
||
|
||
SILENCE allows you to TOTALLY ignore all private messages (PRIVMSG's)
|
||
and notices (NOTICE's) from any user whose nick!user@host matches
|
||
the <pattern> parameter. The characters * and ? can be used
|
||
as wildcards in the pattern.
|
||
|
||
If you wanted to ignore all users from "somewhere.com" you would use:
|
||
SILENCE +*!*@somewhere.com
|
||
|
||
To ignore some with the nickname "Jerk" you would use:
|
||
SILENCE +Jerk
|
||
NOTE: The server will complete the pattern, storing it as "Jerk!*@*"
|
||
|
||
The only drawback of just SILENCE'ing someone by nickname only is
|
||
that the user could quickly change nicknames to avoid your pattern.
|
||
|
||
To remove a pattern, use a - before the pattern you want to remove.
|
||
When the command is used without any parameters, the server will list
|
||
all stored patterns you are currently ignoring with the SILENCE
|
||
command.
|
||
|
||
When used in the first form listed, you will see the SILENCE list for
|
||
the specified user. This list is not necessarily complete nor accurate
|
||
because of how servers share SILENCE information internally. You can
|
||
check to see if someone is ignoring you with SILENCE by first sending
|
||
that user a private message, then using the command to see the user's
|
||
SILENCE list.
|
||
|
||
Currently there is a bug in the servers (hopefully to be fixed soon)
|
||
that will add the nickname you specify to your SILENCE list when you
|
||
attempt to see that user's SILENCE list if that user is not currently
|
||
online.
|
||
|
||
Because SILENCE is a part of the IRC server protocol (on the Undernet)
|
||
it works much more efficiently than IGNORE, but is limited to a very
|
||
brief list of patterns. Also, you don't have as may options as you
|
||
do with IGNORE. If a user is flooding you, SILENCE is many times
|
||
more efficient than IGNORE because the offending user's PRIMSG's or
|
||
NOTICE's (including CTCP) are stopped at the server and never even
|
||
sent to your client.
|
||
|
||
See Also:
|
||
IGNORE
|
||
|
||
|
||
|
||
|
||
From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl>
|
||
Subject: Re: HELP with HELP for SILENCE
|
||
To: agifford@sci.dixie.edu (Aaron Gifford) (Aaron Gifford)
|
||
Date: Wed, 25 May 94 12:29:37 METDST
|
||
Cc: wastelanders@rush.cc.edu (New Wastelanders MailingList)
|
||
In-Reply-To: <9405250313.AA18446@sci.dixie.edu>; from "Aaron Gifford" at May 24, 94 9:20 pm
|
||
Mailer: Elm [revision: 66.33]
|
||
Status: RO
|
||
|
||
> Here it is, draft #1 HELP for SILENCE:
|
||
>
|
||
> Usage: SILENCE [<nick>]
|
||
> SILENCE [+|-<pattern>]
|
||
>
|
||
|
||
As it is now (I do not consider what you mentioned as a bug, I was aware
|
||
of this effect and didn't choose to alter it), it really is:
|
||
|
||
Usage: SILENCE [+|-]<pattern>
|
||
Or : SILENCE <nick>
|
||
|
||
When you leave the '+|-' away A '+' is assumed.
|
||
|
||
The second possibility allows you to check your own silence lists, or
|
||
allows to check if you are silenced by someone after you did message
|
||
him but didn't get a respond (did ping him for instance).
|
||
Indeed, this could be interpreted as a pattern, when <nick> doesn't
|
||
exists.
|
||
|
||
> If you wanted to ignore all users from "somewhere.com" you would use:
|
||
> SILENCE +*!*@somewhere.com
|
||
|
||
SILENCE somewhere.com
|
||
|
||
would do.
|
||
|
||
> When used in the first form listed, you will see the SILENCE list for
|
||
> the specified user. This list is not necessarily complete nor accurate
|
||
> because of how servers share SILENCE information internally. You can
|
||
> check to see if someone is ignoring you with SILENCE by first sending
|
||
> that user a private message, then using the command to see the user's
|
||
> SILENCE list.
|
||
|
||
Mention that a EVAL CTCP <nick> PING $TIME() is better...
|
||
It would not be necessary to do the silence if the ping returns...
|
||
To determine between huge lag and silence, you have to do the silence
|
||
check after that.
|
||
If you add something like this in the manual, people will automatically
|
||
wait a while after the 'message' (ping), so that the servers have time
|
||
to send the silence mask back. Otherwise they might think they can do
|
||
a quick msg+silence at the same time. Nah... Not too important, unless
|
||
with huge lag + silence combination.
|
||
|
||
>
|
||
> Currently there is a bug in the servers (hopefully to be fixed soon)
|
||
> that will add the nickname you specify to your SILENCE list when you
|
||
> attempt to see that user's SILENCE list if that user is not currently
|
||
> online.
|
||
|
||
I didn't consider this as too bad...
|
||
But if people want it, I can change it so that you MUST add a '+' to
|
||
add a mask that doesn't contain a '.', '!' or '@'.
|
||
That would lead to 2.8.19.U3.2 and a very tiny patch for the people who
|
||
already compiled .U3
|
||
|
||
Run
|
||
|
||
|
||
=============================================================================
|
||
U3 - required additions to .ircrc
|
||
=============================================================================
|
||
|
||
|
||
From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl>
|
||
Subject: Re: .ircrc codes for the new patches :)
|
||
To: lamberdc@dad.cs.tuns.ca
|
||
Date: Mon, 23 May 94 11:41:31 METDST
|
||
Cc: wastelanders@rush.cc.edu (New Wastelanders MailingList)
|
||
In-Reply-To: <9405222118.AA02415@dad.cs.tuns.ca>; from "Donald "WHIZZARD" Lambert" at May 22, 94 6:18 pm
|
||
Mailer: Elm [revision: 66.33]
|
||
Status: RO
|
||
|
||
> hiya All
|
||
> I was wondering if some one could send me a copy of the script/
|
||
> for the new patches including the ban , topic and client connecting patches.
|
||
>
|
||
> And whatever is now out with the new .19 code :)
|
||
>
|
||
> thanks
|
||
>
|
||
> -- Donnie
|
||
>
|
||
> aka WHIZZARD
|
||
|
||
The ftp.undernet.org:/pub/undernet/servers/Patches/README file:
|
||
|
||
These are lines you need to add to your .ircrc file in order
|
||
to use all posibilities .U3 profides you:
|
||
|
||
To see when a channel was created:
|
||
|
||
On ^329 * echo *** $1 : created $stime($2)
|
||
|
||
When your server has the .ban patch use this to see who did a ban and when:
|
||
|
||
On ^367 * if ([$4] != []) {echo *** $1 \($3 - $stime($4)) $2} {echo *** $1-}
|
||
|
||
---------------------------
|
||
When ALL servers upgraded to .U3, you can use this command:
|
||
|
||
ALIAS SILENCE QUOTE SILENCE
|
||
On ^RAW_IRC "% SILENCE %" echo *** $*
|
||
|
||
Use this as:
|
||
/SILENCE +mask
|
||
|
||
To add 'mask' to your silence list (will completely stop all private
|
||
messages from people matching 'mask' with their nick!user@host).
|
||
You can VIEW your silence list by typing:
|
||
/SILENCE
|
||
|
||
If you message someone and he doesn't react (like with ping), then you
|
||
can check if you match a silence mask he added by viewing his silence list
|
||
with:
|
||
/SILENCE nick
|
||
|
||
A mask can be deleted by using the command:
|
||
/SILENCE -mask
|
||
|
||
When the some messages you from behind a NON-.U3 server you will not
|
||
receive his message but the line:
|
||
*** Unknown command (SILENCE) (From server.name.undernet.org)
|
||
instead, so you will still be flooded.
|
||
We hope all servers will be upgraded within a few months.
|
||
|
||
------
|
||
And my ircd.motd from Delft* :
|
||
|
||
*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%
|
||
N E W : - This server now runs the official released
|
||
beta version 2.8.19.U3.1.ban
|
||
For you as users this means that:
|
||
-More security : .U3 contains the .TSpre8 patch with
|
||
disallows even ADMINs of servers to hack op on your
|
||
channel with a nick, most server modes are detected.
|
||
-The possibility to see the *creationtime* of a channel
|
||
(used with the TimeStamp (TS) protocol - unique on
|
||
undernet (disables the possibility of 'net.riding'))
|
||
-The possibility to stop EVERY kind of channel flooding
|
||
by *banning* someone : Now a ban stops not only
|
||
part/join floods, but also message floods and even
|
||
nick floods!
|
||
-The possibility to see who did when a certain ban.
|
||
-The possibility to stop anyone flooding you with
|
||
any kind of private messages at his *own* server!
|
||
(This will only work when ALL servers have upgraded)
|
||
To be able to use all of this, ftp to sg.tn.tudelft.nl
|
||
login: ftp ; password : anything ; file: /pub/README
|
||
Put those lines in your .ircrc initialisation file !
|
||
Have fun, Run.
|
||
|
||
----
|
||
|
||
Run
|
||
|
||
=============================================================================
|
||
U3.1 -> U3.2
|
||
=============================================================================
|
||
|
||
|
||
From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl>
|
||
Subject: *BUG* .U3.1 found !!
|
||
To: wastelanders@rush.cc.edu (New Wastelanders MailingList)
|
||
Date: Wed, 25 May 94 16:45:39 METDST
|
||
In-Reply-To: <457.9405250732@ccws-09.brunel.ac.uk>; from "James T Lowe" at May 25, 94 8:32 am
|
||
Mailer: Elm [revision: 66.33]
|
||
Status: RO
|
||
|
||
> :->
|
||
> :-> Hiya..
|
||
> :->
|
||
> :-> Here's what I observed tonight:
|
||
> :->
|
||
> :-> *** Mmmm (mandar@roosevelt.ecn.uoknor.edu) has joined channel #friendly
|
||
> :-> *** Users on #friendly: @Mmmm
|
||
> :-> *** Mode change "-o Mmmm" on channel #friendly by Uxbridge.*
|
||
>
|
||
> Not surprising :
|
||
>
|
||
> #friendly RedRum H* cs93jtl@ccws-09.brunel.ac.uk
|
||
> #friendly Emmy H lamphear@cheshire.oxy.edu
|
||
> #friendly ChemBot H@ cmrobert@hellcat.ecn.uoknor.edu
|
||
>
|
||
>
|
||
>
|
||
> >From Norman :
|
||
>
|
||
> *** ChemBot is cmrobert@hellcat.ecn.uoknor.edu (Charles Michael Roberts)
|
||
> *** on channels: @#ChatZone
|
||
> *** on irc via server Norman.OK.US.undernet.org
|
||
> *** ChemBot has been idle 10 minutes
|
||
>
|
||
>
|
||
> and from Uxbridge :
|
||
>
|
||
> ** ChemBot is cmrobert@hellcat.ecn.uoknor.edu (Charles Michael Roberts)
|
||
> *** on channels: @#chatZone @#friendly
|
||
> *** on irc via server Norman.OK.US.undernet.org
|
||
>
|
||
> :-> But,
|
||
> :->
|
||
> :-> *** Mmmm has left channel #friendly
|
||
> :-> *** Mmmm (mandar@roosevelt.ecn.uoknor.edu) has joined channel #test
|
||
> :-> *** Users on #test: @Mmmm
|
||
> :->
|
||
> :-> works fine..
|
||
> :->
|
||
> :-> Is this due to the U lines? Uworld was in no way involved though :-(
|
||
> :->
|
||
> :-> I personally feel that uxbridge's retaining timestamps of old channels -
|
||
> :-> Run, can ya take a look asap. It can prove most distressing for our users :(
|
||
> :->
|
||
> :-> Thanks!!
|
||
> :->
|
||
> :-> Mmmm
|
||
>
|
||
>
|
||
|
||
Weeehhhw, yeah a real bug :/
|
||
|
||
RedRum and I looked for it for almost 4 hours before it was found...
|
||
|
||
I will release .U3.2 and a patch for .U3.1-U3.2 asap...
|
||
|
||
Description of bug:
|
||
|
||
When someone gets kicked (and doesn't (try to) rejoin), it is flagged
|
||
as a zombie. After a net-break, users are mutual re-joined on both
|
||
sides of the net. It turned out that a zombie is also rejoined after
|
||
a net rejoin.
|
||
|
||
What happened with ChemBot:
|
||
|
||
ChemBot was on #friendly via Norman (non TSpre8). It was banned and then
|
||
kicked. It tried to rejoin, but Norman didn't allow that (ban).
|
||
Delft never saw this try, and ChemBot stayed as a zombie on #friendly.
|
||
Then Delft-UxBridge broke and reconnected... Delft did send a JOIN for
|
||
ChemBot to UxBridge, ending up in a nick-desynced state.
|
||
When Mmmm joined #friendly, he was the first on #friendly on all of the
|
||
net except UxBridge... He was opped by Norman, but that is considered
|
||
as a HACK by UxBridge and was bounced (ChemBot was still there *with*
|
||
ops (those flags aren't reset when someone is marked zombie)).
|
||
The second time Mmmm joined, he again got ops from Norman which now
|
||
was accepted by UxBridge because this +o could be a BOUNCE of the de-op
|
||
by UxBridge (Generating a BOUNCE or HACK: notice on UxBridge).
|
||
|
||
Run
|
||
|
||
|
||
|
||
From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl>
|
||
Subject: Release 2.8.19.U3.2
|
||
To: wastelanders@rush.cc.edu (New Wastelanders MailingList)
|
||
Date: Wed, 25 May 94 23:30:57 METDST
|
||
Mailer: Elm [revision: 66.33]
|
||
Status: RO
|
||
|
||
Hi all,
|
||
|
||
I released 2.8.19.U3.2
|
||
|
||
Fixed:
|
||
|
||
- Rejoining of zombies after net break :/ (ChemBot case)
|
||
- Silence command now give: No such nick, when doing /silence nick
|
||
- I fixed the way a kick is handle, because in a last minute
|
||
thought I realized MURC would get trouble otherwise, see below.
|
||
|
||
As usual you can get it from ftp.undernet.org:/pub/undernet/servers
|
||
|
||
Patches/irc2.8.19.U3.1-2.patch : If you already had .U3.1
|
||
|
||
irc2.8.19.U3.2.tar.gz : If start from scratch (DO SO!!!)
|
||
|
||
For those who use the irc2.8.19.U3.1-2.patch ...
|
||
|
||
------------------------------------------
|
||
*** EDIT include/patchlevel.h !!!!!!!! ***
|
||
------------------------------------------
|
||
|
||
This patch will change your version to irc2.8.19.U3.2 so if you run
|
||
.ban EDIT it !!!
|
||
|
||
=========================================================================
|
||
|
||
The change in KICK handling is as follows:
|
||
|
||
- A kick received from a local client, or for a local client or
|
||
from a direction in which the kicked client is located, is
|
||
simply handled as before: completely removed from channel, no zombie.
|
||
This means also that there is no client-server protocol change anymore:
|
||
/who, /whois and /names won't change.
|
||
|
||
- A kick received for a local client originating from a remote client
|
||
lets the server sent a PART upstream. Since this results for non TSpre8
|
||
servers in a remote "You're not on that channel" message, this
|
||
message is suppressed (would never occur anyway now we are completely
|
||
synced).
|
||
|
||
The reason why this was needed is mainly because MURC constantly kicks
|
||
people who have auto-rejoin disabled from different channels. With U3.1
|
||
they would get into problems after ten channels (needed to send extra
|
||
PART's).
|
||
|
||
Run
|
||
|
||
--
|
||
-------------------------------------------------------------------------------
|
||
| carlo@sg.tn.tudelft.nl | Run @ IRC |
|
||
| | Admin of Delft.NL.EU.undernet.org |
|
||
| * Don't expect anything of live, | and Ircserver.et.tudelft.nl |
|
||
| or you'll miss all the rest of it.| |
|
||
-------------------------------------------------------------------------------
|
||
|
||
|
||
|
||
=============================================================================
|
||
U3->U4, ANTI NICK COLLIDE
|
||
=============================================================================
|
||
Author: Carlo, carlo@sg.tn.tudelft.nl, Run on IRC.
|
||
|
||
Hi all...
|
||
|
||
After we dealt with channel msg-, join/part- and nick-floods (.bquiet),
|
||
and with private message flooding (.silence), now in a sort of follow up
|
||
to the anti net.break.ride (.TSpre7) and anti admin.hacks (TSpre8) we are
|
||
about to deal with one of the last vulnerabilities of our net:
|
||
nick-collision bots.
|
||
Called .anc (anti nick collision).
|
||
- - -
|
||
|
||
Socially spoken it does the following (I hope):
|
||
|
||
- Only kills the RIGHT person, when a nick collision occurs.
|
||
|
||
This would mean:
|
||
|
||
A) If someone tries to harash by connecting to servers that just broke off
|
||
and then take the nick of a person on the other side, both would be
|
||
killed on reconnection. But with the .anc patch on both connecting servers,
|
||
only the net.break rider will be killed.
|
||
|
||
B) Secondly, when your server (or side) breaks off and you connect to some
|
||
other server on the other side, it happens sometimes that due to lag you get
|
||
killed by a nick collision after reconnection of the net.
|
||
|
||
A and B differ strongly in the sense that in case A the *new* -the youngest-
|
||
nick must be killed, while in case B the *old* (lagged) nick must be
|
||
killed.
|
||
Technically this means that we have to look at the user@host.name too.
|
||
This gives rise to some incompatible changes, and therefor, this patch
|
||
must be done in two steps: First we deal with the nick-collision bots and
|
||
make the server compatible with both - the old and new protocol. And then
|
||
once all server upgraded, we deal with the last step: the nick collision
|
||
with yourself.
|
||
|
||
In the future there will be a third possible condition in which we can have
|
||
a nick collision: (long example follows, can be skipped)
|
||
|
||
C) The net breaks, and reconnects else where, and somehow a race condition
|
||
occurs between the 'SERVER' messages of the servers of one side.
|
||
For example:
|
||
|
||
Servers: Part A Part B1 PartB2
|
||
Nicks a(A),b(B) a(A),b(B) a(A),b(B)
|
||
Part A breaks off Part B:
|
||
<-- :b QUIT --> :a QUIT
|
||
<-- SQUIT serversB --> SQUIT serversA
|
||
Result: a(A) b(B) b(B)
|
||
A reconnects to Part B1, but immedeately breaks off again:
|
||
-->SERVERs A
|
||
-->NICK a
|
||
-->:a USER ...
|
||
Break:
|
||
-->SERVERs A
|
||
-->NICK a
|
||
-->:a USER ...
|
||
--> :a QUIT
|
||
--> SQUIT serversA
|
||
A connects to part B2, note that 'part B1 --> part B2' is lagged and the
|
||
"SERVERs A ... etc" didn't arrive yet on partB2.
|
||
Servers: Part B1 Part B2 Part A
|
||
Nicks: b(B) b(B) a(A)
|
||
-->SERVERs A
|
||
-->NICK a
|
||
-->:a USER ...
|
||
--> :a QUIT
|
||
--> SQUIT serversA
|
||
--> SERVERs B
|
||
--> NICK b
|
||
--> :b USER ...
|
||
<-- SERVERs A
|
||
<-- NICK a
|
||
<-- :a USER ...
|
||
Result *before* the lagged messages arive on Part B2:
|
||
Nicks: b(B) b(B),a(A) b(B),a(A)
|
||
-->SERVERs A
|
||
-->NICK a
|
||
-->:a USER ...
|
||
-->:a QUIT
|
||
-->SQUIT serversA
|
||
And when the lagged messages arrive on Part B2, the
|
||
'SERVERs A' get all ignored: "server exists", even more, Part B2 disconnects
|
||
Part B1... :/. Now we are going to deal with the "server exists" problem
|
||
*once* (attaching a timestamp to SERVER I think), in which case 'SERVERs A'
|
||
would only be ignored by Part B2. Then the 'NICK a' would cause a nick
|
||
collision with 1) Same user@host.name, 2) same server A, and 3) same
|
||
nick-TS ! This means: We need to ignore 'NICK nick' when is has the same
|
||
TimeStamp and the same user@host. But when the user@host differ, two people
|
||
signed on at exactly the same time with the same nick and we must kill
|
||
*both* to avoid a desync.
|
||
----
|
||
|
||
How to handle a nick collision, general
|
||
---------------------------------------
|
||
|
||
Up till now when a nick collision occurs, both nicks (when a nick change
|
||
from 'old' to 'new' is involved) are KILLed in ALL directions.. wiped off the
|
||
net thus.
|
||
But even with wiping off the net in mind, it doesn't make sense to kill in
|
||
old direction, it is sufficient to deal with "our side" of the net, because
|
||
every nick collision occurs on two servers, both can deal with their side.
|
||
As an example:
|
||
|
||
Servers: A B
|
||
Nicks: a(A) a(B)
|
||
Reconnection:
|
||
<-- NICK a
|
||
NICK a -->
|
||
|
||
As you see, if A receives the 'NICK a' from B, it only has to deal with
|
||
its own side, because it is certain that B will receive the 'NICK a' from
|
||
A and handle it too as a nick collision (and therefore this 'NICK a' *is*
|
||
already a 'KILL' message).
|
||
|
||
Thus, when we receive a 'NICK' that gives rise to the need of purging
|
||
a nick on *our* side, we deal with it by doing:
|
||
sendto_serv_butone(cptr,":%s KILL ...
|
||
which sends the KILL to all server connections except the link 'cptr' that
|
||
generated the nick collision.
|
||
Also then we have to destroy the memory usage of the killed client on our
|
||
own server, and disconnect him if it is ours, so we call exit_client().
|
||
|
||
Summary so far
|
||
--------------
|
||
|
||
Ok, we discussed when to kill who. Resulting rules are:
|
||
|
||
We receive a "NICK new" or ":old NICK new" from a server direction, and
|
||
we already have a registered 'new'. Then we have a nick collison and deal
|
||
with it as follows:
|
||
1) If the user@host differ,
|
||
and our 'new' is younger or equal, KILL our 'new'.
|
||
and our 'new' is older, ignore the 'NICK new', but kill 'old' on
|
||
our side if it was a nick change.
|
||
2) If user@host is the same:
|
||
and our 'new' is older, KILL our 'new'.
|
||
and our 'new' is younger, ignore the 'NICK new', but kill
|
||
'old' on our side if it was a nick change.
|
||
and our 'new' is equal, KILL our 'new',
|
||
and kill 'old' on our side too if it was a nick change.
|
||
|
||
Remarks:
|
||
The last case, where have a ':old NICK new' collission with
|
||
the same user@host and TimeStamp, can't be case C), but it
|
||
is possible that *we* did send a 'NICK new', and the server at
|
||
the other side kills 'old' off... So we have to do it too.
|
||
With this protocol we *ignore* 'NICK new' message, but of course
|
||
in most cases they will be followed by at least a ':new USER ...' and
|
||
probably
|
||
more like ':new JOIN #...'. This would cause 'Fake direction' errors and
|
||
the current protocol KILLs such a nick in *ALL* direction (???). Now, we
|
||
DON'T want to KILL the nick in the right direction do we? And killing the
|
||
fake direction nick makes no sense: it will be killed automatically due to
|
||
the fact we did send a 'NICK new' in that direction. Thus: we can/have to
|
||
remove the Fake Direction kills.
|
||
Of course, when we receive a 'NICK new hopcount :TimeStamp', we
|
||
*can't* compare with the user@host, because it takes some time before we
|
||
will receive the 'USER'... We also can't store the nick, because it must
|
||
be unique. To solve this, we need to change the protocol so that 'NICK new'
|
||
contains all information and the USER message will be redundant and removed
|
||
in a later patch. This also reduces net.bursts.
|
||
|
||
Attaching a TimeStamp (TS) to nicks
|
||
-----------------------------------
|
||
|
||
Whenever someone takes a new nick, which is available of course, either by
|
||
changing nick or by signing on, the local server attaches a TimeStamp (TS)
|
||
to the nick. Now there will be sent:
|
||
|
||
NICK new hopcount TS user host.name server.name :Real name
|
||
or
|
||
:old NICK new :TS
|
||
|
||
This is 100% compatible with the existing protocol.
|
||
|
||
When a server receives such a nick from a neighbouring server it copies the
|
||
TS, keeping track of the local change time. (When not all servers have
|
||
upgraded, and no TS is received, the .anc server will fill in the time
|
||
itself - being a slight advantage over keeping it 0. It also will assume
|
||
that the host.names are equal or not equal resulting a as many kills as
|
||
needed in the worst case).
|
||
|
||
|
||
Examples
|
||
--------
|
||
|
||
Servers: A B
|
||
Nicks: a(A),b(B) b(B),a(A)
|
||
Both change simultaneously to nick 'c', but 'a' slightly faster (at time=1,
|
||
and b at time=2):
|
||
c(A),b(B) c(B),a(A)
|
||
-> :a NICK c :1
|
||
:b NICK c :2 <-
|
||
Then A receives a ':b NICK c :2' where 2 > 1, and KILLs b on its own side.
|
||
B however receives ':a NICK c :1' where 1 < 2, and KILLs c on its own side.
|
||
Result: c(A) c(A)
|
||
|
||
Due to 'lag', more :c PRIVMSG .. from B to A can follow, resulting in a
|
||
fake direction. 'A' will simply ignore them and not kill c (kills for
|
||
fake direction are nonsense anyway).
|
||
|
||
In the case that someone signs on, taking the same nick as a nick change
|
||
we have almost the same:
|
||
|
||
Servers: A B
|
||
Nicks: a(A) a(A)
|
||
'a' changes simultaneously to nick 'c', but slightly faster (at time=1),
|
||
as a new 'c' signs on at B (time=2).
|
||
c(A) a(A),c(B)
|
||
-> :a NICK c :1
|
||
NICK c 1 :2 <-
|
||
Then A receives a 'NICK c 1 :2' where 2 > 1, and ignores it simply.
|
||
B however receives ':a NICK c :1' where 1 < 2, and KILLs c on its own side.
|
||
Result: c(A) c(A)
|
||
|
||
If the new 'c' was a little bit earlier, we get:
|
||
|
||
Servers: A B
|
||
Nicks: a(A) a(A)
|
||
'a' changes simultaneously to nick 'c', and slightly slower (at time=2),
|
||
as a new 'c' signs on at B (time=1).
|
||
c(A) a(A),c(B)
|
||
-> :a NICK c :2
|
||
NICK c 1 :1 <-
|
||
Then A receives a 'NICK c 1 :1' where 1 < 2, and KILLs c on its own side.
|
||
B however receives ':a NICK c :2' where 2 > 1, and KILLs a on its own side.
|
||
|
||
Result: c(B) c(B)
|
||
|
||
Last case, two people sign on (or during a net reconnection):
|
||
|
||
Server: A B
|
||
Sign on: c(A) c(B)
|
||
-> NICK c 1 :1
|
||
NICK c 1 :2 <-
|
||
Then A receives 'NICK c 1 :2' where 2 > 1, and ignores it.
|
||
and B receives a 'NICK c 1 :1' where 1 < 2, and KILLs c on its own side.
|
||
Result: c(A) c(A)
|
||
|
||
Note: the above didn't take equal TS's into account, and I assumed
|
||
user@hosts to be different: the nick collision bot cases.
|
||
|
||
A last possibility when someone starts hacking... a 'NICK new' twice
|
||
from the same direction, should not be accepted: we kill the earlier one
|
||
always.
|
||
|
||
Compatibility problems
|
||
----------------------
|
||
|
||
In the future, we want to also take 'user@host' into account... Therefor,
|
||
we need to start to ignore 'NICK new' and only act upon ':new USER ...'.
|
||
We can only do that if also 'USER contains the hopcount and TimeStamp'...
|
||
If we change the protocol immedeately to say:
|
||
:nick USER user host.name server.name hopcount TimeStamp :Real name
|
||
the 'hopcount' would be treated as realname, and we the rest would be
|
||
lost :(
|
||
|
||
We can also transfer the info to 'NICK', with:
|
||
|
||
:server.name NICK nick hopcount user host.name TimeStamp :Real name
|
||
|
||
and later forget the USER message. Although someone lamer uses
|
||
the C source line " if (sptr == cptr) ..." in m_nick() to determine if
|
||
it was a 'NICK new' or a ':old NICK new' :/ Geesh (unlogical). He should
|
||
have used " if (IsServer(sptr)) ...". You would need three upgrade steps
|
||
or we will have to do with:
|
||
NICK nick hopcount user host.name server.name TimeStamp :Real name
|
||
|
||
The nice thing about this is, that we can check how many parameters we
|
||
receive and then immedeately use the user@host if it is there... That way
|
||
the .acn will immedeately work once everyone upgraded once, and the second
|
||
step would only get rid of the 'USER' line between servers.
|
||
|
||
Run
|
||
|
||
|
||
=============================================================================
|
||
WALLOPS
|
||
=============================================================================
|
||
Usage: /WALLOPS <message>
|
||
|
||
Sends a message to IRC ops on-line. Remember that users who are /umode +w
|
||
can see wallops as well.
|
||
|
||
|
||
=============================================================================
|
||
STATS W
|
||
=============================================================================
|
||
Author: Michael Vanloon (michaelv@iastate.edu) - mlv on IRC
|
||
Help on /stats w :
|
||
|
||
I've been working on something I think would be quite a useful
|
||
addition to the ircd. It keeps track of the average number of local
|
||
clients, total clients, and total connections (including servers) over
|
||
various periods of time, currently over the last minute, hour, day and
|
||
week. It is invoked by "/stats w server.name". You may try it
|
||
yourself by "/stats w *.iastate.edu". A sample from
|
||
ircserver.iastate.edu looks like this:
|
||
|
||
*** Minute Hour Day Week Userload for:
|
||
*** 44.91 39.4 33 33 iastate.edu clients
|
||
*** 114.40 103.2 69 65 total clients
|
||
*** 120.40 109.0 73 70 total connections
|
||
*** * End of /STATS report
|
||
|
||
I'm debating changing it to show average connections over the last
|
||
minute, hour, day, prev. day, and prev. day, as I think the data
|
||
doesn't change enough after that to really be useful to justify
|
||
keeping it over an entire week.
|
||
|
||
On smaller, less used servers, it should add a negligible amount to
|
||
the resident memory consumed by the ircd. On a large hub such as the
|
||
*.bu.edu servers, penfold, or ircserver.iastate.edu, it might add as
|
||
much as 300k to the amount of memory the ircd attempts to keep
|
||
resident. The amount is determined solely by the number of
|
||
connects/disconnects the server processes over the span of time
|
||
measured.
|
||
|
||
The code is bulletproof and has undergone *extensive* debugging and
|
||
testing before I announced it here.
|
||
|
||
The reason I'm posting this is because I would like to know how many
|
||
people think this would be a useful addition to the server. In
|
||
addition, I'd like feedback on whether you think this should be a
|
||
standard part of the distributed server code. I think it should, but
|
||
Avalon wants me to post here first and see how others feel about it.
|
||
I'd appreciate your input.
|
||
|
||
I will be making a patched 2.7.2 server available with this included,
|
||
for those who would like to have this and stability too. I'll also be
|
||
hooking it into 2.8.x soon, and giving it back to Av to include in the
|
||
standard 2.8 distribution as it matures, if he sees fit to do so.
|
||
|
||
Thanks for your time...
|
||
|
||
--Michael (mlv)
|
||
|
||
IRC log started Wed Aug 18 21:52
|
||
*** Value of LOG set to ON
|
||
*mlv* it's the usage of your server
|
||
*mlv* average number of users on your server over the last minute, hour, day, yesterday, and the day before
|
||
*mlv* local clients, total clients, and total connections (clients + servers)
|
||
-ircserver.iastate.edu- Minute Hour Day Yest. YYest. Userload for:
|
||
-ircserver.iastate.edu- 23.00 23.0 16 17 11 iastate.edu clients
|
||
-ircserver.iastate.edu- 52.00 52.8 37 35 23 total clients
|
||
-ircserver.iastate.edu- 61.00 61.7 45 42 21 total connections
|
||
-> *mlv* hmm...so iastate had 23 local clients in the last minute?
|
||
*mlv* right... in the last minute the average number of local users on our server was 23
|
||
*mlv* 23.45 actually
|
||
-> *mlv* okie...gotcha... thanks :) one other thing
|
||
*mlv* there were an average of 23.1 local users on here over the last hour
|
||
*mlv* shoot
|
||
-> *mlv* is it possible to specify multiple domains?
|
||
-> *mlv* for e.g. uoknor.edu and okstate.edu cos those will be local to midway
|
||
*mlv* it could be coded in, but 1) my code doesn't support it out of the box, and 2) that would add more state info which would increase the memory usage a bit
|
||
-> *mlv* hmm...
|
||
*mlv* it's purely informational... i wouldn't worry about it, really that much
|
||
-> *mlv* okay...also, the Makefile on the ftp site seems hosed.....there's junk at the end...I tried both the .Z and the .gz
|
||
*mlv* i'm thinking about making it log by connection class... but i'll have to use a more efficient statistical algorithm (less precise) if i do that
|
||
*mlv* that way you could put all the local domains into certain classes
|
||
*mlv* oh yeah... it's harmless, just weird
|
||
-> *mlv* that'll work :)
|
||
-> *mlv* well...thanks for your help....will have a look at the stats w patch when you're finished with it :)
|
||
IRC Log ended *** Wed Aug 18 22:22
|
||
|
||
|
||
=============================================================================
|
||
BAN/TOPIC/SIGNON INFO
|
||
=============================================================================
|
||
Author: Paul Foley (pfoley@kauri.vuw.ac.nz) SIO on IRC
|
||
|
||
Help on Ban/Topic/Signon :
|
||
|
||
Since these patches allow the server to maintain additional information, the
|
||
server replies have been changes for the /mode #channel +b (#367), /whois
|
||
(#317) and an additional reply #333 has been added for topic info. The time
|
||
is returned as a long integer in UTC format in all cases. Since the existing
|
||
clients will ignore this additional information, you will need to either
|
||
patch the client, or in case you're using ircII, use the foll. /on statements
|
||
to take benefit of these patches :
|
||
|
||
on ^367 * if ([$4] != []) {echo *** $1 \($3 - $stime($4)) $2} {echo *** $1-}
|
||
on ^333 * echo *** Topic for $1 set by $2 on $stime($3)
|
||
on ^317 * if (index(012345679 $3) != -1) {echo *** $1 has been idle for $2 seconds. Signon at $stime($3)} {echo *** $1 has been idle for $2 seconds.}
|
||
|
||
|
||
Once you have done this, you can see info as follows:
|
||
/mode #wasteland +b
|
||
*** #wasteland (Mmmm - Thu Aug 19 04:44:24 1993) test!*@*
|
||
|
||
/topic #wasteland
|
||
*** Topic for #wasteland: We all love Axl Rose!
|
||
*** Topic for #wasteland set by rbarnes on Thu Aug 19 04:26:56 1993
|
||
|
||
/whois Mmmm
|
||
*** Mmmm is mandar@essex.ecn.uoknor.edu (Mmmm,I get high with a little help
|
||
+from my friends)
|
||
*** on channels: @#wasteland
|
||
*** on irc via server essex.ecn.uoknor.edu (MIDWEST HUB..HELPS YOU GET THERE
|
||
+SOONER)
|
||
*** Mmmm is an IRC Operator
|
||
*** Mmmm has been idle for 454 seconds. Signon at Wed Aug 18 23:47:19 1993
|
||
|
||
|
||
=============================================================================
|
||
CLIENT NOTIFY
|
||
=============================================================================
|
||
Authors: Patrick Ashmore (pda@engr.engr.uark.edu) - Twilight1 on IRC
|
||
Mandar Mirashi (mmmirash@mailhost.ecn.uoknor.edu) - Mmmm on IRC
|
||
Tony Vencill (vencill@iastate.edu) - Tony/Tonto on IRC
|
||
|
||
Help on Client Notify:
|
||
|
||
This patch allows all opers on your server to see clients connecting to your
|
||
server and disconnecting from it (with the reason why they disconnected).
|
||
This can help you identify troublesome clients, or redirect remote clients
|
||
to closer servers, or troubleshoot the reason why a client disconnected.
|
||
|
||
A sample output:
|
||
|
||
*** Notice -- Client connecting : Karll (agifford@sci.dixie.edu).
|
||
|
||
*** Notice -- Client exiting : Karll (agifford@sci.dixie.edu) [Bad link?].
|
||
|
||
PS: if you wish to selectively decide when you wish to see these connection
|
||
notices, use the foll. script
|
||
|
||
on ^server_notice "% % NOTICE -- CLIENT*" if (hideit != 1) {echo *** $2-}
|
||
alias show @ hideit = 0;echo *** You can now see clients connecting/exiting
|
||
alias hide @ hideit = 1;echo *** You will no longer see clients connecting/exiting
|
||
|
||
If you then wish to not see client connects/exits when you are opered, simply
|
||
type /hide. If you wish to see them again, type /show.
|
||
|
||
=============================================================================
|
||
TRACE TIMES
|
||
=============================================================================
|
||
Author: Tony Vencill (vencill@iastate.edu) - Tony/Tonto on IRC
|
||
|
||
Help on Trace Time:
|
||
|
||
This useful patch lets you identify the times since your server last
|
||
heard from any connected servers or clients. This time is displayed in
|
||
seconds, appended to each line of your /trace output. It can be very
|
||
helpful in identifying which servers are going to drop off or which
|
||
clients may ping timeout from your server.
|
||
|
||
A sample output:
|
||
|
||
/trace essex*
|
||
*** Serv [30] ==> 10S 8C cancun.caltech.edu *!*@essex.ecn.uoknor.edu 73
|
||
*** Serv [30] ==> 9S 6C imageek.york.cuny.edu *!*@essex.ecn.uoknor.edu 27
|
||
*** Serv [0] ==> 1S 0C inga1.acc.stolaf.edu[130.71.192.16]
|
||
+*!*@essex.ecn.uoknor.edu 58
|
||
*** Serv [0] ==> 1S 0C shadow.acc.iit.edu *!*@essex.ecn.uoknor.edu 97
|
||
*** Serv [0] ==> 1S 2C curie.ualr.edu Mmmm!mmmirash@essex.ecn.uoknor.edu 98
|
||
*** Serv [0] ==> 1S 1C piaget.phys.ksu.edu *!*@essex.ecn.uoknor.edu 117
|
||
*** Oper [0] ==> Mmmm[essex.ecn.uoknor.edu] 0
|
||
*** Serv [50] ==> 1S 0C pv1629.vincent.iastate.edu *!*@essex.ecn.uoknor.edu 7
|
||
*** Class 0 Entries linked: 6
|
||
*** Class 50 Entries linked: 1
|
||
*** Class 30 Entries linked: 2
|
||
|
||
|
||
=============================================================================
|
||
K- line comments
|
||
=============================================================================
|
||
Author: Mandar Mirashi (mmmirash@mailhost.ecn.uoknor.edu) - Mmmm on IRC
|
||
|
||
This extremely useful patch allows you to specify either a comment or an
|
||
interval in the 2nd field of the K line (instead of the previous format
|
||
of just a restricted interval). The "comment" can even be configured to
|
||
be a *file* name which can then be displayed to the client rejected via
|
||
the K line. All existing K lines will work as they are. This patch is
|
||
an *enhancement* to the K-lines.
|
||
|
||
e.g. (of a comment field)
|
||
|
||
K:*.sdsu.edu:Flooding.is.not.cool.lamer:masc0482
|
||
|
||
As far as possible, do not use a white space in the comment field, because
|
||
this breaks ircII's /stats k handling. You can use the period (.) or the
|
||
underscore instead (_).
|
||
|
||
e.g (of a file to be output to a rejected client
|
||
- #define COMMENT_IS_FILE in config.h)
|
||
|
||
K:*.netcom.com:/ecn/staff0/irc/servers/vinson/sorry.txt:*
|
||
|
||
|
||
=============================================================================
|
||
OPER FAIL
|
||
=============================================================================
|
||
Authors: Michael Vanloon (michaelv@iastate.edu) - mlv on IRC
|
||
Jon C Green (jcgreen@iastate.edu) - Jon2 on IRC
|
||
Bryan Collins (b@ctpm.org) - bwy on IRC
|
||
|
||
This patch notifies you if someone tries to gain oper on your server and
|
||
fails. The notice goes out only to the operators on the server.
|
||
|
||
*** Notice -- Failed OPER attempt by M (mmmirash@lincoln.ecn.uoknor.edu)
|
||
[crackit]
|
||
|
||
|
||
=============================================================================
|
||
MIXED CASE
|
||
=============================================================================
|
||
Authors: Michael Vanloon (michaelv@iastate.edu) - mlv on IRC
|
||
Jon C Green (jcgreen@iastate.edu) - Jon2 on IRC
|
||
|
||
"Here's a patch mlv and I wrote that prevents clients with mixed-case usernames
|
||
from connecting. I don't know of many sites that allow mixed-case, so it
|
||
is effective for stopping many clonebot attacks and also stops many
|
||
would-be username hackers." - Jon2
|
||
|
||
This has been slightly modified by Mmmm to give an option of ignoring the
|
||
case of the first character if desired (useful for those PC users who
|
||
intuitevely enter their first name with the first letter capitalised).
|
||
|
||
e.g.
|
||
*** Notice -- Invalid username: buankBOT[saucer.cc.umr.edu]
|
||
|
||
|
||
=============================================================================
|
||
NOTE
|
||
=============================================================================
|
||
|
||
Usage:
|
||
NOTE USER [&passwd] [+-flags] [+-maxtime] <nick!username@host> <msg>
|
||
- or SEND|SPY|FIND|WAITFOR|NEWS <same as USER args.>
|
||
* or SEND|SPY|FIND|WAITFOR|WALL|WALLOPS|DENY|NEWS|KEY <see USER args.>
|
||
NOTE LS|COUNT|RM|LOG [&pwd][+-flags][#ID] <nick!user@host> [date]
|
||
NOTE FLAG [&passwd] [+-flags] [#ID] <nick!username@host> <+-flags>
|
||
* NOTE SENT [NAME|COUNT|USERS] <f.nick!f.name@host> <date> [RM]
|
||
- NOTE STATS [MSM|MSW|MUM|MUW|MST|MSF|USED]
|
||
- NOTE SENT [NAME|COUNT]
|
||
* NOTE STATS [MSM|MSW|MUM|MUW|MST|MSF|USED|RESET] [value]
|
||
* NOTE SAVE
|
||
|
||
The Note system have two main functions:
|
||
1. Let you send one line messages to irc users which
|
||
they will get when they next sign on to irc.
|
||
Example: NOTE SEND <nick> Hi, this is a note to you.
|
||
2. Let you spy on people, to see when they sign on or off,
|
||
change nick name or join channels.
|
||
Example: NOTE SPY +100 <nick> (spy on nick for 100 days)
|
||
|
||
You may fill in none or any of the arguments listed above, including
|
||
* or ? at any place, as nick@*.edu, !username, ni?k!username etc...
|
||
Other usefull features may be NOTE WAIT <nick>, making nick and
|
||
you get a message when you both are on at the same time.
|
||
|
||
Note was developed 1990 by jarle@stud.cs.uit.no (Wizible on IRC).
|
||
|
||
|
||
*Usage: NOTE [<server>] ANTIWALL
|
||
* Switch off b flag for wall's which you have received on specified
|
||
* server. The person who queued the wall would be notified about
|
||
* the antiwall, and who requested this.
|
||
|
||
|
||
Usage: NOTE COUNT [&<passwd>] [+|-flags] [#<ID>] <nick!username@host>
|
||
Displays the number of messages sent from your nick and username. See
|
||
HELP LS for more info. See HELP FLAG for more info about flag setting.
|
||
|
||
|
||
*Usage: NOTE DENY [&<passwd>] [+|-<flags>] [+|-<maxtime>]
|
||
* <nick!user@host> <msg>
|
||
* DENY is an alias for USER +RZ (default max 1 day)
|
||
* This command makes it impossible for any matching recipient to
|
||
* queue any Note requests until timeout.
|
||
|
||
|
||
Usage: NOTE FIND [&<passwd>] [+|-<flags>] [+|-<maxtime>]
|
||
<nick!username@host> <msg>
|
||
FIND is an alias for USER +FLR (default max 1 day)
|
||
This command makes the server search for any matching recipient, and
|
||
send a note message back if this is found. If <msg> field is used, this
|
||
should specify the realname of the person to be searched for. Examples:
|
||
FIND -4 foo*!username@host
|
||
FIND @host Internet*
|
||
FIND nicky Annie*
|
||
FIND +7 * Annie*
|
||
|
||
|
||
Usage: NOTE FLAG [&<passwd>] [+|-<flags>] [#<ID>]
|
||
<nick!username@host> <+|-flags>
|
||
You can add or delete as many flags as you wish with +/-<flag>.
|
||
+ switch the flag on, and - switch it off. Example: -S+RL
|
||
Following flags with its default set specified first are available:
|
||
-S > News flag for subscribing.
|
||
-M > Request is removed after you sign off.
|
||
-Q > Ignore request if recipient's first nick is equal to username.
|
||
-I > Ignore request if recipient is not on same server as request.
|
||
-W > Ignore request if recipient is not an operator.
|
||
-Y > Ignore request if sender is not on IRC.
|
||
-N > Let server send a note to you if message is delivered.
|
||
-D > Same as N, except you only get a message (no queued note to you).
|
||
-R > Repeat processing the request until timeout.
|
||
-F > Let server send note info for matching recipient(s). Any message
|
||
part specify what to match with the realname of the recipient.
|
||
-L > Same as F, except you only get a message (no queued note to you).
|
||
-C > Make sender's nicks be valid in all cases username@host is valid.
|
||
-V > Make sender's "nick*" be valid in all cases username@host is valid.
|
||
-X > Let server display if recipient signs on/off IRC or change
|
||
nickname. Any message specified is returned to sender.
|
||
-A > Show what server matching user is on using X flag.
|
||
-J > Show what channel matching user is on using X flag.
|
||
-U > Do not display nick-change using X flag.
|
||
-E > Ignore request if nick, name and host matches the message text
|
||
starting with any number of this format: 'nick!name@host nick!... '
|
||
* -B > Send a message to every account who match the nick!user@host
|
||
* This creates a received list with flag H set. (see LS +h)
|
||
* -T > Send a message not all nicks on same accounts too using B flag.
|
||
* -K > Give keys to unlock privileged flags by setting that flags on.
|
||
* The recipient does also get privileges to queue unlimited
|
||
* numer of requests, list privileged flags and see all stats.
|
||
* -Z > Make it impossible for recipient to queue anything at all.
|
||
Other flags which are only displayed but can't be set by user:
|
||
-O > Request is queued by an operator.
|
||
-G > Notice message is generated by server.
|
||
- -B > Broadcasting message.
|
||
* -H > Flag list for who's received Broadcast message (B flag).
|
||
- Notice: Message is not sent to recipient using F, L, R or X flag.
|
||
- Using this flags, no message needs to be specified.
|
||
* Notice: Message is not sent to recip. using F, L, R, X, K, Z or H
|
||
* flag (except if B flag is set for R). For this flags, no msg. needed.
|
||
|
||
Examples:
|
||
FLAG * +cj : Switch on c and j flag for all requests.
|
||
FLAG +x * +c : Switch on c flag for all req. which have x flag.
|
||
FLAG nick -c+j : Switch off c flag and which on j flag for nick
|
||
|
||
|
||
*Usage: NOTE KEY [&<passwd>] [+|-<flags>] [+|-<maxtime>] <nick!user@host>
|
||
* KEY is an alias for USER +KR (default max 1 day)
|
||
* This command is for allowing no-opers to use oper-options by specifying
|
||
* the flag to unlock. Be careful with this option!
|
||
* Example: KEY +365 +s * would make it possible for everybody to use s flag.
|
||
|
||
|
||
Usage: NOTE LOG [&<passwd>] [+|-<flags>] [#<ID>] <nick!username@host>
|
||
Displays how long time since matching person was on IRC. This works
|
||
only after use of NOTE SPY. The log is protected to be seen for other
|
||
users than the person who queued the SPY request. To get short
|
||
output, do not specify any arguments. Example:
|
||
LOG : Print short log of all
|
||
LOG * : Print long log including real names of all
|
||
LOG nick : Print long log for user nick.
|
||
|
||
|
||
Usage: NOTE LS [&<passwd>] [+|-<flags>] [#<ID>]
|
||
<nick!username@host> [<date>]
|
||
Displays requests you have queued. No arguments would show you
|
||
all requests without the message field.
|
||
Use flags for matching all messages which have the specified flags set
|
||
on or off. See HELP NOTE FLAG for more info about flag settings. Time
|
||
can be specified on the form day.month.year or only day, or day/month,
|
||
and separated with one of the three '.,/' characters. You can also
|
||
specify -n for n days ago. Examples: 1.jan-90, 1/1.90, 3, 3/5, 3.may.
|
||
If only '-' and no number is specified max time is set to all days.
|
||
The time specified is always the local time on your system. Example:
|
||
LS !user would show you all requests to username@*
|
||
LS +x would show all your SPY requests.
|
||
LS #300 would show you only request #300.
|
||
|
||
|
||
Usage: NOTE NEWS [&<passwd>] [+|-<flags>] [+|-<maxtime>]
|
||
<group!username@host>
|
||
NEWS with no message is an alias for USER +RS (default max 60 days)
|
||
This command is for subscribing on a specified newsgroup from any
|
||
user(s) or host(s). Wildcards may be used anywhere. Example:
|
||
NEWS irc.note : Subscribe on irc.note
|
||
* NEWS irc.note@*.no : Send to group irc.note, but only for
|
||
* users at host *.no
|
||
* NEWS irc.note : Send to all for group irc.note
|
||
* NEWS Users@*.edu Hi : Send Hi to all users using note in your
|
||
* server located at host *.edu.
|
||
(Advanced users may use User +rs <...> <filter> where filter is a
|
||
string which must matches with field in received news message)
|
||
- Only opers can send news as default.
|
||
* To send news add message and use same format as subscribing, except
|
||
* that username field must matches with subscribed group as alt.irc!*.irc -
|
||
* everybody subscribing on a*.irc or *.irc or alt.irc... would get the news.
|
||
* A speciall case is the group Users which everybody using note in the server
|
||
* are member of.
|
||
|
||
|
||
Usage: NOTE RM [&<passwd>] [+|-<flags>] [#<ID>] <nick!username@host>
|
||
Deletes any messages sent from your nick and username which matches
|
||
with nick and username@host. Use flags for matching all messages which
|
||
have the specified flags set on or off. See HELP FLAG for more info
|
||
about flag settings, and HELP LS for info about time.
|
||
|
||
|
||
*Usage: NOTE SAVE
|
||
* SAVE saves all messages with the save flag set. Notice that the
|
||
* messages are automatically saved (see HELP STATS). Each time server is
|
||
* restarted, the save file is read and messages are restored. If no users
|
||
* are connected to this server when saving, the ID number for each
|
||
* message is renumbered.
|
||
|
||
|
||
Usage: NOTE SEND [&<passwd>] [+|-<flags>] [+|-<maxtime>]
|
||
<nick!username@host> <msg>
|
||
SEND is an alias for USER +D (default max 60 days)
|
||
This command is for sending a message to recipient, and let the server
|
||
send a note + a notice to sender if this is on IRC - if message is sent.
|
||
SEND foobar Hello, this is a test.
|
||
SEND +7 !username@*.edu Hello again!
|
||
|
||
|
||
-Usage: NOTE SENT [NAME|COUNT]
|
||
*Usage: NOTE SENT [NAME|COUNT|USERS] <f.nick!f.name@host> <date> [RM]
|
||
Displays host and time for messages which are queued without specifying
|
||
any password. If no option is specified SENT displays host/time for
|
||
messages sent from your nick and username.
|
||
NAME displays host/time for messages sent from your username
|
||
COUNT displays number of messages sent from your username
|
||
* USERS Displays the number of messages in [], and names for all users
|
||
* who have queued any message which matches with spec. nick/name/host.
|
||
* RM means that the server removes the messages from the specified user.
|
||
|
||
|
||
*Usage: NOTE SERVICE <nick> <note command>
|
||
* Useful in robots. Note will take the requests as if from <nick>
|
||
|
||
|
||
Usage: NOTE SPY [&<passwd>] [+|-<flags>] [+|-<maxtime>]
|
||
<nick!username@host> [msg]
|
||
SPY is an alias for USER +RX (default 1 max day)
|
||
SPY makes the server tell you if any matching recipient sign(s)
|
||
on/off IRC or change nick name. No message needs to be specified.
|
||
However, if a message is specified this is returned to sender including
|
||
with the message about recipient. Message could for example be one or
|
||
more Ctrl-G characters to activate the bell on senders machine.
|
||
As an alternative for using C flag, <msg> field could start with
|
||
any number of nicks on this format: %nick1 %nick2... %nickn, with
|
||
no space between % and the nick name you use. Spy messages would be
|
||
valid for any of the nicks specified.
|
||
SPY with no argument would tell you what users you have spy on who are
|
||
currently on IRC. The system logs last time the last matching person was
|
||
on IRC for each SPY request is queued in the server. See NOTE LOG for this.
|
||
You may use flag +A to see what server matching user is on,
|
||
and/or +J flag to see what channel. (Read HELP NOTE USER for more). Example:
|
||
SPY foobar!username@host <ctrl-G>
|
||
SPY +10 foobar
|
||
SPY +aj &secret * <ctrl-G>
|
||
SPY +365 +e !user nick!*@* <ctrl-G>
|
||
SPY % +7 foo!user
|
||
SPY +5 nicky %mynick %meenick
|
||
|
||
|
||
-Usage: NOTE STATS [MSM|MSW|MUM|MUW|MST|MSF|USED]
|
||
*Usage: NOTE STATS [MSM|MSW|MUM|MUW|MST|MSF|USED|RESET] [value]
|
||
STATS with no option displays the values of the following variables:
|
||
MSM: Max number of server messages.
|
||
MSW: Max number of server messages with username-wildcards.
|
||
MUM: Max number of user messages.
|
||
MUW: Max number of user messages with username-wildcards.
|
||
MST: Max server time.
|
||
MSF: Note save frequency (checks for save only when an user register)
|
||
Notice that 'dynamic' mark after MSM means that if there are more
|
||
messages in the server than MSM, the current number of messages are
|
||
displayed instead of MSM.
|
||
Only one of this variables are displayed if specified.
|
||
* You can change any of the stats by specifying new value after it.
|
||
* RESET sets the stats to the same values which is set when starting the
|
||
* server daemon if no note file exist. Notice that this stats are saved
|
||
* in same file as the other messages.
|
||
|
||
|
||
Usage: NOTE USER [&<passwd>] [+|-<flags>] [+|-<maxtime>]
|
||
<nick!username@host> <msg>
|
||
With USER you can queue a message in the server, and when the recipient
|
||
signs on/off IRC, change nick or join any channel, note checks for
|
||
valid messages. This works even if the sender is not on IRC. See HELP
|
||
FLAGS for more info.
|
||
Password can be up to ten characters long. You may specify password
|
||
using the &, % or $ character. & is equal to to $, except working much
|
||
better cause client use $ for other things...
|
||
The % character works like &, except it makes the queuing silent. It
|
||
makess also sense to use this without any following password.
|
||
If any request queued is equal to any previous except time and maxtime,
|
||
only maxtime is changed as specified. You then get "Joined" instead of
|
||
"Queued".
|
||
HELP FLAGS for info about flag settings. Username can be specified
|
||
without @host. Do not use wildcards in username if you know what it
|
||
is, even if it's possible. Max time before the server automatically
|
||
remove the message from the queue, is specified with hours with a
|
||
'-' character first, or days if a '+' character is specified, as
|
||
-5 hours, or +10 days. Default maxtime is 7 days.
|
||
Note: The received message is *directly* displayed on the screen,
|
||
without the need for a read or remove request.
|
||
NOTE USER &secret +WN +10 Wizible!jarlek@ifi.uio.no Howdy!
|
||
is an example of a message sent only to the specified recipient if
|
||
this person is an operator, and after receiving the message, the server
|
||
sends a note message back to sender to inform about the delivery.
|
||
NOTE USER +XR -5 Anybody <ctrl-G>
|
||
is an example which makes the server to tell when Anybody signs
|
||
on/off irc, change nick etc. This process repeats for 5 hours.
|
||
NOTE USER +FL @*.edu *account*
|
||
is an example which makes the server send a message back if any real-
|
||
name of any user matches *account*. Message is sent back as note from
|
||
server, or directly as a notice if sender is on IRC at this time.
|
||
|
||
|
||
Usage: NOTE WAITFOR [&<pwd>] [+|-<flags>] [+|-<maxtime>]
|
||
<nick!username@host> [<msg>]
|
||
WAITFOR is an alias for USER +YD (default max 1 day)
|
||
Default message is [Waiting]
|
||
This command is for telling the recipient if this appears on IRC that
|
||
you are waiting for him/her and notice that this got that message. Example:
|
||
WAITFOR foobar
|
||
WAITFOR -2 foobar!username@*
|
||
WAITFOR foobar Waiting for you until pm3:00..
|
||
|
||
|
||
*Usage: NOTE WALL [&<passwd>] [+|-<flags>] [+|-<maxtime>]
|
||
* <nick!user@host> <msg>
|
||
* WALL is an alias for USER +BR (default max 1 day)
|
||
* This command is for sending a message once to every matching user
|
||
* on IRC. Be careful using this command. WALL creates a list of
|
||
* persons received the message (and should not have it once more time)
|
||
* with H flag set. This list can be displayed using ls +h from the
|
||
* nick and username@host which the WALL request is queued from.
|
||
* Removing the headers (H) before WALL request is removed would cause
|
||
* the message to be sent once more to what users specified in list.
|
||
* WALL +7 @*.edu Do not do this! - Makes it clear for all users using
|
||
* IRC on host @*.edu the next 7 days how stupid it is to send such WALL's ;)
|
||
|
||
|
||
*Usage: NOTE WALLOPS [&<passwd>] [+|-<flags>] [+|-<maxtime>]
|
||
* <nick!user@host> <msg>
|
||
* WALLOPS is an alias for USER +BRW (default max 1 day)
|
||
* This command is same as WALL, except only opers could receive it.
|
||
=============================================================================
|