Vertical Base

Box Border

  Stable Branch Source/*NIX Win32 Win32 SSL
   All Downloads

Box Border
Frequently Asked Questions

What is the current version and when will next version be released?
The latest Stable version is, released on November 23, 2013. This was an update to 3.2.10 (Dec 2012) and (Apr 2013).

There's currently no time estimate for a 3.2.11 release.

What's new in the latest version?
Have a look at the Release notes of Unreal

I found a bug or I have feature suggestion
If you think you found a bug, or you have a feature suggestion for us, please report it at
This process only takes a couple of minutes.

We use bugtracker software so we don't loose track of bugs, so PLEASE report it there and don't report bugs to us via IRC, email, forums, or any other way... all that will happen is we will forget about it and then your bug will not be fixed.

The bugtracker aids us with coordinating what bugs should be fixed in next version, what has priority, which bugs are similar (or duplicates) and thus may help us spot patterns, who should fix what bugs, etc.
Begin - I got this .tar.gz thing, what to do with it? how to extract?
If you don't know how then you SHOULD NOT run this ircd. UnrealIrcd requires some basic knowledge about networking, IRC and *NIX.
Begin - What's a nameserver?
If you don't know how then you SHOULD NOT run this ircd. UnrealIrcd requires some basic knowledge about networking, IRC and *NIX.
Begin - What to do after extracting? How to config?
Have a look at the README file :).
Compiling - configure: error: C++ preprocessor "/lib/cpp" fails sanity check
If you get this when you did ./Config:
checking how to run the C++ preprocessor... /lib/cpp
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
Fix: This means you need to install a C++ compiler, usually this means you need to install a package named "gcc-c++", "g++", or something similar. After doing that, re-run ./Config and the error should no longer be there.

This issue is also fixed in Unreal3.2.5
Compiling - I ran ./configure and got tons of problems
Do NOT use ./configure! Use ./Config instead.
Compiling - make: *** No targets specified and no makefile found. Stop.
Did you run ./Config?
Probably something went wrong when running ./Config, take a look at the output :P. Maybe you don't have a C compiler or you are compiling on a non-support(-yet) OS.
Compiling - (v)fork: Resource temporarily unavailable
You are trying to compile you ircd on a nice shell and your sysadmin has set your process limit too low.
Explain the problem to your sysadmin (say you are unable to compile because of the process limit) and paste the error to him.
Compiling - undefined reference to RAND_query_egd_bytes
This is a problem with your system. the version of your openssl header files are not the same version as your openssl library files. Probably you have multiple (mixed) openssl versions on your system (ex: /usr/lib vs /usr/local/lib, /usr/include vs /usr/local/include, etc).
Try something like this:
# locate
# locate opensslv.h
# grep OPENSSL_VERSION /usr/include/openssl/opensslv.h
#define OPENSSL_VERSION_NUMBER  0x0090702fL
#define OPENSSL_VERSION_TEXT    "OpenSSL 0.9.7b 10 Apr 2003"
# strings /usr/lib/|grep 0.9.
SSLv2 part of OpenSSL 0.9.7b 10 Apr 2003
SSLv3 part of OpenSSL 0.9.7b 10 Apr 2003
[in this case the versions matched and there were no multiple header files / conflicting libraries (you can have both 0.9.6 and 0.9.7 libs)]
Compiling - ../include/struct.h:68:23: tre/regex.h: No such file or directory
If you get something like:
$ make
Building src
make[1]: Entering directory `/home/irc/Unreal3.2/src'
gcc -I../include -I/home/irc/Unreal3.2/extras/regexp/include -pipe -g -O2 -funsigned-char -export-dynamic   -c auth.c
In file included from auth.c:21:
../include/struct.h:68:23: tre/regex.h: No such file or directory
In file included from auth.c:21:
../include/struct.h:797: error: parse error before "regex_t"
../include/struct.h:797: warning: no semicolon at end of struct or union
../include/struct.h:800: error: parse error before '}' token
In file included from auth.c:21:
../include/struct.h:1200: error: parse error before "regex_t"
../include/struct.h:1200: warning: no semicolon at end of struct or union
../include/struct.h:1282: error: parse error before "regex_t"
../include/struct.h:1282: warning: no semicolon at end of struct or union
make[1]: *** [auth.o] Error 1
make[1]: Leaving directory `/home/irc/Unreal3.2/src'
make: *** [build] Error 2

Then it means something went wrong during ./Config, so check out the last output of that.
Also make sure the date/time on your system is correct (run 'date') or else things will be wrong anyway.
If that didn't work, let us know of the problem and report it on, be sure to include the last 30 lines or so from the ./Config output, and the 'make' output as well, Thanks.
Compiling - Windows: unresolved external symbol ..
This can mean multiple things, but if you get unresolved symbols in non-windows functions, such as:
  Creating library L_COMMANDS.lib and object L_COMMANDS.exp
M_OPER.obj : error LNK2019: unresolved external symbol _sendto_snomask_global re
ferenced in function _m_oper
M_INVITE.obj : error LNK2001: unresolved external symbol _sendto_snomask_global
src/modules/commands.dll : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Then this is because the wircd.def file is not up to date with your compile settings. Fixing this is simple, you need to download dlltool.exe and place it in your path (eg: c:\winnt\system32). Then, for compiling you use something like this:
nmake -f makefile.win32 [your other options here]
nmake -f makefile.win32 SYMBOLFILE
nmake -f makefile.win32 [your other options here]
So basically you just run nmake -f makefile.win32 SYMBOLFILE and then restart compiling again.

If that didn't help, then this is a different problem (eg: old compiler, too new compiler, invalid compile environment, etc).
Compiling - set owner/group ..: Operation not permitted
If you get something like:
mv: Makefile: set owner/group (was: 1002/0): Operation not permitted
config.status: creating src/modules/Makefile
mv: src/modules/Makefile: set owner/group (was: 1002/0): Operation not permitted
config.status: creating unreal
mv: unreal: set owner/group (was: 1002/0): Operation not permitted
config.status: creating ircdcron/ircdchk
mv: ircdcron/ircdchk: set owner/group (was: 1002/0): Operation not permitted
config.status: creating include/setup.h
mv: include/setup.h: set owner/group (was: 1002/0): Operation not permitted.
Then you can safely ignore these warnings.

Long story: if /tmp is mounted with special options, then files copied to there will have their user/group changed, ./Config tries to correct this but that's denied. This is a completly harmless warning, so you can safely ignore it.

Compiling - make: don't know how to make w. Stop
DO NOT use 'gmake', use 'make' instead (as ./Config said when it finished).
Compiling - Windows: I'm unable to compile UnrealIRCd on windows
First of all, be sure to have read doc/compiling_win32.txt to see what you need and how to compile.
HOWEVER, see below for a list of compiler versions that work and do not work.

Version:Official name:Works?Details:
6.0Microsoft Visual Studio 6.0NoNo longer able to compile Unreal
7.0Microsoft Visual Studio .NET (2002)Yes
7.1Microsoft Visual Studio .NET 2003Yes
8.0Microsoft Visual Studio 2005YesWorks since 3.2.5.
9.0Microsoft Visual Studio 2008YesWorks. Used for official compile.

Compiling - FreeBSD: libtool: compile: cannot determine name of library object from `'
If you get something like this:
if /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -g -O2 -Wall -MT tre-ast.lo
-MD -MP -MF ".deps/tre-ast.Tpo" -c -o tre-ast.lo tre-ast.c; \
then mv -f ".deps/tre-ast.Tpo" ".deps/tre-ast.Plo"; else rm -f ".deps/tre-ast.Tpo"; exit 1; fi
libtool: compile: cannot determine name of library object from `'
gmake[3]: *** [tre-ast.lo] Error 1
gmake[3]: Leaving directory `/home/irc/Unreal3.2/extras/tre-0.7.2/lib'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/home/irc/Unreal3.2/extras/tre-0.7.2/lib'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/home/irc/Unreal3.2/extras/tre-0.7.2'
gmake: *** [all] Error 2
Then this is a weird FreeBSD problem (rare?).

In any case, upgrading the bash package should fix it.
Compiling - FreeBSD: make: permission denied
NOTE: This issue has been fixed in Unreal3.2.5

The problem
On *BSD you sometimes get this error after ./Config:
make: Permission denied

The solution
If you then type 'whereis make' and then 'make' again, it usually works. Same can be achieved by logging out of the shell and then logging in again, and running 'make' (in the Unreal3.2 directory of course)

If you get this when compiling for SSL for the first time, then generating the SSL certificate is likely to have failed as well (server.key.pem etc missing). In that case, also type 'make pem' to create it.

This is a FreeBSD bug, it does not happen on my 5.2.1 and 4.x but it does happen on 6.x (though others may be affected as well). It happens both in bash and tcsh, making us suspect it's not a shell-specific problem. The problem has also been noted by the eggdrop guys (faq item 10).

Unreal 3.2.5 has a workaround for this problem (doing a simple directory change after executing make), though this obviously is not a real fix. Someone should bug the FreeBSD guys instead (FYI, running ./Config on 3.2.5-rc1 and enabling SSL makes this 100% reproducable on any affected boxes)
Booting - Windows - It doesn't start?? nothing happens!
Check service.log (or ircd.log) and fix your errors.
Booting - Windows 2003: UnrealIRCd does not boot
A few users get this error message when they try to start UnrealIRCd on windows 2003:
[error] resolver: ares_init_options() failed with error code -1 [(null)]
Workaround 1: Set DNS Server
This problem appears if you don't have any DNS server set. So simply setting a DNS server in your network configuration (for your network adapter) in windows 2003 will fix it.

Workaround 2: Use XP compatability mode
  • Open up explorer and go to your UnrealIRCd directory
  • Right-click on wircd.exe, and choose "Properties"
  • Tab "Compatability", set "Compatability mode" to "Windows XP"
  • Click OK
  • Try to start UnrealIRCd again
Next release this will be fixed
In 3.2.6 this issue will be fixed (Unreal will use set::dns::nameserver as a fallback whenever it can't get the nameserver's IP from the windows registry).
Booting - Someone forgot to load modules with proper commands in them
You didn't load the commands module, you need to load some modules in order to get UnrealIRCd to work. Be sure to have the following lines in your unrealircd.conf:


loadmodule "src/modules/";
loadmodule "src/modules/";
loadmodule "modules/commands.dll";
loadmodule "modules/cloak.dll";

Booting - failed to load: src/modules/
The built-in proxy scanner has been removed because it made the ircd unstable. You can use BOPM instead
*NIX / main site:
Windows build/installer:
Booting - set::<something> missing
You didn't set a required variable in your set block. All variable are explained in detail in the documentation (set block).
Booting - <someblock> { } block missing
Your configfile doesn't contain a required block, please check the documentation which describes every block in detail.
Booting - unknown directive
Several possibilities:
a. you have a unknown/misspelled variable name.
b. you forgot to load a module
c. you are using an older unreal version (note that the online documentation is about CVS so it may contain features not yet available in the current release).
d. you have put the setting in the wrong place, for example set::options::dont-resolve means set { options { dont-resolve; }; };.
e. you have a parse error in your config file. For example, the admin block should be something like:
admin {
If you forget a ; or a } it won't work!
Booting - illegal something::class, unknown class 'something'
You are referring to a class which you didn't declare before. You refer from allow/oper/server blocks to class blocks so the class blocks should be defined _before_ you refer to them. See the documentation about the class block.
Booting - listen with SSL flag enabled on a non SSL compile
You didn't compile your IRC Server with SSL support but have ssl in your listen::options block. Either remove the ssl from your listen options or recompile the server with SSL support (answer Yes to the ./Config question about SSL).
Booting - link somelink with SSL option enabled on a non-SSL compile
You didn't compile the ircd with SSL support and have ssl set in your options block of a link, either recompile with SSL support or remove it from your link::options block.
Booting - link somelink with ZIP option enabled on a non-ZIP compile
You didn't compile the ircd with ziplinks (zlib) support and have zip set in your options block of a link. Either recompile with zip links support or remove it from your link::options block.
Booting - The OS enforces a limit on max open files
If you get:
The OS enforces a limit on max open files
Hard Limit: 512 MAXCONNECTIONS: 1024
or something similar, then your OS is limiting your maximum number of open files/sockets... You need to rerun ./Config and answer the number showed in "Hard Limit" (512 in this example) to the question "How many file descriptors (or sockets) can the IRCd use?", and recompile (make clean; make).
Booting - set::cloak-keys: (key 1) Keys should be mixed a-zA-Z0-9 ..
With the new cloaking method that got introduced in 3.2.1 the cloak keys use a new format.
You now need to use a string with random lowercase (a-z), uppercase (A-Z) and digit characters. The string should be 5-100 characters long (10-20 is just fine)
So for example:
set {
 cloak-keys {
As always, these cloak keys must be the same on all servers on the networks or else bans won't work correctly.
Booting - Error binding stream socket to .. Address already in use
This means another process is listening at this port. Usually it's on of these:
- An ircd process is already running
- You are on a shell box, you then have to bind to a specific IP in your listen block instead of *.

Booting - It seems to start but the screen goes away / connection refused ??
Check ircd.log or service.log :).
Booting - I've a self-compiled windows version and it crashes on startup!
If you compiled with zlib, openssl or remote includes support, be sure you checked out the win32 development page and use the win32 development package.

NOTE TO END USERS: If you did not compile your own UnrealIRCd versions, see Other - My server crashed! on what to do.

Booting - [error] ERROR: No cloaking module loaded.
You need to load a cloaking module. This was mentioned in the release notes of 3.2.1 (and is also mentioned in example.conf):
== [ NEW ]==
- [!] Cloaking has been modulized.
  - This means you now MUST load a cloaking module in order to boot.
    Example: loadmodule "src/modules/";
  - 2 cloaking modules are provided: 'cloak' and 'oldcloak':
  - 'cloak' is the new, RECOMMENDED, and much more secure cloaking algorithm that uses
    md5 internally. It requires 3 keys of 5-100 characters (10-20 is fine) consisting
    of mixed lowcase (a-z), upcase (A-Z) and digits (0-9). So for example:
    set { cloak-keys { "AHsHS6ds2sQGAkish"; "qF5D3orm6Evba26hjf"; "f6oaO2hhd6sIHSfs"; };
  - 'oldcloak' is the <=3.2 cloaking algorithm, it is ONLY ment for use during the
    upgrade process (it will give a warning if you use it), you should switch to the
    much more secure 'cloak' module as soon as all your servers are upgraded.
  - 3rd party cloak modules are also possible.

Booting - failed to load: src/modules/
If you are on windows:
loading the commands and cloak module is required, but you need to specify the proper paths for them. Remove the old loadmodule lines and add these:
loadmodule "modules/commands.dll";
loadmodule "modules/cloak.dll";
If you are on *NIX: Most likely something went wrong with your compile... check if src/modules/ is present in your unreal source dir. If it is, and you specified a different path than the defaults in ./Config, make sure the path in your loadmodule line is correct (eg: perhaps for you it should be modules/
Booting - Unexpected EOF for section starting on line NNN
If you get a message ike:
[error] unrealircd.conf: Unexpected EOF for section starting on line 123
Then this means you forgot a };, " or ; somewhere BEFORE that line number (could be 1 line above, but also 100 lines earlier).
Here's an example of what is GOOD:
admin {
And here are some examples to show what is WRONG:
admin {
admin {
admin {

Booting - * unrealircd.conf:xx: loadmodule src/modules/ [..] undefined symbol: [..]
If you get undefined symbol errors such as:
* unrealircd.conf:52: loadmodule src/modules/ failed to load: tmp/ Undefined symbol "ssl_get_cipher"

Then most likely you did not upgrade or (re)compile UnrealIRCd properly:
make sure you do: 'make clean; ./Config; make && make install'

Reasons why it might not have worked:
- Perhaps you forgot 1 of the steps of above
- Make sure your irc is installed in the path you think it is: 'grep PATH config.settings' will show you what the IRC installation directory is and the path to the ircd binary.
- Perhaps the ircd binaries or modules (.so's) are still the older ones, double check by ls -al'ing them (use the PATH information from above!) and checking the date/time

If all that didn't work, try a clean UnrealIRCd... rm -rf or rename your current one, extract a fresh .tar.gz and configure&compile it (you can just use your original configfiles/motds/rules/etc of course).
Linking - Users on my Windows server are getting killed by other servers very soon after linking
There was an issue in 3.2.10 on Windows where users would get killed on the Windows server by other servers soon after linking. Also other errors where broadcasted to all IRCOps.
Here are a few examples of error messages that could occur:
Notice -- Received KILL message for XXX!yyy@zzz from xxxxx Path: irc!xxxxx (XXX <- YYY)
Cannot find server XX (&....
Missing user XX in SJOIN for #...
The solution is simple: upgrade to UnrealIRCd!
Linking - Trouble with linking two servers
Please check on both sides which messages you get... The *receiving side* will have the detailed error message. Take a look at the documentation on the Link block. The error messages are explained here:
No link block named 'something'
The server does not have a (correct) linkblock with that name, it should be: link servername {. Servername is the name of the remote me { } block, not the ip or something.
Username 'something' didn't match 'blabla'
The link::username field didn't match, just use: username *;
Server is in link block but IP/host didn't match
The servername and username are right, however the link::host and/or link::ip fields didn't match, you should fill in the right hostname or ip of the remote server, this is used both for connecting and validating. Example: hostname;
Linking - Connection reset by peer directly after connecting
Multiple possibilities... Are you perhaps connecting to a SSL port while you don't have ssl in your link options block? If that wasn't the problem, check both sides for error messages, check host/ip/port, etc.
Linking - Connecting to blabla and then nothing?
Multiple possibilities...
SSL: Do you have ssl in your link options field and are you perhaps connecting to a non-SSL port? Do "/mode yourself +s +j" and if you get something like "Internal OpenSSL error or protocol error" then this is probably the case (if you do want to link with SSL then also make sure both servers are compiled with SSL support).
Network: Check link::ip, link::host and link::port.. Also check if the remote host isn't firewalled (?). The easiest way to do this is to simply telnet from server A to server B to the irc port and see if it gets connected.
Linking - Colliding server numeric
Your me::numeric should be different at all servers, see the documentation on the Me block.

After changing the numeric you simply do a /REHASH (note: if you are linked to any servers, you must unlink them first, before rehashing).
Linking - Link blah is having a different cloak key
Your cloak keys (set::cloak-key) should be the same at all servers. If you ignore this advice then bans at cloaked hosts won't work correctly (because the cloaked host will differ between servers).
Linking - (sync) Possible negative TS split at link (1078875430 - 1078875478 = -48)
If you get such a warning this means your clocks are not synched.
Correct time is VERY important for IRC servers, if the clocks are off for just 20 seconds you may run into trouble already. If your clocks are minutes or even hours off, you are guaranteed to have problems.
To name a few:
- temporary *lines/shuns will not expire correctly, they might expire like an hour earlier (or even directly on add) or later
- sudden (wrong) nick collision kills
- channels might not show up in /LIST (this requires the time to be off by 24h or more)
- services might be unable to set a user +r (+r = register user)
- more..

Synch the server clock - *NIX
You should run ntpd (=daemon) or ntpdate (=simple util, usually ran via cron) on all your servers.. this is pretty easy to set up and once it's working it should take care of all your worries. Note however that this requires root access.
Synch the server clock - Windows
There are various time synching progs out there (just google), but newer windows versions (XP, 2003) should already do it automatically.

Synch via services or /TSCTL
This can ONLY be used if your clock is off just for like <30 seconds because the ircd may stall [!] till it's synched again. So if you are off for 10 minutes and you use tsctl or services to synch all clients on the ircd MAY BE FROZEN FOR 10 MINUTES! Therefore, be very careful with this command.

About timezones
Note that linking ircds from different timezones is NO PROBLEM because GMT time is used for everything.
Linking - connect: Invalid argument
If you get an "invalid argument" error when trying to connect (either via /connect or autoconnect) then you could be experiencing an odd-unreal-behavior-issue.

Fix: specify the IP to bind to in bind-ip inside your link block (eg: "" instead of "*"), use the IP of the box itself here [not the one to connect to!] ;).

Another way to fix: reorder your listen lines (eg: move the top one to the bottom, etc) and restart the ircd, see if that helps.

Connecting - Unable to resolve server
This means you do not have your DNS properly configured. If you are connecting to for example '' then you need to OWN the domain '' and add an A record for 'irc' and point it to your IP.

This is really basic network admin knowledge.

Connecting - I can't connect / connect timed out / ..
If you are connecting locally: If the IRCd is on the same box as you then try '/server', if the ircd is running and your listen lines are correct (the default ones are ok) then you should be able to get onto the ircd. If not (still talking locally here), then most likely your ircd is not running or your listen blocks are wrong.

If you are connecting remotely: See next question (below).
Connecting - I'm trying to run my ircd from my cable/*dsl connection but outside users can't connect!!
First of all, always try connecting with the IP first, so instead of '/server' try '/server' where is your internet IP (the one of the IRC server).

If that didn't work, and you verified the ircd is running (eg: task manager on windows, or 'ps x' on *NIX), then most likely you have:
1. A router in between
2. A firewall

If you have a router you need to forward 1 or more ports to your IRC server, usually port 6667. To find out how to do that, consult your router documentation; Unreal support is not Router support!
For a firewall, you will need to allow the IRC ports in (usually 6667). Consult your firewall documentation on how to do it.
Running - Unreal freezes/crashes on FreeBSD 6.1 after a while (possibly random)
We have had multiple reports of freezing (unresponsive) ircd's on FreeBSD 6.1 (with any UnrealIRCd version). Sometimes even going as far as unkillable processes. It is assumed FreeBSD 6.1 has a bug that causes this.

Upgrading to FreeBSD 6.2 is said to fix this (we had a report that "a TCP socket bug has been fixed in 6.2").

Running - Helpop doesn't work
You probably didn't include load the help file in your unrealircd.conf. Add:
include "help.conf";
Also if you are an oper (helpop) you must prefix your request with a "?", like: "/helpop ?" and "/helpop ?usercmds".
Running - ircop - I can't op myself / I can't join a +k/+i/etc channel!
Since this can be pretty abusive you need an additional flag called can_override in your operflags (see oper block).
NOTE: don't forget to /rehash and re-oper (mode yournick -o and then /oper again)!

If you have can_override, you can now op yourself (/mode #chan +o yournick) or without can_override as a services admin or higher you can use /samode #chan +o yournick.
To join a +k/+i/etc channel you need to invite yourself, it will then override it.

Running - I've k/g-lined myself!!!

One possible solution to get in again:
Edit your unrealircd.conf and add an exception block & except ban block for your IP.
For example:

except tkl { mask *@; type { gline; gzline; shun; }; };
except ban { mask; };
And then run './unreal rehash'. These exception blocks will make you immune from: glines, klines, gzlines and shuns. At the time of writing (unreal3.2.2) there was no exception for 'zline' yet.

NOTE: There's no way to remove *lines from the shell, in case you wondered ;).
Running - /helpop doesn't work
First, you need to include help.conf in your configfile, like:
include "help.conf";
2nd, if you are an ircop (helpop) you need to prefix your request with a ?, so: "/helpop ?", "/helpop ?usercmds", etc...
Running - I can't /oper myself
* First of all are you listed in '/stats o'? If not then there's some problem with your oper block. Oh and don't forget to /rehash of course ;)
* Try first with oper::from::userhost set to *@* and after you succeeded in /oper'ing up you can set it more strict if you want.
* you must oper up by typing: '/oper username password'. both username and password are case sensitive!

Running - I want to broadcast a GLOBAL message, how?
You could use: /notice $* Hi this is a message blabla but this requires all of your servernames to end in :P.
If you have services, you usually use operserv for this, like: /os global Hi this is a message
Running - If I type /list (even as ircop) it hides certain channels
First, /list does of course hide +s channels unless you are an oper or already in that channel.
Another possibility is that it's the channelname, mIRC for example has an option called 'Hide non-alphanumeric channels' under 'list options' which is enabled by default and which will hide channels like #.blah, other clients might have similar "features".
There's another possibility as well, if the time on your servers are off by 24h then some or all channels will be hidden.. Solution: SYNCH YOUR CLOCKS.
Running - Warning! Possible desynch: SJOIN for channel .. has a fishy timestamp (XX)
In older Unreal versions (3.2.2 and earlier) this happened after a while after an oper used /SAMODE with certain parameters, this has been fixed in 3.2.3.
If you still get this problem and all your servers are running Unreal3.2.3 then there are still a few posibilities:
- a protocol error, by for example weird services.
- memory corruption

The only solution for it is to recreate the channel. So: let everyone leave the channel and after everyone has done that, join again.

Technical details: the timestamp is when the channel has been created and is measured in epoch time (the amount of seconds since 1-1-1970 00:00 GMT), obviously values like '1' or '30' are impossible.
Running - I (suddenly) got clients quiting with Max SendQ exceeded!
Increase your class::sendq

This happens when a client issues a request that will return A LOT of data, usually '/who' (eg /who #channel). If you for example have huge channels like 300+, 500+ etc... then /who #chan will return A LOT of data, therefore the max sendq (sendq == send queue) is reached and the client is disconnected... Some scripts do a '/who #chan' on join, this explains why certain people will die directly on join, while others will not :).

The solution is to simply increase the sendq, what the best value is.. I can't say, but just double it and see if that works.

Running - hostnames are not resolving
You get *** Couldn't resolve your hostname; using your IP address instead?
The best way to test is to let someone from a remote location (not your LAN) connect to you where you can be sure of his host resolves (for example it works at ircnet/efnet/undernet/..). If it doesn't work, it's probably something with your box or unrealircd:

Currently the 3.2* series ignore the set::dns block and read the nameserver info directly from /etc/resolv.conf (*NIX) or the registry (windows). Type '/quote dns i' (as an oper) to see the current nameserver in use by UnrealIRCd, if you changed your nameserver settings in resolv.conf or in windows then you will have to RESTART (not rehash).

Example of how to test your nameserver at *NIX:
# host domain name pointer test.domain.
# host test.domain
test.domain has address
In this example the host is correct and the nameserver seems to work fine.

Perhaps your firewall/router?
UnrealIRCd uses it's own resolver and listens on a random udp port, this could in rare cases cause problems with firewalls (for example if you use a remote dns server and a dumb+strict firewall). If you type '/quote dns' (as an oper) you'll then see something like: Ca 0 Cd 0 Ce 0 Cl 0 Ch 0:0 Cu 0 Re 0 Rl 5/0 Rp 0 Rq 5 Ru 0 Rsh 0 Rs 10(5) Rt 5
the Rp 0 means it received 0 replies, clearly a problem here.

Running - I'm getting tired of spam/advertising/worms etc!
3.2-RC1 contains "spamfilter", an effective tool for fighting spam. Read more about it in the docs.
Running - Exiting ssl client [..] Internal OpenSSL error or protocol error
If you get messages like:
Exiting ssl client [@]: SSL_write(): Internal OpenSSL error or protocol error
Exiting ssl client [@]: SSL_write(): OpenSSL functions requested a read()

Or anything else like that then it's nothing to worry about, these are sent to the JUNK snomask.. which is.. guess what? for junk...
What this error message means is that someone (or something) tried to connect to the SSL port but something went wrong.. in almost all cases it is a non-SSL client connecting to a SSL port, things like a bot, another server (w/autoconnect) or services trying to connect every X minutes...

To summarize: it's usually nothing to worry about and not an attack, unless you get like X msgs of these per second the whole time ;).
If you don't like it, remove the junk snomask (/mode nick +s -j).

Running - I don't get an oper/admin/.. host when I oper up!
You need to have set::hosts::host-on-oper turned on and have the get_host flag in oper::flags.
When you have both of them enabled it should work.

NOTE: As usual.. always /rehash and re-oper (/mode yournick -o, and /oper up again) to test it.
Running - I've added an operflag but it doesn't seem to work!
Of course you need to /rehash (and check if it doesn't give you any errors or warnings)...
And if you have changed the oper block then you ALSO need to re-oper, so:
- /mode yournick -o
- /oper nick pass

Running - Temporary *lines/shuns are remove too early/too late on different servers!! (*line desynch)
If you add a new gline/gzline/shun with a time limit (say, 300 seconds) and:
- some servers immediately remove it after it was added OR:
- some servers don't seem to remove it at all (or perhaps XX minutes or hours too late!)
(if you are not on those servers you can easily check it remotely via /stats)
Then most likely your clocks aren't synched correctly!
You can check this out via /TSCTL ALLTIME, this will show something like:
*** TStime=1086743157 time()=1086743160 TSoffset=0
*** TStime=1086743157 time()=1086743159 TSoffset=0
*** TStime=1086740151 time()=1086740151 TSoffset=0
As you can see the difference between the alpha+beta and gamma are ~3000 seconds, this is WAY too much.. it may only be a few seconds, anything over 15 seconds is not recommended and likely to bring you into trouble.

Synch the clock
See this FAQ item about how to synch your clocks and more info.
Running - All my users disappeared in the channel / some users cannot see everyone!!?
Most likely you (accidently) set channelmode +u. +u (auditorium) hides normal users (users without voice, ops, etc) in the nicklist and doesn't show join/parts/quits/.. for them to other normal users. It is ment for celebrity alike chat systems, read-only news/announcements channels, and things like that.
Running - WARNING: (g)zlines should be placed on user@IPMASK, not user@hostmask
You do something like /(g)zline * and get:
WARNING: (g)zlines should be placed on user@IPMASK, not user@hostmask (this is because (g)zlines are processed BEFORE a dns lookup is done)

zlines (and global zlines, gzlines) need to be placed on an IPmask and not a HOSTmask. The reason for this is that zlines are processed right after accepting the connection, before any data is received and before any dns lookups are done. So a (g)zline disconnects the user IMMEDIATELY (that's, in fact, the difference between (g)zlines and klines/glines).

Place the ban on the IP of the user (eg: *@, you can get this by /whois'ing the user (the 'connecting from' line). If the user already left then you could use your '/dns [host]' client command, although that's a tad less safe[1].

[1] If the bad guy owns the domain, then he might have updated his name to point to another ip.
Running - I want to disable host cloaking (hosts like:
What is cloaking?
Cloaking is a means to hide the real host from other users, for resolvable hostnames it looks a like, and IP's will look like 9DD2051.356EF559.713C47B6.IP. You get a cloaked host by the usermode +x (this can be manually set, or automatically by the server). For more general information on cloaking, see the section on cloaking in the docs.

How to disable it?
You have several options:
Option 1: make cloaking not the default
Just remove the 'x' in set::modes-on-connect, then users will not be set +x automatically and thus will not be cloaked.
Users can still, if they want to, set themselves usermode +x.
Option 2: fully deny users to be cloaked If you don't even want users to be cloaked when they want themselves to, in other words: prevent users from setting themselves +x. Then like the previous step, remove 'x' from set::modes-on-connect if it is present, AND set set::restrict-usermodes to 'x':
set { restrict-usermodes "x"; };
Option 3: load a "nocloak" cloaking module
While option 2 is recommended if you really want to disable cloaking, it still requires you to set cloak keys etc... To really remove the whole cloaking algorithm from the server you can load a cloaking module that does nothing (iotw: it returns the real host). You can find the nocloak module here.
Running - Self-compiled windows version crashes on-join, on-link, or whatever..
Are you using Microsoft Visual Studio 2005 (8.x)? If so, then it's likely the IRCd will crash. This is a known issue.

See this faq item for compilers that DO work ok and some more info. about this issue.

If you are NOT using MSVC8, then report it at and give some details.
If it's possible to reproduce the bug, then it would be very helpful if you could also check if the official unreal version (from also crashes or not (otherwise you might be asked to do this).
Naturally, the usual rules apply, that is: if you modified the source code (excluding config.h changes) then we are not responsible for the code/crashes anymore. Additionally, if you run 3rd party modules, we might as you to remove them and try again, BUT.. it's still worth to directly report crashes since we are generally quite interested in them.
Running - IPv6: How to make the IRCd listen on IPv4 addresses?
Currently, if you have compiled with IPv6 support, and you need to put IPv4 addresses in a special way at some places.

In your listen blocks
Instead of using
you need to use
listen [::ffff:]:6667

In your link blocks

Other comments...
Be sure to read the documentation for any directive if you hit any problems.

This "annoying behavior" might be changed later, so you can use etc again instead of the ::ffff:x.x.x.x stuff. This is currently under consideration.
Running - IPv6: (*BSD) I have compiled with IPv6, but can't get it to listen at IPv4 addresses
If you are on *BSD (eg: FreeBSD), have compiled with IPv6 ENABLED, and have something like:
listen *:6667;
and while it's listening on the IPv6 address(es) just fine, connecting to the IPv4 IP on 6667 does not work.
Change sysctl net.inet6.ip6.v6only to 0. You can do this by adding net.inet6.ip6.v6only=0 to /etc/sysctl.conf and reboot, and/or executing "sysctl -w net.inet6.ip6.v6only=0" as root.

When we are at it, make sure you have ipv6_ipv4mapping="YES" in your /etc/rc.conf as well.
Services - Where is nickserv? chanserv?
NickServ, ChanServ, .. are supplied by a services package. UnrealIRCd (just like most ircds) doesn't come with services, you have to choose, download and install your services separately.
Services - Why doesnt unreal come with services?
We don't integrate services in UnrealIRCd itself because we feel you should be able to choose a package that you like yourself. People tend to disagree on which services are the best, it's better to keep this separate from the ircd or else we get "religious wars".
Services - Where do I get them? Which do you recommend?
Again, you should decide yourself which services you want.

To give you some links:
Anope (epona) - Lots of features and user-friendly. (*NIX), for the windows version see this
IRC Services - Stable services, has module support and is expandable (*NIX)
Magick IRC Services (*NIX, Win32)
NeoStats, OperStats, SolarStats. - Services used for statistics (*NIX,*NIX,*NIX/Win32)
There are even more services, try google ;)


Services - /cs or /chanserv say: Services are currently down. Please try again later.
Your set::services-server should point to your services server. For example:
set {
 services-server "";

Services - /cs or /chanserv say: Unknown command
These things are called aliases, and you should configure them, usually by just including the correct configuration file in your unrealircd.conf. See the aliases/ directory.

For anope it's for example:
include "aliases/anope.conf";

Services - NickServ/ChanServ don't op me or say I'm not a registered nick all the time
Make sure your services are U-lined at all servers. Also, after you change your ulines, rehash and the services server has to be RELINKED (just restart it).
While you are at it, make sure your set::services-server is set correctly too.
Services - Hey I need help with services, can I ask in #unreal-support?
#unreal-support is strictly (surprise!) for UnrealIRCd support. It is NOT for support on any other software or hardware like: services, DSL modems, routers, how-to-use-Linux, ..
Sure, you can talk about this stuff with someone in a query but not in the channel. If you do start such an conversation, don't be surprised if you get banned!
Other - My server crashed!!
If your server crashed and you are running the latest version without any source modifications, then please report it at
EXCEPTION: If it crashed due to your self-coded services or raw commands then maybe not, see next question... (if you don't know what this means, then just report the bug, since this exception probably does not apply to you ;P).
Other - My server crashed when sending an incorrect raw command from another server (eg: services)
If you managed to crash Unreal by sending some illegal command from a linked server, for example by /OS RAW ..., or by sending your own incorrect raw command by your self-coded services, then this will not be fixed.

UnrealIRCd trusts remote servers (once they are linked), this ranges from access checking (servers have [almost] full power) to syntax checking. Often for various reasons (speed, lazyness, etc) we do (often) not have checks in place to check the syntax of all remote-server traffic, and we DO NOT INTEND TO.
Examples of ways to crash Unreal by a trusted server are:
* sending commands like a STATS request with a server as source (and not a [psuedo-]client)
* sending a command with a missing (or extra) parameter, such as an invalid TKL command
* many more

Such ways to crash UnrealIRCd will not be fixed, instead you should not be sending these illegal things in the first place!.
Users coding their own services or experimenting with RAW should know what they are doing!
Major services packages such as anope and ircservices also warn for the use of RAW and discourage it's use, the same is true if you're not toying with services raw but with a directly linked "own server" or telnet (in fact, the situation is exactly the same).
This philosophy is not unique to Unreal.

Update 2007-01-22:
While I've considered rethinking this position, my conclusion - certainly for now with scarce resources - is that we should dedicate developer resources on other things, and stick with our current position.
Other - Invisibility (usermode +I) doesn't work
Invisibility (usermode +I) was removed over 2 years ago (beta15). There are two reasons for this:
1. Technical: it was a total mess. You have to deal with invisibility in: join, part, names, who, whois, invite, kick, etc. It made the source really ugly. Also as a consequence of this, the code was buggy so spying could easily be detected
2. Ethics: it's unethical to use +I, this also gave Unreal a bad reputation

NOTE: Any discussion on our forum/IRC channel/etc about spying will cause you (or your message) to be removed immediately.
Other - How do I get the latest development version? (CVS/HG/Mercurial)
We use mercurial (hg), you can check out the latest development version of UnrealIRCd by:
hg clone
If you get something like 'hg: command not found' then you need to install mercurial, usually the package is called 'mercurial'. If you don't have such a package, or you are on Windows or Mac OS X, then go to the mercurial site.

Alternatively, you can download the daily generated .tar.gz's from here.

Windows users can download development builds here (binary versions with installer etc). Or take a look at my main UnrealIRCd page here.

Other - I would like a symbol/prefix for +q/+a like ./*/^/etc (or: how to get rid of the &/~ prefixes)

PREFIX_AQ will give +a (chanadmin) the & prefix, and +q (chanowner) the ~ prefix... just like +o has @. This also means you no longer need to +qo/+ao a user, just +q/+a is enough.

The question whether to enable this is asked during ./Config on *NIX. It's turned ON in all our windows builds.

How to turn it off
As said above for *NIX, just say No to the ./Config question. Windows users will have to compile their own UnrealIRCd (which requires a compiler and some experience with this), grab the source (the .tar.gz) and see doc/compiling_win32.txt for instructions. You can find the PREFIX_AQ define in include\setup.h

It is NOT possible to use any other symbol than & and ~, if you try it anyway you'll loose support and break other things. Also support questions on this will result in an immediate ban/topic delete/etc.

Other - why is running an old UnrealIRCd version bad?
In UnrealIRCd (just like in any other software package) bugs are discovered all the time which are then fixed in the new version. Now we see people happily running beta14 or 3.1.3, but you should understand that these bugs also include ones which enable any user to crash the server or even worse bugs which enable you to become an ircop or execution of code.
So even while you were running a particular version for 2 years, you NEED to upgrade.. It's not fun when a kiddie is crashing all your servers every 5 minutes and you need to upgrade all ircds as soon as possible, half of your admins are away/unreachable and your users are going crazy...
Other - Why is modifying the source not supported?
First, we do NOT help with modifying the source.
Second, if you modify the source you'll loose all support (weird bugs, crashes, etc) because we can no longer be sure if any bug is caused by us or by you. It's easy to make a tiny mistake in C which causes memory corruption and can screw everything up.
However, you can still get support by trying to reproduce any bugs on a "clean" UnrealIRCd (that is, ircd with no modification), and then reporting it on So it's not like you are completely cut off.. We just want you to retry things on the official version.
You can imagine what our reaction is after (an) hour(s) of debugging just to find out it's caused by your modifications!
Here's an example [IRC LOG]: I was about to watch television but then some came in #unreal-support and talked about crashes, so I thought let's query him quickly.. I ask him explicitly if he's using any 3rd party modules or modifications, he says no... in the end it turns out unrealircd crashes at an impossible position because of HIS modified code.

We do offer custom coding for money however (modifications done by someone of the team), in that case the person that did the modifications will help you if you have any crashes/weird bugs.

Other - I want my ircd to hold over 1024 connections!

This is easier said than done. The maximum amount of connections (also called file descriptors [fd's] or open files) depends on multiple things... Before you read all of this you should understand that the following requires help of your sysadmin (unless you have root access yourself) and it's not easy so it might be better to do just like most people do: run multiple servers.

** The global maximum **
With Linux 2.4 and Linux 2.6 everything should be ok already, so just skip this step :)
With Linux 2.2 you'll have to do something like: echo 8192 >/proc/sys/kernel/file-max although I really recommend you to use Linux 2.4 or 2.6 because there are several other limits of 2.2* that might affect you.
With FreeBSD you should do something like: sysctl kern.maxfiles=8192 (and add it to your /etc/sysctl.conf of course). You probably also need to increase kern.ipc.nmbclusters, and perhaps some other ones as well I'm unaware off. [FEEDBACK is welcome.. if you know how to properly tweak freebsd to get 4096 or 8192 connections, let me know at syzop AT unrealircd DOT com].

** The ulimit value **
Unless you are root you cannot upgrade your ulimit -n value, so..
FreeBSD: sysctl kern.maxfilesperproc=4096 and then everything is ok (well, you prolly want to add that to sysctl.conf as well and don't forget to relogin, otherwise the changes will have no effect).
Linux: what you probably want is edit /etc/security/limits.conf and add 2 lines like:
username hard nofile 4096
username soft nofile 4096
Where 'username' is your login name (eg: syzop)
Assuming your pam is configured correctly, relogin (yes you have to login again) and type ulimit -n, it should now show 4096.
If it didn't, then your pam isn't loading the session limit module (or something else), you'll have to add a line like session required to /etc/pam.d/login, /etc/pam.d/sshd, /etc/pam.d/su, and perhaps some others as well (cron???). But please be careful, since you can lock yourself out if you make a mistake, so be sure to keep 1 terminal logged in etc ;).

** The header files **
FreeBSD? Then you are already set :).
Linux? Then you'll have to do this step too...
Search for __FD_SETSIZE in /usr/include/bits/typesizes.h or /usr/include/bits/types.h and change the value.
At my system it was a matter of changing this line:
#define __FD_SETSIZE 1024
to this:
#define __FD_SETSIZE 4096

*** UnrealIRCd ***
Now you've finished everything, doublecheck that ulimit -n displays the correct value, and then you can specify this value at the MAXCONNECTIONS question (eg: 4096) of ./Config (and then do make.. etc).

*** Test results ***
I've done several tests with 10K (yes, 10000) clients on Linux 2.4* and it went fine. But to handle this amount of clients you need a good box like with a ghz proc, and more important: with enough (free) memory... at least 512Mb, and preferably 1Gb+ (not only for unreal, but also for socket buffers, etc).

I'm aware of a few "live nets" that in fact hold ~3000 users on 1 server. Why I'm only aware of a few? Well, as said.. most networks just use multiple servers.

If you are on W9X or ME, forget about it.. you really need at least NT or higher (W2K, XP, 2003, ..).
The current windows version of UnrealIRCd can handle 4096 connections by default which should be enough for most servers/networks.
If you want more, you would have to compile your own ircd, then change MAXCONNECTIONS in include/config.h to the value you want and compile it. Note that if you experience any problems/odd issues, you should mention this change in the bugreport since this has not been tested extensively.

Other - irssi and prefixes (&/~)
Since irssi 0.8.10 (released on December 11 2005), irssi has support for & and ~ prefixes, +q/+a channel modes, and more ("005 support").

Other - I would like to restrict /map and /links
The reason we don't have this feature is because it would give a false sense of security... and having a false sense of security is worse than ""no security"".

Let me explain some ways how you can discover servernames:
- /who
- /whois
- /whowas
- netsplits
- netjoins
- usually, there's a list somewhere online (see later)
- "server unmask"-tricks, /version a*, /version b*, it's fun!
- and more... main thing is: server names were never ment to be 'private information'!

So back to "why is this useful"? Hiding the names of your client servers makes no sense, since.. because they are client servers.. people have to connect to them so they are either listed on the webpage or have some kind of dns round robin..

Now some reasons which DO make sense:
A. You want a "flat map" so the routing information isn't shown (what is linked to what, hopcount, etc), this function exists and is implemented as set::options::flat-map (since 3.2.1).
B. You want to hide your hubs (non-public servers). See Section 8.6 Denial of Service attacks (DoS) [or: how to protect my hub] for a (similar) solution to this.
Both are usually ment to prevent (or rather.. limit the impact of) [D]DoS attacks...
Other - How do I make my users spread evenly over multiple servers?
If you have multiple servers and you want your users to automatically spread evenly over several (or all) servers, then you use DNS Round Robin.

DNS Round Robin is a DNS (Domain Name System) feature, basically it means you add multiple "A records" for the same domainname in your nameserver, so instead of: A
you do: A A A

Naturally for all this to work, you need to own a domainname, and have access to the nameserver records of your domain (either directly or indirectly via a web interface).

For more information, just google at "dns round robin", there are tons of articles and howto's about it :).

Other - how can I use an encrypted certificate when running the ircd as a service under windows?
Short answer:
You can't.
The solution is to remove the password from the certificate (see the openssl manual or google).
OR, run UnrealIRCd in GUI mode so you get prompted for the password (note: this is not recommended for "real servers").

Long answer:
If you think of it, it also doesn't make any sense to do so.
Situation: you have the certificate encrypted for security reasons, so that when somebody can get his/her hands on the certificate it will not be broken immediately.
And now you want it so the ircd can boot automatically without providing the passphrase?
The only solution to do that is to store the password somewhere. This password cannot be stored hashed ("unencryptable") since it has to be entered. Hence, it will either have to be stored somewhere as plaintext or fake-encrypted (near-identical to plaintext, just obfuscated).
So how does this help?
It only gives a false sense of security.

Other - Other - What about future UnrealIRCd releases? 3.3? 3.4? 4.0?
See the forum post: Future development - Unreal3.2 & Unreal3.4.

Other - I want to get rid of this annoying connect message on windows / get rid of nospoof
When a client connects to a win32 UnrealIRCd (or another ircd with nospoof) it gets:
*** If you are having problems connecting due to ping timeouts, please type /quote pong 50CF4C86 or /raw pong 50CF4C86 now.
The client then has to PONG back to a random number, this happens automatically for any sane client.

Some people have requested disabling of this message, this is now done as of Unreal3.2.6 by default. If this is what you want, you can stop reading here ;).

Others have requested to disable the entire protection (initial PING/PONG) altogether.
On *NIX this is generally no problem, simply re-run ./Config and choose NO when asked for nospoof support (but feel free to read on, since it can still actually protect you against post proxies).
On Windows, this is generally a BAD idea.

This nospoof protection does two things:
  1. On some OS's (mainly Windows NT/2000/XP) it is there to fight IP spoofing. Without it, a user can show up onto your server with almost any IP, including funny things like To be exact: this is because some OS's have an insecure TCP ISN, which makes it easy for hackers to spoof any IP.
  2. In general (regardless of the OS), nospoof also protects against other "blind clients". One example of this is HTTP POST proxies. They can't connect succesfully if nospoof is enabled.
So, disabling nospoof on windows is a bad idea since it allows people to spoof IP's. Hence, disabling nospoof is NOT supported on Windows.

If you're on *NIX, and you are using any recent Linux/FreeBSD/OpenBSD/Solaris, it's completely safe to disable nospoof.
Some "obscure" *NIX'es or older versions (like 5+ year old) can still have insecure TCP ISN issues, in such a case nospoof would still be necessary. Again, if you are using any recent *NIX of the "normal" *NIX'es you shouldn't have any problem.

Our policy might change in the future, due to the fact that 2003 seems to have secure ISN's and that in the past few years there have been some (major) enhancements to w2k/XP as well but I have not investigated them yet.