EFnet - Darknet & Deepweb
The EFnet IRC Network RBL is comprised of a collection of data from several sources with the purpose of providing a "one stop shop" for IRC admins to block a multitude of undesirable clients.
The collected sources are as follows:
- Scanned open proxies by the EFnet Open Proxy Monitors
- Spamtrap hosts with scores of 666 (known self spreading virii and trojans)
- Spamtrap hosts with scores of 50 or more (virii and trojans known to self-spread)
- Scanned TOR exit node proxies
- Other unsavory types, manually added by trusted admins (don't use this if you don't trust us), or automatically added by drone detection patterns
Open proxies and spam trap hosts are listed in the RBL for 7 days.
Because of the generally more static nature, TOR nodes are listed for 10 days.
General Questions »
What is IRC?
Internet Relay Chat, or IRC, is a real-time chat system, connecting
clients on many different servers. People can talk to eachother one on
one, or in a more public environment in channels (think CB radios)..
What is EFnet?
EFnet is the modern-day descendant of the original IRC network.
EFnet is short for "Eris Free" network. eris.berkeley.edu was a server in
the very early nineties that was not run so well. When it left the
network, the powers that be decided to name the network Eris Free network,
Is EFnet a free network?
Well, it depends on your definition of free. Do you have to pay to get on?
No, unless you bought a shell account specifically for that purpose. Is it
free in the sense that there are no rules? No. Each EFnet server has
operators and administrators to run their servers and the network. Eris
Free does not equal anarchy.
How long has EFnet been around?
IRC was started in 1988. The network started being called EFnet in August
of 1990. You can find a longer version of the history here
Connection Questions »
How do I get onto the Darknet ?
You need to download and install navigateur TOR browser. Many shell account and
universities already have them installed on their machines. For a Windows
machine, the most popular client is mIRC. If you are running a
flavor of Unix, a popular client is EPIC. You should refer to the
home pages for the clients with questions about installation. Once
you have your client installed, you have to connect to a server.
Which server should I choose?
The choice is completely up to you. However, for a variety of reasons, not
all servers will allow you to join. You should try until you get one to
work by using the /server command, like /server irc.darknet.info.
Why can't I connect to server x?
The administrators of each server decide on who can and can not join their
server. However, the four most common error notices are
You are not authorized to use this server
You must install ident
Couldn't look up your hostname.
Why am I not authorized to use server x? What is an I:line?
You probably do not have an I:line to that server. I:lines, or Invite
lines, dictate who can join a server and who can't. They are usually coded
like *@*.domain.name. If your domain does not have one, then you can not
join. Servers that have a limited amount of I:lines are called "closed
I:". Servers that are "open I:" have an I:line that reads *@*.*, so anyone
What is ident? How do I install it?
Basically, ident makes sure that you are who you say you are. This is
mostly an mIRC problem. You can find out more information here.
Why is my username bad?
Most servers do not allow usernames with certain symbols in them. Take
them out, go back to letters and numbers, and you should be ok.
Why can't my hostname be looked up?
This problem likely had to do with either your DNS server, or the one by
the IRC server you are trying to connect to. Unless you happen to run one
of these machines, there really isn't much you can do. However, the
servers with the open I:line should still let you on.
Using IRC/Channel Questions »
How do I learn the rules of the server I'm on?
Every server has a message of the day (motd). If the motd did not show up
when you joined the server, you can hit /motd at any time to view it.
What can a channel operator do?
A channel operator, or chanop, can set the modes on a channel. A chanop
can also kick clients out of a channel, and ban them from coming in again.
How do I become a channel operator?
There are two ways to become a chanop: either another chanop gives you
operator status on the channel, or you start your own channel.
What do I do if someone is using my nick?
You have two options. Either you can use another nick until your nick is
free, or you can talk to the person using your nick. Now, the nicer you
are to the person using your nick, the more likely they are to give it up.
However, if you are a new user, you may be the one
imposing on someone who had used a nickname for up to 15 years. You may
want to just be happy putting a number after the nickname, or surrounding
it with underscores, etc. Nicks on darknet are NOT owned. There is no
nickname service which will protect your nickname for you until you come
What is the best way to start a conversation in a channel?
First, to debunk a common myth, not everyone on IRC is friendly. As a
matter of fact, you may find that people are openly hostile towards you
(or anyone they don't particularly know). Usually, sitting back and
catching the flow of conversation in a channel is a good way to get
yourself acclimated to that channel. Think of it as entering a
bar (or a school cafeteria, depending on your age). Do you immediately
walk up to a group of people you don't know and butt in on their
conversation? The same goes for /msg'ing people that you don't know. In
the above example, it's the equivalent of whispering in someone's ear.
My channel is opless. Now what?
darknet has a channel fix service, called CHANFIX. If your channel is made
opless for any reason, CHANFIX will op the five most opped people in its
database. The service takes snapshots of the network at regular intervals
to see who is opped on every channel at
that time. If none of the five most opped people are on, you will have to
wait for one of them to come onto the channel.
Why can't I join certain channels?
There are channel modes which can be set in order to block people from
joining channels. In alphabetical order, they are:
+b - Channel ban. Upon trying to join, you will get a message saying that
you are banned from the channel. To get unbanned, you can try asking an
operator of the channel to unban you (do a /names #channel, and find a
chanop that way). However, if you are the cause for the ban, you might
want to stop trying for a while.
+i - Invite only. Your message will say that the channel is invite only).
A channel operator has to invite you. Again, you can try finding a chanop
that is willing to invite you using the /names command.
+k - Channel key. Your message will say that you have a bad channel key.
This is equivalent to having a password to enter the channel.
+l - Channel user limit. You will get a message that the channel is at its
limit, and therefore cannot allow you to connect immediately. If the
channel is not +s, you can /list #channelname to see if anyone has left
the channel to see if you could possibly join.
What are some other channel modes?
Some other modes accepted on darknet include:
+n - No messages to the whole channel from anyone outside the channel
+t - Only channel operators can set the topic
+s - Secret channel. It can't be seen in a /whois or a /list
+e - Ban exemption. Mostly used to allow specific people in from domains
that are generally banned from a channel.
+I - Invite exemption. If a channel is +i, anyone with a +I set can join
freely without an invite.
I started a channel. How do I maintain it?
A lot depends on the type of channel you're on, and who you invite to it.
If you start a very peaceful channel, say #Ilovethisfaqthatpillswrote, I
highly doubt that anyone else will want it. Thus, you will not need
anything to maintain the channel; if you invite a few friends over, they
can hold chanops for you while you're gone. If you're the only one there,
it's really not a big deal, is it? However, if that is not the case, you
may want to get a quiet bot to hold the channel for you.
What kind of bot should I get?
Where can I put my bot?
If you are on IRC already, you should /motd some various servers to see
which allow bots. You will see some servers allow quiet bots, and some
have a "don't ask, don't tell" policy. Do NOT put your bot on anything
other than these servers.
What can I do about takeovers?
CHANFIX also has the ability to regain channels for the regular channel
operators. If your channel was taken over, join #chanfix and someone will
likely be able to help you. CHANFIX only keeps a limited database, so the
quicker you report a takeover, the more likely it is that you can get your
Server Questions »
What can a server operator do?
A server operator, or IRCop, can kill users, which knocks them off of the
network. An IRCop can also ban users from the server that he/she has
operator status on. They can also disconnect servers from the network if
the lag gets too bad, and reconnect them in a better place.
What CAN'T a server operator do?
A server operator can't see into +s channels, or get onto channels that
are +i or +k. They can't restore channel ops if a channel is opless or
taken over. Unfortunately, too many people have taken advantage of
trusting IRCops, and so they rarely get involved in
channel matters. The exact list of what IRCops can and cannot do is listed
How do I become a server operator?
This is probably the MOST frequently asked question of server operators.
There is no real answer. Most server operators got their status because
they knew someone who had it already that could give it to them. The rest
put up their own servers.
How do I link my own server to darknet?
If you are interested in linking a server to darknet, you should fill out
the new server
application. There are different server applications for each of the
three regions: US, Canada and Europe.
How do I find out who the active operators are on a particular server?
The command /stats p. In general, /stats will show you various statistics
about a server; /stats p shows active opers. The number after the nick is
the idle time in seconds. If you want to see the active opers on the
server you are on, simply hit /stats p. If you want to see a particular
server's active operators, you can /stats p server.name. If you got
spammed, or if someone on a server is doing something which is against the
rules of the server they are on, you can /stats p username, where username
is the nickname of the spammer or bad client.
What is a K:line?
The misnomered K:line, or Kill line, is actually a ban on a server level.
K:lines are permanent; k:lines are temporary, and are set in minutes.
K:lines can be set for a specific user@host, or even on a domain level. If
you try to connect to a server where your host has a K:line, you will see
a message telling you that you are banned from that server, and the reason
What is a D:line?
A D:line, or Deny line, denies access to a specific IP address or block of
addresses, and work similarly to K:lines. If you are D:lined from a
server, you will see a message telling you that you are, and the reason
What is a G:line?
A G:line, or Global K:line, is exactly that. A G:line is a ban on a
network level. While not every server accepts G:lines, those that do will
not allow the host in question to connect for a certain amount of time.
What is an X:line?
An X:line (no real name here!) will ban a user from a server it their
realname field (whatever is after the user@host in the /whois) matches
that of the X:line.
Logging and Reporting IRC Abuses ยป
The Quick Version
Use /admin server.name.here for the email address of the administrator or mailing list of a server, such as "/admin irc.whatever.com". Include a log of the event(s), the output of the /date command, your current /whois information, and a /whois or /whowas of the abuser(s).
Now even if that's all you wanted, you probably should take a minute to read the following anyway.
Why do you want to talk to an IRCop?
First, realize that the job of the IRC operators (IRCops or OPERs) is to run the servers. They are not "IRC cops" and they do not enforce laws or monitor people for bad behavior. They are not responsible for getting back nicks or channels, since neither are 'owned' or 'registered' on darknet IRC. On darknet, IRCops do not have the omnipotent ability to see into secret channels or change channel modes. Opers can sometimes help you if somebody is viciously attacking you or your channel, running bots or clones, or otherwise violating the rules of that server. These rules are spelled out in the message of the day for every server, type /MOTD server.name.here to read them.
If another user is being abusive or insulting or flooding, use the /ignore commands provided with your client for this purpose. You may also want to change channels, nicks, and even servers, if he is persistent. Considering there are tens of thousands of people on IRC, IRCops cannot possibly keep up with your personal problems, nor is it their role to punish people for profanity, pornography, "unfair" kick/bans, etc.
A word on channel takeovers. The maintenance of a channel is the responsibility of the ops of that channel. It's often too late once a channel is lost, because the takeover artists can close the channel so that even opers cannot figure out who to sanction. Also, since channels are not owned, even the few opers who might care about this issue will not interfere based on your word alone, so if your channel was 'stolen' by a another IRC user and not a bot, it's now theirs unless you can come up with some good objective proof. So know the people you decide to give ops to. These days, it is best to require a password as well as checking the other person's user@host before giving ops.....from every person, every time. This is very important.
Now, if you still want to talk to an IRCop
If you're really sure you want to talk "live" to an oper, make sure you find one from the server that the abuser is using. Do not bother the opers from your server unless the abuser is also on your server. To find out what server the abuser is using, do /whois nickname-of-abuser. Then type /MOTD server.name.here to read the rules of that server. If the server /MOTD says to send logs of abuse to an email address, that's what they want you to do, don't waste your time trying to /msg the opers.
Here are some other commands for finding opers. Use these sparingly, because troublemakers often use these commands, and you wouldn't want to be mistaken for one of those. Some servers will not allow you to do these commands unless you are connected to the server yourself.
/stats p server.name.here will show you currently connected opers on that server (and some may show idle time as well)
/trace server.name.here does much the same thing.
/stats o server.name.here shows the list of opers authorized by that server, but it does not guarantee they are using that nick or even online at the moment. /whois nick nick (typing the nick twice) should show you their idle time.
Remember, If an oper says they will not or cannot help you, please respect the answer. Opers are usually volunteers, they are not paid by you or anybody else, so they are not obligated to do anything for you.
I found an oper to help me, how do I send them a log?
Do not copy and paste unexpected or uninvited information to an IRCop.
Most IRCops do not run mIRC, which has separate windows for each messager. If you copy/paste the flood of the abuse you just got to an IRCop you will most likely get /killed. (When a user pastes 20 lines of floods or abuse to my screen without warning, it totally floods the information I am working on off the screen. I don't know it is a copy, I think I am being attacked.) Information of more than 2-3 lines probably would be better sent as a /DCC file send of a log.
Make your message count.
Opers are busy. they do not want to have to beg you for the pertinent information. (Sometimes a user takes so long to get to the point, that I have lost the thread of what they are talking about. If the channel name is 3 screens back, it takes me more time to put all the information together) So give the oper the nickname of the abuser and the channel involved, and if it is a bot, any information you have to show why you think it is one.
If you do email, please be sure you are emailing from an address that will accept a reply.
I have spent many hours writing a helpful reply to users, only to find they are undeliverable.
How to actually make a logfile
Okay, if you need help on how to make a logfile, here are some hints for some popular IRC clients:
mIRC (for Windows)
type /log on or click on the upper left-hand corner of the window and select the logging option. The log then starts to capture what passes through that window from that point in time. If the info you want to save has already passed, backscroll the window with the Page-Up key and highlight the text you wish to select, which saves it to a buffer. Select Clipboard, Notepad, Windows Write, or another text editor, then use the Ctrl-V command to paste the block of information to the screen. Save the file, and it is yours. Save as many windows of text as you need. If the window has been closed, unfortunately, that information is lost if it was not logged before closing.
For the Win 3.x program, one can select another application with the CTRL-esc keys to get to Program Manager.
PIRCH (for Windows)
PIRCH has logging options to select the logfile directory, and whether to Auto-log. Later versions of PIRCH also has a /set logs on(or off) command line to toggle logging at the command line. Check your /help files for more information on this.
WSIRC (for Windows)
CHANNELlog will toggle logging on/off for WSIRC.
ircII (for UNIX, VMS, Windows, etc.)
For ircII, you may choose the name of the logfile you desire with: /set logfile new.logfile.name. Otherwise the default IrcLog name will be used. (don't forget that UNIX is case sensitive, so you have to use the caps in IrcLog to find it) Use /set log on and /set log off to open or close the file. The information is saved to that file on your shell account, and subsequent openings/closings will append information to the file. If you use /quit to exit IRC, the file is automatically closed.
To capture information that has passed previously, open your logfile as quickly as possible, and then use the /lastlog command to scroll the information from your lastlog buffer into the opened file. It will capture much of what has happened. However, there may be things, like channel parts/joins that do not show up with the /lastlog command.
After /quit'ing IRC and returning to your shell, you would use any text editor, like pico, vi, or emacs to read it. If you have it, the pico editor is the easiest to use, since it is similar to the Pine email editor. If you just want to view it, the 'more' command will show you the contents of your file, one page at a time (hit space to advance to the next page). For example: more IrcLog
If you are using a mouse-compatible interface, or a communications program like Telix, which has a screen capture ability (alt-I for Telix allows you to take a 'picture' of a screen. ), a true backscroll will serve you well, since more channel information like join/parts will show up. The true backscroll for ircII is managed with 3 commands, ESC-p (hit "escape" key, then hit "p" key) for previous half screen at a time, ESC-n for next screen, and ESC-e to exit from backscroll and return to end. (Remember the ESC-e so you can get back to your command line.) When using backscroll, use the ESC-p command twice to get a full screen change, then take your screen image capture.
Ircle (for Macintosh)
It's easy to log stuff in Ircle and other Mac clients. Simply select the text you want, copy, go to a text editor such as SimpleText or BBEdit, paste, and save. If the text extends beyond the current screen, you can just use the mouse to select and scroll up while holding down the mouse button. You can also "shift-select" the text: click on the first word, use the scroll bar to go to the other end, then hold down shift and click on the last word to select everything in between. Ircle also supports automatic logging if you want to routinely log everything, see File / Preferences / Logging.
Due to an insecure password on an old admin account, hackers were able to retrieve a data dump of the forum database. At this point, it is safe to assume that all passwords are compromised. All passwords have been reset to a random string, you will need to perform a reset in order to login.
irc.arcti.ca renames to irc.shaw.ca
irc.arcti.ca has decided to rename its server to irc.shaw.ca. The server have been linked to efnet for many years and have before that had the name irc.powersurfr.com and irc.videontron.ab.ca. The admins have also decided to open up and everyone should now be able to use the server.
Connections tagged as TOR exit node by mistake
Some EFnet servers mistakenly tagged all incoming connections as TOR Exit node by mistake and issued a kline. The reason for this is that the blacklist provider ahbl.org have decided to shut down the service and returns positive responses for the queries our monitoring bots sends. So if you unexpectanly got tagged as TOR exit node the last days that might be a false positive.
irc.shoutcast.com delinks as the company Shoutcast was sold from AOL some months back. The server linked during summer 2006 and was administrated by deppy the whole period.
After 10 years in service the sponsor of irc.wh.verio.net have decided to pull it`s support. The server linked 4. March 2002 and have been administrated by Andrew "next" Prins the entire time. Thanks to Verio, next and the staff for the 10 years hosting and running the server on EFnet
IRC Operators Guide
- Interacting with Users and Other Operators
III. Bots and Bothunting
IV. Cloners, Flooders, and Spoofing
- Why Operators (Usually) Don't Get Involved In Channel Affairs
VII. IRCD and Associated Files
VIII. Server Information Commands (TRACE, STATS, LINKS, and HTM)
IX. Server Routing and Connectivity
- Other Server Commands (REHASH, RESTART, and DIE)
XII. Linking New Servers
XIII. Attitude and Perspective
I. Interacting With Users and Other Operators
This is the most important aspect of "opering". It will make or break you as an operator. There are a lot of politics that go on in the irc operator community and, whether you like it or not, these politics are here to stay. Fighting this and complaining about it will get you nowhere.
From what I've seen, most opers look down on users, make fun of them, and ignore them. Try to avoid this ego trip side of opering. Answer private messages, unless it is someone just sending you a hate message. Opers would get a lot less crap from users if they would be a little less egotistical. Something I might suggest is that you spend an hour or two every couple of weeks helping the newbies out in #irchelp or whatever equivalent you may find.
One thing to be wary of is that users will frequently try to manipulate you into helping them takeover channels. Very rarely will a user simply report a bot without a reason. Generally this will be because a bot tookover a channel or a user is flooding them. Fairly regularly you'll get these requests from users who want someone killed off the server so they can take control of a channel. Because of this, request the channel in addition to the nickname so you can see what's going on before you kill or K-line.
Frequently, you will get requests from other operators to kill or K-line a user. Opers should be trusted unless you've had problems with someone in the past. You should always require a reason before killing or placing the K-line. If it's in the least bit questionable, add "requested by " or something similar to the K-line reason.
If you are being harassed by a user on the network, handle it like a user should handle it, not like an oper has the capability of handling it. The temptation of killing a user for flooding you is something that pretty much all of us give into on occasion, but it's generally not the right response. If we are going to expect regular users to simply /ignore flooders, then we should do the same. Though I have to admit, a user must be pretty stupid to flood an oper...
On occasion, opers have their disagreements. There is a bit of a pecking order that exists in the oper ranks, usually with hub admins and opers being more "powerful" than leaf admins and opers. It's generally not a good idea to try to win an argument with the people who are providing your connectivity to the IRC network. For that matter, it's generally not a good idea to try to win any argument at all. If you do have a serious problem with another oper, and can't resolve it directly with him/her, go to your admin about it. Your admin can then approach the issue with the other oper's admin, and if that goes nowhere, with their uplink admin. This is a quick way to make enemies, so make sure it's important to you before doing it. _____________________________________________________________
II. Using KILL and KLINE
The KILL and KLINE commands are as follows:
KILL nick :reason KLINE nick :reason KLINE username@hostmask :reason
In my K-lines, I always use "reason [aaronb MM/DD/YY]" so that the user knows when and by whom they were K-lined, and also so that I am accountable for my K-lines.
Generally, whatever you do on your local server really is not a big deal. Different servers have different policies on using KILL and KLINE, but if you are doing global kills (killing a user on a different server), you need to make sure you understand what the IRC network's guidelines are.
Users tend to have one of two reactions to kills. Occasionally you'll get the user to cool off and realize that they need to fix whatever they are doing. More often, they will want to argue the point with you. Try to explain it to them, but if they don't seem to be willing to follow the server guidelines, just K-line them. After they get K-lined from a few servers, they'll figure it out.
You probably want to avoid K-lining users unless it's really necessary. A K-line means that you don't want that user on your server, for whatever reason. Depending on the server, K-lines may be cleared after a week or two, a few months, or maybe never. It might be wise to have a "permanent" section of K-lines, and then the rest can stay or go at anyone else's discretion. For clearing K-lines, generally it's a good idea to talk to the person who placed it before doing so. With access to ircd.conf (to remove K-lines), you can be a lot less cautious about placing them.
The best guideline for doing global kills is to ask yourself "Is this really necessary?" You can usually find an oper on the server the user is on to handle an issue for you instead. If an oper on the server won't do it, then probably they wouldn't like you killing the user off their server either.
Frequently it seems that opers are just looking for a reason to kill. Probably if you are in that mood, it would be a good time to deoper and go find something else to do for a while. Killing like that looks bad for both you and for your server.
It's a wise idea to keep logs of everything you do. I have yet to see a client that doesn't have the capability of logging. If a user or another oper challenges your kill (usually to your admin, since they typically don't have the guts to talk to you), you can provide them. You will most likely be accused of abusing your O-line, and threatened by users to get it taken away, on a regular basis. Logs are your best defense. _____________________________________________________________
III. Bots and Bothunting
A "bot" generally refers to any automated program or client that doesn't have a person sitting behind it, not just a program that is called one. If a client is idle for several hours and is behaving like a bot, it's usually considered one.
There are a couple of reasons why bots are frequently considered to a problem. First, they take up resources on IRC that could be used for regular client connections. The primary reason, though, is because bots are frequently used to flood and harass users. You'll want to check what your server's policies are regarding bots, but an abusive bot should never be tolerated.
Finding bots generally isn't that difficult. Many have ctcp responses that don't match what you would expect, or have bogus idle times (in their ctcp finger response). Also, there are a couple of good portscanners that can help you check hosts for bots (eggdrop bots usually listen on a port for incoming telnet connections).
You probably aren't going to find all the bots being run by hardcore botrunners. They generally find out quickly about whatever new bothunting methods we come up with and spread the word. With these, your best bet is to wait until someone complains about it, and then monitor its behavior.
Here is a short description of a few of the bots out there, and a couple of tips for finding them: * eggdrop - this is the most common bot that you'll run into. Typically you'll see "/msg botnick hello" in the gecos field (the description line in the whois information) if the bot is poorly configured. Additionally, by default, these bots PRIVMSG #lamest for invite/ops. They also join #botcentral by default. * johbot - these bots PRIVMSG blahb1ah on a regular basis. If you change your nickname to that, you can sit and wait for them to find you. Additionally, if you enter the channel a suspected johbot is in, and do a fake netsplit quit (/quit irc.blah.com irc.something.net), the johbot will automatically change its nickname. * combot - these are a comstud creation. I have never found one myself, which either means there aren't many around, or they just hide really well. I've heard that doing a /ctcp botnick source will generate a reply with "Combot" followed by the version.
There are other methods of finding bots, but they change far too regularly for this document. Also, we don't need to be giving the masses out there all of our secrets. Keep in touch with other opers on this stuff. _____________________________________________________________
IV. Cloners, Flooders, and Spoofing
Clones are multiple clients from the same person. Most servers define this as multiple connections from the same hostmask (matching user@*host.tld). If it's obvious someone is running multiple clients from different domains, they are also considered clones.
Generally, cloning itself is not all that bad (just taking up connections). Frequently when you see clones, however, they are being used to flood users or takeover channels.
The best approach to take with clones is to kill them, and see if they return. If you do this a couple of times, and the user insists on keeping them on, it's time for a K-line. Unless a user is consistently a problem, clone K-lines should be relatively temporary (a few weeks is sufficient).
You'll see two forms of flooding on IRC. The first is CTCP flooding, which attempts to get a user to flood the server with CTCP responses, tripping the server's flood protection, and terminating the user with the message "Excess Flood". Many bot networks ("fludnets") use this type of flood. Flood protection scripts may prevent this from being very effective, but the real problem is the impact on the network. If 20 bots flood a user for 10 seconds, sending five 100 byte CTCP requests per second, that is 20 * 100 * 5 = 10k/sec, or 100k of data total over the 10 seconds. When a network that is maintaining 30000 users, this sort of activity is not at all acceptable.
The second type of flooding, which is not related to IRC (but is frequently the result of conflicts on IRC), is ICMP flooding. This is usually done from a reasonably fast link (ISDN or higher) and consists of flooding a user or server with ICMP packets (such as ping). This is considered a "Denial Of Service" attack, and is against the law.
There are many flooding scripts out there right now, and a couple of these have supposedly "random" nicknames they use for CTCP flooding. A trick to use is to set a couple of those nicks in your notify. Some flooding scripts also have the clones join specific channels (e.g. #srfloodclones).
DNS spoofing is a relatively new hit these days on IRC. You'll generally find spoofs one of two ways - you're watching the connections (usermode +c) and an unusual hostmask appears, or a user reports one. The first thing to do is to get the user's IP address (/stats L nick), and check to see if the DNS lookup matches the IP address. If it doesn't, you know you have a spoof. With this information, you can KILL the spoof, and when it reconnects, see where the real host is and issue a K-line (which won't stop them from spoofing again, but will prevent them from signing on *without* spoofing). Some servers have the capability of D-lines, which allow you to ban by ip mask. A D-line will prevent the client from connecting at all, regardless of whether they try DNS spoofing or not. If the server supports the DLINE command, you can do /dline ipmask :reason. _____________________________________________________________
V. Why Operators (Usually) Don't Get Involved In Channel Affairs
The primary function of opers is to maintain the servers and the network, not to deal with channels. The main reason the general policy is for opers not to get involved is because it is frequently difficult to determine who really should be controlling a channel. There are a lot of deceitful users out there that will ask you to help them get their channel back when it is not their channel in the first place. Even if you do know who the regular ops are, oper involvement is questioned and challenged, so many opers will ignore channel issues entirely just to save the grief.
In practice, you'll find opers defend their own channels, and turn their backs on others. It's a little pathetic, but after you get harassed enough by users saying "why are you getting involved? I thought opers weren't supposed to get involved in channel affairs" you'll start to understand the cynicism. _____________________________________________________________
VI. Dealing with "How Does One Become an IRC Operator?"
Most users have no comprehension of what opering involves, and really have no place becoming one. This does not mean, however, that they deserve an abusive answer or to be blown off when asking how to become an operator. It's easy to set up a simple alias to provide an automated response to this question.
For example, use an alias like "Becoming an IRC Operator requires not only a strong working knowledge of IRC and this IRC network, but also a working relationship with hub admins and other opers. Opers are selected when there is a need, and never given based on who is asking for it."
The thing to remember is that there are always going to be more people that want to be an operator than there are openings. If you really want to help the network, the best way to do it is by answering new user questions on channels like #irchelp and #help. _____________________________________________________________
VII. IRCD and Associated Files
IRCD is the server daemon process. The large IRC networks will only allow unix-based servers, because they are the only ones proven to perform adequately on a large network (and because the current set of operators are mostly unix bigots... including myself to some degree). EFnet uses modifications of the 2.8.2 version; IRCnet uses modification of the 2.9.x versions.
The installed file structure varies from server to server, but you should have at least these two primary files:
ircd the IRC server daemon (main program) ircd.conf the server configuration file
The configuration file has various configuration items in it, which are in a format beginning with a letter and a colon. This file is read and processed backwards, so when you do STATS commands (described later), you'll see the information in the reverse order of the entries in ircd.conf. This file has the following configuration lines in it:
A:Company/Institute Name:Server Description:Admin Name
This configures the administrative functionality of the server, which is returned when a user does /admin on your server. The fields are completely up to the administrator of the server, but what I put above seems fairly standard. This is a mandatory field.
This line indicates a permitted bot. The server has built-in bot checking for certain known instances of bots, and will refuse the connection if it detects one. If the bot has this line in the config file, the server will not refuse the connection.
C:server hostname:password:server name:port:connection class N:server hostname:password:server name:hostmask:connection class
C/N-lines are connections to other servers. The C-line defines what servers your server can connect to, and the N-line defines what servers your server allows incoming connections from. I have never seen one without the other, and according to the sample ircd.conf, they must be used in pairs. The server hostname, password, and servername are fairly self explanatory. The port is used to identify which port your server will try to connect to automatically; if the port field is blank, your server will not automatically attempt to connect to that server. I have never seen the hostmask used (nor do I really understand what it does). The connection class is numeric, and defined in the Y-lines.
This line is used to ban a block of IP addresses. If a system administrator has control over several domains, he/she may attempt to avoid bans by changing the reverse DNS lookup on the host (a perfect example of this is smartec.com, who has several domains and several machines all on one Class C). With a D:line, you can ban 205.230.73.* (smartec) and nobody from that address space can connect, regardless of DNS lookup.
The E-line protects certain users from server bans (K-lines). Generally operators use them to protect themselves from accidental K-lines, but in some cases, a server run by an ISP will also use them to protect their customers.
H:remote servers permitted::hub server
This defines a hub server, which is a server that may have other servers connected behind it. The "remote servers permitted" is usually "*" or may have a hostmask to limit the remote connected servers to within that mask.
I:address mask:password:domain mask::connection class
I-lines define what clients are allowed to connect to your server. Additionally, they define what connection class (defined by Y-lines) the client is placed in. The password is usually left blank.
Most people already know what a K-line is, but for the record, it's simply a ban from the server. I have never seen a K:line with a time field, but it allows you to define what times a client is allowed on the server. Generally, K-lines are added with the KLINE command on the server, and the reason is stored as a comment in the config file.
L:restricted servers::connected server:depth
This is used to identify leaf depth behind a server. The restricted servers field is a hostmask for what servers to not allow behind the connected server (usually this is blank). The depth is what depth of servers may be connected behind it.
M:hostname:*:server description:default port
This line sets the basic information for your server. The fields are pretty self-explanatory. This is a mandatory field.
O:ident@hostname:password:nickname:connection class o:ident@hostname:password:nickname:connection class
These lines define the operators on the server. The lower case o-line identifies a local operator, who can do local server KILLs and KLINE, as well as SQUIT and CONNECT their server from/to an uplink server. The upper case O-line is a global operator, who can additionally do global KILLs (killing users off other servers) and SQUIT and CONNECT any server on the network. The connection class is as specified in the Y-lines.
These are the ports that your server listens for connections on (in addition to the default port set in the M-line). The hostmask is an optional field that allows you to specify which users may connect to that port.
The Q-line specifies a server that will not be allowed to link to the network at all (all servers must have identical Q-lines according to the sample config file). I have never seen this used.
Allows you to process access control through an external program (provided by the server admin). Whenever a client connects, the server calls this external program with the user information. The program then responds based on whether or not the user should be granted access to the server. I've never seen this used either, and is probably impractical for any server with a large client base.
Y:class id:ping frequency:connect frequency:max connections:max sendq
The Y-line defines a connection class. The class id is a number that identifies the class, and is used in I-lines and C/N-lines to identify which Y-line to use. The ping frequency is the time (in seconds) between ping requests (to verify that the connection is still alive). Connect frequency is the time between automatic connection attempts for server connections (should be zero for client connection classes). Max connections is self explanatory. The "sendq" is the amount of data (in bytes) that is allowed to be pending going out to a connection in that class before the server will close it (with a message such as "Sendq exceeded"). On the 2.9.x versions of ircd, the connect frequency is replaced with an identifier to handle cloning. If it is a positive number, it identifies how many clients can connect from the same hostmask. If negative, it identifies how many clients can connect from the same username@hostmask.
I would recommend reading the example.conf file in the ircd distribution. It has samples of most of these, as well as descriptions that are probably better than mine. _____________________________________________________________
VIII. Server Information Commands (TRACE, STATS, LINKS, and HTM)
There are a few commands that you can use to get information from a server to help with opering:
The TRACE command is used to trace the path from your current server to the specified server or user.
When the destination is a server, TRACE will also return information about current server and operator connections, incoming connections (with negative class numbers), and the number of users in each class. The oper connections contain the connection class, the nickname, and user@hostmask for the oper. For server connections, it shows the connection class, the number of servers behind it (followed by "S"), the number of clients on and behind it (followed by "C"), the server name, and what was responsible for connecting it.
When the destination is a user, TRACE shows the connection class, nickname and user@hostmask for that user.
The STATS command returns server information. These tend to vary by server version, and are sometimes case sensitive. Here are a few that I know or use regularly:
? Server connection statistics b B-lines c C/N-lines d D-lines e E-lines h H/L-lines i I-lines k K-lines l Data transfer statistics by connection The numeric fields are as follows: sendQ (outgoing message queue) sendM (protocol messages sent) sendK (total kilobytes sent) receiveM (protocol messages received) receiveK (total kilobytes received) time in seconds since the connection was created L Same as STATS l, except shows IP address instead of host m Command statistics o O/o-lines p Current opers online t General server statistics u Server uptime v Server link information y Y-lines z More server statistics
If you are not currently an oper, I don't recommend going through and testing these all at once. Multiple STATS requests are usually viewed as a threat to the server (some people have been known to flood a server with STATS requests to fill up the server's sendq and cause network splits).
LINKS [server mask]
This shows the structure of the irc network, and is a bit useless if you don't have a script or client that formats it for you. Each line contains the server name, its uplink name, the number of hops from your server to the server, and the server description.
The HTM command is used to view and set the high-transfer mode threshold. Additionally, it shows the incoming data rate, which is useful when monitoring how you are doing when relinking to the network. _____________________________________________________________
IX. Server Routing and Connectivity
I'll qualify this section by saying that I am not presently a hub operator, and have done very little in the way of connecting and disconnecting remote server connections. However, I have researched this quite a bit.
For my description, let's assume a network that looks something like this:
| | |
I J----K L----M
Usually when there is a problem, you first notice it by the decrease in response time from other users. Then you try pinging a few users and notice that ping times are outrangeously high. Usually with a channel-wide ping and LINKS, you can identify where the problem connection is. Assuming you are on server A, you notice ping times are fine up to server C, but everything from D and beyond is lagged. The first thing you do is a STATS l on server C (/stats l irc.c.com) to see what the outgoing sendq is to server D. Looking at just the server entry for server D, it might look like this:
211 irc.d.com[188.8.131.52] 1621588 9780 559 469469 24111 5862
The sendq is the first number after the IP address, or 1621588 in this case. If we do a STATS y on server C (/stats y irc.c.com), we can see what the max sendq allowed is. Look for the connection class with something aside from 0 in the connect frequency field (600 in this case):
So if that number reaches 4000000, server C will disconnect server D, and you'll see everyone on the other side quit with the message "*** Quit: nick (irc.c.com irc.d.com)" or whatever.
Now, if you were on server L, you would do STATS l on server D (/stats l irc.d.com) and look for the entry for server C. In this scenerio, you might see
211 irc.c.com[184.108.40.206] 142 8841 512 485915 21058 1234
Since the sendq going from irc.d.com to irc.c.com is only 142 bytes, it looks like a one-way lag situation (server irc.d.com is having trouble receiving data from irc.c.com).
Let's say you continue to monitor the sendq from irc.d.com to irc.c.com (with /stats l irc.d.com from your position on server A), and it rises from the previous 1621588 bytes to 3140419 bytes. You could wait it out and see if it splits or catches back up, but we'll decide to reroute it now instead.
Before you do anything, you have your clone over on server L do a STATS c on server D (/stats c irc.d.com) to see where it can reconnect to. Let's say an alernative link is server F. You now have a place to put it, but then you need to find a port. From your client on server L, you do a STATS l on server D (/stats l irc.d.com) and look at what ports it has open. Here's a couple of STATS l response lines that we are interested in:
The first line is the default port (6667), and looks like it's been pretty busy, so let's use port 6665 to relink on instead.
Now, we want to disconnect server D from server C, and then tell server F to connect to server D on port 6665. We will do all this from server A. We start with the SQUIT command, which has the following format:
SQUIT server :reason
So we do this:
/squit irc.d.com :reroute
At this point, it's a good idea to wait a minute for the servers to process the change, and then we can relink using CONNECT, with the following format:
CONNECT server port link_server
So we do this:
/connect irc.d.com 6665 irc.f.com
You can monitor the reconnect status with STATS l on irc.f.com, though in most cases, a good connect will take less than a minute.
If you are opering from a leaf server (like I do now), then you will generally only SQUIT and CONNECT locally to your uplink. So you have the following network:
A----B----C | D----E
And you are on server A, with real lag to the network, then you can reroute yourself to server D with:
/squit irc.b.com :reroute /connect irc.d.com [port]
My previous discussion should carry over to help with evaluation of the connection between server A and server B.
One last issue regarding server connectivity is "juping". When a server is having problems or has been compromised, and an admin for the server is not available, the server can be prevented from relinking by putting a fake server connection to the network in its place. When the server attempts to link, the network sees it as already being connected and rejects the server connection. _____________________________________________________________
- Other Server Commands (REHASH, RESTART, and DIE)
These are a few commands you won't use often unless you are responsible for administration of the server or need to handle an emergency.
The REHASH command simply tells the server to reload its configuration file. This must be done for changes to ircd.conf to take effect.
This command completely shuts down the server and restarts it. All connections will be closed (including yours).
This shuts the server down. Generally this is done when restarting the system the server is running on. _____________________________________________________________
XI. Operator Communications (WALLOPS and OPERWALL)
The WALLOPS (and OPERWALL) command is used to send a broadcast message to all operators across the network. Oper wallops were originally publically visible and intended to be used for disaster announcements and the like, but have been abused to the point where now they are operator only.
The format for both commands are:
WALLOPS :message text OPERWALL :message text
When you do a remote CONNECT or SQUIT, the server sends out an automatic WALLOPS announcing your action. _____________________________________________________________
XII. Linking New Servers
Everyone seems to want to link a new server, mostly because of the ego boost of being a server admin on a large irc network, and occasionally because they want to provide it as a service to a customer base.
These are some of the issues that face new servers:
The minimum link speed to get a link is usually T1 (1.544 mbps) to a major backbone provider. Even this is often considered inadequate.
The server must be running some flavor of Unix. Unix was designed around networking and generally can handle far more than other operating systems can. Whether this is true or not isn't the issue - it's completely based on the opinions of existing hub admins (which I happen to agree with on this issue).
The ircd process generally can take between 30 and 60 megs of memory when running on EFnet, so 64 megs is probably the minimum there. No other real processes should be running on the machine.
Existing IRC Users
To get a link, you should probably be averaging about 30 users at any given time from your domain. This can vary, and may not be a serious requirement if you have excellent connectivity.
Your list of potential operators can affect your ability to link. If you have known abusers as operators on your server, you probably won't get a link.
What it all really comes down to is whether or not you know and are liked by the hub admins. If they don't like you, I'd recommend pursuing golf as a hobby instead. :) _____________________________________________________________
XIII. Attitude and Perspective
The fact is, this is IRC. It's a chat network - a social gathering. Don't build your self image based on what other people think of you, on or off IRC. If you come on IRC because it's more important to you than blood, you should probably invest some money in counseling. Don't get all emotional over what happens on here. _____________________________________________________________
I hope that this document has helped someone out there. I wrote it to appeal to the average user, not to other operators. If you can think of anything more I should cover, or if you want to send me hatemail (or maybe even a nice comment), please feel free.
- Aaron Brinton
IRC CHANNEL SEARCH
Text in Channel Name
Text in Topic
In looking at the original "opermyth" document, we here at efnet.info decided that it needed to be re-done. In the five years since this was written, EFnet has undergone some drastic changes. So, here’s the updated "opermyth" document.
Q: What can ALL opers on EFnet do?
A: This is a list of what ALL of us can do:
Squit our own server, separating it from the rest of the net
Connect our own server to an uplink
Kill a local user
See the nickname changes of a local user
See all invisible users on our server
Mass msg/CTCP/notice a hostmask
Mass msg/CTCP/notice a server
See and send Operwall notices
Q: What can MOST opers on EFnet do?
A: In addition to the above, this is a list of what MOST opers can do:
Squit ANY server on EFnet from its uplink
Connect ANY server to an uplink
Die our own server
Kill a user on ANY server
K:line (or un-K:line) a hostmask or domain
D:line (or un-Dline) an IP address
Start or vote on a G:line to knock someone off of the servers that accept G:lines
See when someone does a local /whois on them (/whois nick nick)
Use the operspy commands
X:line (or un-X:line) a phrase
Get a score on a channel from CHANFIX
Q: What can SOME opers on EFnet do?
A: In addition to the above, this is a list of what SOME opers can do:
Use CHANFIX to fix a channel
Edit the ircd.conf file on our own server to do things such as adding I:lines
Q: What can ONLY admins on EFnet do?
A: In addition to the above, this is a list of what ONLY admins can do:
Call a vote and vote on EFnet issues
Give a user an O:line on our own server
Give a user a hostmask spoof on our own server
Q: With all of this power, what can EFnet opers NOT do?
A: EFnet opers can NOT:
Track nickname changes on clients that are not local to them
Op ourselves in a channel, unless we are near the top of the CHANFIX oplist, and the channel warrants a chanfix
Op anyone else in a channel, unless we have ops, or that person is near the top of the CHANFIX oplist, and the channel warrants a chanfix.
De-op someone in a channel, unless it warrants a chanfix.
All of the above actions under "warrants a chanfix" are actually done by CHANFIX, and not the oper.
Q: What are some other oper issues that come into play?
A: Here are some other issues that come up occasionally
The most common issue probably is killing for nicks. Is it abuse? Should we be able to? Some opers think that the notion that nicks are not owned should apply to everyone on EFnet; some opers think that their own nicknames should be reserved for them. There are no rules either way. However, it is very rare that an oper uses the /kill command for a nick other than their own. That is still looked down upon by the oper community, and considered abuse by some.
A new issue that has come up is overuse of CHANFIX. CHANFIX is meant to prevent the occasional takeover and provide ops to opless channels; it is NOT meant as a channel service to be used every day to prevent takeovers. Yes, occasionally, channels will be packeted off in full for a few days on end. However, that is rare. Every channel should take steps, even with CHANFIX, to make sure their channel isn’t taken over.
Another common issue is users packeting other users. While we can, with enough proof, knock these abusers off of IRC, it doesn’t do much to stop the packeting. Your best bet is to complain to their ISP or shell provider.
- efnet.multiplay.co.uk - ipv6 - 35 users - Hampshire, UK - Multiplay
- efnet.port80.se - ipv6 - ssl - 2536 users - Stockholm, Sweden - Port 80
- efnet.portlane.se - ipv6 - 768 users - Stockholm, Sweden - Portlane
- irc.du.se - 261 users - Borlange, Sweden - Dalarnas University
- irc.efnet.fr - 653 users - Paris, France - BSO Communication
- irc.efnet.pl - 187 users - Warsaw, Poland - ATMAN
- irc.homelien.no - ipv6 - 1481 users - Oslo, Norway - Powertech
- irc.inet.tele.dk - ipv6 - 1902 users - Aarhus, Denmark - TDC
- irc.inter.net.il - ipv6 - 50 users - Tel Aviv, Israel - Internet Zahav
- irc.swepipe.se - ssl - 502 users - Stockholm, Sweden - PRQ AB
- irc.underworld.no - ipv6 - 2900 users - Oslo, Norway - Underworld
- irc.choopa.net - ipv6 - ssl - 2956 users - New York, NY - Choopa LLC
- irc.colosolutions.net - 828 users - Orlando, FL - Colo Solutions
- irc.mzima.net - ipv6 - 2630 users - Los Angeles, CA - Mzima
- irc.paraphysics.net - ipv6 - ssl - 841 users - Houston, TX - nLayer
- irc.Prison.NET - 770 users - San Francisco, CA - United Layer
- irc.servercentral.net - 1892 users - Chicago, IL - Server Central
- irc.shaw.ca - ipv6 - ssl - 562 users - Calgary, AB - Shaw Communications
- irc.umich.edu - ssl - 194 users - Ann Arbor, MI - University of Michigan
Protocols : RFCs, Protocol definitions, etc
Internet Relay Chat
User Mode +g
User and Channel modes
TS5 TimeStamp specification
Internet Relay Chat: Architecture
EFnet historic server list
This list was originally written by < ... > and have since 1999 been maintained by Hardy @ EFnet.
Servers with + after their name split of to IRCnet in July 1996
If I am missing any servers, please send me a mail to hardy (a) underworld.no and i will try to correct it as soon as i can.
Last updated: 15.01.2020
USA --- help.us
note.mit.edu (a noteserv server)
engr.uark.edu -> irc.uark.edu
pegasus.ccs.itd.umich.edu -> irc.umich.edu
irc.erols.com -> deepweb.rcn.com
irc.exodus.net -> irc.idle.net -> irc.ef.net
irc-e.primenet.com -> irc-e.frontiernet.net -> irc.east.gblx.net
irc-w.primenet.com -> irc-w.frontiernet.net -> irc.west.gblx.net
irc.phoenix.net -> irc.c-com.net -> irc*.deepweb.net -> irc*.lagged.org -> irc.chowned.net -> irc.paraphysics.net
opus.bridge.net -> irc.bridge.net
ircd.solidstreaming.net -> ircd.flamed.net
irc.solidstreaming.net -> irc.flamed.net
irc.lightning.net -> irc.he.net
ircd.lightning.net -> ircd.he.net
irc.servercentral.net -> irc.scnet.net -> irc.sucks.net -> irc.servercentral.net
irc.foxlink.net -> irc.colosolutions.net
irc.secsup.uu.net -> irc.secsup.org
ircd.secsup.uu.net -> irc.secsup.org
irc.limelight.us -> irc.blackened.com
babel.cltr.uq.oz.au (real name of ircserver.cltr.uq.oz.au)
poc.dfat.gov.au -> irc.dfat.gov.au + (retired)
speech.elec.uow.edu.au + (retired)
uni-linz.ac.at -> linz.irc.at +
deepweb.dkom.at -> irc.dkom.at
dinf.vub.bfu.ac.be -> irc.vub.ac.be +
irc.videontron.ab.ca -> irc.powersurfr.com -> irc.arcti.ca
ircd-h.powersurfr.com -> ircd.arcti.ca
irc.etsmtl.ca -> irc.qeast.net
irc.avalonworks.ca -> irc.igs.ca
ircd.eris.dk -> hub.dk
cs.jyu.fi -> irc.jyu.fi +
kannel.lut.fi -> juuri.cc.lut.fi +
mopo.cc.lut.fi -> aapo.it.lut.fi +
tolsun.oulu.fi -> irc.oulu.fi +
uni-stuttgart.de + -> efnet.uni-stuttgart.de (deceased)
darmol.elte.hu -> irc.elte.hu +
irc.sch.bme.hu -> irc.bme.hu +
irc.ibm.net.il -> ircd.ibm.net.il +
mentai.hakozaki.karrn.ad.jp -> irc.karrn.ad.jp +
tonkotsu.hakozaki.karrn.ad.jp -> irc.karrn.ad.jp +
wsclark.huie.hokudai.ac.jp ->irc.huie.hokudai.ac.jp +
efnet.vuurwerk.nl -> irc.efnet.nl
mimir.ifi.uio.no -> irc.ifi.uio.no +
ircd.banetele.no -> ircd.efnet.no
irc.banetele.no -> irc.efnet.no
krakow-test.irc.pl -> krakow.irc.pl +
irc.dd.chalmers.se -> irc.cd.chalmers.se +
irc.ced.chalmers.se -> irc.hemmet.chalmers.se -> irc.csbnet.se
ircserver.seed.net.tw -> irc.seed.net.tw +
CHANFIX: EFnet Channel Fixing
What is CHANFIX? READ THIS PLEASE!
CHANFIX is an EFnet service that can sometimes give back ops when you lose all ops or get taken over by outsiders. CHANFIX is not like chanserv or other registration services, where a "founder" owns the channel forever. Instead, CHANFIX keeps a score list of how often each person held ops in each channel. This list follows very strict rules, as described later. The highest scores go to those who qualify and held ops the most during the past two weeks. If a channel loses ops, CHANFIX will automatically re-op any qualifying former ops with the highest scores. We cannot arbitrarily op or deop anybody. CHANFIX is a last resort; it does not exist for your convenience or to substitute for good commonsense and proper channel management. You should still run your channel properly, such as requiring username@hostname and password verification before granting ops. Manually opping people, even ones you think you know, is a guarantee for disaster. To learn how to run a channel properly, we encourage you to read The New IRC Channel Operator's Guide.
1. How do I register with CHANFIX or trigger it to work?
You do not register your channel with CHANFIX. You just need to make sure that it meets certain qualifying conditions. CHANFIX then will automatically keep track of the ops in the channel. Likewise, if your channel qualifies and you lose ops, you do not need to trigger CHANFIX, it will reop your channel automatically. See the next question on qualifications and opless channels.
2. My Channel is opless, how do I get ops back?
If you have lost ALL ops, CHANFIX will restore ops automatically as long as your channel meets ALL of the conditions listed below. This process may take up to an hour or more, depending on how regularly your qualifying former ops held ops. People who hold ops all the time tend to be re-oped quickly. You cannot invite or trigger CHANFIX to do its job. If CHANFIX joins and leaves without giving ops, that means nobody on the channel currently qualifies. Read on to find out why.
2A. Conditions for CHANFIX to reop an opless channel:
You must meet ALL of these conditions. CHANFIX is an automatic service, it is not possible to make exceptions.
The channel should have existed for some time. Any channel less than a few days old is probably too new to fix, because you have not established a stable set of regular ops. Either create a new channel, or just chat on an existing channel since you might not be ready yet to run your own.
Before CHANFIX will start to keep track of your ops automatically, the channel must have at least 4 users in it. Again this is a technical minimum, but unless you really have a lot of people, it is often quicker to fix the channel yourself by "cycling" it (orgnaize everybody to /part, then recreate the channel from scratch).
Before CHANFIX can reop anybody, you must have at least 1 and preferably 5 or more qualifying former ops in the channel right now. Qualifications are listed below. (The more regular ops you have, the better, otherwise CHANFIX might reop somebody who held ops for a very short time before, because those people are the only qualifying former ops present. This can lead to fights and takeovers.)
The former ops were ops regularly during the past 4 weeks. "Regular" doesn't have to be 24/7, but it means they are usually an op - not just a few hours every few days. Anything before 4 weeks ago is irrelevant because CHANFIX only keeps records that long. It does not matter who created the channel or who is supposed to "own" it.
Their hostname or IP is "static", meaning it has not changed over the last 4 weeks, otherwise when it changes, the score for that person is reset to zero. The hostname or IP is the address following the @ in your /whois, for example if it says the hostname is "whatever.com".
The nickname does not matter, but the username must not have changed. In the example above, the "blah" before the @ symbol is the username. CHANFIX uses username@hostname to track scores.
If you meet ALL of the above conditions, just get those qualifying regular ops back in the channel. CHANFIX will automatically reop the highest scoring ops first, then it goes down the list until there are 5 ops. It may leave and rejoin several times before this is accomplished, depending on how high the scores are. Higher scores are given ops sooner.
If you just cannot meet those conditions and do not get reoped automatically, read the next section below.
2B. Why won't CHANFIX reop my opless channel?
If you lose all ops and CHANFIX does not join your channel automatically within 1 hour, then that probably means your channel does not qualify according to the conditions in the previous section.
If you lose all ops and CHANFIX joins your channel, if CHANFIX keeps joining without giving ops to anybody, it means you do have qualifying ops in the score database, and it is trying to find 5 people to op, but nobody currently on the channel qualifies. Stay calm, re-read the conditions in the previous section, and try to get those qualifying former ops back. For example if you usually have a bot or botnet holding ops, it may have the highest scores, get it back in the channel!
If you just can't meet those conditions, such as if you have a new/small channel, or if you have been opless over 4 weeks, then CHANFIX just does not have a record of your channel, and you are on your own. You must cycle the channel (clear everybody out and restart it) to regain ops. Consider it your first challenge: If you can't even manage the channel properly (by keeping ops or cycling the channel) when you have only a few people in it, imagine the chaos if you had 50 or 500 people in the future. The simple fact is, running an EFnet channel takes at least 10 people (not bots) who qualify according to the previous section. If you don't have that, what's the point of having a channel anyway? Visitors aren't going to come to some small, poorly organized channel when there are thousands of bigger channels already. If you insist on running a channel anyway, consider moving your new/small channel to a network with registration services.
2C. Why Can't you just op me?
On EFnet, nobody can just op you on any channel, not even IRC operators ("opers") or admins. There is no secret command. EFnet is not like other networks such as DALnet where they have services that give opers these powers. For more information, see Why EFnet has no registration services and The Myths of Opers.
3. We still have ops but they are all idle, can you op me instead?
As long as at least one regular op (one holding a high score) is opped in the channel, there is nothing CHANFIX can do. You need to work it out with that person. It doesn't matter if he is a bot, or idle for weeks, or doesn't want to share ops, you should have thought of that before giving him ops in the first place. CHANFIX is a last resort only when you lose ALL ops or get taken over by outsiders. EFnet does not have services like chanserv for your convenience. As chan ops, just pretend there is no CHANFIX, and learn to run your channel properly, including setting up scripts to safely request or give ops.
4. My channel was taken over, please help?
CHANFIX can be triggered manually to reverse a recent takeover. A takeover is defined as when there are still ops on the channel, but they did not hold ops before (example: you mistake a stranger for a regular and accidentally give him ops, he then deops everybody). We do NOT interfere in internal op disputes, where regular ops fight each other for control (example: there is a disagreement about who should run the channel, so one of the regular ops decides to deop everybody else). In other words, if somebody was one of your top 10 most regular ops over the last 4 weeks (anything before that is irrelevant, doesn't matter if you created the channel or if you held ops for years), he can do anything he wants including deoping everybody else. That's unfortunately what happens when you trust the wrong people, but neither CHANFIX nor anybody else can help then. Please settle it yourself or start a new channel.
If you had an actual takeover by an outsider, then you need to figure out how they got ops (accidental op, "hacked" bot/shell, denial of service attack that knocked everybody else offline, etc.). Then make sure it doesn't happen again. We do not issue fixes until you have demonstrated that you won't get taken over again right away. You should have as many as possible of your qualifying regular ops online and awake, either sitting in the channel or ready to rejoin at a moment's notice. Be ready to act to secure the channel right after the fix is issued.
How does the fix actually work? Once we verify there is a takeover, CHANFIX can be triggered manually. It would first de-op everybody and remove all modes that might keep people out (+b bans, +i invite-only, +k keyword-required, +l limit). This is when you must rejoin quickly. Then CHANFIX rejoins later and restores ops to the regular ops as it would in an opless channel.
To reverse a takeover, if you meet all qualifying conditions for opless channels, go to EFnet #CHANFIX and tell us the name of your channel, what went wrong, what you've done to prevent a recurrence, then wait quietly for help. We will get to you as soon as we can.
If you don't qualify, see the relevant section above. Good luck, you'll need it.
5. How does CHANFIX keep scores?
CHANFIX keeps track on who has ops on a channel by using a score database. To hold a score, your channel must meet all qualifying conditions above. These conditions include having a minimum number regular of ops with a static hostname/IP over a minimum period of time. If you qualify, you do not need to register or log in, and it doesn't matter if you change nicknames. The score is kept automatically according to your username@hostname.
If you qualify, for every 5 minutes that you hold ops on a channel, your score is increased by 1 point. The more regularly you hold ops, the higher your score will be. The scores are kept for only the last 4 weeks. The best scores tend to go to people (or bots) who qualify and have a 24/7 connection, and who get ops automatically as soon as they join the channel. A stable channel should have preferably 10 or more ops with high scores, i.e., holding ops at least 25-50% of the time. That way even if something goes wrong, it's obvious who are the regular ops and CHANFIX can do its job easily. Score information is accessible by IRC operators but cannot be given to you, even if you are one of the top 10 regular ops. This is to protect you and your channel against possible attacks targeted against your top ops.
For more technical discussions of how the scoring system works, see the links in the last section.
6. More Information
History: CHANFIX (originally named JUPES) was voted upon and passed by a majority of EFnet admins in April 2001, and began operation in early July 2001. You can see the original vote [ext. link] which also contains a somewhat technical comparison to other competing channel-fixing ideas.
Open CHANFIX: open source CHANFIX. Requires hybrid ircd. Replaced original CHANFIX on EFnet in 2005. Lots of detailed examples on how scoring works, how a fix is executed, etc.
CHANFIX guide for opers [ext. link]. This is a guide intended for new opers and CHANFIX helpers. It describes how one experienced helper approaches each request for help. To some it may seem overly burdensome, but really it's the most responsible, helpful approach IMHO, to make sure that the user actually learns from his mistakes and the channel actually stays fixed.
The New IRC Channel Operator's Guide. Although not technically related to CHANFIX, if more people would learn how to run their channels properly using guides like this, there wouldn't be any need for CHANFIX at all!