InspIRCd - 10,000 revisions reached!

From the makers of InspIRCd.

This page has been marked as Historical. Information posted here may be inaccurate and out of date. This information is kept for sentimental and/or historical reference purposes.

This page will be expanded as we add to the protocol. Protocol changes will be generally backwards-compatible with previous versions (up to a point).

Linking a server into an InspIRCd spanning tree is relatively straightforward for anyone who's handled irc servers and their protocols before. To connect to a server (which has our details in a <link> tag) we first proceed with the authentication phase, as detailed in the section below.

Contents 1 The Authentication Phase 1.1 Step One - Connection 1.2 Step Two - Inbound Authentication 1.3 Step Three - Outbound Authentication 1.4 Step Four - Network Burst 1.5 Example Authentication Phase 2 Command List 2.1 Modular commands 2.2 SERVER 2.3 FJOIN 2.4 FMODE 2.5 SQUIT 2.6 FTOPIC 2.7 BURST 2.8 ENDBURST 2.9 OPERTYPE 2.10 REHASH 2.11 NICK 2.12 USER 2.13 VERSION 2.14 FHOST 2.15 FNAME 2.16 ADDLINE 2.17 GLINE 2.18 ELINE 2.19 ZLINE 2.20 QLINE 2.21 SVSNICK 2.22 SVSJOIN 2.23 SVSMODE 2.24 METADATA 2.25 IDLE 2.26 PUSH 2.27 TIME 2.28 AES 2.29 CAPAB 2.30 PING 3 Message Routing 3.1 One to One routing 3.2 One to all (Broadcast) 3.3 One to all-but-one 3.4 One to group 4 Server Types 4.1 Hubs 4.2 Leafs 4.3 U-Lines 5 Timestamp Syncronization 6 Example Traffic

The Authentication Phase

During the authentication phase, a three-way handshake is performed where both servers exchange their passwords. Unlike most ircds (the notable exception being ircu) this must be done in lock-step fashion, e.g. one server sends a request then waits for the other server to reply before sending another. Note that once the authentication phase is complete, the data flow moves to being full duplex and no such restrictions apply once the BURST command is received (see below).

Step One - Connection

Server A, wishing to connect to the network, connects to server B using connect() or equivalent. When the connection is established, it immediately sends the SERVER command (see the commands list below) to server B which is waiting for inbound connections. Up until this point, server B will do nothing but accept the connection.

Step Two - Inbound Authentication

Server B, after receiving server A's SERVER command, analyzes the parameters (namely server name and password) and if it is not happy with the credentials, should instantly send a suitable ERROR reply, and close its connection. However, if server B deems the credentials correct for server A, server B then sends its own SERVER command, with its own credentials in to authenticate to server A.

Step Three - Outbound Authentication

Server A, upon receiving server B's credentials, analyzes them (again, namely the server name and password), and again, if it is not happy, it can send an ERROR reply, and close its connection. If the details are correct however, server A now sends a BURST command (see the commands list below) and begins its network burst.

Step Four - Network Burst

Upon receiving server A's network burst, server B also sends its own network burst, preceeded again by the BURST command. When both servers have finished bursting, they send the ENDBURST command. BURST and ENDBURST are only sent for local bursts.

The order which data is sent during the burst is important, and should be:

• Firstly, the names of any servers connected to this one, directly or otherwise, with relative hop counts, 1 being a direct connection (these will be re-calculated by the receiving side)
• Secondly, the nicknames of any users, sent using NICK, their OPERTYPE if they are an oper, and their channel list using FJOIN (see the commands list, below)
• Thirdly, the modes (Sent using FMODE), topics (sent using FTOPIC) and bans (sent again using FMODE) for each channel in turn (no specific order of channels).
• Lastly, any module specific data (which may be a combination of FMODE and any other module-specific commands).

Example Authentication Phase

This is an example of a successful authentication:

>> SERVER services-dev.chatspike.net password 0 :Description here
<< SERVER test.chatspike.net password 0 :ChatSpike InspIRCd test server
>> BURST
<< BURST

(both servers now operate in duplex mode sending data freely)

Command List

This section documents all valid server to server commands which are specific to InspIRCd. Most commands are similar or identical to RFC1459 to make adding support to other programs (such as services packages) straightforward. Where commands are not documented here, they are transmitted across the spanning tree in standard form:

:<nickname> COMMAND <parameters>

For example:

:Brain PRIVMSG #chatspike :Moo moo!

or,

:Craig MODE #chatspike +ov Brain Brain

Where commands are part of the RFC, but their behaviour or their syntax is different, the commands are documented here in their InspIRCd form.

Modular commands

Any module which implements a command, for example SAJOIN, will have those commands automatically passed out onto the network as a broadcast. Any servers which also have this module loaded and handling the same command will be informed of the inbound command coming in off the network. If a server does not recognise a command, it should close the connection immediately to prevent a desync. This ensures transparent operation of modules on the spanning tree, independent of what tasks these modules perform. To load a module network wide, configuration files should be edited then then the modules introduced via /rehash *. Examples of such modular commands are SAJOIN, SAPART, KNOCK, REMOVE, PARK.

SERVER

(Broadcast, One-To-One)

SERVER <servername> <password> <hopcount> :<description>

The SERVER command is used to authenticate to the network, or to introduce a new server, once authenticated. The two forms of this command are as follows:

SERVER <servername> <password> 0 :<description>

This version of the command is used when authenticating (see the authentication phase, above). The password must be supplied and must be valid on the remote server, and the hopcount must be zero otherwise an ERROR should be generated by the remote side.

:<local server> SERVER <remote server> * <distance> :<description>

This version of the command is used after authentication (during bursting and normal operation) to indicate a new server has been introduced. This command will be passed on to all other servers. The password field contains a * as it is unused. The distance field must be one or greater, indicating a non-local connection. The actual value is not important so long as it is greater than zero, as the hopcounts are relative and re-calculated by the recipient to match their local view of the server map.

FJOIN

(Broadcast)

:<server> FJOIN <channel> <timestamp> <[@|%|+|]nickname> {<[@|%|+|]nickname>}

This command is used within a netburst to syncronize all of the users on a channel, and set their permissions upon that channel. Channel restrictions for remote users, sent with FJOIN or JOIN, should be ignored to prevent desyncs. For example:

:fudge.chatspike.net FJOIN #staff 1133630884 @Brain @Craig %Dune +Azhrarn w00t Elf

Note that the modes built from this should be merged then sent only to local clients, for example, the above FJOIN will queue and send the mode change to be sent after the clients are joined to the channel:

:fudge.chatspike.net MODE #staff +oohv Brain Craig Dune Azhrarn

The timestamp is used to determine which modes are the established modes upon the channel. To prevent split riding, the channel which has the lowest timestamp will bounce the modes of the channel with the highest timestamp. This means that for example, if server A sends this:

:server.a FJOIN #staff 1230 @Brain @Craig

and server B sends this:

:server.b FJOIN #staff 1234 @ol typobox43

Then when server A receives the FJOIN from server B, it will immediately counter its mode changes with the following command sent to all servers (including the one which sent the FJOIN), and will not accept the mode change for the user 'ol' on its local server:

:server.a FMODE #staff -o ol

Doing things this way around means that it is not possible for a server to ignore its settings and allow netjoin abuse to occur.

NB: In the current implementation, if one server has the channel empty, it will emulate an extremely high local timestamp on the empty channel (20 seconds ahead of current time) so that all mode changes will be automatically allowed by the remote server and will not be bounced. When a user is the first user in the channel, the current implementation will send an FJOIN instead of a JOIN to specify clearly that by joining the channel the user has been given ops. This is done for compatibility with services packages.

In the 1.0.x implementation, only status modes @%+ are checked via timestamps. This is enough to prevent the majority of malicious activity, as it still ensures the correct people end up opped. A maximum of 12 users may be sent per FJOIN line to prevent breaking services packages which are still restricted to MAXPARA parameters. The 1.0.x implementation may only receive one mode per user (the highest privilage mode), and these modes may only be core-implemented prefixes @%+. Any further modes, or modes without prefixes must be sent via FMODE after the FJOIN. The 1.0.x implementation should treat unknown prefixes as part of the nickname.

FMODE

(Broadcast)

:<source server> FMODE <target> <modes and parameters>

This command is used within a netburst (or sometimes after the burst) to syncronize modes on channels and users. For example:

:irc.mynet.org FMODE #opers +bb *!user@spy.com *!person@watching.us

SQUIT

(Broadcast)

:<local server> SQUIT <remote server> :<reason>

This command indicates that server <remote server> has disconnected from <local server> with the given reason. When servers receive this command they must update their server maps accordingly, removing any users which existed upon the orphaned section of network. Seperate QUIT messages will not and should not be sent out for the exited users.

FTOPIC

(Broadcast)

:<server/nickname> FTOPIC <channel> <time-set> <set-by> :<topic>

This command is used during a network burst to syncronize the channel topics. When setting a topic, the newest topic (highest time-set value) is set and the other discarded. The time-set value is a unix epoch time.

BURST

(One-To-One)

BURST {timestamp}

This command indicates the start of the network burst. It should only be sent when the network burst is local to indicate the end of the authentication phase (See above). If a timestamp is given, the local server must match their timestamp against that of the remote server, aborting if the delta between the two is greater than ten minutes (> 600 secs or < -600 secs).

ENDBURST

(One-To-One)

ENDBURST

This command indicates the end of the network burst. Currently ignored, it may be used in the future for timing purposes or transactional purposes (to save for needing to 'roll back' the burst on failure) so should always be sent at the end of a network burst.

OPERTYPE

(Broadcast)

:<nickname> OPERTYPE <type name>

This command indicates that the specified user is an IRC operator of the given type. The <type name> given should exist in the configurations of all servers on the network for the oper status to propogate. If oper status does not propogate, desyncs can occur. Please note that InspIRCd does not let users or remote servers set the +o usermode under any circumstances. Sending OPERTYPE successfully places the +o usermode upon the given user as well as setting their oper type, so should be used to 'oper up' clients. The exception to this is u-lined servers, as u-lines are a core feature (there is no easy way around doing this) which permit all users with that server name in their record special abilities which negate the need for the +o flag.

REHASH

(Broadcast)

:<local server> REHASH <remote server>

This command indicates that all servers matching the given <remote server> mask should immediately rehash their config files. This command is broadcast, meaning that all servers will receive and act upon it.

NICK

(Broadcast)

:<local server> NICK <timestamp> <nick> <hostname> <displayed-hostname> <ident> +<modes> <ip> :<gecos>
:<old nick> NICK <new nick>

The first version of this command introduces a new client into the network. If there is a nickname collision, the remote server you send the NICK command to is responsible for generating a KILL message and sending it back to you. The ip field is in dotted decimal form, e.g. 1.2.3.4.

The second version of this command changes an existing user's nickname, as in the RFC.

USER

(N/A)

The RFC1459 command "USER" is not implemented by InspIRCd between servers, as this functionality is handled by the 8-parameter version of the NICK message.

VERSION

(Broadcast, One-To-One)

:<source server> VERSION :<arbitary version string>

Whereas the RFC version of this command (no pun intended) requires that each time a user requests a remote server version, the server should direct a version request at a local server and wait for a reply, the InspIRCd version of this command operates differently. To save on cross-network bandwidth, instead, the InspIRCd protocol requires that this be sent as part of the network burst. All servers then cache the version strings of all other connected servers and may return them to clients without making any requests to the network. Servers may also update their version strings at any point after the burst.

FHOST

(Broadcast)

:<nickname> FHOST <new displayed host>

The FHOST command is sent out when a server changes the displayed host of a user local to that server.

FNAME

(Broadcast)

:<nickname> FNAME :<new GECOS field>

The FNAME command is sent out when a server changes the GECOS (full name) field of a user local to that server.

ADDLINE

(Broadcast)

:<source server> ADDLINE [Q|Z|E|G] <mask> <setter> <time set> <duration> :<reason>

The ADDLINE command is used to (silently) set a GLINE, ZLINE, ELINE or QLINE. Whereas the GLINE, ZLINE, ELINE and QLINE commands can only be sent from a user source, and require that user to be online, ADDLINE may only be sent by a server (with a valid server name as the source), and the setter can be any arbitary text up to 64 characters in length (so it may be a nick which is not online, or a server name). Servers must use this command to sync Q, Z, E and G lines during a burst. After that point, users may add (or remove) G, Z, E and Q lines using the GLINE, ZLINE, ELINE and QLINE commands as documented below. The duration for ADDLINE may only be represented in seconds, and not the more complex form as shown for the other *LINE commands.

GLINE

(Broadcast)

:<source nickname> GLINE <user@host> <duration> :<reason>
:<source nickname> GLINE <user@host>

This command sets or removes a GLINE (the first syntax given is to add, the second to remove) and is passed on to servers exactly as it is formatted in our client Commands guide. The duration in this command may be formatted in the form: 1y2w3d4h5m6s which means 1 year, 2 weeks, 4 hours, 5 minutes 6 seconds, or simply as a number of seconds (as in ADDLINE)

ELINE

(Broadcast)

:<source nickname> ELINE <user@host> <duration> :<reason>
:<source nickname> ELINE <user@host>

This command sets or removes a ELINE (the first syntax given is to add, the second to remove) and is passed on to servers exactly as it is formatted in our client Commands guide. The duration in this command may be formatted in the form: 1y2w3d4h5m6s which means 1 year, 2 weeks, 4 hours, 5 minutes 6 seconds, or simply as a number of seconds (as in ADDLINE)

ZLINE

(Broadcast)

:<source nickname> ZLINE <ipmask> <duration> :<reason>
:<source nickname> ZLINE <ipmask>

This command sets or removes a ZLINE (the first syntax given is to add, the second to remove) and is passed on to servers exactly as it is formatted in our client Commands guide. The duration in this command may be formatted in the form: 1y2w3d4h5m6s which means 1 year, 2 weeks, 4 hours, 5 minutes 6 seconds, or simply as a number of seconds (as in ADDLINE)

QLINE

(Broadcast)

:<source nickname> QLINE <nickmask> <duration> :<reason>
:<source nickname> QLINE <nickmask>

This command sets or removes a QLINE (the first syntax given is to add, the second to remove) and is passed on to servers exactly as it is formatted in our client Commands guide. The duration in this command may be formatted in the form: 1y2w3d4h5m6s which means 1 year, 2 weeks, 4 hours, 5 minutes 6 seconds, or simply as a number of seconds (as in ADDLINE)

SVSNICK

(Broadcast)

:<source server> SVSNICK <old nick> <new nick> <timestamp>

This command is implemented for services compatibility. When given it will change the user <old nick>'s nick to have the nickname <new nick>. Unlike many other implementations this command may be issued by any server (not just a U-Lined server). The client's timestamp value will be reset to the timestamp given in the SVSNICK command. USE WITH CAUTION! There is purposefully no client-side version of SVSNICK for opers, the SANICK module must be used instead for opers to change user nicks, which does not change the user's timestamp. This command is never sent out by InspIRCd servers directly, however it is forwarded from services servers, and should therefore be supported.

PLEASE NOTE: When using this command, it does not in itself force a nickchange at each server directly that it passes through. The server where the old nickname resides is the only server to directly act upon the SVSNICK, and does so by echoing back a NICK to the rest of the network 'acknowledging' the nickchange. Any other servers where the old nick is not a local user will just pass the SVSNICK on, so long as the old nick exists. This allows for services servers to wait for confirmation that the user changed nick, or collided, before actually introducing enforcers.

SVSJOIN

(Broadcast)

:<source server> SVSJOIN <nick> <channel>

This command is implemented for services compatibility. When given it will force the given nick to join the given channel. Unlike many other implementations this command may be issued by any server (not just a U-Lined server) but there is purposefully no client-side version for opers, the SAJOIN module must be used instead for opers to force users to join channels. This command is never sent out by InspIRCd servers directly, however it is forwarded from services servers, and should therefore be supported.

SVSMODE

(Broadcast)

:<source nick> SVSMODE <nick> <channel>

This command is implemented for services compatibility. When given it will allow modes to be set on users which are on remote servers, bypassing client-side checks. Unlike many other implementations this command may be issued by any server (not just a U-Lined server) but there is purposefully no client-side version for opers, the SAMODE module must be used instead for opers to force user or channel MODEs. This command is never sent out by InspIRCd servers directly, however it is forwarded from services servers, and should therefore be supported.

METADATA

(Broadcast)

:<source server> METADATA <channel|user> <key> :<value>

Because InspIRCd is completely modular, modules require a way of passing messages from server to server, transparent of the actual protocol in use, without two modules competing over resources. To accomplish this, InspIRCd allows modules to extend user and channel 'records' in the ircd itself with arbitary data, known as metadata (in InspIRCd API terms, this is known as the Extensible class). Each extra piece of data is named uniquely using an ASCII key, and each module only modifies its own keys and values. The internal format of this data is module specific.

When two servers sync, the protocol module, m_spanningtree.so, retrieves the list of metadata names for each user or channel as it is synched, and then queries all modules, asking them to submit an ASCII string that represents the given key's metadata. This is then sent to the opposite side of the netburst. The opposite end, upon receiving this metadata, again queries all modules, until one claims it and re-assembles the ASCII <value> field back into its native form, and stores it in the key for that particular user or channel.

Most non-InspIRCd systems can safely ignore METADATA commands (and should do so!), and should NOT send any without knowing exactly which module uses the given key, and what for, and the format of their ASCII data. Please note that the <value> field only has to be meaningful to the module which generated the message, and is not required to be usable in any other form (e.g. it may be encrypted or otherwise munged).

IDLE

(One-To-One)

:<source nick> IDLE <target nick>
:<source nick> IDLE <target nick> <signon> <seconds idle>

When a user issues a remote WHOIS, the IDLE command (in its first form listed above) is sent out. The user issuing the WHOIS is placed into the <source nick> field and the user being whois'ed is placed into the <target nick> field. The WHOIS response is then locally delayed, until a remote server responds via the second format of the command. The user they whois'ed is placed in the <source nick> field, and the user that issued the WHOIS is placed in the <target nick> field, along with the signon time and idle time of the source nickname. Once the original server receives this information, it is able to then build its entire WHOIS response and send it to the originating user.

PUSH

(One-To-One)

:<source server> PUSH <target nick> :<any text>

The PUSH command may only be sent from a u-lined server, and when sent, will be passed to the server where <target nick> resides, and then the arbitary text contained within <any text> will be dumped to the user's file descriptor. This may be used as an encapsulation mechanism for sending raw lines to users and implementing systems in InspIRCd which the protocol does not directly support.

TIME

(One-To-One)

:<source server> TIME <target server> <issuing nick>
:<source server> TIME <target server> <issuing nick> <timestamp>

The TIME command is a more efficient version of the TIME command and numeric used by other ircds. The first form of the command is used to request the time of remote server <target server> on behalf of <issuing nick>. When the remote server replies to the request it should use the second form of the command, which has the timestamp appended, and <target server> and <source server> transposed so that the message finds its way back to the issuer. Once the issuer receives the response they should decode the timestamp using localtime() and asctime() and display it to the user given by <issuing nick> in the same manner as a local TIME request.

AES

(One-To-One)

AES <server name>

Upon connection, servers which are of version 1.0 RC1 or later may negotiate optional AES encryption. When doing so, the connecting server will send this command before the SERVER and BURST command, but after any CAPAB commands (see below) and any commands following the AES command (including the SERVER command and the netburst) will be encrypted using AES, wrapping each encrypted line in base64 before transit. Both ends of the connection are expected to have a shared private key which is used to encrypt and decrypt the session. If the session cannot be decrypted, no authenticated connection can be made.

It is possible to send the AES message after negotiation of the server link, however this is not supported by current versions of InspIRCd. If the AES message is sent more than once in a single session, the second (and any other) AES commands will be dropped and an error given.

Encryption strengths of 128, 192 and 256 bits are currently allowed, using key lengths of 16, 24 or 32 bytes respectively with the CBC cipher.

WARNING: While in AES mode, lines sent over the link may exceed 512 bytes! Because messages must be padded to the nearest block size, where a block is equal to the key size, the encrypted payload may be up to 543 characters in length (512 plus the maximum modulus of 31 for the largest permitted key length). Also, the base64 encoded payload, which wraps the encrypted payload will further increase its size by up to 20%, making messages be as long as potentially 750 bytes! Because InspIRCd itself uses the C++ std::string class, the actual length of the message is not important as a buffer overflow cannot occur in any practical situation.

When the connect is running in AES encrypted mode, a certain subset of commands may be allowed along the link unencrypted so that the network is still able to understand them in the event of an encryption failure. Currently, the most recent version of InspIRCd only allows the ERROR command to pass along the link in this manner.

CAPAB

(One-To-One)

CAPAB <module list>

The capab command, if sent, must be sent in the authentication phase before any other command (including the optional AES command. If the server is listening for connections, then it must immediately send out this command as its 'banner'.

Any server which does not understand the CAPAB command should silently ignore it. Otherwise, the alphabetically sorted module list which is given in the command as its single parameter must be compared to our local list, and if they do not match, the link should be aborted immediately with an error message.

To build this list, InspIRCd servers make a list of all modules with either (or both) of the VF_COMMON and VF_STATIC flags set in their version information (e.g. they implement modes, or otherwise are globally reaching), and sort it alphabetically, seperating each module name with commas. As windows builds of InspIRCd also use .so as the file extension for modules, this will not effect linking to versions of InspIRCd running on windows, or other non-unix platforms, so long as naming conventions are adhered to.

PING

(One-To-One)

:<source server> PING <destination-data>
:<source server> PONG <destination-data>
:<source> PING <source server> :<destination server>
:<source> PONG <source server> :<destination server>

The PING command is implemented in two forms. The two-parameter version of PING is identical to RFC 1459, and you should refer to RFC 1459 and RFC 2813 for more information on this command. This format of the PING (and PONG) command can traverse servers and can be used for latency and end-of-burst checks. The short form of the command with one parameter is InspIRCd-specific. If you receive a PING command with one parameter, you must answer with a PONG on the same connection the PING came from. the contents of the PONG reply are not important, however most InspIRCd servers populate this field with the target server name. If you do not reply to the one-parameter PING with a one-parameter PONG within two minutes, the remote server should close your connection.

NB: The short-form of PING with one parameter can NEVER travel more than one server away from its source. It should only be used for local 'liveliness' checks on the connection.

Message Routing

InspIRCd has four behaviours when it routes a message. These four behaviours are chosen dependent upon the message and the target and source of that message individually. These behaviours are:

One to One routing

This is used to route a message from one server directly to another server, taking a route only through servers which need to process the message in order to pass it straight to its destination. Examples of this are PRIVMSG and NOTICE direct to a user (not to a channel) and any messages exchanged during the initial burst and authentication phase.

One to all (Broadcast)

This is used to broadcast a message to all servers, and each server which receives such a message will then pass it on to its peers using "one to all-but-one" as shown below. This is used for messages which the entire network must see to remain synchronized, e.g. NICK and QUIT.

One to all-but-one

This is used to pass on a "one to all" message which has originated from another server. The message may not be passed on via a second "one to all" message, because doing so would bounce the message back along the network to its source and cause a desync.

One to group

This is used only by channel PRIVMSG and NOTICE. To cut down on bandwidth, channel PRIVMSG and NOTICE are not broadcast. To achieve routing for these types of message, a list is compiled consisting only of locally connected servers the PRIVMSG or NOTICE must be sent to in order to reach all of its recipients. Each recipient is then responsible for running the message against this algorithm again to ensure it eventually reaches all intended recipients, and no extra servers which do not have users on the channel will receive the message or act upon it.

Server Types

InspIRCd has three types of server. Although the same in design, and speaking the same protocol, their behaviours are different due to the roles they play in maintaining the network. These are:

Hubs

A hub is categorized as any server which has more than one locally connected server. A hub differs from normal operation in that the bandwidth passing through a hub is usually much greater than that passing through a leaf, and it may expend more computing power to run a hub.

Leafs

A leaf is categorized as any server which has only one, or no connected servers. A leaf does not have to route as much information as a hub (see above) but usually because of this is configured to hold many more clients as it has the spare computer power to hold the users.

U-Lines

A U lined server is usually a leaf server, however in InspIRCd, a hub may also be U lined. U lined servers have many extra privilages, which are required for example to operate a services server or similar. U lines must be individually configured on all servers to work, and all servers must be in agreement about the names of the U lined servers. If they are not in agreement, mode changes will be dropped and commands forbidden which should operate normally.

Timestamp Syncronization

Because the InspIRCd spanning tree protocol operates using timestamps based around the UNIX "epoch" value, you must ensure that all clocks are synchronized on your network. This is best done with ntpd or ntpdate. If you do not synchronize the clocks on your servers, you will find that timestamp calculations will exhibit strange results, and users will be randomly deopped in new channels.

The InspIRCd spanning tree protocol should build in a margain of error of up to ten minutes (600 seconds) for FJOINs to new channels only, so that upon the clocks being out of sync, new channels can still be created successfully.

Example Traffic

This is an example of a netburst and some random traffic between InspIRCd 1.0 beta 6 and IRCServices, running the newer IRCServices module, which is shown here to aid those wanting to see first hand how InspIRCd behaves when sent certain commands, etc.

This example shows a connection to a test network with two connectable servers and a services server:

[09:31] --- test2.chatspike.net
[09:31] --- `-test.chatspike.net
[09:31] ---   `-services-dev.chatspike.net
[09:31] --- End of /MAP

Initiated connection to 10.0.0.1:7000
Sent: SERVER services-dev.chatspike.net password 0 :IRCServices test server
Sent: BURST
Sent: :services-dev.chatspike.net VERSION :ircservices-5.0.56 services-dev.chatspike.net :build #26, compiled Wed Dec  7 11:31:19 GMT 2005
Sent: :services-dev.chatspike.net NICK 1133994664 OperServ chatspike.net chatspike.net services +oii 0.0.0.0 :Operator Server
Sent: :services-dev.chatspike.net NICK 1133994664 Global chatspike.net chatspike.net services +oii 0.0.0.0 :Global Noticer
Sent: :services-dev.chatspike.net NICK 1133994664 NickServ chatspike.net chatspike.net services +oi 0.0.0.0 :Nickname Server
Sent: :services-dev.chatspike.net NICK 1133994664 ChanServ chatspike.net chatspike.net services +oi 0.0.0.0 :Channel Server
Sent: :services-dev.chatspike.net NICK 1133994664 MemoServ chatspike.net chatspike.net services +oi 0.0.0.0 :Memo Server
Sent: :services-dev.chatspike.net NICK 1133994664 StatServ chatspike.net chatspike.net services +ii 0.0.0.0 :Statistics Server
Sent: :services-dev.chatspike.net NICK 1133994664 HelpServ chatspike.net chatspike.net services +i 0.0.0.0 :Help Server
Sent: :services-dev.chatspike.net NICK 1133994664 DevNull chatspike.net chatspike.net services +i 0.0.0.0 :/dev/null -- message sink
Sent: :services-dev.chatspike.net ADDLINE G test@test.com Brain 1133994664 0 :You are banned from this network
Received: SERVER test.chatspike.net password 0 :ChatSpike InspIRCd test server
Received: BURST
Received: :test.chatspike.net VERSION :InspIRCd-1.0(Beta6)+CVS Rev. 1.516 test.chatspike.net :FreeBSD neuron.brainbox.winbot.co.uk 5.4-RELEASE [FLAGS=0,kqueue,singlethread]
Received: :test.chatspike.net SERVER test2.chatspike.net * 1 :Second server
Received: :test2.chatspike.net VERSION :InspIRCd-1.0(Beta6)+CVS Rev. 1.516 test2.chatspike.net :Linux brainwave 2.6.12-gentoo-r6 [FLAGS=0,epoll,singlethread]
Received: :test.chatspike.net NICK 1133992412 Brain synapse.brainbox.winbot.co.uk netadmin.chatspike.net ~brain +xwsioS 10.0.0.2 :Craig Edwards
Sent: :NickServ SVSMODE Brain :-r
Sent: :NickServ NOTICE Brain :This nickname is registered and protected.  If it is your nickname, type /msg NickServ IDENTIFY password.  Otherwise, please choose a different nickname.
Sent: :OperServ GLOBOPS :Brain is now an IRC operator.
Received: :Brain OPERTYPE NetAdmin
Received: :test.chatspike.net METADATA Brain swhois :blah blah test blah
Received: :test2.chatspike.net NICK 1133992705 Brain2 127.0.0.1 0284D4C2C220AFC6.Blah.cloak ~brain +xwsi 127.0.0.1 :Craig Edwards
Received: :test.chatspike.net NICK 1133992510 w00teh my.fart.made.an.eternalstorm.org InspIRCd-Testnet-0893F385B1545E74.fart.made.an.eternalstorm.org ~w00t +x 66.111.40.128 :Robin Burchell
Received: :test.chatspike.net NICK 1133992412 DesktopOm wlupton.gotadsl.co.uk netadmin.chatspike.net ~om +xwsioS 81.6.252.165 :><(((\uffff\uffff>
Sent: :NickServ SVSMODE DesktopOm :-r
Sent: :NickServ NOTICE DesktopOm :This nickname is registered and protected.  If it is your nickname, type /msg NickServ IDENTIFY password.  Otherwise, please choose a different nickname.
Sent: :OperServ GLOBOPS :DesktopOm is now an IRC operator.
Received: :DesktopOm OPERTYPE NetAdmin
Received: :test.chatspike.net NICK 1133992598 Ghost hack.fi InspIRCd-Testnet-9204BC848FC84F28.fi ~Ghost +x 83.145.201.47 :Ghost
Received: :test.chatspike.net NICK 1133992430 Cyan 69.90.46.135 67B46DBE20695D01.InspIRCd-Testnet.cloak ~cyan +xiw 69.90.46.135 :Cyan Garamonde
Received: :test.chatspike.net NICK 1133992409 Omster wlupton.gotadsl.co.uk InspIRCd-Testnet-BD9CEF261F514F7B.gotadsl.co.uk ~om +xwsi 81.6.252.165 :Mr. Tiddles
Received: :test.chatspike.net FJOIN #test 1133992411 Omster Brain DesktopOm Cyan w00teh Ghost Brain2
Sent: :services-dev.chatspike.net FTOPIC #test 1133865017 Ghost :This is a test server. Support network at irc.inspircd.org -- Yes, this ircd package will eventually replace unreal on ChatSpike | Pwnd by Ghost
Received: :test.chatspike.net FMODE #test +ntr
Received: :test.chatspike.net FTOPIC #test 1133865017 Ghost :This is a test server. Support network at irc.inspircd.org -- Yes, this ircd package will eventually replace unreal on ChatSpike | Pwnd by Ghost
Received: :test.chatspike.net ADDLINE Z 66.66.66.66 <Config> 1133992407 0 :This is the devils ip. You cannot use it.
Received: :test.chatspike.net ADDLINE Z 69.69.69.69 <Config> 1133992705 0 :No porn here thanks.
Received: :test.chatspike.net ADDLINE Q *[rxHO]* <Config> 1133992407 0 :Script kiddiot.
Received: :test.chatspike.net ADDLINE Q ChanServ <Config> 1133992705 0 :Reserved For Services
Received: :test.chatspike.net ADDLINE Q NickServ <Config> 1133992705 0 :Reserved For Services
Received: :test.chatspike.net ADDLINE Q OperServ <Config> 1133992705 0 :Reserved For Services
Received: :test.chatspike.net ADDLINE Q MemoServ <Config> 1133992705 0 :Reserved For Services
Received: :test.chatspike.net ADDLINE G test@test.com Brain 1133992727 0 :You are banned from this network
Received: :test.chatspike.net ADDLINE E *@ircop.host.com <Config> 1133992705 0 :Opers hostname
Received: ENDBURST
Sent: :ChanServ MODE #test +ntr
Received: :Brain PRIVMSG NickServ : identify xxxxxxx
Sent: :NickServ NOTICE Brain :Password incorrect.
Received: :test.chatspike.net PING services-dev.chatspike.net
Sent: :services-dev.chatspike.net PONG services-dev.chatspike.net services-dev.chatspike.net

Bold text