]>
Commit | Line | Data |
---|---|---|
189935b1 | 1 | |
2 | The available patches for 2.8*mu servers are: | |
3 | ||
4 | Tp8 = TimeStampPre8 - A protocol which disallows netsplit ops and channel | |
5 | desynchs. | |
6 | ||
7 | Bquiet - does not allow a person who is banned to speak over the channel | |
8 | ||
9 | Silence - Cuts off flooding at local server | |
10 | ||
11 | Anc = Anti-Nick collide - *Intentional* nick collides are impossible with | |
12 | this wonderful patch. | |
13 | ||
14 | W = Wallops - lets you send messages to other IRC ops | |
15 | ||
16 | ban = BanInformation - Lets you see who did a ban and when, as well | |
17 | ||
18 | sw = /stats w - lets you gather statistics on average client connects | |
19 | ||
20 | To = TopicInformation - Lets you see who set the topic for a channel and when | |
21 | ||
22 | S = Signon Time - Tells you when a local user signed onto IRC | |
23 | ||
24 | Cl = Client connect - Notifies opers on your server of client connects/ | |
25 | disconnects (with disconnect reason) | |
26 | ||
27 | TT = Trace Times - displays the time (in secs) since your server last heard | |
28 | anything from a client/server, when you do /trace. | |
29 | ||
30 | KL = K-line comments - Allows you to modify the lame "no ghosts allowed" default | |
31 | comment to whatever you wish, or alternately, display a | |
32 | file to a rejected client. | |
33 | ||
34 | OF = Oper fail patch - displays a warning to current ops when someone fails | |
35 | in entering the right oper password. | |
36 | ||
37 | MC = Mixed case patch - useful for those pesky clone bots and hacked logins; | |
38 | disallows userids which have mixed case or control chars | |
39 | ||
40 | N = Note - allows you keep a "note" for other users, amongst other things | |
41 | ||
42 | ----------------------------------------------------------------------------- | |
43 | Explanations for these patches follow..... | |
44 | ||
45 | Help on patches written by Mandar Mirashi (mmmirash@mailhost.ecn.uoknor.edu) | |
46 | Mmmm on IRC. | |
47 | ||
48 | ||
49 | ============================================================================= | |
50 | TIMESTAMP | |
51 | ============================================================================= | |
52 | Author: Carlo, carlo@sg.tn.tudelft.nl, Run on IRC. | |
53 | Info on TS protocol: | |
54 | ||
55 | TSpre7 | |
56 | ||
57 | ------ | |
58 | Effects of the TS protocol: | |
59 | ||
60 | > No mode wars possible. | |
61 | When you take someones op there are three possibilities: | |
62 | - You were too late (You was already de-opped on your server). | |
63 | - You take it (On the *whole* net). | |
64 | - You start taking it (on your server, but it is 'bounced' (ie your mode | |
65 | change is cancelled); This occurs when you try to do mode change | |
66 | direct after a net re-connection in a situation were you hacked op by | |
67 | net-break riding. | |
68 | > No desynchronisation possible. | |
69 | > No unnecessary MODE msg send. You can't send 'double' mode's that don't | |
70 | make sense. Servers don't send unnecessary MODE's either. | |
71 | > Hacking op is from now on *only* possible by admins that hacked their | |
72 | servercode, and therefor easier to prosecute. Also you can 'hack' op still | |
73 | exactly like now (by riding net break) on an *opless* channel. | |
74 | > The protocol is fully compatible with older servers: It is invisible | |
75 | and it works with old servers like this: Every 'block' of direct connected | |
76 | 2.8.x.TS servers will stay synchronized, Hacking op is impossible by means | |
77 | of riding a net break between two TS-servers on channels that were created | |
78 | within that block. In all other cases the same happens as without TS. | |
79 | ||
80 | Here follow technical details implemented in TSpre7: | |
81 | ||
82 | ------ | |
83 | ||
84 | Reference: 2.8.14/15.TSpre7 | |
85 | Full list of TS-MODE-Change protocol: | |
86 | ||
87 | -Mode changes (originating by clients) are refused only: | |
88 | 1) from a client that is directly connected and has no chan ops on | |
89 | the channel on its server. | |
90 | 2) when not being a change of the internal state of a server (Well, refused | |
91 | is to strong, propagation of the mode is just unnecessary and thus not | |
92 | done). | |
93 | 3) from someone flagged as de-opped-by-server. (flag is reset when this | |
94 | person is opped again by anyone) (The server detecting this mode change | |
95 | cancels the mode change, by bouncing it upstream, thus keeping the net | |
96 | synchronized). | |
97 | ||
98 | -An extra parameter is added behind MODE changes *done* by servers, sended | |
99 | *to* other servers. It is a Universal Time in ascii seconds. This extra | |
100 | parameter is NOT sended when it is 0 (can happen with old servers on the | |
101 | net), 0 means <NONE> rather then Jan 1st 1970 :). | |
102 | This parameter is the creationtime of the channel being: the universal time at | |
103 | which the channel was created by a *local* client; or the non-zero received | |
104 | creation time from an other server (as parameter with a mode change) that | |
105 | was earlier then its own; or equal 0 when the channel was created by | |
106 | a non-local client and no MODE with TS was received (yet). | |
107 | ||
108 | -Of the channel_flags is 1 bit more used: CHFL_DEOPPED, set when de-opped | |
109 | by a server (compare CHFL_CHANOP, set when channel operator). It's reset | |
110 | when opped. (And starts reset on joining (creation?) of a channel, this | |
111 | will be changed to 'set' on join, when all servers have TS; making detection | |
112 | of op hacking by admins a bit easier). | |
113 | ||
114 | -Timestamps (sended by TS-servers) are handled as follows: | |
115 | Received TS Own TS Bounced/Propagated | |
116 | equal equal propagated | |
117 | later >0,earlier if ops: bounced with own TS | |
118 | if no ops: propagated with own TS | |
119 | (own TS is sended upstream too, to make sure | |
120 | TS stays synchronized). | |
121 | earlier later TS copied, propagated | |
122 | none any propagated, own TS sended. | |
123 | >0 none if ops: propagated, no TS sended, own TS stays 0. | |
124 | if no ops: TS copied, propagated. | |
125 | ||
126 | -A mode change +/-o nick (+/- v) from a person that is deopped by a server | |
127 | results in a -/+o nick back up stream (and is not propagated) if it was | |
128 | an attempt to change the internal state of the receiving server. | |
129 | ||
130 | -kick is handled as mode -o, internal state 'not on channel' being 'already | |
131 | de-opped'. Bounce includes JOIN and restoring o and v flags. | |
132 | (Effect: You don't even *see* the kick on one side, on the other side | |
133 | the person joins again and gets his flags back from the bouncing server). | |
134 | ||
135 | -A received TimeStamp that claims a creation time *earlier* then that | |
136 | this server dissapeared from the net results in a HACK: notice (with | |
137 | time difference in seconds). Bye OPER.. (This meaning, to hack op | |
138 | on an existing channel that was created 15 minutes before you disconnected | |
139 | your server, you will have generated a HACK notice: Clock set back at least | |
140 | 900 seconds by <nick>.) (Not yet implemented, prob. in pre8). | |
141 | ||
142 | ||
143 | TSpre8 | |
144 | ||
145 | ||
146 | From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl> | |
147 | Subject: *** IMPORTANT; RFC | |
148 | To: wastelanders@rush.cc.edu (New Wastelanders MailingList) | |
149 | Date: Thu, 14 Apr 94 18:03:38 METDST | |
150 | Mailer: Elm [revision: 66.33] | |
151 | Status: RO | |
152 | ||
153 | Hi, please read this carefully and respond if you think it will result | |
154 | in INCORRECT behaviour under any circumstances: | |
155 | ||
156 | Here follow technical details implemented in TSpre8: | |
157 | ||
158 | ------ | |
159 | ||
160 | Reference: 2.8.17.TSpre8 | |
161 | Full list of TS-MODE-Change protocol: | |
162 | ||
163 | -Mode changes (originating by clients) are refused only: | |
164 | 1) from a client that is directly connected and has no chan ops on | |
165 | the channel on its server. | |
166 | 2) when not being a change of the internal state of a server (Well, refused | |
167 | is to strong, propagation of the mode is just unnecessary and thus not | |
168 | done). | |
169 | 3) from someone flagged as de-opped-by-server. (flag is reset when this | |
170 | person is opped again by anyone) (The server detecting this mode change | |
171 | cancels the mode change, by bouncing it upstream, thus keeping the net | |
172 | synchronized). | |
173 | 4) When a '0' as timestamp is received, originating from a server (see below). | |
174 | Then the whole mode is ignored, a HACK notice is sent to all ops and the | |
175 | string is propagated as received. | |
176 | ||
177 | -An extra parameter is added behind MODE changes *done* by servers, sent | |
178 | *to* other servers *containing* a +o, -o, +v or -v. | |
179 | It is a Universal Time in ascii seconds. | |
180 | Whenever a HACK is detected, a HACK: notice is sent to all local opers, | |
181 | and the full MODE is propagated with a '0' as timestamp, generating | |
182 | a HACK notice on all other servers. | |
183 | Otherwise this parameter is the creationtime of the channel being: the | |
184 | universal time at which the channel was created by a *local* client; | |
185 | or the non-zero received creation time from an other server (as parameter | |
186 | with a mode change) that was earlier then its own; or equal 0 when the | |
187 | channel was created by a non-local client and no MODE with TS was received | |
188 | (yet). | |
189 | ||
190 | -Of the channel_flags is 1 bit more used: CHFL_DEOPPED, set when de-opped | |
191 | by a server (compare CHFL_CHANOP, set when channel operator). It's reset | |
192 | when opped. It starts *set* on joining (creation?) of a channel, making | |
193 | detection of op hacking by admins a bit easier. | |
194 | ||
195 | -Timestamps (sent by TS-servers) are handled as follows: | |
196 | Received TS Own TS Bounced/Propagated | |
197 | equal equal propagated | |
198 | later >0,earlier if ops: bounced with own TS | |
199 | if no ops: TS copied, propagated | |
200 | earlier later TS copied, propagated | |
201 | 0 or none any HACK generated, 0 propagated, own TS is kept | |
202 | >0 none TS copied, propagated. | |
203 | ||
204 | -A mode change +/-o nick (+/- v) from a person that is deopped by a server | |
205 | results in a -/+o nick back up stream (and is not propagated) if it was | |
206 | an attempt to change the internal state of the receiving server. | |
207 | ||
208 | -kick is handled as mode -o, internal state 'not on channel' being 'already | |
209 | de-opped'. Bounce includes JOIN and restoring o and v flags. | |
210 | (Effect: You don't even *see* the kick on one side, on the other side | |
211 | the person joins again and gets his flags back from the bouncing server). | |
212 | ||
213 | -A received TimeStamp that claims a creation time *earlier* then that | |
214 | this server dissapeared from the net results in a HACK: notice (with | |
215 | time difference in seconds). Bye OPER.. (This meaning, to hack op | |
216 | on an existing channel that was created 15 minutes before you disconnected | |
217 | your server, you will have generated a HACK notice: Clock set back at least | |
218 | 900 seconds by <nick>.) | |
219 | ||
220 | ||
221 | ||
222 | ||
223 | From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl> | |
224 | Subject: TSpre8 can work! :) | |
225 | To: wastelanders@rush.cc.edu (New Wastelanders MailingList) | |
226 | Date: Wed, 20 Apr 94 11:44:39 METDST | |
227 | Mailer: Elm [revision: 66.33] | |
228 | Status: RO | |
229 | ||
230 | Well... it took me a few days (a night and some dreams actually), but | |
231 | I think I found a solution for the problem I mentioned during the meeting :) | |
232 | ||
233 | Let me first repeat the problem: | |
234 | ||
235 | - I stated that TSpre8 would prevent op hacking by admins, but... later | |
236 | I realized that that was impossible the way wanted it :( | |
237 | My idea was at first: Simply generate a HACK notice when a server | |
238 | comes on the net with a creation time earlier then when it did split off | |
239 | (and earlier then my own creation time). This sounds nice, but in | |
240 | even this simple case it doesn't work: | |
241 | ||
242 | Server A and B, users a and b: | |
243 | ||
244 | A -- B | |
245 | | | |
246 | @a TS=100 | |
247 | ||
248 | Split at t=200 | |
249 | ||
250 | A B | |
251 | | | |
252 | @a | |
253 | ||
254 | b joins at t=300 | |
255 | ||
256 | A(TS=100) B(TS=300) | |
257 | | | | |
258 | @a @b | |
259 | ||
260 | Net joins: | |
261 | ||
262 | A -- B | |
263 | | | | |
264 | a b | |
265 | ||
266 | Both are de-opped: b because he sends a TS of 300 with is greater (later) | |
267 | then 100 (correctly: he used the netbreak). And a is deopped with a | |
268 | HACK notice by B, because he introduces 1) a TS earlier then the existing | |
269 | TS (100<300) and 2) the 100 is earlier then the time the split occured. | |
270 | ||
271 | The reason why this goes wrong is simply because B *forgets* the channel | |
272 | AND the TS of 100, after the split... If B would *keep* in memory that | |
273 | the channel existed on A and with what TS, it would be possible, but only | |
274 | at cost of a lot of extra memory usage... | |
275 | ||
276 | Now my new idea :) It allows hacking, but only in not so very interesting | |
277 | cases... And at least it makes it extremely difficult for a newbee, so we | |
278 | might at least catch 99% before they understand how it works :) | |
279 | ||
280 | (This explanation should not be on a public ftp site anymore after a while :) | |
281 | ||
282 | New rules: | |
283 | ||
284 | - Servers that are OFF the net for more then one day are forgotten. | |
285 | - New servers (or forgotten servers), are always bounced except on channels | |
286 | that have no ops (when they create a channel of their own thus :) unless | |
287 | the receiving server is younger then one day and the introduced TS is | |
288 | earlier then the start up time (minus 10 minutes :/) of the receiving server. | |
289 | 'Birthdays' of those servers are also kept. | |
290 | - A server that splitted off while a channel already existed, and thus | |
291 | has a creation time earlier then the "received squit time" of that | |
292 | server, is not allowed to introduce an earlier timestamp then the | |
293 | creationtime of the channel (HACK), and also not an equal TS when | |
294 | younger then one day. | |
295 | - A server introducing a server with an earlier "time of received squit" | |
296 | inherrits that time as its own "time of received squit". | |
297 | ||
298 | This allows to hack op on a channel that didn't exist when you splitted | |
299 | (not interesting). You also can't keep a server off the net till you need | |
300 | it (a telnet connection), because those can't do anything for one day long, | |
301 | unless they send the TS *equal* to the existing TS (The only exception :(), | |
302 | having to connect between two and one days before the hack, break between | |
303 | zero and one day before the hack but before the channel existed, connect | |
304 | and hack with equal TS. | |
305 | ||
306 | What do you think? Just for fun? :) | |
307 | ||
308 | Apart from that it would be suspicious when someone connects/breaks every | |
309 | 24 hours a "test" server, channels that exist longer then one day are | |
310 | unhackable. | |
311 | ||
312 | The "disadvantages" are: servers that break off the net for *longer* then | |
313 | one day, but keep a channel up with an op, on *both sides of the net, will | |
314 | be completely de-opped after reconnection. | |
315 | ||
316 | *** IMPORTANT: | |
317 | ||
318 | I am absolutely not sure ;) if there aren't any other disadvantages or | |
319 | unwanted effects :) Please, think this over and mail me if you find some | |
320 | objection... | |
321 | ||
322 | Run | |
323 | ||
324 | ||
325 | ||
326 | ||
327 | From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl> | |
328 | Subject: 2.8.19.U3 RELEASED | |
329 | To: wastelanders@rush.cc.edu (New Wastelanders MailingList) | |
330 | Date: Sun, 22 May 94 14:15:41 METDST | |
331 | Cc: carlo@sg.tn.tudelft.nl | |
332 | Mailer: Elm [revision: 66.33] | |
333 | Status: RO | |
334 | ||
335 | Hi all :) | |
336 | ||
337 | Proud to present: 2.8.19.U3 :) | |
338 | ||
339 | I have spend *enormous* amounts of time in TESTING this version, | |
340 | and I really hope it is completely bug free, but the changes are | |
341 | very big, so maybe persons who only want to upgrade/compile ONCE | |
342 | should wait a little longer then the compile cracks we have here ;) | |
343 | ||
344 | For real testing we need the HUBs though! So please, don't hesitate, | |
345 | Delft (a HUB) is running it already for a long time, also linked to | |
346 | other 2.8.19.U3 test servers. | |
347 | ||
348 | Before I'll tell about whats new in U3, I want to especially thank | |
349 | President for the tremendous help in testing TSpre8 -- I would never | |
350 | have been able bring up the stength to go through the difficult | |
351 | periods without him being there to listen to my technical complaints ;) | |
352 | ||
353 | ======================================================================= | |
354 | ||
355 | NEW in .U3 | |
356 | ---------- | |
357 | ||
358 | First all, TSpre8. | |
359 | ||
360 | It did not become what I hoped/expected to be possible :( | |
361 | Hacking will still be possible, but at least it will be a LOT | |
362 | more difficult when you don't know what you are doing, and I think | |
363 | we WILL catch (new) admins that think they can abuse their powers | |
364 | to be GOD on "their" channel. | |
365 | ||
366 | Especially, nobody will be able to hack *anything* with a normal nick. | |
367 | And because server modes are more obvious a hack, this alone is a | |
368 | step forward against admin hacking prevention imho. | |
369 | ||
370 | The .patch file is | |
371 | -rw------- 1 carlo users 65142 May 22 01:29 irc2.8.19-TSpre8.patch | |
372 | big. | |
373 | ||
374 | I'll now brows through it and mentions changes in the order they appear | |
375 | in the .patch file, arbitrary order thus ;) | |
376 | ||
377 | Zombies | |
378 | ------- | |
379 | ||
380 | As mentioned before on 'wastelanders', I changed the internal way a KICK | |
381 | is handled, to be able to stop illegal -hacked- kicks from *outside* the | |
382 | channel. This has no effect on server-server protocol nor on server-client | |
383 | protocol. But because this way it is possible to keep (a little) memory | |
384 | for channels you're not on (being kicked from) I thought it would be no | |
385 | more then logical to stop people from joining the usual 10 ten channels | |
386 | at the same time, *including* the ones you are kicked from (because they | |
387 | occupy memory). This memory is released when you 1) Try to rejoin (so with | |
388 | all people having a auto-rejoin-on kick NOTHING changed at all), or 2) | |
389 | when you do a part - this is new and only intended to use when you do | |
390 | NOT have auto-rejoin, when you do not even WANT to rejoin, or try, assuming | |
391 | you might not be banned, when you have been kicked like this of a lot of | |
392 | channels and all together are "on" 10 channels so you NEED to leave one | |
393 | before you can join another... For this rare case, you must know on | |
394 | *which* channels you "are", therefor this is visible when you do a | |
395 | /names, or /who or /whois to yourself. It is never visible for others. | |
396 | Example: | |
397 | ||
398 | 12:07 * Run (Daryl@sg.tn.tudelft.nl) has joined channel #wasteland | |
399 | *** Mode change "+o Run" on channel #wasteland by Wasted | |
400 | *** #wasteland : created Fri May 13 17:08:34 1994 | |
401 | <Macro> Hi Run ! | |
402 | *** You have been kicked off channel #wasteland by Run (Test) | |
403 | *** Run is Daryl@sg.tn.tudelft.nl (/msg Run profile) | |
404 | *** on channels: !#wasteland | |
405 | *** on irc via server Delft.NL.EU.undernet.org (Runaway Server | |
406 | +[130.161.188.188]) | |
407 | *** Run is away: Writting E-mail | |
408 | *** Run is an IRC Operator | |
409 | *** Run has been idle for 642 seconds. | |
410 | ||
411 | As you can see, the channel is marked with a '!' to show you are NOT | |
412 | not that channel... Both, a part #wasteland as well as a join (being | |
413 | not able to actually join because of ban, invite-only, key or limit), will | |
414 | remove you from this channel. The part will be sent back to (only) you, and | |
415 | everything has turned out to be 100% compatible with ircii protocol. | |
416 | Finally, of course the channel is removed when everyone is kicked and/or | |
417 | left the channel (a channel with only zombies is removed immedeately). | |
418 | ||
419 | #define RPL_CREATIONTIME 329 | |
420 | -------------------------------- | |
421 | ||
422 | A new numeric is sent when you ask for a MODE of a channel, by doing | |
423 | /MODE #channel | |
424 | without parameters. | |
425 | The reply is the same as before, but followed by a new numeric 329: | |
426 | ||
427 | /MODE #wasteland | |
428 | Delft.NL.EU.undernet.org 324 Run #wasteland +t | |
429 | Delft.NL.EU.undernet.org 329 Run #wasteland 768845314 | |
430 | ||
431 | To supress this, you'll have to add something like: | |
432 | ON ^329 * | |
433 | to your .ircrc file. If you want to see this new numeric, you would | |
434 | add | |
435 | On ^329 "*" echo *** $1 : created $stime($2) | |
436 | ||
437 | It turns out that ircii clients ask for this mode when you join a | |
438 | channel, therefor you will see the creationtime when you join a channel, | |
439 | I'll leave it as an exercise to suppress this, but still being able to | |
440 | see it when you specifically ask for it :) | |
441 | ||
442 | New ircd.conf line | |
443 | ------------------ | |
444 | ||
445 | This is IMPORTANT : | |
446 | In order for Uworld to work you MUST add those lines to your ircd.conf file: | |
447 | ||
448 | U:Uworld.undernet.org::* | |
449 | U:Underworld.nl::* | |
450 | ||
451 | The later to allow the backup Underworld.nl to still function. | |
452 | If you forget this, or do it wrong, your server might refuse to accept | |
453 | certain mode changes from Uworld.undernet.org and start *bouncing* | |
454 | modes done by lusers that got op from it. The name of servers allowed | |
455 | to hack have to be agreed upon totally, by all admins. If one admin | |
456 | removes his U: line, the service will not work always correctly. | |
457 | ||
458 | When a server does a mode change that is detected to be a hack, you | |
459 | will see -as an oper, or +s luser- this notice: | |
460 | ||
461 | -> *uworld* opcom MODE #wasteland +o Mmmm | |
462 | !Uworld.undernet.org! Run is using Uworld to : MODE #wasteland +o Mmmm | |
463 | *** Notice -- HACK: Uworld.undernet.org MODE #wasteland +o Mmmm | |
464 | *** Mode change "+o Mmmm" on channel #wasteland by Uworld.undernet.org | |
465 | ||
466 | Normally, this HACK notice would NOT take effect! You still *see* the | |
467 | HACK notice for the U: line server(s) but then they DO take effect. | |
468 | ||
469 | Every other message (some including the word HACK) do also take effect, | |
470 | and are only a warning that someone is MAYBE hacking... | |
471 | I didn't see it occur yet. | |
472 | ||
473 | Removed bugs | |
474 | ------------ | |
475 | ||
476 | I did find some bugs in TSpre7, never thought that was possible :) | |
477 | I forgot what it exactly was, but under (very rare) circumstances it | |
478 | could be pretty serious :/ | |
479 | ||
480 | One rather important thing is that now the TimeStamp is sent during a | |
481 | net re.join when there are no ops. Before it was possible to create | |
482 | a partly TimeStamp less net on an opless channel. TSpre8 garantees | |
483 | that the TS is synchronized on the whole net at any time. | |
484 | ||
485 | Other messages | |
486 | -------------- | |
487 | ||
488 | Apart from the (true) HACK notice, you can get a: | |
489 | ||
490 | BOUNCE or HACK: notice, which does take effect and is most probably | |
491 | just a bounce of a mode done by an attacker: someone immedeately after | |
492 | a net re.join with his net.ride ops trying to de-op the others. | |
493 | I don't think this will happen often because it will be clear to all lusers | |
494 | that it is useless to try. | |
495 | ||
496 | NET.RIDE on opless #channel notice, you'll see this if someone does | |
497 | really abuses a net break to get ops on some opless channel. The mode | |
498 | does take effect however. | |
499 | ||
500 | FULL bounce of modes | |
501 | -------------------- | |
502 | ||
503 | When before someone would ride a net break, and try something, ONLY | |
504 | his +/- o/v modes. Other modes like +mlk 1 \\|/\|/ would still take | |
505 | effect. With TSpre8 this changed... All modes (except bans) are bounced | |
506 | when someone rides a net break. Also the bouncing is more compact, while | |
507 | with TSpre7 every o and v mode took one line, now all modes are kept into | |
508 | one line. | |
509 | ||
510 | More allowed | |
511 | ------------ | |
512 | ||
513 | Before you was (how lame) not allowed to mix things like k, o and v... | |
514 | Now you are allowed, why not? Also you can use up to six parameters, | |
515 | really gives you a power kick ;) | |
516 | ||
517 | *** Mode change "+vvvvvv flux epa Skip Run Mmmm gyn" on channel #wasteland by | |
518 | +Run | |
519 | ||
520 | User friendly mask fixing | |
521 | ------------------------- | |
522 | ||
523 | The lame way Avalon fixes a mask (for a ban) is like this: | |
524 | ||
525 | /mode * +bb *.tudelft.nl Daryl@sg*.tn.tudelft.nl | |
526 | ||
527 | becomes: | |
528 | ||
529 | *** Mode change "+bb *.tudelft!*@* Daryl!*@sg*.tn.tudelft.nl" on channel | |
530 | +#wasteland by Run | |
531 | ||
532 | The same on a TSpre8 server gives: | |
533 | ||
534 | *** Mode change "+b *!*@*.tudelft.nl" on channel #wasteland by Run | |
535 | ||
536 | While just Daryl@sg*.tn.tudelft.nl results in: | |
537 | ||
538 | *** Mode change "+b *!Daryl@sg*.tn.tudelft.nl" on channel #wasteland by Run | |
539 | ||
540 | which what one would expect! | |
541 | ||
542 | ||
543 | ---------------------------------------------------------------- | |
544 | ||
545 | Goodluck with compiling, | |
546 | ||
547 | Run | |
548 | ||
549 | PS If you encounter any problems, realize it is VERY unlikely that | |
550 | it is .U3, but if you really think so, then first try to compile | |
551 | plain 2.8.19. If you succeed, save the Makefile the include/config.h | |
552 | and the include/setup.h. Unpack .U3, replace those files and recompile. | |
553 | With this I assume you don't put your ircd.conf inside the source | |
554 | directories of course, that would still have the paths set wrong then. | |
555 | ||
556 | A smart move is to make patch file once for your Makefile/config.h : | |
557 | First ONLY edit the Makefile and config.h (or copy the them from a | |
558 | working source tree to a empty directory), and then make a diff with: | |
559 | diff -rc irc2.8.19.clean irc2.8.19.my.makefile > Makefile.config.h.patch | |
560 | ||
561 | That really speeds up upgrading with later versions. | |
562 | (irc2.8.19.my.makefile only needs to contain | |
563 | irc2.8.19.my.makefile/Makefile | |
564 | irc2.8.19.my.makefile/include/config.h ) | |
565 | Of course, keep the include/setup.h seperately. | |
566 | ||
567 | ### KILL for Mmm. Mmmm (stop it lamer (unnecessary flooding of alexbot)) | |
568 | ||
569 | ||
570 | ============================================================================= | |
571 | BQUIET | |
572 | ============================================================================= | |
573 | Author: Carlo, carlo@sg.tn.tudelft.nl, Run on IRC. | |
574 | Helpful ideas by: Aaron, agifford@sci.dixie.edu, Karll on IRC | |
575 | ||
576 | ||
577 | In order to fight flooding, and as discussed on wastelanders, banning | |
578 | someone on a channel will now also stop him from doing anything visible | |
579 | on the channel. This allows to let someone see what you think of him | |
580 | without even kicking him, he will leave by himself. | |
581 | He will still be able to appologise by private msgs of course and then | |
582 | he can be de-banned. A ban is this way a short cut for +m+vvvv everyone | |
583 | excpet the flooder. Note that even NICK floods are stopped: When you are | |
584 | on a channel where you are banned, you are not allowed to change your nick. | |
585 | ||
586 | ============================================================================= | |
587 | SILENCE | |
588 | ============================================================================= | |
589 | Author: Carlo, carlo@sg.tn.tudelft.nl, Run on IRC. | |
590 | Helpful ideas by: Aaron, agifford@sci.dixie.edu, Karll on IRC | |
591 | ||
592 | My solution to flooders with clone bots etc :) | |
593 | Let the user that GETS flooded decide he doesn't want that and stop | |
594 | the flooder right at his own server (the server of the flooder). | |
595 | This is a new command, and the clients will need unfortunately a few | |
596 | lines in their .ircrc before it can work. | |
597 | Moreover, before this works, ALL servers must have .U3. | |
598 | ||
599 | The lines I use at the moment are: | |
600 | ||
601 | ALIAS SILENCE QUOTE SILENCE | |
602 | ALIAS SILE QUOTE SILENCE | |
603 | ON ^RAW_IRC "% SILENCE %" echo *** $* | |
604 | ||
605 | It turns out that some auto-rejoin on kick lines, like Davemans toolbox, | |
606 | disables the use of ON RAW_IRC, or at least makes it work incorrectly. | |
607 | You should disable this auto-rejoin line and you could add the one I use | |
608 | instead: | |
609 | ||
610 | ON ^RAW_IRC "% KICK % % *" { | |
611 | IF ([$3]==[$N]) { | |
612 | //QUOTE JOIN $2 | |
613 | ECHO $MID(11 5 $STIME($TIME())) * You have been kicked off channel $2 by $LEFT($INDEX(! $0) $0) \($MID(1 256 $4-)\) } { | |
614 | ECHO $MID(11 5 $STIME($TIME())) * $3 has been kicked off channel $2 by $LEFT($INDEX(! $0) $0) \($MID(1 256 $4-)\) } | |
615 | } | |
616 | ||
617 | which are 6 lines, not 8. | |
618 | ||
619 | The way the silence patch works is as follows: | |
620 | ||
621 | When you add a silence mask (using the same user friendly mask fixing) | |
622 | like: | |
623 | ||
624 | /SILENCE Tsunami*@ | |
625 | ||
626 | It will echo back to you how it is added: | |
627 | ||
628 | *** Run!Daryl@sg.tn.tudelft.nl SILENCE +*!Tsunami*@* | |
629 | ||
630 | Note that there is a '+' infront of the mask now. | |
631 | You can also type: | |
632 | ||
633 | /SILENCE +bot* | |
634 | ||
635 | *** Run!Daryl@sg.tn.tudelft.nl SILENCE +bot*!*@* | |
636 | ||
637 | If you want to silence one particular nick, you must add the '+', because | |
638 | when you do: | |
639 | ||
640 | /SILENCE nick | |
641 | ||
642 | and 'nick' exists, you will get the silence list of nick. Just using | |
643 | /SILENCE gives your own silence list: | |
644 | ||
645 | *** Run bot*!*@* | |
646 | *** Run *!Tsunami*@* | |
647 | *** End of Silence List | |
648 | ||
649 | However, check the silence list of someone ELSE make only really sense | |
650 | when you already did sent a message to this person. Because a silence | |
651 | mask only propagates to the server of the flooder when it is actually | |
652 | necessary. For instance: You can add up to 5 silence masks and delete them | |
653 | again and it will only be local to your own server. Only when someone | |
654 | would message you, matching a mask, the mask propagates to the server of | |
655 | the flooder. And stays there till you signoff, or till you delete it. | |
656 | If you delete a mask, it follows the same path as the +masks... | |
657 | ||
658 | As a result of this, +s lusers and opers will see the message: | |
659 | ||
660 | *** SILENCE : Unknown command (from Lausanne.CH.EU.UnderNet.org) | |
661 | ||
662 | When someone from *behind* a non .U3 server sends you a message | |
663 | (Lausanne is this case). So, you will STILL be flooded ;) UNTIL ALL | |
664 | servers are upgraded... (Or must do -s, but at least the net is flooded). | |
665 | ||
666 | ||
667 | To: wastelanders@rush.cc.edu | |
668 | From: agifford@sci.dixie.edu (Aaron Gifford) | |
669 | Subject: HELP with HELP for SILENCE | |
670 | Status: RO | |
671 | ||
672 | Hey, here's a VERY VERY VERY rough draft of a HELP entry for SILENCE, | |
673 | assuming it becomes a new command for ircII and not a replacement for | |
674 | IGNORE either via new code, or aliases like: | |
675 | ALIAS SILENCE { QUOTE SILENCE $* } | |
676 | ||
677 | Anyway, PLEASE PLEASE PLEASE alter, modify, correct, add, hack-up, etc this | |
678 | rough draft and send me your alterations. I just typed this up VERY | |
679 | quickly because StGeorge is now running irc2.8.19.U3.1. The bug I mention | |
680 | in the file will hopefully disappear very soon, so that text will have to | |
681 | do likewise and vanish. :) | |
682 | ||
683 | Here it is, draft #1 HELP for SILENCE: | |
684 | ||
685 | Usage: SILENCE [<nick>] | |
686 | SILENCE [+|-<pattern>] | |
687 | ||
688 | SILENCE allows you to TOTALLY ignore all private messages (PRIVMSG's) | |
689 | and notices (NOTICE's) from any user whose nick!user@host matches | |
690 | the <pattern> parameter. The characters * and ? can be used | |
691 | as wildcards in the pattern. | |
692 | ||
693 | If you wanted to ignore all users from "somewhere.com" you would use: | |
694 | SILENCE +*!*@somewhere.com | |
695 | ||
696 | To ignore some with the nickname "Jerk" you would use: | |
697 | SILENCE +Jerk | |
698 | NOTE: The server will complete the pattern, storing it as "Jerk!*@*" | |
699 | ||
700 | The only drawback of just SILENCE'ing someone by nickname only is | |
701 | that the user could quickly change nicknames to avoid your pattern. | |
702 | ||
703 | To remove a pattern, use a - before the pattern you want to remove. | |
704 | When the command is used without any parameters, the server will list | |
705 | all stored patterns you are currently ignoring with the SILENCE | |
706 | command. | |
707 | ||
708 | When used in the first form listed, you will see the SILENCE list for | |
709 | the specified user. This list is not necessarily complete nor accurate | |
710 | because of how servers share SILENCE information internally. You can | |
711 | check to see if someone is ignoring you with SILENCE by first sending | |
712 | that user a private message, then using the command to see the user's | |
713 | SILENCE list. | |
714 | ||
715 | Currently there is a bug in the servers (hopefully to be fixed soon) | |
716 | that will add the nickname you specify to your SILENCE list when you | |
717 | attempt to see that user's SILENCE list if that user is not currently | |
718 | online. | |
719 | ||
720 | Because SILENCE is a part of the IRC server protocol (on the Undernet) | |
721 | it works much more efficiently than IGNORE, but is limited to a very | |
722 | brief list of patterns. Also, you don't have as may options as you | |
723 | do with IGNORE. If a user is flooding you, SILENCE is many times | |
724 | more efficient than IGNORE because the offending user's PRIMSG's or | |
725 | NOTICE's (including CTCP) are stopped at the server and never even | |
726 | sent to your client. | |
727 | ||
728 | See Also: | |
729 | IGNORE | |
730 | ||
731 | ||
732 | ||
733 | ||
734 | From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl> | |
735 | Subject: Re: HELP with HELP for SILENCE | |
736 | To: agifford@sci.dixie.edu (Aaron Gifford) (Aaron Gifford) | |
737 | Date: Wed, 25 May 94 12:29:37 METDST | |
738 | Cc: wastelanders@rush.cc.edu (New Wastelanders MailingList) | |
739 | In-Reply-To: <9405250313.AA18446@sci.dixie.edu>; from "Aaron Gifford" at May 24, 94 9:20 pm | |
740 | Mailer: Elm [revision: 66.33] | |
741 | Status: RO | |
742 | ||
743 | > Here it is, draft #1 HELP for SILENCE: | |
744 | > | |
745 | > Usage: SILENCE [<nick>] | |
746 | > SILENCE [+|-<pattern>] | |
747 | > | |
748 | ||
749 | As it is now (I do not consider what you mentioned as a bug, I was aware | |
750 | of this effect and didn't choose to alter it), it really is: | |
751 | ||
752 | Usage: SILENCE [+|-]<pattern> | |
753 | Or : SILENCE <nick> | |
754 | ||
755 | When you leave the '+|-' away A '+' is assumed. | |
756 | ||
757 | The second possibility allows you to check your own silence lists, or | |
758 | allows to check if you are silenced by someone after you did message | |
759 | him but didn't get a respond (did ping him for instance). | |
760 | Indeed, this could be interpreted as a pattern, when <nick> doesn't | |
761 | exists. | |
762 | ||
763 | > If you wanted to ignore all users from "somewhere.com" you would use: | |
764 | > SILENCE +*!*@somewhere.com | |
765 | ||
766 | SILENCE somewhere.com | |
767 | ||
768 | would do. | |
769 | ||
770 | > When used in the first form listed, you will see the SILENCE list for | |
771 | > the specified user. This list is not necessarily complete nor accurate | |
772 | > because of how servers share SILENCE information internally. You can | |
773 | > check to see if someone is ignoring you with SILENCE by first sending | |
774 | > that user a private message, then using the command to see the user's | |
775 | > SILENCE list. | |
776 | ||
777 | Mention that a EVAL CTCP <nick> PING $TIME() is better... | |
778 | It would not be necessary to do the silence if the ping returns... | |
779 | To determine between huge lag and silence, you have to do the silence | |
780 | check after that. | |
781 | If you add something like this in the manual, people will automatically | |
782 | wait a while after the 'message' (ping), so that the servers have time | |
783 | to send the silence mask back. Otherwise they might think they can do | |
784 | a quick msg+silence at the same time. Nah... Not too important, unless | |
785 | with huge lag + silence combination. | |
786 | ||
787 | > | |
788 | > Currently there is a bug in the servers (hopefully to be fixed soon) | |
789 | > that will add the nickname you specify to your SILENCE list when you | |
790 | > attempt to see that user's SILENCE list if that user is not currently | |
791 | > online. | |
792 | ||
793 | I didn't consider this as too bad... | |
794 | But if people want it, I can change it so that you MUST add a '+' to | |
795 | add a mask that doesn't contain a '.', '!' or '@'. | |
796 | That would lead to 2.8.19.U3.2 and a very tiny patch for the people who | |
797 | already compiled .U3 | |
798 | ||
799 | Run | |
800 | ||
801 | ||
802 | ============================================================================= | |
803 | U3 - required additions to .ircrc | |
804 | ============================================================================= | |
805 | ||
806 | ||
807 | From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl> | |
808 | Subject: Re: .ircrc codes for the new patches :) | |
809 | To: lamberdc@dad.cs.tuns.ca | |
810 | Date: Mon, 23 May 94 11:41:31 METDST | |
811 | Cc: wastelanders@rush.cc.edu (New Wastelanders MailingList) | |
812 | In-Reply-To: <9405222118.AA02415@dad.cs.tuns.ca>; from "Donald "WHIZZARD" Lambert" at May 22, 94 6:18 pm | |
813 | Mailer: Elm [revision: 66.33] | |
814 | Status: RO | |
815 | ||
816 | > hiya All | |
817 | > I was wondering if some one could send me a copy of the script/ | |
818 | > for the new patches including the ban , topic and client connecting patches. | |
819 | > | |
820 | > And whatever is now out with the new .19 code :) | |
821 | > | |
822 | > thanks | |
823 | > | |
824 | > -- Donnie | |
825 | > | |
826 | > aka WHIZZARD | |
827 | ||
828 | The ftp.undernet.org:/pub/undernet/servers/Patches/README file: | |
829 | ||
830 | These are lines you need to add to your .ircrc file in order | |
831 | to use all posibilities .U3 profides you: | |
832 | ||
833 | To see when a channel was created: | |
834 | ||
835 | On ^329 * echo *** $1 : created $stime($2) | |
836 | ||
837 | When your server has the .ban patch use this to see who did a ban and when: | |
838 | ||
839 | On ^367 * if ([$4] != []) {echo *** $1 \($3 - $stime($4)) $2} {echo *** $1-} | |
840 | ||
841 | --------------------------- | |
842 | When ALL servers upgraded to .U3, you can use this command: | |
843 | ||
844 | ALIAS SILENCE QUOTE SILENCE | |
845 | On ^RAW_IRC "% SILENCE %" echo *** $* | |
846 | ||
847 | Use this as: | |
848 | /SILENCE +mask | |
849 | ||
850 | To add 'mask' to your silence list (will completely stop all private | |
851 | messages from people matching 'mask' with their nick!user@host). | |
852 | You can VIEW your silence list by typing: | |
853 | /SILENCE | |
854 | ||
855 | If you message someone and he doesn't react (like with ping), then you | |
856 | can check if you match a silence mask he added by viewing his silence list | |
857 | with: | |
858 | /SILENCE nick | |
859 | ||
860 | A mask can be deleted by using the command: | |
861 | /SILENCE -mask | |
862 | ||
863 | When the some messages you from behind a NON-.U3 server you will not | |
864 | receive his message but the line: | |
865 | *** Unknown command (SILENCE) (From server.name.undernet.org) | |
866 | instead, so you will still be flooded. | |
867 | We hope all servers will be upgraded within a few months. | |
868 | ||
869 | ------ | |
870 | And my ircd.motd from Delft* : | |
871 | ||
872 | *%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*% | |
873 | N E W : - This server now runs the official released | |
874 | beta version 2.8.19.U3.1.ban | |
875 | For you as users this means that: | |
876 | -More security : .U3 contains the .TSpre8 patch with | |
877 | disallows even ADMINs of servers to hack op on your | |
878 | channel with a nick, most server modes are detected. | |
879 | -The possibility to see the *creationtime* of a channel | |
880 | (used with the TimeStamp (TS) protocol - unique on | |
881 | undernet (disables the possibility of 'net.riding')) | |
882 | -The possibility to stop EVERY kind of channel flooding | |
883 | by *banning* someone : Now a ban stops not only | |
884 | part/join floods, but also message floods and even | |
885 | nick floods! | |
886 | -The possibility to see who did when a certain ban. | |
887 | -The possibility to stop anyone flooding you with | |
888 | any kind of private messages at his *own* server! | |
889 | (This will only work when ALL servers have upgraded) | |
890 | To be able to use all of this, ftp to sg.tn.tudelft.nl | |
891 | login: ftp ; password : anything ; file: /pub/README | |
892 | Put those lines in your .ircrc initialisation file ! | |
893 | Have fun, Run. | |
894 | ||
895 | ---- | |
896 | ||
897 | Run | |
898 | ||
899 | ============================================================================= | |
900 | U3.1 -> U3.2 | |
901 | ============================================================================= | |
902 | ||
903 | ||
904 | From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl> | |
905 | Subject: *BUG* .U3.1 found !! | |
906 | To: wastelanders@rush.cc.edu (New Wastelanders MailingList) | |
907 | Date: Wed, 25 May 94 16:45:39 METDST | |
908 | In-Reply-To: <457.9405250732@ccws-09.brunel.ac.uk>; from "James T Lowe" at May 25, 94 8:32 am | |
909 | Mailer: Elm [revision: 66.33] | |
910 | Status: RO | |
911 | ||
912 | > :-> | |
913 | > :-> Hiya.. | |
914 | > :-> | |
915 | > :-> Here's what I observed tonight: | |
916 | > :-> | |
917 | > :-> *** Mmmm (mandar@roosevelt.ecn.uoknor.edu) has joined channel #friendly | |
918 | > :-> *** Users on #friendly: @Mmmm | |
919 | > :-> *** Mode change "-o Mmmm" on channel #friendly by Uxbridge.* | |
920 | > | |
921 | > Not surprising : | |
922 | > | |
923 | > #friendly RedRum H* cs93jtl@ccws-09.brunel.ac.uk | |
924 | > #friendly Emmy H lamphear@cheshire.oxy.edu | |
925 | > #friendly ChemBot H@ cmrobert@hellcat.ecn.uoknor.edu | |
926 | > | |
927 | > | |
928 | > | |
929 | > >From Norman : | |
930 | > | |
931 | > *** ChemBot is cmrobert@hellcat.ecn.uoknor.edu (Charles Michael Roberts) | |
932 | > *** on channels: @#ChatZone | |
933 | > *** on irc via server Norman.OK.US.undernet.org | |
934 | > *** ChemBot has been idle 10 minutes | |
935 | > | |
936 | > | |
937 | > and from Uxbridge : | |
938 | > | |
939 | > ** ChemBot is cmrobert@hellcat.ecn.uoknor.edu (Charles Michael Roberts) | |
940 | > *** on channels: @#chatZone @#friendly | |
941 | > *** on irc via server Norman.OK.US.undernet.org | |
942 | > | |
943 | > :-> But, | |
944 | > :-> | |
945 | > :-> *** Mmmm has left channel #friendly | |
946 | > :-> *** Mmmm (mandar@roosevelt.ecn.uoknor.edu) has joined channel #test | |
947 | > :-> *** Users on #test: @Mmmm | |
948 | > :-> | |
949 | > :-> works fine.. | |
950 | > :-> | |
951 | > :-> Is this due to the U lines? Uworld was in no way involved though :-( | |
952 | > :-> | |
953 | > :-> I personally feel that uxbridge's retaining timestamps of old channels - | |
954 | > :-> Run, can ya take a look asap. It can prove most distressing for our users :( | |
955 | > :-> | |
956 | > :-> Thanks!! | |
957 | > :-> | |
958 | > :-> Mmmm | |
959 | > | |
960 | > | |
961 | ||
962 | Weeehhhw, yeah a real bug :/ | |
963 | ||
964 | RedRum and I looked for it for almost 4 hours before it was found... | |
965 | ||
966 | I will release .U3.2 and a patch for .U3.1-U3.2 asap... | |
967 | ||
968 | Description of bug: | |
969 | ||
970 | When someone gets kicked (and doesn't (try to) rejoin), it is flagged | |
971 | as a zombie. After a net-break, users are mutual re-joined on both | |
972 | sides of the net. It turned out that a zombie is also rejoined after | |
973 | a net rejoin. | |
974 | ||
975 | What happened with ChemBot: | |
976 | ||
977 | ChemBot was on #friendly via Norman (non TSpre8). It was banned and then | |
978 | kicked. It tried to rejoin, but Norman didn't allow that (ban). | |
979 | Delft never saw this try, and ChemBot stayed as a zombie on #friendly. | |
980 | Then Delft-UxBridge broke and reconnected... Delft did send a JOIN for | |
981 | ChemBot to UxBridge, ending up in a nick-desynced state. | |
982 | When Mmmm joined #friendly, he was the first on #friendly on all of the | |
983 | net except UxBridge... He was opped by Norman, but that is considered | |
984 | as a HACK by UxBridge and was bounced (ChemBot was still there *with* | |
985 | ops (those flags aren't reset when someone is marked zombie)). | |
986 | The second time Mmmm joined, he again got ops from Norman which now | |
987 | was accepted by UxBridge because this +o could be a BOUNCE of the de-op | |
988 | by UxBridge (Generating a BOUNCE or HACK: notice on UxBridge). | |
989 | ||
990 | Run | |
991 | ||
992 | ||
993 | ||
994 | From: Carlo Kid - Runaway <carlo@sg.tn.tudelft.nl> | |
995 | Subject: Release 2.8.19.U3.2 | |
996 | To: wastelanders@rush.cc.edu (New Wastelanders MailingList) | |
997 | Date: Wed, 25 May 94 23:30:57 METDST | |
998 | Mailer: Elm [revision: 66.33] | |
999 | Status: RO | |
1000 | ||
1001 | Hi all, | |
1002 | ||
1003 | I released 2.8.19.U3.2 | |
1004 | ||
1005 | Fixed: | |
1006 | ||
1007 | - Rejoining of zombies after net break :/ (ChemBot case) | |
1008 | - Silence command now give: No such nick, when doing /silence nick | |
1009 | - I fixed the way a kick is handle, because in a last minute | |
1010 | thought I realized MURC would get trouble otherwise, see below. | |
1011 | ||
1012 | As usual you can get it from ftp.undernet.org:/pub/undernet/servers | |
1013 | ||
1014 | Patches/irc2.8.19.U3.1-2.patch : If you already had .U3.1 | |
1015 | ||
1016 | irc2.8.19.U3.2.tar.gz : If start from scratch (DO SO!!!) | |
1017 | ||
1018 | For those who use the irc2.8.19.U3.1-2.patch ... | |
1019 | ||
1020 | ------------------------------------------ | |
1021 | *** EDIT include/patchlevel.h !!!!!!!! *** | |
1022 | ------------------------------------------ | |
1023 | ||
1024 | This patch will change your version to irc2.8.19.U3.2 so if you run | |
1025 | .ban EDIT it !!! | |
1026 | ||
1027 | ========================================================================= | |
1028 | ||
1029 | The change in KICK handling is as follows: | |
1030 | ||
1031 | - A kick received from a local client, or for a local client or | |
1032 | from a direction in which the kicked client is located, is | |
1033 | simply handled as before: completely removed from channel, no zombie. | |
1034 | This means also that there is no client-server protocol change anymore: | |
1035 | /who, /whois and /names won't change. | |
1036 | ||
1037 | - A kick received for a local client originating from a remote client | |
1038 | lets the server sent a PART upstream. Since this results for non TSpre8 | |
1039 | servers in a remote "You're not on that channel" message, this | |
1040 | message is suppressed (would never occur anyway now we are completely | |
1041 | synced). | |
1042 | ||
1043 | The reason why this was needed is mainly because MURC constantly kicks | |
1044 | people who have auto-rejoin disabled from different channels. With U3.1 | |
1045 | they would get into problems after ten channels (needed to send extra | |
1046 | PART's). | |
1047 | ||
1048 | Run | |
1049 | ||
1050 | -- | |
1051 | ------------------------------------------------------------------------------- | |
1052 | | carlo@sg.tn.tudelft.nl | Run @ IRC | | |
1053 | | | Admin of Delft.NL.EU.undernet.org | | |
1054 | | * Don't expect anything of live, | and Ircserver.et.tudelft.nl | | |
1055 | | or you'll miss all the rest of it.| | | |
1056 | ------------------------------------------------------------------------------- | |
1057 | ||
1058 | ||
1059 | ||
1060 | ============================================================================= | |
1061 | U3->U4, ANTI NICK COLLIDE | |
1062 | ============================================================================= | |
1063 | Author: Carlo, carlo@sg.tn.tudelft.nl, Run on IRC. | |
1064 | ||
1065 | Hi all... | |
1066 | ||
1067 | After we dealt with channel msg-, join/part- and nick-floods (.bquiet), | |
1068 | and with private message flooding (.silence), now in a sort of follow up | |
1069 | to the anti net.break.ride (.TSpre7) and anti admin.hacks (TSpre8) we are | |
1070 | about to deal with one of the last vulnerabilities of our net: | |
1071 | nick-collision bots. | |
1072 | Called .anc (anti nick collision). | |
1073 | - - - | |
1074 | ||
1075 | Socially spoken it does the following (I hope): | |
1076 | ||
1077 | - Only kills the RIGHT person, when a nick collision occurs. | |
1078 | ||
1079 | This would mean: | |
1080 | ||
1081 | A) If someone tries to harash by connecting to servers that just broke off | |
1082 | and then take the nick of a person on the other side, both would be | |
1083 | killed on reconnection. But with the .anc patch on both connecting servers, | |
1084 | only the net.break rider will be killed. | |
1085 | ||
1086 | B) Secondly, when your server (or side) breaks off and you connect to some | |
1087 | other server on the other side, it happens sometimes that due to lag you get | |
1088 | killed by a nick collision after reconnection of the net. | |
1089 | ||
1090 | A and B differ strongly in the sense that in case A the *new* -the youngest- | |
1091 | nick must be killed, while in case B the *old* (lagged) nick must be | |
1092 | killed. | |
1093 | Technically this means that we have to look at the user@host.name too. | |
1094 | This gives rise to some incompatible changes, and therefor, this patch | |
1095 | must be done in two steps: First we deal with the nick-collision bots and | |
1096 | make the server compatible with both - the old and new protocol. And then | |
1097 | once all server upgraded, we deal with the last step: the nick collision | |
1098 | with yourself. | |
1099 | ||
1100 | In the future there will be a third possible condition in which we can have | |
1101 | a nick collision: (long example follows, can be skipped) | |
1102 | ||
1103 | C) The net breaks, and reconnects else where, and somehow a race condition | |
1104 | occurs between the 'SERVER' messages of the servers of one side. | |
1105 | For example: | |
1106 | ||
1107 | Servers: Part A Part B1 PartB2 | |
1108 | Nicks a(A),b(B) a(A),b(B) a(A),b(B) | |
1109 | Part A breaks off Part B: | |
1110 | <-- :b QUIT --> :a QUIT | |
1111 | <-- SQUIT serversB --> SQUIT serversA | |
1112 | Result: a(A) b(B) b(B) | |
1113 | A reconnects to Part B1, but immedeately breaks off again: | |
1114 | -->SERVERs A | |
1115 | -->NICK a | |
1116 | -->:a USER ... | |
1117 | Break: | |
1118 | -->SERVERs A | |
1119 | -->NICK a | |
1120 | -->:a USER ... | |
1121 | --> :a QUIT | |
1122 | --> SQUIT serversA | |
1123 | A connects to part B2, note that 'part B1 --> part B2' is lagged and the | |
1124 | "SERVERs A ... etc" didn't arrive yet on partB2. | |
1125 | Servers: Part B1 Part B2 Part A | |
1126 | Nicks: b(B) b(B) a(A) | |
1127 | -->SERVERs A | |
1128 | -->NICK a | |
1129 | -->:a USER ... | |
1130 | --> :a QUIT | |
1131 | --> SQUIT serversA | |
1132 | --> SERVERs B | |
1133 | --> NICK b | |
1134 | --> :b USER ... | |
1135 | <-- SERVERs A | |
1136 | <-- NICK a | |
1137 | <-- :a USER ... | |
1138 | Result *before* the lagged messages arive on Part B2: | |
1139 | Nicks: b(B) b(B),a(A) b(B),a(A) | |
1140 | -->SERVERs A | |
1141 | -->NICK a | |
1142 | -->:a USER ... | |
1143 | -->:a QUIT | |
1144 | -->SQUIT serversA | |
1145 | And when the lagged messages arrive on Part B2, the | |
1146 | 'SERVERs A' get all ignored: "server exists", even more, Part B2 disconnects | |
1147 | Part B1... :/. Now we are going to deal with the "server exists" problem | |
1148 | *once* (attaching a timestamp to SERVER I think), in which case 'SERVERs A' | |
1149 | would only be ignored by Part B2. Then the 'NICK a' would cause a nick | |
1150 | collision with 1) Same user@host.name, 2) same server A, and 3) same | |
1151 | nick-TS ! This means: We need to ignore 'NICK nick' when is has the same | |
1152 | TimeStamp and the same user@host. But when the user@host differ, two people | |
1153 | signed on at exactly the same time with the same nick and we must kill | |
1154 | *both* to avoid a desync. | |
1155 | ---- | |
1156 | ||
1157 | How to handle a nick collision, general | |
1158 | --------------------------------------- | |
1159 | ||
1160 | Up till now when a nick collision occurs, both nicks (when a nick change | |
1161 | from 'old' to 'new' is involved) are KILLed in ALL directions.. wiped off the | |
1162 | net thus. | |
1163 | But even with wiping off the net in mind, it doesn't make sense to kill in | |
1164 | old direction, it is sufficient to deal with "our side" of the net, because | |
1165 | every nick collision occurs on two servers, both can deal with their side. | |
1166 | As an example: | |
1167 | ||
1168 | Servers: A B | |
1169 | Nicks: a(A) a(B) | |
1170 | Reconnection: | |
1171 | <-- NICK a | |
1172 | NICK a --> | |
1173 | ||
1174 | As you see, if A receives the 'NICK a' from B, it only has to deal with | |
1175 | its own side, because it is certain that B will receive the 'NICK a' from | |
1176 | A and handle it too as a nick collision (and therefore this 'NICK a' *is* | |
1177 | already a 'KILL' message). | |
1178 | ||
1179 | Thus, when we receive a 'NICK' that gives rise to the need of purging | |
1180 | a nick on *our* side, we deal with it by doing: | |
1181 | sendto_serv_butone(cptr,":%s KILL ... | |
1182 | which sends the KILL to all server connections except the link 'cptr' that | |
1183 | generated the nick collision. | |
1184 | Also then we have to destroy the memory usage of the killed client on our | |
1185 | own server, and disconnect him if it is ours, so we call exit_client(). | |
1186 | ||
1187 | Summary so far | |
1188 | -------------- | |
1189 | ||
1190 | Ok, we discussed when to kill who. Resulting rules are: | |
1191 | ||
1192 | We receive a "NICK new" or ":old NICK new" from a server direction, and | |
1193 | we already have a registered 'new'. Then we have a nick collison and deal | |
1194 | with it as follows: | |
1195 | 1) If the user@host differ, | |
1196 | and our 'new' is younger or equal, KILL our 'new'. | |
1197 | and our 'new' is older, ignore the 'NICK new', but kill 'old' on | |
1198 | our side if it was a nick change. | |
1199 | 2) If user@host is the same: | |
1200 | and our 'new' is older, KILL our 'new'. | |
1201 | and our 'new' is younger, ignore the 'NICK new', but kill | |
1202 | 'old' on our side if it was a nick change. | |
1203 | and our 'new' is equal, KILL our 'new', | |
1204 | and kill 'old' on our side too if it was a nick change. | |
1205 | ||
1206 | Remarks: | |
1207 | The last case, where have a ':old NICK new' collission with | |
1208 | the same user@host and TimeStamp, can't be case C), but it | |
1209 | is possible that *we* did send a 'NICK new', and the server at | |
1210 | the other side kills 'old' off... So we have to do it too. | |
1211 | With this protocol we *ignore* 'NICK new' message, but of course | |
1212 | in most cases they will be followed by at least a ':new USER ...' and | |
1213 | probably | |
1214 | more like ':new JOIN #...'. This would cause 'Fake direction' errors and | |
1215 | the current protocol KILLs such a nick in *ALL* direction (???). Now, we | |
1216 | DON'T want to KILL the nick in the right direction do we? And killing the | |
1217 | fake direction nick makes no sense: it will be killed automatically due to | |
1218 | the fact we did send a 'NICK new' in that direction. Thus: we can/have to | |
1219 | remove the Fake Direction kills. | |
1220 | Of course, when we receive a 'NICK new hopcount :TimeStamp', we | |
1221 | *can't* compare with the user@host, because it takes some time before we | |
1222 | will receive the 'USER'... We also can't store the nick, because it must | |
1223 | be unique. To solve this, we need to change the protocol so that 'NICK new' | |
1224 | contains all information and the USER message will be redundant and removed | |
1225 | in a later patch. This also reduces net.bursts. | |
1226 | ||
1227 | Attaching a TimeStamp (TS) to nicks | |
1228 | ----------------------------------- | |
1229 | ||
1230 | Whenever someone takes a new nick, which is available of course, either by | |
1231 | changing nick or by signing on, the local server attaches a TimeStamp (TS) | |
1232 | to the nick. Now there will be sent: | |
1233 | ||
1234 | NICK new hopcount TS user host.name server.name :Real name | |
1235 | or | |
1236 | :old NICK new :TS | |
1237 | ||
1238 | This is 100% compatible with the existing protocol. | |
1239 | ||
1240 | When a server receives such a nick from a neighbouring server it copies the | |
1241 | TS, keeping track of the local change time. (When not all servers have | |
1242 | upgraded, and no TS is received, the .anc server will fill in the time | |
1243 | itself - being a slight advantage over keeping it 0. It also will assume | |
1244 | that the host.names are equal or not equal resulting a as many kills as | |
1245 | needed in the worst case). | |
1246 | ||
1247 | ||
1248 | Examples | |
1249 | -------- | |
1250 | ||
1251 | Servers: A B | |
1252 | Nicks: a(A),b(B) b(B),a(A) | |
1253 | Both change simultaneously to nick 'c', but 'a' slightly faster (at time=1, | |
1254 | and b at time=2): | |
1255 | c(A),b(B) c(B),a(A) | |
1256 | -> :a NICK c :1 | |
1257 | :b NICK c :2 <- | |
1258 | Then A receives a ':b NICK c :2' where 2 > 1, and KILLs b on its own side. | |
1259 | B however receives ':a NICK c :1' where 1 < 2, and KILLs c on its own side. | |
1260 | Result: c(A) c(A) | |
1261 | ||
1262 | Due to 'lag', more :c PRIVMSG .. from B to A can follow, resulting in a | |
1263 | fake direction. 'A' will simply ignore them and not kill c (kills for | |
1264 | fake direction are nonsense anyway). | |
1265 | ||
1266 | In the case that someone signs on, taking the same nick as a nick change | |
1267 | we have almost the same: | |
1268 | ||
1269 | Servers: A B | |
1270 | Nicks: a(A) a(A) | |
1271 | 'a' changes simultaneously to nick 'c', but slightly faster (at time=1), | |
1272 | as a new 'c' signs on at B (time=2). | |
1273 | c(A) a(A),c(B) | |
1274 | -> :a NICK c :1 | |
1275 | NICK c 1 :2 <- | |
1276 | Then A receives a 'NICK c 1 :2' where 2 > 1, and ignores it simply. | |
1277 | B however receives ':a NICK c :1' where 1 < 2, and KILLs c on its own side. | |
1278 | Result: c(A) c(A) | |
1279 | ||
1280 | If the new 'c' was a little bit earlier, we get: | |
1281 | ||
1282 | Servers: A B | |
1283 | Nicks: a(A) a(A) | |
1284 | 'a' changes simultaneously to nick 'c', and slightly slower (at time=2), | |
1285 | as a new 'c' signs on at B (time=1). | |
1286 | c(A) a(A),c(B) | |
1287 | -> :a NICK c :2 | |
1288 | NICK c 1 :1 <- | |
1289 | Then A receives a 'NICK c 1 :1' where 1 < 2, and KILLs c on its own side. | |
1290 | B however receives ':a NICK c :2' where 2 > 1, and KILLs a on its own side. | |
1291 | ||
1292 | Result: c(B) c(B) | |
1293 | ||
1294 | Last case, two people sign on (or during a net reconnection): | |
1295 | ||
1296 | Server: A B | |
1297 | Sign on: c(A) c(B) | |
1298 | -> NICK c 1 :1 | |
1299 | NICK c 1 :2 <- | |
1300 | Then A receives 'NICK c 1 :2' where 2 > 1, and ignores it. | |
1301 | and B receives a 'NICK c 1 :1' where 1 < 2, and KILLs c on its own side. | |
1302 | Result: c(A) c(A) | |
1303 | ||
1304 | Note: the above didn't take equal TS's into account, and I assumed | |
1305 | user@hosts to be different: the nick collision bot cases. | |
1306 | ||
1307 | A last possibility when someone starts hacking... a 'NICK new' twice | |
1308 | from the same direction, should not be accepted: we kill the earlier one | |
1309 | always. | |
1310 | ||
1311 | Compatibility problems | |
1312 | ---------------------- | |
1313 | ||
1314 | In the future, we want to also take 'user@host' into account... Therefor, | |
1315 | we need to start to ignore 'NICK new' and only act upon ':new USER ...'. | |
1316 | We can only do that if also 'USER contains the hopcount and TimeStamp'... | |
1317 | If we change the protocol immedeately to say: | |
1318 | :nick USER user host.name server.name hopcount TimeStamp :Real name | |
1319 | the 'hopcount' would be treated as realname, and we the rest would be | |
1320 | lost :( | |
1321 | ||
1322 | We can also transfer the info to 'NICK', with: | |
1323 | ||
1324 | :server.name NICK nick hopcount user host.name TimeStamp :Real name | |
1325 | ||
1326 | and later forget the USER message. Although someone lamer uses | |
1327 | the C source line " if (sptr == cptr) ..." in m_nick() to determine if | |
1328 | it was a 'NICK new' or a ':old NICK new' :/ Geesh (unlogical). He should | |
1329 | have used " if (IsServer(sptr)) ...". You would need three upgrade steps | |
1330 | or we will have to do with: | |
1331 | NICK nick hopcount user host.name server.name TimeStamp :Real name | |
1332 | ||
1333 | The nice thing about this is, that we can check how many parameters we | |
1334 | receive and then immedeately use the user@host if it is there... That way | |
1335 | the .acn will immedeately work once everyone upgraded once, and the second | |
1336 | step would only get rid of the 'USER' line between servers. | |
1337 | ||
1338 | Run | |
1339 | ||
1340 | ||
1341 | ============================================================================= | |
1342 | WALLOPS | |
1343 | ============================================================================= | |
1344 | Usage: /WALLOPS <message> | |
1345 | ||
1346 | Sends a message to IRC ops on-line. Remember that users who are /umode +w | |
1347 | can see wallops as well. | |
1348 | ||
1349 | ||
1350 | ============================================================================= | |
1351 | STATS W | |
1352 | ============================================================================= | |
1353 | Author: Michael Vanloon (michaelv@iastate.edu) - mlv on IRC | |
1354 | Help on /stats w : | |
1355 | ||
1356 | I've been working on something I think would be quite a useful | |
1357 | addition to the ircd. It keeps track of the average number of local | |
1358 | clients, total clients, and total connections (including servers) over | |
1359 | various periods of time, currently over the last minute, hour, day and | |
1360 | week. It is invoked by "/stats w server.name". You may try it | |
1361 | yourself by "/stats w *.iastate.edu". A sample from | |
1362 | ircserver.iastate.edu looks like this: | |
1363 | ||
1364 | *** Minute Hour Day Week Userload for: | |
1365 | *** 44.91 39.4 33 33 iastate.edu clients | |
1366 | *** 114.40 103.2 69 65 total clients | |
1367 | *** 120.40 109.0 73 70 total connections | |
1368 | *** * End of /STATS report | |
1369 | ||
1370 | I'm debating changing it to show average connections over the last | |
1371 | minute, hour, day, prev. day, and prev. day, as I think the data | |
1372 | doesn't change enough after that to really be useful to justify | |
1373 | keeping it over an entire week. | |
1374 | ||
1375 | On smaller, less used servers, it should add a negligible amount to | |
1376 | the resident memory consumed by the ircd. On a large hub such as the | |
1377 | *.bu.edu servers, penfold, or ircserver.iastate.edu, it might add as | |
1378 | much as 300k to the amount of memory the ircd attempts to keep | |
1379 | resident. The amount is determined solely by the number of | |
1380 | connects/disconnects the server processes over the span of time | |
1381 | measured. | |
1382 | ||
1383 | The code is bulletproof and has undergone *extensive* debugging and | |
1384 | testing before I announced it here. | |
1385 | ||
1386 | The reason I'm posting this is because I would like to know how many | |
1387 | people think this would be a useful addition to the server. In | |
1388 | addition, I'd like feedback on whether you think this should be a | |
1389 | standard part of the distributed server code. I think it should, but | |
1390 | Avalon wants me to post here first and see how others feel about it. | |
1391 | I'd appreciate your input. | |
1392 | ||
1393 | I will be making a patched 2.7.2 server available with this included, | |
1394 | for those who would like to have this and stability too. I'll also be | |
1395 | hooking it into 2.8.x soon, and giving it back to Av to include in the | |
1396 | standard 2.8 distribution as it matures, if he sees fit to do so. | |
1397 | ||
1398 | Thanks for your time... | |
1399 | ||
1400 | --Michael (mlv) | |
1401 | ||
1402 | IRC log started Wed Aug 18 21:52 | |
1403 | *** Value of LOG set to ON | |
1404 | *mlv* it's the usage of your server | |
1405 | *mlv* average number of users on your server over the last minute, hour, day, yesterday, and the day before | |
1406 | *mlv* local clients, total clients, and total connections (clients + servers) | |
1407 | -ircserver.iastate.edu- Minute Hour Day Yest. YYest. Userload for: | |
1408 | -ircserver.iastate.edu- 23.00 23.0 16 17 11 iastate.edu clients | |
1409 | -ircserver.iastate.edu- 52.00 52.8 37 35 23 total clients | |
1410 | -ircserver.iastate.edu- 61.00 61.7 45 42 21 total connections | |
1411 | -> *mlv* hmm...so iastate had 23 local clients in the last minute? | |
1412 | *mlv* right... in the last minute the average number of local users on our server was 23 | |
1413 | *mlv* 23.45 actually | |
1414 | -> *mlv* okie...gotcha... thanks :) one other thing | |
1415 | *mlv* there were an average of 23.1 local users on here over the last hour | |
1416 | *mlv* shoot | |
1417 | -> *mlv* is it possible to specify multiple domains? | |
1418 | -> *mlv* for e.g. uoknor.edu and okstate.edu cos those will be local to midway | |
1419 | *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 | |
1420 | -> *mlv* hmm... | |
1421 | *mlv* it's purely informational... i wouldn't worry about it, really that much | |
1422 | -> *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 | |
1423 | *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 | |
1424 | *mlv* that way you could put all the local domains into certain classes | |
1425 | *mlv* oh yeah... it's harmless, just weird | |
1426 | -> *mlv* that'll work :) | |
1427 | -> *mlv* well...thanks for your help....will have a look at the stats w patch when you're finished with it :) | |
1428 | IRC Log ended *** Wed Aug 18 22:22 | |
1429 | ||
1430 | ||
1431 | ============================================================================= | |
1432 | BAN/TOPIC/SIGNON INFO | |
1433 | ============================================================================= | |
1434 | Author: Paul Foley (pfoley@kauri.vuw.ac.nz) SIO on IRC | |
1435 | ||
1436 | Help on Ban/Topic/Signon : | |
1437 | ||
1438 | Since these patches allow the server to maintain additional information, the | |
1439 | server replies have been changes for the /mode #channel +b (#367), /whois | |
1440 | (#317) and an additional reply #333 has been added for topic info. The time | |
1441 | is returned as a long integer in UTC format in all cases. Since the existing | |
1442 | clients will ignore this additional information, you will need to either | |
1443 | patch the client, or in case you're using ircII, use the foll. /on statements | |
1444 | to take benefit of these patches : | |
1445 | ||
1446 | on ^367 * if ([$4] != []) {echo *** $1 \($3 - $stime($4)) $2} {echo *** $1-} | |
1447 | on ^333 * echo *** Topic for $1 set by $2 on $stime($3) | |
1448 | 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.} | |
1449 | ||
1450 | ||
1451 | Once you have done this, you can see info as follows: | |
1452 | /mode #wasteland +b | |
1453 | *** #wasteland (Mmmm - Thu Aug 19 04:44:24 1993) test!*@* | |
1454 | ||
1455 | /topic #wasteland | |
1456 | *** Topic for #wasteland: We all love Axl Rose! | |
1457 | *** Topic for #wasteland set by rbarnes on Thu Aug 19 04:26:56 1993 | |
1458 | ||
1459 | /whois Mmmm | |
1460 | *** Mmmm is mandar@essex.ecn.uoknor.edu (Mmmm,I get high with a little help | |
1461 | +from my friends) | |
1462 | *** on channels: @#wasteland | |
1463 | *** on irc via server essex.ecn.uoknor.edu (MIDWEST HUB..HELPS YOU GET THERE | |
1464 | +SOONER) | |
1465 | *** Mmmm is an IRC Operator | |
1466 | *** Mmmm has been idle for 454 seconds. Signon at Wed Aug 18 23:47:19 1993 | |
1467 | ||
1468 | ||
1469 | ============================================================================= | |
1470 | CLIENT NOTIFY | |
1471 | ============================================================================= | |
1472 | Authors: Patrick Ashmore (pda@engr.engr.uark.edu) - Twilight1 on IRC | |
1473 | Mandar Mirashi (mmmirash@mailhost.ecn.uoknor.edu) - Mmmm on IRC | |
1474 | Tony Vencill (vencill@iastate.edu) - Tony/Tonto on IRC | |
1475 | ||
1476 | Help on Client Notify: | |
1477 | ||
1478 | This patch allows all opers on your server to see clients connecting to your | |
1479 | server and disconnecting from it (with the reason why they disconnected). | |
1480 | This can help you identify troublesome clients, or redirect remote clients | |
1481 | to closer servers, or troubleshoot the reason why a client disconnected. | |
1482 | ||
1483 | A sample output: | |
1484 | ||
1485 | *** Notice -- Client connecting : Karll (agifford@sci.dixie.edu). | |
1486 | ||
1487 | *** Notice -- Client exiting : Karll (agifford@sci.dixie.edu) [Bad link?]. | |
1488 | ||
1489 | PS: if you wish to selectively decide when you wish to see these connection | |
1490 | notices, use the foll. script | |
1491 | ||
1492 | on ^server_notice "% % NOTICE -- CLIENT*" if (hideit != 1) {echo *** $2-} | |
1493 | alias show @ hideit = 0;echo *** You can now see clients connecting/exiting | |
1494 | alias hide @ hideit = 1;echo *** You will no longer see clients connecting/exiting | |
1495 | ||
1496 | If you then wish to not see client connects/exits when you are opered, simply | |
1497 | type /hide. If you wish to see them again, type /show. | |
1498 | ||
1499 | ============================================================================= | |
1500 | TRACE TIMES | |
1501 | ============================================================================= | |
1502 | Author: Tony Vencill (vencill@iastate.edu) - Tony/Tonto on IRC | |
1503 | ||
1504 | Help on Trace Time: | |
1505 | ||
1506 | This useful patch lets you identify the times since your server last | |
1507 | heard from any connected servers or clients. This time is displayed in | |
1508 | seconds, appended to each line of your /trace output. It can be very | |
1509 | helpful in identifying which servers are going to drop off or which | |
1510 | clients may ping timeout from your server. | |
1511 | ||
1512 | A sample output: | |
1513 | ||
1514 | /trace essex* | |
1515 | *** Serv [30] ==> 10S 8C cancun.caltech.edu *!*@essex.ecn.uoknor.edu 73 | |
1516 | *** Serv [30] ==> 9S 6C imageek.york.cuny.edu *!*@essex.ecn.uoknor.edu 27 | |
1517 | *** Serv [0] ==> 1S 0C inga1.acc.stolaf.edu[130.71.192.16] | |
1518 | +*!*@essex.ecn.uoknor.edu 58 | |
1519 | *** Serv [0] ==> 1S 0C shadow.acc.iit.edu *!*@essex.ecn.uoknor.edu 97 | |
1520 | *** Serv [0] ==> 1S 2C curie.ualr.edu Mmmm!mmmirash@essex.ecn.uoknor.edu 98 | |
1521 | *** Serv [0] ==> 1S 1C piaget.phys.ksu.edu *!*@essex.ecn.uoknor.edu 117 | |
1522 | *** Oper [0] ==> Mmmm[essex.ecn.uoknor.edu] 0 | |
1523 | *** Serv [50] ==> 1S 0C pv1629.vincent.iastate.edu *!*@essex.ecn.uoknor.edu 7 | |
1524 | *** Class 0 Entries linked: 6 | |
1525 | *** Class 50 Entries linked: 1 | |
1526 | *** Class 30 Entries linked: 2 | |
1527 | ||
1528 | ||
1529 | ============================================================================= | |
1530 | K- line comments | |
1531 | ============================================================================= | |
1532 | Author: Mandar Mirashi (mmmirash@mailhost.ecn.uoknor.edu) - Mmmm on IRC | |
1533 | ||
1534 | This extremely useful patch allows you to specify either a comment or an | |
1535 | interval in the 2nd field of the K line (instead of the previous format | |
1536 | of just a restricted interval). The "comment" can even be configured to | |
1537 | be a *file* name which can then be displayed to the client rejected via | |
1538 | the K line. All existing K lines will work as they are. This patch is | |
1539 | an *enhancement* to the K-lines. | |
1540 | ||
1541 | e.g. (of a comment field) | |
1542 | ||
1543 | K:*.sdsu.edu:Flooding.is.not.cool.lamer:masc0482 | |
1544 | ||
1545 | As far as possible, do not use a white space in the comment field, because | |
1546 | this breaks ircII's /stats k handling. You can use the period (.) or the | |
1547 | underscore instead (_). | |
1548 | ||
1549 | e.g (of a file to be output to a rejected client | |
1550 | - #define COMMENT_IS_FILE in config.h) | |
1551 | ||
1552 | K:*.netcom.com:/ecn/staff0/irc/servers/vinson/sorry.txt:* | |
1553 | ||
1554 | ||
1555 | ============================================================================= | |
1556 | OPER FAIL | |
1557 | ============================================================================= | |
1558 | Authors: Michael Vanloon (michaelv@iastate.edu) - mlv on IRC | |
1559 | Jon C Green (jcgreen@iastate.edu) - Jon2 on IRC | |
1560 | Bryan Collins (b@ctpm.org) - bwy on IRC | |
1561 | ||
1562 | This patch notifies you if someone tries to gain oper on your server and | |
1563 | fails. The notice goes out only to the operators on the server. | |
1564 | ||
1565 | *** Notice -- Failed OPER attempt by M (mmmirash@lincoln.ecn.uoknor.edu) | |
1566 | [crackit] | |
1567 | ||
1568 | ||
1569 | ============================================================================= | |
1570 | MIXED CASE | |
1571 | ============================================================================= | |
1572 | Authors: Michael Vanloon (michaelv@iastate.edu) - mlv on IRC | |
1573 | Jon C Green (jcgreen@iastate.edu) - Jon2 on IRC | |
1574 | ||
1575 | "Here's a patch mlv and I wrote that prevents clients with mixed-case usernames | |
1576 | from connecting. I don't know of many sites that allow mixed-case, so it | |
1577 | is effective for stopping many clonebot attacks and also stops many | |
1578 | would-be username hackers." - Jon2 | |
1579 | ||
1580 | This has been slightly modified by Mmmm to give an option of ignoring the | |
1581 | case of the first character if desired (useful for those PC users who | |
1582 | intuitevely enter their first name with the first letter capitalised). | |
1583 | ||
1584 | e.g. | |
1585 | *** Notice -- Invalid username: buankBOT[saucer.cc.umr.edu] | |
1586 | ||
1587 | ||
1588 | ============================================================================= | |
1589 | NOTE | |
1590 | ============================================================================= | |
1591 | ||
1592 | Usage: | |
1593 | \ 2NOTE\ 2 USER [&passwd] [+-flags] [+-maxtime] <nick!username@host> <msg> | |
1594 | - or SEND|SPY|FIND|WAITFOR|NEWS <same as USER args.> | |
1595 | * or SEND|SPY|FIND|WAITFOR|WALL|WALLOPS|DENY|NEWS|KEY <see USER args.> | |
1596 | \ 2NOTE\ 2 LS|COUNT|RM|LOG [&pwd][+-flags][#ID] <nick!user@host> [date] | |
1597 | \ 2NOTE\ 2 FLAG [&passwd] [+-flags] [#ID] <nick!username@host> <+-flags> | |
1598 | * \ 2NOTE\ 2 SENT [NAME|COUNT|USERS] <f.nick!f.name@host> <date> [RM] | |
1599 | - \ 2NOTE\ 2 STATS [MSM|MSW|MUM|MUW|MST|MSF|USED] | |
1600 | - \ 2NOTE\ 2 SENT [NAME|COUNT] | |
1601 | * \ 2NOTE\ 2 STATS [MSM|MSW|MUM|MUW|MST|MSF|USED|RESET] [value] | |
1602 | * \ 2NOTE\ 2 SAVE | |
1603 | ||
1604 | The Note system have two main functions: | |
1605 | 1. Let you send one line messages to irc users which | |
1606 | they will get when they next sign on to irc. | |
1607 | Example: NOTE SEND <nick> Hi, this is a note to you. | |
1608 | 2. Let you spy on people, to see when they sign on or off, | |
1609 | change nick name or join channels. | |
1610 | Example: NOTE SPY +100 <nick> (spy on nick for 100 days) | |
1611 | ||
1612 | You may fill in none or any of the arguments listed above, including | |
1613 | * or ? at any place, as nick@*.edu, !username, ni?k!username etc... | |
1614 | Other usefull features may be NOTE WAIT <nick>, making nick and | |
1615 | you get a message when you both are on at the same time. | |
1616 | ||
1617 | Note was developed 1990 by jarle@stud.cs.uit.no (Wizible on IRC). | |
1618 | ||
1619 | ||
1620 | *Usage: NOTE [<server>] ANTIWALL | |
1621 | * Switch off b flag for wall's which you have received on specified | |
1622 | * server. The person who queued the wall would be notified about | |
1623 | * the antiwall, and who requested this. | |
1624 | ||
1625 | ||
1626 | Usage: NOTE COUNT [&<passwd>] [+|-flags] [#<ID>] <nick!username@host> | |
1627 | Displays the number of messages sent from your nick and username. See | |
1628 | HELP LS for more info. See HELP FLAG for more info about flag setting. | |
1629 | ||
1630 | ||
1631 | *Usage: NOTE DENY [&<passwd>] [+|-<flags>] [+|-<maxtime>] | |
1632 | * <nick!user@host> <msg> | |
1633 | * DENY is an alias for USER +RZ (default max 1 day) | |
1634 | * This command makes it impossible for any matching recipient to | |
1635 | * queue any Note requests until timeout. | |
1636 | ||
1637 | ||
1638 | Usage: NOTE FIND [&<passwd>] [+|-<flags>] [+|-<maxtime>] | |
1639 | <nick!username@host> <msg> | |
1640 | FIND is an alias for USER +FLR (default max 1 day) | |
1641 | This command makes the server search for any matching recipient, and | |
1642 | send a note message back if this is found. If <msg> field is used, this | |
1643 | should specify the realname of the person to be searched for. Examples: | |
1644 | FIND -4 foo*!username@host | |
1645 | FIND @host Internet* | |
1646 | FIND nicky Annie* | |
1647 | FIND +7 * Annie* | |
1648 | ||
1649 | ||
1650 | Usage: NOTE FLAG [&<passwd>] [+|-<flags>] [#<ID>] | |
1651 | <nick!username@host> <+|-flags> | |
1652 | You can add or delete as many flags as you wish with +/-<flag>. | |
1653 | + switch the flag on, and - switch it off. Example: -S+RL | |
1654 | Following flags with its default set specified first are available: | |
1655 | -S > News flag for subscribing. | |
1656 | -M > Request is removed after you sign off. | |
1657 | -Q > Ignore request if recipient's first nick is equal to username. | |
1658 | -I > Ignore request if recipient is not on same server as request. | |
1659 | -W > Ignore request if recipient is not an operator. | |
1660 | -Y > Ignore request if sender is not on IRC. | |
1661 | -N > Let server send a note to you if message is delivered. | |
1662 | -D > Same as N, except you only get a message (no queued note to you). | |
1663 | -R > Repeat processing the request until timeout. | |
1664 | -F > Let server send note info for matching recipient(s). Any message | |
1665 | part specify what to match with the realname of the recipient. | |
1666 | -L > Same as F, except you only get a message (no queued note to you). | |
1667 | -C > Make sender's nicks be valid in all cases username@host is valid. | |
1668 | -V > Make sender's "nick*" be valid in all cases username@host is valid. | |
1669 | -X > Let server display if recipient signs on/off IRC or change | |
1670 | nickname. Any message specified is returned to sender. | |
1671 | -A > Show what server matching user is on using X flag. | |
1672 | -J > Show what channel matching user is on using X flag. | |
1673 | -U > Do not display nick-change using X flag. | |
1674 | -E > Ignore request if nick, name and host matches the message text | |
1675 | starting with any number of this format: 'nick!name@host nick!... ' | |
1676 | * -B > Send a message to every account who match the nick!user@host | |
1677 | * This creates a received list with flag H set. (see LS +h) | |
1678 | * -T > Send a message not all nicks on same accounts too using B flag. | |
1679 | * -K > Give keys to unlock privileged flags by setting that flags on. | |
1680 | * The recipient does also get privileges to queue unlimited | |
1681 | * numer of requests, list privileged flags and see all stats. | |
1682 | * -Z > Make it impossible for recipient to queue anything at all. | |
1683 | Other flags which are only displayed but can't be set by user: | |
1684 | -O > Request is queued by an operator. | |
1685 | -G > Notice message is generated by server. | |
1686 | - -B > Broadcasting message. | |
1687 | * -H > Flag list for who's received Broadcast message (B flag). | |
1688 | - Notice: Message is not sent to recipient using F, L, R or X flag. | |
1689 | - Using this flags, no message needs to be specified. | |
1690 | * Notice: Message is not sent to recip. using F, L, R, X, K, Z or H | |
1691 | * flag (except if B flag is set for R). For this flags, no msg. needed. | |
1692 | ||
1693 | Examples: | |
1694 | FLAG * +cj : Switch on c and j flag for all requests. | |
1695 | FLAG +x * +c : Switch on c flag for all req. which have x flag. | |
1696 | FLAG nick -c+j : Switch off c flag and which on j flag for nick | |
1697 | ||
1698 | ||
1699 | *Usage: NOTE KEY [&<passwd>] [+|-<flags>] [+|-<maxtime>] <nick!user@host> | |
1700 | * KEY is an alias for USER +KR (default max 1 day) | |
1701 | * This command is for allowing no-opers to use oper-options by specifying | |
1702 | * the flag to unlock. Be careful with this option! | |
1703 | * Example: KEY +365 +s * would make it possible for everybody to use s flag. | |
1704 | ||
1705 | ||
1706 | Usage: NOTE LOG [&<passwd>] [+|-<flags>] [#<ID>] <nick!username@host> | |
1707 | Displays how long time since matching person was on IRC. This works | |
1708 | only after use of NOTE SPY. The log is protected to be seen for other | |
1709 | users than the person who queued the SPY request. To get short | |
1710 | output, do not specify any arguments. Example: | |
1711 | LOG : Print short log of all | |
1712 | LOG * : Print long log including real names of all | |
1713 | LOG nick : Print long log for user nick. | |
1714 | ||
1715 | ||
1716 | Usage: NOTE LS [&<passwd>] [+|-<flags>] [#<ID>] | |
1717 | <nick!username@host> [<date>] | |
1718 | Displays requests you have queued. No arguments would show you | |
1719 | all requests without the message field. | |
1720 | Use flags for matching all messages which have the specified flags set | |
1721 | on or off. See HELP NOTE FLAG for more info about flag settings. Time | |
1722 | can be specified on the form day.month.year or only day, or day/month, | |
1723 | and separated with one of the three '.,/' characters. You can also | |
1724 | specify -n for n days ago. Examples: 1.jan-90, 1/1.90, 3, 3/5, 3.may. | |
1725 | If only '-' and no number is specified max time is set to all days. | |
1726 | The time specified is always the local time on your system. Example: | |
1727 | LS !user would show you all requests to username@* | |
1728 | LS +x would show all your SPY requests. | |
1729 | LS #300 would show you only request #300. | |
1730 | ||
1731 | ||
1732 | Usage: NOTE NEWS [&<passwd>] [+|-<flags>] [+|-<maxtime>] | |
1733 | <group!username@host> | |
1734 | NEWS with no message is an alias for USER +RS (default max 60 days) | |
1735 | This command is for subscribing on a specified newsgroup from any | |
1736 | user(s) or host(s). Wildcards may be used anywhere. Example: | |
1737 | NEWS irc.note : Subscribe on irc.note | |
1738 | * NEWS irc.note@*.no : Send to group irc.note, but only for | |
1739 | * users at host *.no | |
1740 | * NEWS irc.note : Send to all for group irc.note | |
1741 | * NEWS Users@*.edu Hi : Send Hi to all users using note in your | |
1742 | * server located at host *.edu. | |
1743 | (Advanced users may use User +rs <...> <filter> where filter is a | |
1744 | string which must matches with field in received news message) | |
1745 | - Only opers can send news as default. | |
1746 | * To send news add message and use same format as subscribing, except | |
1747 | * that username field must matches with subscribed group as alt.irc!*.irc - | |
1748 | * everybody subscribing on a*.irc or *.irc or alt.irc... would get the news. | |
1749 | * A speciall case is the group Users which everybody using note in the server | |
1750 | * are member of. | |
1751 | ||
1752 | ||
1753 | Usage: NOTE RM [&<passwd>] [+|-<flags>] [#<ID>] <nick!username@host> | |
1754 | Deletes any messages sent from your nick and username which matches | |
1755 | with nick and username@host. Use flags for matching all messages which | |
1756 | have the specified flags set on or off. See HELP FLAG for more info | |
1757 | about flag settings, and HELP LS for info about time. | |
1758 | ||
1759 | ||
1760 | *Usage: NOTE SAVE | |
1761 | * SAVE saves all messages with the save flag set. Notice that the | |
1762 | * messages are automatically saved (see HELP STATS). Each time server is | |
1763 | * restarted, the save file is read and messages are restored. If no users | |
1764 | * are connected to this server when saving, the ID number for each | |
1765 | * message is renumbered. | |
1766 | ||
1767 | ||
1768 | Usage: NOTE SEND [&<passwd>] [+|-<flags>] [+|-<maxtime>] | |
1769 | <nick!username@host> <msg> | |
1770 | SEND is an alias for USER +D (default max 60 days) | |
1771 | This command is for sending a message to recipient, and let the server | |
1772 | send a note + a notice to sender if this is on IRC - if message is sent. | |
1773 | SEND foobar Hello, this is a test. | |
1774 | SEND +7 !username@*.edu Hello again! | |
1775 | ||
1776 | ||
1777 | -Usage: NOTE SENT [NAME|COUNT] | |
1778 | *Usage: NOTE SENT [NAME|COUNT|USERS] <f.nick!f.name@host> <date> [RM] | |
1779 | Displays host and time for messages which are queued without specifying | |
1780 | any password. If no option is specified SENT displays host/time for | |
1781 | messages sent from your nick and username. | |
1782 | NAME displays host/time for messages sent from your username | |
1783 | COUNT displays number of messages sent from your username | |
1784 | * USERS Displays the number of messages in [], and names for all users | |
1785 | * who have queued any message which matches with spec. nick/name/host. | |
1786 | * RM means that the server removes the messages from the specified user. | |
1787 | ||
1788 | ||
1789 | *Usage: NOTE SERVICE <nick> <note command> | |
1790 | * Useful in robots. Note will take the requests as if from <nick> | |
1791 | ||
1792 | ||
1793 | Usage: NOTE SPY [&<passwd>] [+|-<flags>] [+|-<maxtime>] | |
1794 | <nick!username@host> [msg] | |
1795 | SPY is an alias for USER +RX (default 1 max day) | |
1796 | SPY makes the server tell you if any matching recipient sign(s) | |
1797 | on/off IRC or change nick name. No message needs to be specified. | |
1798 | However, if a message is specified this is returned to sender including | |
1799 | with the message about recipient. Message could for example be one or | |
1800 | more Ctrl-G characters to activate the bell on senders machine. | |
1801 | As an alternative for using C flag, <msg> field could start with | |
1802 | any number of nicks on this format: %nick1 %nick2... %nickn, with | |
1803 | no space between % and the nick name you use. Spy messages would be | |
1804 | valid for any of the nicks specified. | |
1805 | SPY with no argument would tell you what users you have spy on who are | |
1806 | currently on IRC. The system logs last time the last matching person was | |
1807 | on IRC for each SPY request is queued in the server. See NOTE LOG for this. | |
1808 | You may use flag +A to see what server matching user is on, | |
1809 | and/or +J flag to see what channel. (Read HELP NOTE USER for more). Example: | |
1810 | SPY foobar!username@host <ctrl-G> | |
1811 | SPY +10 foobar | |
1812 | SPY +aj &secret * <ctrl-G> | |
1813 | SPY +365 +e !user nick!*@* <ctrl-G> | |
1814 | SPY % +7 foo!user | |
1815 | SPY +5 nicky %mynick %meenick | |
1816 | ||
1817 | ||
1818 | -Usage: NOTE STATS [MSM|MSW|MUM|MUW|MST|MSF|USED] | |
1819 | *Usage: NOTE STATS [MSM|MSW|MUM|MUW|MST|MSF|USED|RESET] [value] | |
1820 | STATS with no option displays the values of the following variables: | |
1821 | MSM: Max number of server messages. | |
1822 | MSW: Max number of server messages with username-wildcards. | |
1823 | MUM: Max number of user messages. | |
1824 | MUW: Max number of user messages with username-wildcards. | |
1825 | MST: Max server time. | |
1826 | MSF: Note save frequency (checks for save only when an user register) | |
1827 | Notice that 'dynamic' mark after MSM means that if there are more | |
1828 | messages in the server than MSM, the current number of messages are | |
1829 | displayed instead of MSM. | |
1830 | Only one of this variables are displayed if specified. | |
1831 | * You can change any of the stats by specifying new value after it. | |
1832 | * RESET sets the stats to the same values which is set when starting the | |
1833 | * server daemon if no note file exist. Notice that this stats are saved | |
1834 | * in same file as the other messages. | |
1835 | ||
1836 | ||
1837 | Usage: NOTE USER [&<passwd>] [+|-<flags>] [+|-<maxtime>] | |
1838 | <nick!username@host> <msg> | |
1839 | With USER you can queue a message in the server, and when the recipient | |
1840 | signs on/off IRC, change nick or join any channel, note checks for | |
1841 | valid messages. This works even if the sender is not on IRC. See HELP | |
1842 | FLAGS for more info. | |
1843 | Password can be up to ten characters long. You may specify password | |
1844 | using the &, % or $ character. & is equal to to $, except working much | |
1845 | better cause client use $ for other things... | |
1846 | The % character works like &, except it makes the queuing silent. It | |
1847 | makess also sense to use this without any following password. | |
1848 | If any request queued is equal to any previous except time and maxtime, | |
1849 | only maxtime is changed as specified. You then get "Joined" instead of | |
1850 | "Queued". | |
1851 | HELP FLAGS for info about flag settings. Username can be specified | |
1852 | without @host. Do not use wildcards in username if you know what it | |
1853 | is, even if it's possible. Max time before the server automatically | |
1854 | remove the message from the queue, is specified with hours with a | |
1855 | '-' character first, or days if a '+' character is specified, as | |
1856 | -5 hours, or +10 days. Default maxtime is 7 days. | |
1857 | Note: The received message is *directly* displayed on the screen, | |
1858 | without the need for a read or remove request. | |
1859 | NOTE USER &secret +WN +10 Wizible!jarlek@ifi.uio.no Howdy! | |
1860 | is an example of a message sent only to the specified recipient if | |
1861 | this person is an operator, and after receiving the message, the server | |
1862 | sends a note message back to sender to inform about the delivery. | |
1863 | NOTE USER +XR -5 Anybody <ctrl-G> | |
1864 | is an example which makes the server to tell when Anybody signs | |
1865 | on/off irc, change nick etc. This process repeats for 5 hours. | |
1866 | NOTE USER +FL @*.edu *account* | |
1867 | is an example which makes the server send a message back if any real- | |
1868 | name of any user matches *account*. Message is sent back as note from | |
1869 | server, or directly as a notice if sender is on IRC at this time. | |
1870 | ||
1871 | ||
1872 | Usage: NOTE WAITFOR [&<pwd>] [+|-<flags>] [+|-<maxtime>] | |
1873 | <nick!username@host> [<msg>] | |
1874 | WAITFOR is an alias for USER +YD (default max 1 day) | |
1875 | Default message is [Waiting] | |
1876 | This command is for telling the recipient if this appears on IRC that | |
1877 | you are waiting for him/her and notice that this got that message. Example: | |
1878 | WAITFOR foobar | |
1879 | WAITFOR -2 foobar!username@* | |
1880 | WAITFOR foobar Waiting for you until pm3:00.. | |
1881 | ||
1882 | ||
1883 | *Usage: NOTE WALL [&<passwd>] [+|-<flags>] [+|-<maxtime>] | |
1884 | * <nick!user@host> <msg> | |
1885 | * WALL is an alias for USER +BR (default max 1 day) | |
1886 | * This command is for sending a message once to every matching user | |
1887 | * on IRC. Be careful using this command. WALL creates a list of | |
1888 | * persons received the message (and should not have it once more time) | |
1889 | * with H flag set. This list can be displayed using ls +h from the | |
1890 | * nick and username@host which the WALL request is queued from. | |
1891 | * Removing the headers (H) before WALL request is removed would cause | |
1892 | * the message to be sent once more to what users specified in list. | |
1893 | * WALL +7 @*.edu Do not do this! - Makes it clear for all users using | |
1894 | * IRC on host @*.edu the next 7 days how stupid it is to send such WALL's ;) | |
1895 | ||
1896 | ||
1897 | *Usage: NOTE WALLOPS [&<passwd>] [+|-<flags>] [+|-<maxtime>] | |
1898 | * <nick!user@host> <msg> | |
1899 | * WALLOPS is an alias for USER +BRW (default max 1 day) | |
1900 | * This command is same as WALL, except only opers could receive it. | |
1901 | ============================================================================= |