Support Training
Last update: MAY 31, 2020
Undernet User-Committee. Authored by: QueenElsa
The Undernet User Committee is one of the governing organs of the Undernet IRC Network. It is composed of a group of users who volunteer their time to try to improve the Undernet. This committee covers a vast amount of territory, from educational classes and
improving documentation, to holding special events and helping the network’s users. You can view all of the User-Com projects and teams by visiting their website at https://undernet.org/docs/
With such a large area to cover, the User Committee is split into several smaller projects. This allows each project to focus on a specific area. Currently, there are eight ongoing projects in operation. Each week brings another new accomplishment or task completed.
The current eight projects are as follows:
The Class Project: A weekly class that is run in #Class to help users learn more about IRC and the Undernet. Class is run in many different languages for users who don’t understand English.The Newsletter Project: An informational newsletter containing information about various technical issues, IRC related items, web page reviews, etc. The newsletter is put out at the start of every second month at the current moment, but is planning on going monthly with its issues in the very near future.
The Webmasters Project: This project is a group of web developers who oversee the various web properties of the User-Committee. They are responsible for ensuring that web properties are secure, current and insightful. Current properties include undernet.org, user-com.undernet.org, forum.undernet.org and help.undernet.org.
The Promotions Project: A group of people responsible for putting on live events in the #LiveEvents channel for the users of Undernet.
The Documents Project: This project gathers Undernet and IRC related articles to help inform users about historical and up-to-date information concerning what has happened and is happening on Undernet.
The UUS Project: This project oversees the Undernet User Script to assist people on Undernet that specifically use the mIRC client.
The Standard Response Project: This project is responsible for answering all of the users’ mail. This includes the Standard Response Team (SRT). Only members of a team affiliated with the SRT are permitted to answer users’ mails individually. This means, you should never answer mails directly to a user. It could result in your removal from the User-Com and Userguide mailing lists.
The Support Project: This project is composed of the #help and #userguide channels. These channels are staffed by User-Com members who aim to assist users with their IRC issues. #help covers general IRC issues – like connection issues and configuring a client. #userguide covers Undernet-specific issues like LoC and the websites/forum.
Users in our channels (#help and #userguide) are to be treated politely and in a courteous manner at all times. Ops are to be patient and understanding when dealing with a user. Our users have the right to ask questions without being embarrassed. Ops have to welcome and ask new people who join if they require assistance whenever possible. Doing this makes our users feel welcomed.
User questions are our first priority. We are all here for the users. Without them, there is no Undernet. Our priority should always be the users and their needs.
We try to limit use of colors and sound, since not all clients support it. We ask that users not run any script that warns about colors, sound, etc. Ops should not use scripts that kick and ban automatically without approval from the Coordinator. Remember, most of the users joining these channels are already facing an issue and might not understand what is happening.
When possible, #help and #userguide should always have available, awake volunteers. Ops should op themselves in the channel when they are present and available. If they’re not available, they should not be opped. This helps reduce confusion amongst our users. Users are welcomed to idle in our channels. This allows them to observe and learn.
Ops should work towards creating a community within our channels. This community should be inclusive of all users and new volunteers alike. It helps us build a strong relationship with the users of the Undernet as a whole.
New people willing to assist in #help and/or #userguide should send their request to userguide@undernet.org to get a standard reply from the SRT. Once this is done, they will be contacted and asked to remain in the channel for a period of time to observe and learn how #help or #userguide functions.
Once a new volunteer has observed and learned, they will take a short test. Upon passing the test, they may select or be assigned a mentor from the members of #help or #userguide.
Preferably, this will be an op who comes on at the same time as the new volunteer. The mentor would then teach and help the new volunteer with what he/she should know. In addition to doing that, the mentor would also observe the volunteer assisting users and submit a report about the volunteer at the end of the mentoring period.
It’s quite vague what happened next in the development of IRC as Oikarinen and many of the others who participated in updating and improving the technology made no formal records. What is clear is that in 1989, Oikarinen convinced several of his friends at other Finnish and Swedish universities to run the IRC server program on their computers, which were on the Finnish network which itself was inspired by the American BITNET network.
IRC began to grow rapidly as it became a more global network. In August of 1990, the network of IRC servers which had grown in size from one server to thirty eight servers in under two years split into several networks. By April of 1997, there were roughly 30,000 visits to IRC servers, each month.
Just as interesting, is that users don’t normally use their real names. When you connect to a server, you’re asked to provide a nickname (commonly known as a nick) and you’re generally free to use whatever nick your heart desires. There can be any number of people gong by the name of John or Roboto or Xena or whatever. (Some networks allow you to own a specific nickname. Undernet does not.) Because of this, things can quickly get confusing. You can change your nickname at any time with the /NICK command.
IRC users meet in channels. The official definition of a channel, according to the technical description of the IRC protocol in RFC1459 is a named group of one or more clients, which will all receive messages addressed to that channel. The definition says nothing about the content of the shared messages, but by convention, messages on a given channel are confined to one topic area.
IRC is impressive enough on a standalone server, but its magic lies in the fact that IRC servers can be linked together to form an IRC network. Publicly accessible channels on a given linked server become available to any user on any server on that network.
We should all keep in mind that, even though we are all “anonymous” on IRC, we shouldn’t abuse that privilege. Just as the Golden Rule says “Do unto others as you would like them to do unto you.” – We should treat people the way we would want to be treated. (I.E: Nicks on Undernet are not owned, but people shouldn’t take another’s nick only to disturb the person.)
Creating a channel is easy. Just type /join #channel – if no one is in it, then you’ve just created it. I there are already users in that channel, then you’ve joined it.
Before you can register a channel on Undernet, it has to be established. Channels need to have a certain number of users in it before it can be considered for registration. An additional requirement for registration is a username. You and five of your users must have usernames. If you don’t have a username, you can register for one on the Channel Services website by going to https://cservice.undernet.org/live and clicking on the Register link.
Make sure you read the terms of use carefully and follow those guidelines closely. You are responsible for any activity that occurs with your username. When you have registered your username and ensured that your supporters have registered usernames (if they didn’t already have one) – you can then take the next step and submit a registration application.
To register your channel, visit the same website you used to register your username.
Login to the site using your username and password. Once you’re logged in, you can click on the Register a Channel link. Your username must be at least 3 days old. Your supporters’ usernames must be at least two days old. None of the usernames in your application can have a history of abuse. You may register up to 3 channels, as long as you meet the following conditions:
- If your username is less than one year old: You may only register one channel.
- If your username is one year old: You may register two channels.
- If you username is two or more years old: You may register three channels.
Once your application is submitted, your supporters must vote to support or reject your application. There are two ways to complete this process. They may login to the CService website. Once logged in, they’ll be asked to confirm or deny their support. The second way is via X’s support command. When a supporter logs into X, they are given instructions on how to support the channel’s registration application.
After everyone has confirmed their support for your channel registration application, it’ll take about 3 to 5 days for the channel to be completely registered and for X to join. During this time, it is possible for people to use the website to object to the registration of your channel.
CService or Channel Services is the owner of the Channel and Username registration process. They also oversee the Channel Services Bot, X.
Channels generally are self-governing. Each channel is its own community with its own set of rules. You should follow the rules of each channel you’re in. Some channels may have a person or a bot that will provide the rules to you when you join. Others may have a website with their rules listed. For channels that don’t provide rules, they generally expect you to follow basic etiquette (called netiquette, by many) – this means avoid annoying users, don’t be rude, don’t repeat text, etc. If you follow the rules, you’re likely to be happy in the channel.
Channels are controlled by ChanOps or Channel Operators. They can be identified by the @ symbol in front of their nick. They are important to the proper function of a channel. ChanOps are given control of the channel and are able to remove (kick) anyone from a channel and stop them from returning. They are also able to set a topic in the channel. As this is an important role to any channel, you’re often only given it if you’re trusted in the channel. If you are given ops in a channel, you should respect the rules and ensure you enforce them fairly.
If you were banned because you broke a channel’s rules, you should speak to the person who banned you. Explain the situation that caused you to break the rules and promise not to break them again in the future. Then live up to your promise. You will find if you can’t stop breaking the rules in a given channel, a permanent ban may be set and enforced against you.
If you were banned and you have access to X (a minimum access level of 75), you can remove the ban yourself through X with the unban command. By typing: /msg X unban #channel banmask. If you still cannot remove the ban try contacting another ChanOp in the channel.
Here are a few useful websites:
https://cservice.undernet.org/ - The CService Website
http://www.user-com.undernet.org – The User-Com Website
https://forum.undernet.org – The Undernet Forum
https://undernet.org – The Undernet IRC Network Home Page
https://help.undernet.org – The Undernet Help Center Website
What should you do when you lose ops? – This depends on the number of users in the channel. If your channel has a low number of users, you can normally get away with asking everyone to /part then /join. The first user to rejoin will be reopped. When it comes to larger channels, you will need the assistance of someone with IRCop status.
To find an IRCop, you can use the /who 0 o command. (The first 0 is the number zero) This will display a list of IRCops that are visible to the users (I.E: The ones who don’t have the invisible mode (usermode +i) set).
When you have found an IRCop, you should make sure you have support to prove you normally have operator status in the channel. This is usually done with log files. When you know you have proof, you should contact the IRCop using the /msg command. Remember, IRCops are busy people. They may not respond straight away. You should remain patient, as they will try to assist you when they’re able to.
Some other IRC problems, such as clones/flooding, can cause you anguish. If you’re flooded, always try to turn on auto-protection in your IRC client or a bot that sets mode +Dmi quickly in the channel. Those modes will protect your channel from being flooded with CTCP, msg, join/part, etc.
If you need help regarding an opless channel or a channel being hit by clones/floodbots, /join #zT and ask for help. Be patient until someone assists you.
You’ll see a variety of quit messages from time to time that indicates a reason why a user has disconnected from the network.
- Net Splits: These aren’t permanent quits, rather it happens when two or more servers can no longer communicate with each other. This can be caused by many problems such as high internet usage, slow communication between the servers or people attacking the server. When a netsplit occurs, multiple users might quit all at once with the same message: *** User has quit IRC (*.net *.split)
- Oper Kills: These quits are the direct result of an IRCop killing a user. IRCops have the ability to force servers to disconnect a user (this is called killing a user) if they have broken the network’s rules. These quit messages look like this: *** User has quit IRC (Killed (*.undernet.org (Test ))).
The user should be able to reconnect as soon as they’ve been disconnected. Since this was only a /kill and not a gline.
- Read/Write Errors: Read Error: A read error occurs when a server cannot successfully read data from a client connected to it. When this error occurs, the server was expecting a file of a certain length, but instead of getting the expected length, the server receives an EOF (End of File)
- Write Error: A write error occurs when a server cannot write information to a client. A server normally responds to a client’s information by replying with data of its own. When the server gets an error while trying to write to the client, it will disconnect the
*** User has quit IRC (Write error: Broken pipe)
*** User has quit IRC (Write error: Connection reset by peer)
- Connection Reset by Peer: When a user sees this message, it normally means they were disconnected and the server reset the connection to the client. This kind of error can be caused by many issues – like a delayed or slow
*** User has quit IRC (Read error: Connection reset by peer)
*** User has quit IRC (Write error: Connection reset by peer)
- Ping Timeout: Servers automatically ping each user on the network regularly to make sure the user is still connected to that server. If the server doesn’t receive a reply from the user’s client for more than a few minutes, it will disconnect the user. This is usually identified by the following error: *** User has quit IRC (Ping timeout).
- Too Many Hosts: This normally happens when a user is attempting to connect to the network and has too many clones or multiple connections to the network. This can often happen if you have been disconnected and are trying to reconnect to the network while your ghost is still
- Throttled: Connecting too fast: This error occurs if a user is attempting to join a server and their client is sending data too faster for the server to handle. In response to such incidents, the server will slow that connection down. If this error occurs, the user should wait a few minutes before trying to connect again or try a different server.
- G-Lined – Open Proxy: This means that, while scanning the user’s host – the Undernet found an open socks proxy port (1080). These ports can allow remote connections. If the user has a proxy server running, they should be sure that it only allows connections from a restricted list of people – like people in their private
For example: #help or #userguide.
All mode commands are set in this fashion: /mode #channel +i Mode commands can be strung together: /mode #channel +ipm
The below table describes the modes and their meanings:
| Channel Mode: | +i |
| Name: | Invite Only |
| Description | |
| This sets a channel to invite only mode. Users can only join the channel if they’ve been invited by an op. It’s a useful mode when your channel is being attacked. To invite a user, use the invite command: /invite #channel nick |
|
| Channel Mode: | +p |
| Name: | Private |
| Description | |
| This sets a channel to private. Users doing a /whois on you won’t see this channel listed in your channels list unless they are also in the channel. This also hides the channel from the /list command and the /names command. | |
| Channel Mode: | +s |
| Name: | Secret |
| Description | |
| This sets a channel to secret. It’s very similar to the private mode. | |
| Channel Mode: | +n |
| Name: | No External Messages |
| Description | |
| This mode keeps people who aren’t joined to the channel from sending messages and notices to the channel. | |
| Channel Mode: | +t |
| Name: | Only ops set Topic |
| Description | |
| This mode prevents ordinary users from changing the channel topic. Only channel ops can change the topic. | |
| Channel Mode: | +r |
| Name: | Registered Users Only |
| Description | |
| This mode prevents users who are not logged into X from joining the channel. Users who don’t have a username can get one at https://cservice.undernet.org/live | |
| Channel Mode: | +l |
| Name: | Limit |
| Description | |
| This mode limits the number of users allowed to join the channel. The number after the letter specifies the actual limit. Example: /mode #channel +l 25 The above example prevents #channel from having more than 25 users in it. |
|
| Channel Mode: | +k |
| Name: | Key |
| Description | |
| This mode sets a key on the channel. Users cannot join without specifying the key in the join command. Example to set a key: /mode #channel +k test In the above example, the channel key is set to test. Example to join a keyed channel: /join #channel test In that example, the user is specifying the key by placing it at the end of the join command. |
|
| Channel Mode: | +m |
| Name: | Moderated |
| Description | |
| This mode limits who can talk in the channel. When it is set, only ops and voiced users may talk. This is useful if your channel is being attacked by floodbots. | |
| Channel Mode: | +b |
| Name: | Ban |
| Description | |
| This mode does not affect all users. It only affects users that match the specified hostmask. When a user matches a hostmask that has been banned, the user is not permitted to join the channel. If the user is already in the channel, they are not permitted to talk in the channel. Example to set a ban: /mode #channel +b *!*@demo.users.undernet.org In the above example, we banned all nicks and idents using the host demo.users.undernet.org from the channel #channel. |
|
This simply means they have the ability to use some server commands that aren’t available to ordinary users.
IRCops also have the ability to use Undernet’s services like EUworld in attempts to keep the Undernet together as a network. The primary responsibility for all IRCops is to ensure that their servers remain linked to the Undernet.
IRCops maintain the servers. That means, when a server is linked to the Undernet, it needs to have at least one IRCop who takes care of it. Each IRCop represents one primary server (although, they may have O:lines on other servers. These are called backup O:lines.) and should be concerned with keeping that one server connected and working well.
To become an IRCop, get yourself a t-3 one hop off of the national backbone, run your server and keep it online 24/7, then apply to Routing-Com to have it linked to the network. Or, you could also be chosen by the administrator of a server. Operators are supposed to be chosen as ones who are responsible, dedicated, knowledgeable people who can represent the server’s presence on the network.
The IDENT is used on IRC to help tell one user apart from the other. Clients which have a working IDENT server installed are identifiable because their user@host information is not prefixed with a ~ (tilde).
- ThisIsMe (ident@host.name.country) <- IDENT is installed and
- ThisIsMe2 (~email@host.name.country) <- IDENT isn’t
Channel Ops: If you have problems with flooding or abusive users, banning non-idented clients often eliminates most of the hassle - /mode #channel +b *!~*@* bans all non-idented clients. This is another reason that guests should try to get their IDENTD working correctly.
Here are some instructions to configure IDENTD on mIRC:
- Click on File > Options > Connect. (Expand this if it’s collapsed. Use the + button to )
- Click on IDENTD under the Connect
- Enable IDENTD must be
- User ID should be the same part as the first part of your e-mail: If your e-mail address is usertest@something.fake, your user ID should be usertest. (This prevents confusion of your identity if Ident should)
- System MUST say UNIX. (Yes, even though you’re likely using Windows, UNIX is what must be entered into the System box for Ident to )
The main goal for flooders on IRC is to get you disconnected from the IRC Server you use. A server usually disconnects you for sending too much data to it in a certain period of time, or if you try to send it data when it hasn’t finished processing your previous data. Below are the types of floods that occur on IRC.
CTCP Floods: This occurs when a user (or users) send you many CTCP requests in a short period of time. Your client will attempt to automatically respond to all of them which causes the server to disconnect you. mIRC’s flood protection and/or ignoring these people will stop this.
This is considered the most dangerous type of IRC flood.
Ping Flood: This occurs when a user rapidly pings you until your system becomes overloaded and you disconnect. These are very rare these days, with the more advanced floods below, but they do still happen.
Channel Text Floods: This occurs when multiple lines of text are sent to a channel.
Usually, it’s considered a flood if it’s over 3 lines.
Nick Flood: This occurs when a user (or users) change their nicks repeatedly and rapidly causing the channel to be flooded with nick change notices.
DCC Floods: This occurs when a user (or users) rapidly attempts to send you massive amounts of DCC chat requests or files to you.
If you find yourself as the target of a flood, you can stop it. The easiest way is to change your nick to something that you don’t normally use. You can also disable your client’s automatic responses to things like CTCP. If this doesn’t work, your best bet is to hide. :P
This section will provide a general overview of attacks in which the primary goal is to deny the victim(s) access to a particular resource. Included is information that may help you respond to such an attack.
The strategy of Denial of Service (DoS) attacks is to disrupt a client’s access to a server’s functionality. This can be done in several ways. One way is to flood the server with so many request that it is unable to process all of them. This causes its service to grind to a halt.
This is the method that is employed by Distributed Denial of Service (DDoS) attacks. They compromise many machines so that a signal from a control machine causes all of the compromised machines to send many requests to a specific server. Automated tools are used to search for security weaknesses and compromise vulnerable machines, so thousands of machines may be involved in the attack.
Source IP addresses are spoofed, so that the attacking machines must be tracked down one hop at a time. Because of the large number of machines and networks involved and the time it takes to contact ISP personnel to determine the source of a message it may be hours or days before the attack can be stopped.
Important things to do as a current or potential victim of packet flooding Denial of Service:
- Avoid FUD: FUD stands for Fear, Uncertainty and D The recent attacks have been obviously launched with provocation, hysteria and overreactions in mind due to the victims that have been targeted.
- Arrange with your Internet uplink provider(s): It is very important that you have assistance and cooperation from your direct backbone and uplink network providers. The bandwidth used in DoS attacks is so major, that your own network probably cannot handle it regardless of what you
- Optimize your routing and network structure: If you don’t have only a host, but a bigger network, then tune your routers to minimize the impact of DoS attacks. To prevent SYN flooding attacks, setup the TCP interception feature. Details about
this can be found at https://www.cisco.com or at your router manufacturer’s website.
Block the kinds of UDP and ICMP messages that your network doesn’t require to operate. Especially, permitting outgoing ICMP. Unreachable messages could multiply the impact of a packet flooding attack.
- Optimize your more important publicly accessible hosts: Do the same on the hosts that can be potential targets. Deny all traffic that isn’t explicitly needed for the servers you run. Additionally, multi-homing (assigning many different IPs to the same hostname) will make it a lot harder for the
We suggest that you multi-home your website to many physically different machines, while the HTML index site on those machines may only contain a forwarding entry to the pages on your actual, original webserver.
- During ongoing attacks: Start countermeasures as soon as possible. It is important that you start the backtracking of packets as soon as possible and contact any further uplink providers when traces indicate that the packet storm came over their
Don’t reply on the source addresses, as they can be practically chosen arbitrarily in DoS attacks. The overall effort of being able to determine origins of spoofed DoS attacks depends on your quick action, as the router entries that allow traffic backtracking will expire a short time after the flood is halted.
- Confirm that your hosts are not compromised and secure: There are many recent vulnerability exploits and a lot more older exploits out there. Check exploit databases such as https://www.exploit-db.com/ or https://www.cvedetails.com/ to make sure that the versions of your server software are not proven
- Audit your systems regularly: Realize that you are responsible for your own systems and for what is happening with them. Learn sufficiently enough about how your system and your server software operates. Review your configuration and the security measures you apply frequently. Check full disclosure security sites for new vulnerabilities and weaknesses that might be discovered in the future in
your operating system and server software.
- Use cryptographic checking: On a system on which you have verified that it has not been broken into or compromised, you are urged to setup a system that generates cryptographic signature of all your binary and other trusted system files to compare the changes to those files
- Shut down your systems immediately during ongoing attacks and investigate: If you detect an attack emerging from your networks or host OR if you’re being contacted because of this, you must immediately shut down your systems or at least disconnect all of your systems from any network
If such attacks are being run on your hosts, it means the attacker has almost-full control of the machines. They should be analyzed, then reinstalled. You are also encouraged to contact security organizations or emergency response teams.
SEI’s CERT Division (www.cert.org) or SANS (www.sans.org) are some places where you can request support after a compromise. Also, keep in mind that by providing these organizations the data from your compromised machine(s) left by the attacker is important, because it will assist them in tracking down the origin of the attacks.
Useful URLs
- https://www.us-cert.gov/ncas/current-activity
- https://tools.cisco.com/security/center/resources/guide_ddos_defense
- https://insights.sei.cmu.edu/sei_blog/2016/11/distributed-denial-of-service-attacks- four-best-practices-for-prevention-and-response.html
- https://www.akamai.com/us/en/resources/ddos-prevention.jsp
- https://www.cloudflare.com/learning/ddos/ddos-mitigation/
- https://it.mst.edu/policies/compromised-computer-recovery/
A channel takeover is a situation that one would describe as the following: A channel that is being owned (or rather managed) by a certain person who the other ops/users of the channel do not consider to be the real manager.
Concrete, this would mean that someone gets ops on a channel, deops all of the other ops in that channel and thus takes over the channel as the normal ops have no way of controlling their channel. The person that is taking over the channel then has all power over the channel and he/she then decides who stays, who is kicked out/banned/removed and who gets ops.
For small, unregistered channels – simply waiting until the op disconnects or leaves the channel gives you opportunity to get everyone else to voluntarily leave the channel. Then you
rejoin and if you’re the first person, you will regain ops in the channel and it will be yours again.
Sometimes, this isn’t possible. Some channels are too large to have everyone cycle in and out. Other times, a bot might be used by person taking over the channel. In such cases you will need to contact an IRC Operator.
IRC Operators (or IRCops, Opers) are people who are appointed by Server Administrators (the people who run IRC servers) to make sure that the IRC server and the IRC network run smoothly and to protect users on the network. IRC Operators use a special service called EUworld to obtain ops in a channel. They can do this without access in a channel. Even if the channel has no ops or bots.
After a takeover, you would have to contact an IRC Operator. IRC Operators can always be found in #help. It is expected that you have proof to show you manage the channel before you can get ops back in your channel. Anyone can say that their channel has been taken over. The best way to prove that you are the channel manager/owner is to keep logs on the incident. For example, if you have all IRC Sessions of yourself logged, you can prove with those logs that an actual takeover occurred. If you have logs of earlier IRC sessions showing you opped
regularly, those can also help in proving that the channel belongs to you. For this reason, it’s imperative that you enable logging in your client. The most important log is the one you might not have.
Once members of #help sees your situation, they will investigate the takeover and try to solve it in a mature way. If this seems to be impossible, an IRC Operator will be asked to handle the matter by deopping the persons taking over the channel, opping you and taking further action. Channel Takeovers are prohibited by the general guidelines and will be handled as abuse with further consequences to follow.
If you do not normally log the sessions yourself, it may be possible that some of the members of your channel do. So ask around to get logs, if possible. If getting logs of a channel takeover isn’t possible, another way to prove that you’re the channel manager/owner is a general consensus. People ready to state that the channel legitimately belongs to you. If a volunteer comes into the channel and asks if the information is correct and people verify, the matter will be solved.
The best way to protect yourself against a takeover is to register you channel with the Undernet Channel Services. When your channel is registered, a special bot named X is placed into your channel. It can take care of most channel operations. It can op people, kick people, set/reset channel modes and much more. X cannot be deopped or kicked from the channel. As a result, X is always in the channel and always has ops unless you tell X that it should leave.
Other than that, the possibility of a channel takeover is neutralized. Whenever X splits for any reason, it will always regain ops when it returns.
You can also protect your channel by using a bot. However, your bot can always be kicked from the channel or deopped by a rouge op. The best way to protect your channel, is to be aware of who you op in your channel. In other words, who is trustworthy and who isn’t. Don’t just op anyone in a channel because they joined.
Because of the nature of IRC, it’s not uncommon for channels to sometimes become opless. An opless channel is a channel which has no ops and no bots to regain ops. Effectively, the normal channel ops are unable to control the channel. Normally this would require the intervention of an IRC operator. Over the years, a new service was developed.
Chanfix or as it’s more commonly known – C – is the Undernet service that deals with unregistered channels. C works by keeping scores of how long a given user has been opped in a channel. The longer a user has been opped, the higher their score will be. Scores are kept for the top 10 ops in an unregistered channel. In the event the channel becomes opless, C will begin reopping from the top 10 list, with the highest scoring ops being reopped first.
C can’t be used to fix registered channels, though it does keep score in those channels too. The score keeping system is based on CService Usernames. In order for an op to be scored in a channel, they must be logged into a CService Username. If the ops in a channel aren’t logged into a username, then no scores are kept.
For scoring to work there are some rules that need to be kept in mind.
- You need at least 4 people in your
- At least one of those people need to be logged into X and opped in the channel. Usermode +x is
- You need to be opped in the channel for 13.5 hours in the two week scoring period in order for C to build a score for
You receive one point every 5 minutes you spend opped in the channel. In the event that your channel ends up opless, C will immediately begin to reop the channel. If people with high scores are in the channel OR if they join, C will op them first and keep reopping until 5 users are reopped or there are no more high scoring users left to reop.
If you op your friends, C will stop opping. If none of the high scoring ops login to X and join the channel, C will keep working for a few days. C knows who joined the channel in the first three days of its life and it knows who have been opped in the past two weeks. Therefore, it is important to remain opped. C’s scores are cleared after 14 days, unless you’re opped.
C can also be used to restore control to a channel that has been taken over, without an IRC Operator’s assistance. When C is reopping a channel, it will clear all modes in the channel, including bans, voices and ops. It will then begin to reop the legitimate users.
This usually happens automatically, but if it becomes necessary, you can manually trigger a reop on your own. It’s important that you know the two commands necessary to effectively use C. First, to check the scores and see who can issue a fix, use the /msg C canfix #channel command.
The canfix command will show all usernames that can ask C to fix the channel. It also shows the time they were first opped and the time they were last opped. IRC Operators use this information frequently to make determinations on who rightfully owns the channel.
Once you’ve seen who can fix the channel, if your username is scored high enough, you can request ops in the channel using the /msg C requestop #channel contact command. This command instructs C to clear all modes in the channel, deop and devoice everyone, remove all bans. Then contact the highest scoring members and reop them as they join the channel.
When C begins reopping a channel, the reopping phase lasts for 1 hour. This means, if a high scoring op joins within 1 hour of the requestop command being issued, they will automatically be opped, until the top 5 highest scoring ops have been reopped.
Scores go up as long as you’re joined to the channel. If you disappear for a few days, your score will decrease. After 14 days, your score will be purged from C’s database. It cannot be stressed enough, to maintain ownership of your channel, you must be logged into X.
There are different kinds of bots. A bot is a service on a channel. It can be placed there by the ops in the channel or by the Undernet itself. Bots provide channel ops with all of the necessary functions to manage a channel. A few of these functions are management functions used for opping people, setting channel modes, changing the topic, etc. There are also bots that don’t provide any sort of service to a channel. Those will be addressed in a lower paragraph.
Undernet Channel Service: The first and without a doubt, most popular bot on the Undernet is the Undernet Channel Service – more commonly known as X. X is run and administered by the Channel Services Committee and runs on its own server –
channels.undernet.org. X isn’t your ordinary bot. Unlike Eggdrops and mIRC based bots, X is completely safe when it is placed into a channel. This is something that cannot be guaranteed with personal bots.
Eggdrop bots: An eggdrop is a program, mostly used on Unix/Linux systems that are written specifically to run on IRC channels and provide functions to channel ops and users. An eggdrop responds to special privmsg commands or through DCC-chat to the bot. If you want to use a bot residing on a given channel, the best way is to ask the channel owner or the bot owner on how to operate it. They know how the bot is made and what functions it has. If you want to run your own eggdrop, you can go to https://www.eggheads.org/
mIRC bots: These are actually just normal mIRC clients running a special script that allow them to perform commands just like other bots do. Because of this, there is no limit to the number of commands that might exist and thus there is no list of commands for these bots.
Each scripter can customize their bot differently.
Other kinds of bots: The last kinds of bots that will be addressed here are known as abusive bots. They’re used to mess up the network and are thus prohibited by the Undernet. They can be used to create clones or even takeover channels. These are the types of bots that give bots a bad reputation.
Scripts allow you to upgrade your client. They provide additional functionality that can range from posting a quote of the day into a channel to automatically logging into X. Some even change the appearance of your client.
This document has been written to serve the most basic commands on IRC. Some of these commands may vary depending on your IRC client. The most common commands available in most clients have been covered.
In each command shown below, you may see parameters inside of [] and <>. [parameter] is optional. You do not need to specify this to use the command.
is required. The command will not function without this parameter.
| Command: | /server[port] [password] |
| Description | |
| This command connects to you the name of the server you typed in. If you specify a port – that port will be used in place of the standard port. If you specify a password, it will be used to connect to the server. | |
| Command: | /nick |
| Description | |
| This command changes your nick to whatever you specify as your new nick, if it is available. | |
| Command: | /whois [same nick] |
| Description | |
| This command shows details about the given user. By default, this information comes from the server you’re using. If you specify the same nick twice (/whois nick nick) then the information comes from the server that user is using. | |
| Command: | /me |
| Description | |
| This command is used to perform an action in a channel or private message. For example: /me hugs X will produce this response in the channel *** User hugs X |
|
| Command: | /msg |
| Description | |
| This command sends a message to the specified person. For example: /msg User2 hello J |
|
| Command: | /part <#channel> [reason] |
| Description | |
| This command causes you to leave a channel. If you specified a reason, it will be shown to the users in that channel once your client has parted. | |
| Command: | /list [keyword] |
| Description | |
| This command lists all publicly visible channels on the network. If a keyword is specified, the list will be filtered by the keyword. | |
| Command: | /names |
| Description | |
| This command lists all visible users in a channel. This will not work if the channel is set to +p or +s. Users who have mode +i set on themselves will also not be shown. | |
| Command: | /away |
| Description | |
| This sets an away message. Users who /whois you, will see your away message. If you don’t specify a message, your away message is removed and you are marked as back. |
|
| Command: | /quit [message] |
| Description | |
| This command disconnects you from the network. If you specify a reason, it will be displayed as your client is disconnecting. | |
| Command: | /query |
| Description | |
| This works similarly to the /msg command. The difference is, this command will open a dedicated window or set the current active window as dedicated to messages from the specified user. | |
| Command: | /ctcp <nick> ping |
| Description | |
| This command calculates the time it takes a message from one person to reach another person. The reply is based on Unix time and is normally converted by your IRC client. Your client might have a built in replacement for this command – for example /ping <nick> |
|
| Command: | /dcc chat |
| Description | |
| This command is used to open a direct chat with a person. It bypasses the IRC network and allows them to chat immediately. Using this will reveal your actual IP address if you’re logged into X. It’s strongly recommended that you don’t DCC chat with strangers. |
|
| Command: | /dcc send |
| Description | |
| This command is used to send files between one or more people. Using this will reveal your actual IP address if you’re logged into X. It’s strongly recommended that you don’t DCC send with strangers. |
|
| Command: | /topic <#channel> <topic message> |
| Description | |
| This command sets the topic in a channel. This command might be limited to channel ops only. | |
| Command: | /kick <nick> [reason] |
| Description | |
| This command kicks a user from the active channel. If you specified a reason, it will be shown as the user is kicked from the channel. Only channel ops can use this command. | |
| Command: | /mode <#channel> <modes> [parameters] |
| Description | |
| This command changes the mode(s) in a channel. Depending on the mode, optional parameters may be needed. Only channel ops can use this command. | |
Most of you already know this, but for those that don’t, you should probably read about it here: https://en.wikipedia.org/wiki/Trojan_Horse
A Trojan is pretty much the same. It invades your device pretending to be something funny, nice or cool. It then opens up your device to further attacks (or something much worse, deleting data or surrendering full control of your device to the Trojan operator.)
A few historically well-known Trojans are Sub7, NetBus, etc. To ensure you never get a Trojan, follow these simple rules.
- NEVER open attachments from e-mail without scanning them for viruses. If they come from an unknown source (someone you don’t know) – just delete them. If it was important, the user would’ve said so in the
- NEVER open attachments with double extensions. Examples of a double extension are as follows: file.log.pif or file.jpg.exe – Most modern e-mail clients will show you the full name of a file, including its extension. If you see multiple extensions, its
usually a sign that something isn’t right with the file.
- ALWAYS put DCC on ignore for ALL FILES. Use the disable for 3 minutes feature if you need to receive a file through DCC. NEVER EVER enable automatic DCC. This is how many IRC Trojans
Now, if you find that you have already been infected by a Trojan – start by visiting https://www.trendmicro.com/en_us/forHome/products/housecall.html and performing a free scan. This is an online virus scanner that will detect various types of viruses, Trojans, works and other malicious software on your device – then remove them.
Some other valuable resources for learning more about viruses and Trojans:
| URL: | https://www.microsoft.com/en-us/wdsi/threats |
| Description | |
| Microsoft Security Intelligence – Malware database | |
| URL: | https://www.trendmicro.com/vinfo/us/threat-encyclopedia/ |
| Description | |
| Trend Micro – Threat Encyclopedia | |
| URL: | https://docs.microsoft.com/en-us/windows/security/threat-protection/intelligence/safety-scanner-download |
| Description | |
| Microsoft Safety Scanner (manual virus scanner, no install needed) | |
The Undernet may seem very simple to the common user, but behind the scenes there are many people hard at work for the users. Many people devote their time to performing many necessary tasks to maintain the Undernet.
The Undernet is comprised of many different committees and subcommittees. Each committee works with one another to create a better network and maintain network stability and sustainability. There are a total of four committees, each having their own subcommittees/teams. They are listed below:
| URL: | https://cservice.undernet.org/live/ |
| E-Mail: | cservice@undernet.org |
| Description | |
| Channel Services Committee: This committee provides an easy method for registering channels in order to maintain channel stability, prevent takeovers and to manage a banlist and Teams: CService Abuse, Channel Registration, #CService help channel | |
| URL: | https://coder-com.undernet.org/ |
| E-Mail: | coder-com@undernet.org |
| Description | |
| Coder Committee: This committee concentrates on the continued development of the IRC protocol with the goal of making the Undernet a better chat | |
| URL: | https://www.undernet.org/ |
| E-Mail: | user-com@undernet.org |
| Description | |
| User Committee: This committee provides a voice for Undernet users and is the public relations body of the Subcommittees: Help Channels (#help and #userguide); Webmasters, Documents, Promotions, Newsletter, UUS | |
| URL: | http://routing-com.undernet.org/ |
| E-Mail: | routing-com@undernet.org |
| Description | |
| Routing Committee: This committee is responsible for evaluating new applicants for server links. The goal of this committee is to ensure only the most qualified servers are permitted to link to | |
As an Undernet user, you have access to a number of documents that help you have an excellent experience online. The User-Committee’s documents team provides a list of documents you need at https://www.undernet.org/docs which cover everything from the history to of the Undernet to the Undernet FAQ.
You can also e-mail the documents team at documents@undernet.org
There are many help and assistance channels on Undernet. There are also many knowledgeable people that can help you out with any problems you may have. Here are some of the places on Undernet that you can go to for help:
| Channel: | #cservice |
| Description | |
| For registered channels and issues regarding X. | |
| Channel: | #help |
| Description | |
| General IRC help and assistance. | |
| Channel: | #opschool |
| Description | |
| A CService class for new ops/channel managers. | |
| Channel: | #user-com |
| Description | |
| The Undernet User-Committee’s home channel. It’s always staffed with helpful people. | |
| Channel: | #userguide |
| Description | |
| The User-Committee’s help channel. Its goal is to handle Undernet-specific issues. | |
| Channel: | #zt |
| Description | |
| Technical help channel. | |
The Undernet also provides e-mail addresses where you can get help. Here’s a few that cover most of the topics that users often ask about.
| E-Mail: | abuse@undernet.org |
| Description | |
| Abuses or misuses of power by IRC Operators. This address does NOT deal with channel affairs. | |
| E-Mail: | cservice@undernet.org |
| Description | |
| Channel Services mailing list. | |
| E-Mail: | help@undernet.org |
| Description | |
| For general IRC help and assistance. | |
| E-Mail: | opschool@undernet.org |
| Description | |
| For new ops/managers who need to learn about opping. | |
| E-Mail: | user-com@undernet.org |
| Description | |
| The User-Committee’s mailing list. | |
| E-Mail: | webmasters@undernet.org |
| Description | |
| Maintainers of the Undernet website. | |
This document describes the guidelines which official volunteers are to follow. Keep in mind that these are guidelines, not rules.
When you’re helping in one of our help channels (#help or #userguide) you should keep these in mind:
1. You are there to help the user. Not make them more frustrated.
2. There is no such thing as stupid questions.
3. Be polite.
You are there to help the user. This is the most important thing when in the channel. If for some reason, you can’t help in the channel for an extended period of time, deop yourself. When you return and are available to assist again, reop yourself.
There is nothing more frustrating than for a user to enter a help channel and see it full of idling ops. A user generally gives a channel only once chance. One mistake and he/she is gone.
Remember, there is no such thing as stupid questions. The user can ask any question he/she likes. Even ones that are covered in the help files. Don’t worry if you don’t know the answer to the question, maybe someone else does. In such a case, inform the user that you don’t know the answer and point him/her to someone else or to the userguide list.
Be polite, no matter what the user says, asks or does. Just greeting a joining user when they come into the channel creates a pleasant and friendly atmosphere for the user. Of course, this only works if there are only one or two volunteers greeting.
Keep in mind, being polite doesn’t mean that people can just walk all over you. If a user begins to act out of line and harasses you or other users, give them a fair warning. Explain to them the error of their ways and why their behavior isn’t permitted. Should the bad behavior continue, kick them from the channel.
Never reply back with insults or anything like that. Most users who are out to cause problems just like the attention. This just inflames the situation and disrupts the channel and the experience for other guests.
Keeping these guidelines in mind when helping users will make the experience better for everyone and help make Undernet a better network for all.
Undernet Sponsors
We would like to thank the following organisations for helping to sponsor the Undernet and for providing the many different aspects used for the network's structure and other services.
