From: Bleep Date: Sat, 18 Mar 2000 05:20:30 +0000 (+0000) Subject: Author: Bleep X-Git-Url: http://git.pk910.de/?p=ircu2.10.12-pk.git;a=commitdiff_plain;h=ae91ef6320f611af74e70a0db2620c338fbaa7d5 Author: Bleep Log message: Update ircu2.10 to ircu2.10.10 level merge beta into main trunk git-svn-id: file:///home/klmitch/undernet-ircu/undernet-ircu-svn/ircu2/trunk@27 c9e4aea6-c8fd-4c43-8297-357d70d61c8c --- diff --git a/.patches b/.patches deleted file mode 100644 index 915a87a..0000000 --- a/.patches +++ /dev/null @@ -1 +0,0 @@ -ircu2.10.07+.09 diff --git a/BUGS b/BUGS index 2ca1337..c5c9519 100644 --- a/BUGS +++ b/BUGS @@ -1,8 +1,6 @@ # -# $Id: BUGS,v 1.2 1999-12-11 08:54:13 bleep Exp $ +# BUGS file for ircu2.10 # -# Undernet ircu BUGS File -# Please put information about known bugs here, if the bug has been resolved -# please comment the entry with "(fixed)" +# $Id: BUGS,v 1.3 2000-03-18 05:20:27 bleep Exp $ # diff --git a/ChangeLog b/ChangeLog index 8753262..1589727 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,32 +1,8 @@ # -# ChangeLog for Undernet ircu Servers +# ChangeLog for ircu2.10.11 # -# $Id: ChangeLog,v 1.12 2000-03-18 01:59:56 bleep Exp $ +# $Id: ChangeLog,v 1.13 2000-03-18 05:20:27 bleep Exp $ # -# Please insert new entries on the top of the list, a one or two line comment -# is sufficient. Please include your name on the entries we know who to blame. -# Please keep lines < 80 chars. -#------------------------------------------------------------------------------- -* Added hostname hiding compatible with ircu2.10.10 to allow host hiding - for transitioning services, back out pline8 for now. --Bleep -* Fixed default behavior for BADCHAN. supposed to DEFAULT yes, however - should not change each time a make config is done. -- WT -* doc/readme.www: add Runs link update patch for linux info. --Bleep -* channel.c, channel.h: add David M's fixup for local channel oper overrides. - --Bleep -* s_misc.c (date): add Runs Y2K patch --Bleep -* hash.c (hChangeClient): bug fix. If the client pointer matched the first - pointer in the bucket, the change was ignored (returned 0), leaving stale - values in the hash table, eventually causing the server to die for mysterious - reasons. Bug discovered by Quant and Isomer --Bleep -* config-sh.in, channel.h, numeric.h, channel.c, s_debug.c, s_err.c: - add lchanmode patch by CaptJay, add symbols to incredibly long - feature string. Bump patchlevel to .03 --Bleep -* list.h list.c s_conf.h s_conf.c opercmds.c: - badchan patch 2 seperate settings, allow global, and allow local. - currently allow_local is 'unapproved' for use on undernet. --WildThang -* ircd.h, s_serv.h, s_debug.h, ircd.c, s_user.c, s_bsd.c: - removed STAT_MASTER/BOOT_OPER code, original patch by Isomer --Bleep -* s_user.c (m_nick): removed redundant check for acptr --Bleep -* ChangeLog (file): added ChangeLog, and BUGS files, import to ircu2.10 --Bleep - +# Insert new changes at beginning of the change list. +# +* new version tag diff --git a/ChangeLog.07 b/ChangeLog.07 new file mode 100644 index 0000000..f5ceb2e --- /dev/null +++ b/ChangeLog.07 @@ -0,0 +1,32 @@ +# +# ChangeLog for Undernet ircu Servers +# +# $Id: ChangeLog.07,v 1.1 2000-03-18 05:20:28 bleep Exp $ +# +# Please insert new entries on the top of the list, a one or two line comment +# is sufficient. Please include your name on the entries we know who to blame. +# Please keep lines < 80 chars. +#------------------------------------------------------------------------------- +* Added hostname hiding compatible with ircu2.10.10 to allow host hiding + for transitioning services, back out pline8 for now. --Bleep +* Fixed default behavior for BADCHAN. supposed to DEFAULT yes, however + should not change each time a make config is done. -- WT +* doc/readme.www: add Runs link update patch for linux info. --Bleep +* channel.c, channel.h: add David M's fixup for local channel oper overrides. + --Bleep +* s_misc.c (date): add Runs Y2K patch --Bleep +* hash.c (hChangeClient): bug fix. If the client pointer matched the first + pointer in the bucket, the change was ignored (returned 0), leaving stale + values in the hash table, eventually causing the server to die for mysterious + reasons. Bug discovered by Quant and Isomer --Bleep +* config-sh.in, channel.h, numeric.h, channel.c, s_debug.c, s_err.c: + add lchanmode patch by CaptJay, add symbols to incredibly long + feature string. Bump patchlevel to .03 --Bleep +* list.h list.c s_conf.h s_conf.c opercmds.c: + badchan patch 2 seperate settings, allow global, and allow local. + currently allow_local is 'unapproved' for use on undernet. --WildThang +* ircd.h, s_serv.h, s_debug.h, ircd.c, s_user.c, s_bsd.c: + removed STAT_MASTER/BOOT_OPER code, original patch by Isomer --Bleep +* s_user.c (m_nick): removed redundant check for acptr --Bleep +* ChangeLog (file): added ChangeLog, and BUGS files, import to ircu2.10 --Bleep + diff --git a/ChangeLog.10 b/ChangeLog.10 new file mode 100644 index 0000000..1059c7e --- /dev/null +++ b/ChangeLog.10 @@ -0,0 +1,548 @@ +# +# ChangeLog for ircu2.10.10 +# +# $Id: ChangeLog.10,v 1.1 2000-03-18 05:20:28 bleep Exp $ +# +# Insert new changes at beginning of the change list. +# +* Don't bother doing hostname lookup or setting me.sockhost + since we never want to display it there is really no reason + to have the info. --Bleep +* Bugfix broken N:line check in chkconf --Maniac +* Bugfix, fix clients occasionally getting stuck in IPcheck + code. Add note to members in client struct that aren't used + for any remote client code, didn't want to actually move them + this close to release (paranoia) --Bleep +* A few little cleanups in check_pings, removed yet another + address display. --Bleep +* Bugfix, autoconnects displaying server IP address to opers. + --Bleep +* Remove names from /stats p, since its always the server + name from the M:line anyhow, (redundant information) + --Bleep +* Unborked throttling. --Bleep +* Fix two stupid bugs, related to IP mismatch kills. --Bleep +* Clean up configuration, make it a bit easier for admins to + turn off asserts and heap checking code. Moved host name dns + query for listener virtual host ports to dead code and use + me.name for the listener name (no sense in looking up the name + if we don't want to display it). Change direct bump of unknowns + in s_bsd.c to Count_newunknowns(UserStats) for consistency. + --Bleep +* Added option to kill any connecting client with a forward and + reverse DNS mismatch. Fixed bug in s_auth that that caused + incorrect counts for unknown clients. Replaced missing server + notice for SNO_IPMISMATCH. --Bleep +* Added a few more little name tweaks, no sense in looking up + the hostname in the conf if no one knows it. --Bleep +* Moved to beta archive, bumped patchlevel, fixed message for + lost C:line in s_conf.c (I don't think I've ever seen this happen) + --Bleep +* Finished host hiding changes, it should not be possible for any + online user to discover the real hostname or IP address of any + connected or unconnected server listed in the configuration. This + applies to opers and regular users. The name in the M:line is the + name used for connecting and all informational messages. --Bleep +* Removed code in dbuf.c that flushes the dbufs if the server runs out + it looks like a fully loaded server may not be able to handle a net + break without shedding a few clients. --Bleep +* Finish IP address cleanup, alpha should be clean for not displaying + server hosts or IP addresses to users now. This needs to be verified. + Changed version to u2.10.10 per Isomers suggestion. --Bleep +* Remove server IP address from info line for connecting servers. + This almost completes the IP address hiding changes for alpha, there + are still a few stats commands available to users that will show the + server addresses, but they can be easily disabled or only show '*'s + to non-opers. --Bleep +* Fix possible (but not likely) memory leak in debug allocator, couldn't + find the "meg a minute" problem, using the debug allocator on the + production network with more than 1000 clients on a server may cause + problems if you don't have a lot of memory. (This does not seem to + be a problem with non-debug builds) --Bleep +* Captialisation fixes, just to keep certain ppl quiet. --Isomer +* Removed +s channels from /list. They were shown sometimes, but not + others, and the information that was shown about them was inconsistant. + list is not an effective way to gain information anyway. Reformatted + and touched up readme.who as well. --Isomer +* Added MAP to ISUPPORT, added doc/features.txt --Isomer +* Added suggestions made by scripters. more info for ISUPPORT, and + added stuff to 'TODO' --Isomer +* More TODO items 'done'. P:'s now ignore '*'s. ping shouldn't do funky + stuff with mirc anymore, needs discussion --Isomer +* Typo fixed. Now I'm annoyed. --Isomer +* Right, Makefile's gonna work now or I'm going to get REALLY annoyed at it. + --Isomer +* TODO, m_ping, ircd/Makefile.in: Added note to TODO, added info to + m_ping, and fixed Makefile bug using bsdmake. --Isomer +* s_bsd.c, listener.c, s_user.c, s_serv.c, s_bsd.h: + Set receive and send buffers in correct order to enable flow + control for clients and support fat pipes better for servers. + Finally got it right :) + See Stevens "Unix Network Programming" v1 p 191-193 + --Bleep +* ircd.c (main): added idiot checking to make sure MAXCONNECTIONS + is sane. --Bleep +* send.c: Don't let negative fd's break stuff, audit sentalong + usage for sillyness. --Bleep +* send.c (sendto_common_channels): bug fix, code assumed client + local, file descriptor is only in local client struct + --Bleep +* table_gen.c, channel.c: make FIXME changes, removed + FIXME code from table_gen, readd FIXME code to channel.c, + I hope I got this right. --Bleep +* Makefile.in: Add purify def, fix so CFLAGS don't error + off when using Solaris compiler --Bleep +* fda.c (fda_free): fix compile error on Solaris --Bleep +* configure.in: add SunOS case to detect Solaris --Bleep +* os_solaris.c (os_send_nonb): fix solaris compile error --Bleep +* exaconf.2: add file from conf design to docs directory to + have it available for new conf parser development --Bleep +* fda.c (fda_free): fix memory leak, doh!!! --Bleep +* hash.c (addNickJupes): fix buffer overrun --Bleep +* s_bsd.c (read_message(poll)): fix uninitialized memory read + bogosity in poll macros. --Bleep +* channel.c (send_user_modes): change to send XXX:ov instead + of XXX:o:v doesn't send XXX: if no modes set. --Bleep +* s_bsd.c (connect_server): bugfix for connect/rehash/connect + multiple outstanding dns query core. --Bleep +* channel.c (send_user_modes): bugfix for burst not sending modes + when burst line is created. --Gte +* m_gline.c: change NumServ(cptr) to NumServ(sptr) found by Gte + --Bleep +* config-sh.in: add WildThangs BADCHAN config fix --Bleep +* config-sh.in: add Runs restart bugfix --Bleep +* Makefile.in: make sure version.c gets regenerated when checksums + change --Bleep +* Makefile.in: remove hash.c/crypt/sums idiocy, all of the ridiculous + anti-hack stuff is already done in version.c anyhow. + "Shhh..., don't tell the admins ( .)( .) you're being watched" + --Bleep +* hash.c (m_hash): fix count bugs --Bleep +* m_squit.c (mo_squit): fix off by one, /quote SQUIT bug --Bleep +* ircd_relay.c: oops, changed the wrong one. Fixed previous fix. --Isomer +* Makefile.in, ircd_relay.c: Fixed 'make depend', added dependancies, fixed + bug where server would core on sending a server notice --Isomer +* m_kick.c (ms_kick): fix core on kick message coming from + server --Bleep +* config.in: remove CRYPT_LINK_PASSWORD option --Bleep +* doc/readme.www: Applied Runs' doc patch --Bleep +* client.h: Add member to client struct to try to aggravate the + bug found by Jesus --Bleep +* client.h: Remove IsListening macros and flags, add FLAGS_UPUNG + and IsUPing/GetUPing/SetUPing macros --Bleep +* m_silence.c, m_create.c: check for IsServer(sptr) don't + allow X SILENCE X +*@*.com or X C #blah 947477407 core the + server. --Bleep +* os_*.c, res.c: clean interface for os_recvfrom_nonb --Bleep +* uping.c, uping.h: new files for UDP pings, these aren't hooked up yet, or + finished or tested. + --Bleep +* channel.c: find_member_link(): Fail fast for Servers, prevents core when + servers set a channel mode. --Isomer +* channel.c, channel.h, various.c: Changed find_member_link() to take + a chptr instead of the first member, and special case'd +k users + (see comment in code for more details) --Isomer +* ircd/Makefile.in: Changed gnu specific $^ for $< in table_gen + rules --Bleep +* INSTALL: Explained about CVS --Isomer +* example.conf: Point to coder-com@ for help configuring the server. --Isomer +* INSTALL: Make things a bit more plain. --Isomer +* s_bsd.c (read_message (poll)): removed local_cptr array using + this temp made possible a bug where if a client lower in the list + managed to exit a client higher in the list, a dangling reference + to the already exited client would be left in the local_cptr array. + Found by Quantum by loading 100's of clones with the same nick. + --Bleep +* INSTALL: Added instructions for -lcrypt FAQ --Isomer +* INSTALL: Added instructions for -lresolv FAQ --Isomer +* INSTALL: Added instructions for making ./configure executable --Isomer +* numeric.h: Merged in some more numerics that other ircds user --Isomer +* IPcheck.c: Fix gramatical error to keep pedants happy. --Isomer +* IPcheck.c: Allow -DNOTHROTTLE for debugging purposes. --Isomer +* m_stats.c: make stats c available to opers only, TEMP_HACK --Bleep +* IPcheck.c: Fixed outdated comment. Thanks Quantum --Isomer +* ircd_reply.c: Fix the fix, silly typo. thanks Bleep --Isomer +* ircd_reply.c: added check for people without nicks. --Isomer +* doc/Authors, ircd/version.c.SH: updated /info and maintainer + lists. --Isomer +* channel.h, channel.c, m_join.c, m_mode.c: add David M's + lchanmode patch update --Bleep +* s_auth.c: fix ident bug, comment code for rule. --Bleep +* m_invite.c (m_invite): Fix syntax error, missing ')'. -- Isomer. +* m_invite.c (m_invite): tokenize invites, change from accidental + broadcast to directed message (bug fix). --Bleep +* m_time.c (m_time): send tokenized time messages --Bleep +* s_user.c (set_user_mode): Send wallops to everyone by default + allow compile option WALLOPS_OPER_ONLY for networks that want + to disable wallops for users. --Bleep +* s_misc.c (exit_one_client): tokenize client quit message to other servers. + --Gte +* m_kick.c: you would have thought I'd fix all of them the first time, but + no... -- Isomer +* m_kick.c: Fixed missing space after TOK_KICK -- Isomer +* m_burst.c: Fixed netrider kick bugs -- Isomer +* s_user.c: Bug fix --Bleep +* s_user.c: only send wallops to opers --Bleep +* s_user.c: enforced undernet policy. -- Isomer +* s_user.c: replace user_modes with struct UserMode array + change code to use new struct. --Bleep +* s_user.c (set_user_mode): clean up switch statement --Bleep +* channel.c (set_mode): fixed -k foo bug, extra == 0 typo in + conditional. --Bleep +* dbuf.c (dbuf_alloc): fixed count bug, we _have_ to count it in + the branches. --Bleep +* dbuf.c, send.c, s_bsd.c, send.h: bahh finally did it right, + if a dbuf allocation fails, attempt to flush all send buffers except + for the one we are trying to build (we're twiddling with the list etc..) + if the allocation fails a second time, _then_ bail. --Bleep +* s_bsd.c, send.c: if dbuf_put fails for send or receive buffers, + call flush connections to free up some buffers (safe here). --Bleep +* dbuf.c (dbuf_put): back out previous change, afaict it would fail + spectacularly --Bleep +* dbuf.c (dbuf_put): call flush_connections(0) if we can't allocate + a dbuf the first time, this may prevent the server from dropping + connections during netbursts. --Bleep +* m_privmsg.c: fix IDLE_ON_MSG fix -- Isomer +* m_privmsg.c, parse.c: fix IDLE_ON_MSG bug --Bleep +* m_ison.c (m_ison): Temp hack to fix missing null terminator. --Bleep +* m_nick.c (m_nick): fix null nick reply bug --Bleep +* ircd_string.c, match.c: fix a couple possible issues with + the character attribute changes --Bleep +* s_auth.c, ircd.c: turn off connection status messages for + connections to server ports. --Bleep +* ircd.c, s_conf.c, m_server.c, ircd.h, s_conf.h: + removed portnum and server_port global variables, server port + in M:lines is ignored, server ports now need to be defined in + the P:lines. Add SERVER_PORT config option to allow: + '/connect server.net.dom' without specifying the port. --Bleep +* config-sh.in: change PORTNUM to SERVER_PORT now used for + default server port for outgoing connections in m_connect. + --Bleep +* example.conf: document changes to M:line for server port --Bleep +* ircd_chattr.h, ircd_string.h, ircd_string.c, table_gen.c: + put Nemesi's table generation code and macros back in, the + tables are now automagically generated whenever the table_gen.c + file is modified, use a slightly different mechanism to get the + tables in the executable. Add reference data file to test dir + for character attributes. --Bleep +* s_auth.c (check_ident_reply): add function that implements + auth reply undernet rules checking. --Bleep +* s_misc.c (date): added Runs Y2K patch --Bleep +* m_privmsg.c: work on server handlers, hookup new code to parser, + test, fixed a couple bugs, fixed username bug in server NICK + processing --Bleep +* ircd_chattr.c, m_privmsg.c: Work on privmsg code a bit more, + commit for review, still a bit more to do --Bleep +* os_bsd.c, configure.in: add os dependency file for bsd + --Bleep +* m_privmsg.c, ircd_string.c: little cleanups for privmsg + work on prototype handler for new parser. --Bleep +* m_connect.c, s_conf.c: clean up /connect handling code + --Bleep +* m_away.c, m_admin.c, m_close.c, m_connect.c: + start cleaning up handlers --Bleep +* whocmds.c, whowas.c, *.c: split out handlers from whocmds.c + and whowas.c --Bleep +* s_serv.c, m_*.c: split out handlers from s_serv.c + --Bleep +* querycmds.c, m_*.c: split out handlers from querycmds.c + --Bleep +* opercmds.c, m_stats.c, m_connect.c, parse.c, handlers.h, *.c + add new command handlers --Bleep +* channel.c, m_names.c: new file for names handler --Bleep +* channel.c, m_list.c: new file for list handler --Bleep +* channel.c, m_topic.c: new file for topic handler --Bleep +* channel.c, m_burst.c: new file for burst handler --Bleep +* channel.c, m_create.c: new file for create handler --Bleep +* channel.c, m_destroy.c: new file for destroy handler --Bleep +* channel.c, send.c, m_join.c: new file for join handler, + const fixups for send.c --Bleep +* channel.c, m_mode.c: new file for mode command handler, + clean up file scope buffer mess. --Bleep +* m_silence.c: split out SILENCE handler to a new file, + cleanup --Bleep +* m_ison.c: split out ISON handler to a new file, cleanup --Bleep +* m_userip.c: split out to new file, change userhost and userip + to use same algorithm with different formatting functions --Bleep +* m_userhost.c: split out to new file --Bleep +* send.c: add new function send_buffer, cleanup godemode ick a bit + --Bleep +* m_wallchops.c: split out wallchops handler --Bleep +* m_cprivmsg.c: split out m_cprivmsg and m_cnotice. +* m_pass.c, s_user.c: split out m_pass, pass message handler + --Bleep +* m_oper.c: split out m_oper.c from s_user.c, setup to use + new parser. --Bleep +* m_pong.c, m_ping.c, parse.c, s_user.c, channel.c: + Add new file for pong messages, convert ping and pong to use + numerics. Test pings and pongs on testnet. Fix numeric + nick bug in channel.c. --Bleep +* m_ping.c, s_serv.c, parse.c: new file for pings, fixed a + minor bug in ping handling. --Bleep +* m_nick.c, m_kill.c: clean up nick code for servers, still needs work + fix string formatting bug in m_kill --Bleep +* m_nick.c, s_user.c, ircd_chattr.c: add new file for NICK command, + clean up local client registration for nicks. --Bleep +* m_away.c, s_user.c, parse.c: split out m_away handlers for client, + add user_set_away function. --Bleep +* m_kill.c, ircd_reply: Rework handling of kill from server, add new error + message formatter. --Bleep +* m_kill.c (mo_kill): Rework handling for kill from operator on server + kill originated from --Bleep +* m_kill.c: new message handler file for kill --Bleep +* configure.in, ircd/Makefile.in: added automatic os checking to autoconf + checked --Gte +* m_quit.c: new message handler file for quit --Bleep +* m_privmsg.c: new message handler file for privmsg --Bleep +* ircd_string.c, support.c, support.h, *.c: moved strtoken to ircd_string + and renamed ircd_strtok --Bleep +* channel.c, s_user.c, s_debug.c, send.c, channel.h: finish membership code + --Bleep +* channel.c, more cleanups of membership code and macros --Bleep +* channel.c, s_misc.c: more cleanup in channel link code, most likely + still a bit broken yet, more to come. --Bleep +* querycmds.h (Count_remoteclientquits): fix minor bug --Bleep +* ircd.h, querycmds.h, struct.h, channel.c, list.c, map.c, opercmds.c, + s_err.c, s_serv.c, s_user.c, s_misc.c: Add Isomers passivelag0-1.patch + fixed minor bug in macros --Bleep +* channel.h, channel.c, s_user.c, s_debug.c, s_user.c: + added Membership struct for channel associations, change user/channel + lookups to use new struct. --Bleep +* channel.c, channel.h, s_user.c: cleanup channel and user code + a bit, new function find_no_nickchange_channel --Bleep +* parse.c, m_defaults.c: added default handlers and hooked up new + message handlers --Bleep +* *.c, struct.h: added Isomer's passivelag patch and, the second + p10 patch --Bleep +* ircd_reply.[ch]: new files for commonly used replies --Bleep +* m_proto.[ch]: new file for protocol command support, needed for zip + links --Bleep +* client.h, parse.c, msg.h: add code to support multiple message handlers + depending on client status. --Bleep +* s_bsd.c, packet.c: code cleanup prep for zip links --Bleep +* channel.c, opercmds.c, ircd.c, s_serv.c, s_user.c, querycmds.c, + whocmds.c, whowas.c: Add Isomers p10ify patch, tokenize server to + server commands --Bleep +* s_user.c (m_nick): killed goto --Bleep +* client.h, *.c: moved client stuff to client.h --Bleep +* version.c.SH, patchlevel.h, .patches: change version string + generation, patch level is now set in patchlevel.h by simply + bumping the number in the PATCHLEVEL string. --Bleep +* ircd_alloc.c, channel.c: fixup warnings in release build (NDEBUG) + --Bleep +* fda.h, ircd_alloc.h, fda.c, ircd_alloc.c, fda_t.c: new files, + runmalloc was core dumping on squits and unable to handle or + detect double frees, the memory debug code can be disabled by + compiling with NDEBUG defined --Bleep +* channel.c (remove_user_from_channel): refactor function --Bleep +* channel.c (m_kick): refactor function a bit, put all checks at top + move code out to new function (make_zombie) --Bleep +* s_bsd.c (completed_connection): fixed stupid + "Write error to blah: Socket not connected" bug --Bleep +* struct.h, send.h, send.c, s_bsd.c, IPcheck.c, s_user.c, *: + More socket code cleanup, move file descriptor to local part of + client struct, use cptr->error to handle the errno of any socket + error, fix bug in IPcheck that ends up only disallowing every + 256th clone, Add more ipcheck forgiveness to s_user.c (needs work). + Changed IPcheck_local_connect and IPcheck_connect_fail interfaces to + use struct in_addrs instead of client structs to allow delaying the + allocation of the client struct till after the check was done. + Added can_send function to send.c (should be called before work is done + but right now it's called just before trying to send (needs work)) +* channel.c: Added Isomers netride2.patch, still needs a config option + to turn it on (NO_INVITE_NETRIDE) --Bleep +* parse.c, msg.h: Added silent ignores for notices so connect progress + messages do not cause connecting server to spew ERR_REGISTER_FIRST + messages at the server it's connecting to. --Bleep +* s_serv.c, s_user.c, channel.c, send.c: Tokenised BURST, NICK, + END_OF_BURST, EOB_ACK, PRIVMSG and NOTICE Server to Server. + About 8-10% Bandwidth saving on BURSTS. --Gte +* channel.c (m_join): servjoin patch --Isomer +* ircd_osdep.h, os_*.c, s_bsd.c, send.c: more cleanups in socket code, + use enumeration for IO results. --Bleep +* s_bsd.c: clean up select and poll code a bit more, fixed message pacing bug + in poll. --Bleep +* supported.h, numeric.h, s_user.c, s_err.c: Added Isomers features + patch. Use numeric 005 RPL_ISSUPPORT to convey server features to + clients. --Bleep +* s_user.c (m_nick): IP differ patch, use IP address instead of host + name to determine different user@host for nick collides. --Isomer +* hash.c (hChangeClient): Bug fix. Fixed bug that caused stale entries + to be left in client hash table after a name change. Discovered by + Quant and Isomer. --Bleep +* hash.c (hSeekClient): fixed bug I introduced when reversing my hash + table code changes, thanks Quant and Isomer --Bleep +* opercmds.c (m_lusers): send limited luser info to remote + clients --Isomer +* numeric.h, channel.c, s_err.c: Changed invite list numerics + from 283/284 to 346/347 to match IRCnet numerics --Bleep +* config-sh.in, gline.h, numeric.h, gline.c, opercmds.c, s_debug.c, s_err.c: + Add badchan patch by WildThang --Bleep +* config-sh.in, channel.h, numeric.h, channel.c, s_debug.c, s_err.c: + Add lchanmode patch by David M --Bleep +* channel.c (cancel_mode): removed incorrect assert --Bleep +* *.c: removed P9 support, not everything is completely gone but most + of it is, the server builds and connects to other servers, but thats + as far as it's been tested so far. --Bleep +* ircd.h, ircd.c, s_bsd.c: + removed BOOT_INETD/BOOT_CONSOLE code, unused non-functional --Bleep +* struct.h, ircd.h, ircd.c, s_user.c, s_bsd.c: + removed BOOT_OPER/STAT_MASTER code, original patch by Isomer --Bleep +* s_user.c (m_nick): removed redundant check for acptr +* hash.c (hSeekClient, hSeekChannel): roll back some of hash.c changes +* hash.c (hSeekClient, hSeekChannel): removed unused variable from previous + changes. +* hash.c (hSeekClient, hSeekChannel): fix compile error from status changes, + fix logic bug that caused the first client that matched the mask to be + returned regardless of whether or not it's name matched, this can result + in wierd problems where the wrong server/client could be returned from the + hash table lookup. Removed code that moved client to head of hash table + chain for it's bucket when it's looked up, if the hash table is working + reasonably well this just wastes cpu. +* hash.c, list.c: added code to zero out cptr->hnext when client removed + from hash table, added assert for hnext == 0 in list.c to make sure that + client was actually removed from the hash table before freeing it's memory. +* various: misc cleanups +* support.c: removed dead code +* configure.in: remove unneeded checks for minix, aix, ansi/posix headers + these things are handled by porting layer code. +* res.c: remove calls to add_local_domain, these were causing incorrect + behavior +* opercmds.c: cleanups in gline code +* s_bsd.c: increase socket buffers to 65535 for server connections +* crypt/mkpasswd.c: mutter correct runes to get file to compile without warnings +* gline.c, gline.h: add new files to attempt to encapsulate glines a bit, + some code from opercmds.c needs to be moved here still +* opercmds.c (m_gline): fix local gline bug +* s_conf.c (initconf): add password change on rehash fix +* s_conf.c (rehash): fix rehash freeing and reloading the motd/rmotd files for + every client connected. +* ircd_log.c: use 2K fixed buffer instead of vsnprintf, nothing we write to + the log should ever exceed 512 bytes, but it doesn't hurt to be paranoid. +* res.c: change resolver timeouts to 5 seconds, per RFC1123 +* channel.c: more little cleanups, no code changes +* channel.c: a) stops iterating over /invite list + b) adds /invite to list the channels you're currently invited to. + c) adds lotsa new numerics --Isomer +* ircd_signal.c, ircd.c: fix bug in signals +* channel.c (can_send) add Isomer's changes +* channel.c: add send_ban_list, cleanup a few names, reformat some parts to make + more readable, fix bug introduced by name changes +* ircd_chattr.[ch]: add new macro for checking K:line time chars vs comments +* listener.c (show_ports): add code to show client/server and hidden status +* s_conf.c: bug fixes, cleanups, add code to set server port and hidden + status for listeners (P:lines) +* s_conf.c (initconf): add interface selection code to P:lines so ports can + be set on a single interface or multiple interfaces (multi-homed hosts) +* s_conf.c: rewrote C/N line code, removed N:lines entirely, clean up server + conf line code. +* s_conf.c (check_server): move ip checks out of resolved or not so they can + be checked for worse case situations on server connects +* res.c (resolver_read): add Isomer's debug info for failed resolver queries +* opercmds.c (m_stats): remove call to time(0) for each local client in + stats l command, use CurrentTime instead +* s_conf.c (initconf): only do lookups on C:lines instead of both C/N lines +* res.c: fix resolver hang bugs +* s_conf.c (rehash): remove extra semicolin that was causing c/n lines to + accumulate +* s_conf.c (rehash): add portnum back to the listener list so we don't loose + the server port on a rehash +* s_auth.c, listener.c: remove warnings for normal errors +* s_auth.c, listener.c: use osdep non-blocking calls instead of locals +* s_auth.c, listener.c: add code for non-blocking recovery for listeners and + auth queries +* s_auth.c (auth_error): call IPcheck_connect_fail if the client socket dies + during the auth check so the reference count doesn't get borked in the + IPcheck code. +* numnicks.c: yet another extended numerics bug fix... sheesh +* s_bsd.c, s_conf.c: move conf line code from s_bsd.c to s_conf.c, cleanup + cleanup check_server, check_client (still not completely tested, may be + a bit buggy yet). +* parse.h, parse.c, s_debug.c: remove privmsg logging code +* numnicks.c (FindXNServer): fix off by one bug +* common.h, common.c: removed unused files +* s_bsd.c (net_connect_completed): new function, called after connection + establishment for servers and clients, release reference count for + the dns reply and set the socket buffer size to IRCD_READBUF_SIZE + for servers and 2K for clients. +* channel.c, crule.c: cleanup bogus casts +* listener.h (add_listener): fix bug that caused server a server port listener + to think it was a client port listener. +* s_user.c, s_serv.c: release reference to dns_reply when connection is + established. +* s_bsd.c (completed_connection): removed call to start_auth for connects + the auth module expects connections not to be linked anywhere and owns + the client struct until it's done. +* listener.c (release_listener): fix inverted assert client exit bug +* ircd_chattr.c: fix signed/unsigned warnings with Sun Workshop (+w) +* ircd_chattr.c, ircd_chattr.h: new files for character attributes and case + translation, hopefully they will be a bit easier to maintain. +* s_conf.c (rehash): fixed logic bug that caused and infinite loop, + fix port update bug (needed to call mark_listeners_closing before initconf) +* *.c, runmalloc.[ch]: change the way the server deals with out of memory + conditions. On server startup a no-memory handler is installed which + calls server_restart if an allocation fails. Allocations are now checked + in the memory allocation functions. Added asserts after every allocation + to verify for debug. +* *.c *.h: move authentication and dns to authentication module rename a few + globals, const correctness fixes, add ircd_string code, rework network + code, use dns callbacks, removed a lot of redundant code +* s_bsd.c: finish this stage of net code work +* *.c, *.h: rewrite select and poll code, add listener.[ch] net.code overhaul + in progress, prepare for adding auth module +* s_bsd.h, struct.h: moved client struct macros back into struct.h for now, + the last place they belonged was in the network code... feh +* ircd.c (open_debugfile): removed client for debug file +* ircd_string.h, ircd_string.c: new files for string processing, add + ircd_strncpy function +* *.c, *.h: rename ircstp to ServerStats +* *.c, *.h: rename now to CurrentTime +* listener.h, listener.c: new files for listener ports +* include/ircd_defs.h: new file for global definitions (HOSTLEN, USERLEN) +* struct.h: add local_flag to client struct, to make local/remote detection simpler +* s_bsd.c (read_message): split out separate versions for select and poll +* s_bsd.h, various source files: remove the rest of the unix domain socket + support this removes a number of comparisons that were unneeded in + code that should run reasonably fast. +* os_*.c, res.c, ircd_osdep.h: add os_recvfrom_nonb for resolver +* os_*.c, s_bsd.c, s_auth.c, ircd_osdep.h: add os_get_sockname, os_get_peername +* bsd.h, bsd.c: merge into s_bsd +* ircd_osdep.h, os_generic.c, os_linux.c, ircd_osdep.h: move os variable stuff + to separate compilation units, os generic contains the original code + (start here). +* s_bsd.c, send.c, struct.h: remove pyr (pyramid) finally +* res.h, res.c, s_misc.c: cleanup headers/dependencies in res.h +* match.h: include sys/types.h before netinet/in.h, broken BSD system headers +* ircd/Makefile.in: remove CFLAGS from link line, use LDFLAGS instead +* ircd.c: add missing include for sys/socket.h +* common.h (strChattr, strCasediff): remove pointless non-portable inline + decls. The functions are complex enough that inlining just bloats the code +* ircd_xopen.h, ircd_xopen.c, s_user.c, s_serv.c: porting layer for crypt and + other xopen library calls, moved crypt to ircd_xopen. +* s_uping.c, s_uping.h, s_bsd.c, s_misc.c, s_bsd.h, ircd.c, s_debug.c: + Removed s_ping. There are much better tools available that actually work + correctly. The s_ping code was a waste of resources, and has historically + given incorrect results (it never worked correctly). +* ircd/s_bsd.c, res.c, s_user.c, s_serv.c: little fixups to allow code to + build on Solaris, still have some warnings there. + TODO: wrap crypt and things that depend on _XOPEN_SOURCE in their own + file so it doesn't bother the network code. +* ircd/s_bsd.c: cast option arg to const char* for setsockopt (solaris) +* ircd/Makefile.in: removed hard coded dependencies for hash.o chkconfig.o, + let the automatic stuff take care of it, it does it better than humans. +* *.c *.h: remove register keywords, attribute macro junk, cleanup + dependencies, rename MIN and MAX to IRCD_MIN IRCD_MAX all headers in + C files are sorted, removed as many duplicate includes as I could find + (dozens) general cleanups. Mutter the correct runes to get the protoype + for crypt included where it was needed. +* *.c *.h: dependency cleanups up to querycmds.c +* ircd.c, bsd.c, s_bsd.c: move signal handling code to ircd_signal.c +* ircd_signal.c, ircd_signal.h: new files, use only POSIX signals remove + support for unreliable signals. +* *.h *.c: include guards, dependency cleanups +* Configure.in, setup-sh.in: include guards, config.h includes setup.h + add config dir to include path +* sys.h: include guards, remove hard coded path to config.h +* s_user.c (hunt_server): fix logic bug +* numnicks.c (SetServerYXX): fix off by one error +* multiple files (n2k patch): add code to handle extended numerics diff --git a/INSTALL b/INSTALL index 2336cb8..01ebc04 100644 --- a/INSTALL +++ b/INSTALL @@ -1,39 +1,84 @@ - INSTALL file by Run - +INSTALL file by Run + Updated by Isomer This is the UnderNet IRC daemon. The installation of the IRC daemon (ircd) exists of the following steps: -1) Untar the package. +1) Retrieve the package. 2) cd into the base directory. -3 )`./configure' +3) `./configure' 4) `make config' 5) `make' 6) `make install' -1) Untar the package +1) Retrieve the package. ==================== -The name of the package is something like `ircu2.x.y.z.tgz', where -"x.y.z" is the current release (at the time of writing we have -ircu2.10.00.beta3.tgz). +The recommended way to get the ircu package now is to use CVS. CVS makes +upgrades a lot less painful and lets you get the latest package. + +1.1) The first thing you need to do is 'authenticate' yourself against the +server. + +This is done with: + +cvs -d :pserver:anoncvs@coder.com.undernet.org:/home/coder-com/cvs login + +(we recommend that you cut and paste the above line to use it :) +When it prompts you for a password enter 'anoncvs'. + +1.2) Then you have to decide which of the trees you want to use: + +irc2.10 - This is the *STABLE* tree. If in doubt use this one! -You need `gzip', the GNU unzip command, to uncompress this package. -You can download this from every GNU ftp site for almost any Operating system. +beta - This tree is undergoing testing before being promoted to ircu2.10 + It may be buggy. Use on the undernet production network is prohibited, + except for certain authorised servers. -If you have GNU tar, type: +alpha - This is the development tree, if you are planning on making patches + to be submitted to the main source tree we recommend you use this + tree. However this tree is *not* guaranteed to compile, and should + be concidered HIGHLY unstable. It is not intended for production + use. -tar xzf ircu2.x.y.z.tgz +to check out the tree, type: -where "ircu2.x.y.z.tgz" is the name of the package. +cvs -d :pserver:anoncvs@coder-com.undernet.org:/home/coder-com/cvs checkout + -P irc2.10 -If your tar doesn't support the 'z' flag, you can type alternatively: +The above two lines shouldn't have an enter between them. if you want to +use another tree, replace 'irc2.10' with the tree you want to use. This +will create a directory irc2.10, and put all the files in there. -gzip -dc ircu2.x.y.z.tgz | tar xf - +to get the latest version, from within the tree type "cvs update -dP". -Both methods result in a directory "ircu2.x.y.z" in your current directory. +For more information see the coder-com website at +http://coder-com.undernet.org/ +The old (tried and true) method that works even when the website isn't being +DoS'd (sigh) is included below. Using the method below means you /cant/ +just type 'cvs update -dP' to get the latest version. + + The name of the package is something like `ircu2.x.y.z.tgz', where + "x.y.z" is the current release (at the time of writing we have + ircu2.10.00.beta3.tgz). + + You need `gzip', the GNU unzip command, to uncompress this package. + You can download this from every GNU ftp site for almost any Operating system. + + If you have GNU tar, type: + + tar xzf ircu2.x.y.z.tgz + + where "ircu2.x.y.z.tgz" is the name of the package. + + If your tar doesn't support the 'z' flag, you can type alternatively: + + gzip -dc ircu2.x.y.z.tgz | tar xf - + + Both methods result in a directory "ircu2.x.y.z" in your current directory. + 2) cd into the base directory ============================= @@ -41,6 +86,8 @@ Make this directory your current directory by typing: cd ircu2.x.y.z +or ircu2.10 if you used cvs. + where "ircu2.x.y.z" is the name of the unpacked directory. 3) `./configure' @@ -49,6 +96,9 @@ where "ircu2.x.y.z" is the name of the unpacked directory. This will generate 'config/setup.h', your Operating System dependend configuration. +If this produces a 'Permission Denied' error message, then try typing +`chmod a+x ./configure` first to give yourself permission to run the file. + 4) `make config' ================ @@ -71,6 +121,14 @@ you did everything the right way. If you want your Operating System to be supported in future releases, you best make a patch that actually fixes the problem. +If you have problems here with it complaining about unresolved symbols in +res.o, try "make config" again and add -lresolv to LDFLAGS. Note, there is +no 'e' on the end of resolv. It's not a typo, it's supposed to be like +that. + +If you have problems here with it complaining about unresolved symbols +possibly in s_user.c for 'crypt', add -lcrypt to LDFLAGS. + 6) `make install' ================= @@ -102,3 +160,5 @@ This will write debug output to your screen, probably showing why it doesn't start. Don't use a server with DEBUGMODE defined on a production net. + +If things still don't work, try emailing coder-com@undernet.org diff --git a/README b/README new file mode 100644 index 0000000..cd9cea9 --- /dev/null +++ b/README @@ -0,0 +1,97 @@ + +README for ircu2.10.10.beta +Please read this completely before running the server + +* If you run ircu2.10.10 on the production network and expect + more than 1000 local clients to connect you will want to make + sure you add -DNDEBUG to the extra CFLAGS setting when you do + a make config. +* Ircu now uses asserts in a lot of places to insure referential + integrity and that impossible situations do not occur. Also + memory integrity checking is defaulted to on as well. The asserts + and memory checking both use cpu and in the case of memory checking + extra memory. We have not had an assert trigger in quite some time + but would prefer to leave the checks enabled for beta testing. + The asserts insure that if the server is going to core it will do + so in well defined places where the problem will be easy to trace, + without them the server could core in not so well defined places. + If you want to disable the checks, add -DNDEBUG in the extra CFLAGS + when you do a make config. + +* Ircu no longer uses separate C/N lines, the functionality of both + has been combined in C:lines, see the example.conf for more information. + +* Ircu has an different mechanism for defining ports than the previous + versions. Please see the example.conf for information on configuring + them. Ircu also ignores the port specified on the M:line, you MUST define + a server port with a P:line if you want servers to connect to you. + +* For beta releases, please understand that there may be bugs we haven't + found yet, (that's why you're beta testing it in the first place :)). + Please report any bugs found in the server to bugs@undernet.org or + coder-com@undernet.org with as much information as you can provide + about how to reproduce the problem. Stack traces for coredumps are + usually helpful, however we aren't expecting any of those ;-). + +* Ircu 2.10.08 is a P10 only server, and cannot be used to host P9 + links. On a mostly P10 network this is not a major issue, it does + mean that you cannot connect services directly to a 2.10.08 server, + but does not preclude it's use as a leaf or a hub. For now, services + need to continue to be hosted by 2.10.07 servers. + +* EXTENDED_NUMERICS is not defined by default, we need to get everyone + using 2.10.07 before we can allow it to be turned on anywhere. If you + are using 2.10.08 on a network where everyone is up to at least 2.10.07 + it is safe to turn them on. We have tested them on testnet and they do + work. :) + +* The masked notices using #*.mask has changed to use $@*.mask instead. + Since most of the servers on the net will not understand the new masking + mechanism, this probably won't work for a while. The server notice mask + ($*.us.undernet.org) still functions properly. This was a trade off + between backwards compatibility and the improved protocol, we chose to + not maintain backwards compatibility for this command. The #*.mask + functionality is easily circumvented, and the command is rarely used + it is not considered to be a major issue. + +* The server no longer sends notices for errors on connections that are + suddenly dropped during connection setup. If you really want to see + them, we suggest you get a life. :) + +* Removed: unix domain sockets, uping, m4 preprocessor spawning, + dozens of bugs. + +* New stuff: + Added ISUPPORT code to match dalnets. + Added connection progress notices. + Cleaned up operating system checks. + /invite with no arguments lists the channels you're invited to. + Many speedups, ipdiffer, faster strncpy, faster inetntoa. + Passive lag and numerics now displayed by map command. + Server to server tokenization. + Much larger TCP windows/kernel buffers for server connections, + smaller for clients. + Removed BOOT_OPER security hole. + Complete listener port specifications including per port virtual + hosting and hidden listeners. + Default server port for connects (config option). + Speed up some channel ops using new Membership struct. + Hash table performance stats are available now (basic). + Much of the socket code has been rewritten, we now only make one + pass through the local client array. + Added initial support for PROTOCOL command. + Many functions have been made reentrant. + Resolver now uses callbacks for all queries. + Almost every command that is sent to a server uses full P10 numerics + and tokenization, this reduces netburst sizes by at least 10% and + many server to server message sizes by 10-50%. + Major source code reorginization to support engine model. + Parser now uses an indexed table for commands, which elminates + the need to do IsServer IsUser IsOper checks and allows much more + efficient implementation of user/server/oper command handlers. + +* For a much longer winded explanation of all this stuff, see the + ChangeLog in this directory, or the cvs log at the coder-com + web site at http://coder-com.undernet.org/ + + diff --git a/RELEASE.NOTES b/RELEASE.NOTES new file mode 100644 index 0000000..2f0ea56 --- /dev/null +++ b/RELEASE.NOTES @@ -0,0 +1,123 @@ +Release Notes for ircu2.10.10 + +This is a brief description of the changes we have made to the server +since the release of ircu2.10.07. + +This is the first Undernet server that is fully P10, it is no longer +compatible with older P9 only servers. The server has been verified +to be compatible with Undernet server versions 2.10.06 and above. + +Enhancements: +All server to server communications use tokenization and numeric id's, +this reduces the bandwidth requirements approximately 10-20%. + +Much of the network code has been rewritten and many old bugs relating +to the networking core of the server have been fixed. + +The port handling code has been rewritten to allow much better control +over listeners. + +The server supports extended numerics which theoretically would allow +the entire population of the planet to participate on a network without +running out of unique values. + +Added ISUPPORT messages on client connects to allow client coders to +detect network specific enhancements to the client protocol. + +Server aliasing and virtual hosting (port forwarding) are available for +larger DoS attack prone networks. This will be improved in the next +release. + +Status messages are sent to connecting clients so connections don't +seem to hang during client registration. + +The server now uses a bit less memory and cpu under full load, we +estimate around a 10% improvement in resource usage over the previous +version. + +Configuration Changes: +Please read example.conf in the doc directory for detailed information +on various configuration options. +Virtual host IP addresses are now in the password field of the server M:line, +there is no longer a command line option for specifying them. This is the +address the server will bind to for all outgoing server to server connections. +The port field of the server M:line is no longer used and is ignored when +the server reads the configuration file, server ports are now specified +only on P:lines. +The server ignores N:lines, C:lines are used for all connect server +information now. This means that the passwords for both sides of the +connection must match, this change does not degrade server connection +security of the existing protocol. +There are several new configuration options for P:lines (listener ports). + +Compile Time Options: +If you are planning on hosting more than 1000 clients on your server +we recommend that you do not turn on asserts and heap checking or +debug messages. This is known to cause problems. +There are several new compile time options that you will automatically +be prompted for when you configure the server which should be self +explanitory. + +Undocumented Features: +Every Undernet server released has had at least one undocumented +feature ;-) Here are a few of the ones available in ircu2.10.10. +I'm sure there are a few more we are unaware of, these are the ones +we know about. +To enable these you need to add them to the extra CFLAGS when you +run make config. +-DEXTENDED_NUMERICS This option configures the server to send +extended numerics as well as parse them. This option should only +be used on networks that run ircu2.10.07 and above only. +-DFERGUSON_FLUSHER If you have a server with a lot of resources +available this option will cause the server to attempt to flush +it's internal buffers before dropping clients during a netbreak. +Don't define this if you don't know, if you're not careful this +can end up rebooting FreeBSD boxes. +-DWALLOPS_OPER_ONLY Setting this option removes the ability for +clients that are not opered to see wallops messages. + +Operating System and Kernel Requirements: +If you plan allowing more than 1000 clients on your server, you +may need to adjust your kernel resource limits for networking +and I/O. There are two things you will need to pay particular +attention to, the number of file descriptors available and the +number of buffers the kernel has available to read and write +data to the file descriptors. + +To calculate kernel buffer requirements a good place to start +is to multipy the expected number connections expected on the machine +by the amount of data we buffer for each connection. +Doubling the result of the above calculation and dividing it by the +size of the buffers the kernel uses for I/O should give you a starting +place. + +The server uses 2K kernel buffers for clients, and 64K kernel +buffers for servers (actual use may be somewhat higher). + +c_count - number of clients expected +c_q - number of bytes buffered for each client +s_count - number of servers expected +s_q - number of bytes buffered for each server + +buffer count = (2 * (c_count * c_q + s_count * s_q)) / kernel buffer size + +If the client count is 2000 and the server count is 1 (normal leaf) +and your server uses 2K as an I/O buffer size: + +You need (2 * (2000 * 2048 + 1 * 65536)) / 2048 or a minimum +of 4064 buffers available, if the kernel uses 512 byte buffers you +will need a minimum of 16256 kernel buffers. + +These settings may be a bit light for netbreaks under full client load +you will need to experiment a bit to find the right settings for your +server. + +FreeBSD +You may want to increase your kernel resources if you want to put +a lot of clients on your machine here are a few values to start with: +CHILD_MAX=4096 +OPEN_MAX=4096 +FD_SETSIZE=4096 +NMBCLUSTERS=8096 + + diff --git a/TODO b/TODO new file mode 100644 index 0000000..9de3e18 --- /dev/null +++ b/TODO @@ -0,0 +1,40 @@ + +Undernet Server TODO List +This list contains things that still need to be done. + +Remember: +Premature optimisation is the root of all evil - Knuth +Debugging is at least twice as difficult as programming. So if you +write a program that uses all of your ability, you'll never be able +to debug it all. + +High Priority: + +* something is leaking "a meg a minute" with heap debugging on + with 1300+ clients + (No idea) + +Medium Priority: +* why do the allocation counts change the first time you rehash + after a server boot without changing the conf file: + *** Allocations: 416(41848) + *** ircd.conf : Rehashing + *** Allocations: 424(42006) + *** ircd.conf : Rehashing + *** Allocations: 424(42006) + +* Use numeric nicks for numeric replies to remote clients +* Finish message handlers. +* Clean up ircd.conf processing, lots of sub issues. +* Implement PROTOCOL handshaking + http://www.xs4all.nl/~carlo17/irc/prot.html +* Prepare network code to handle even more connections: + http://www.kegel.com/c10k.html +* Implement zlib compression for server links. +* Cleanups, lots of them. +* Document undernet protocol as it is used in + doc/rfc1459.unet +* Finish tokenization. +* Allow for /WHO by IP address. (for finding who's port scanning you + for example). Suggested by Nuke + diff --git a/config/Configure.in b/config/Configure.in index 3217707..ff9df95 100644 --- a/config/Configure.in +++ b/config/Configure.in @@ -477,6 +477,11 @@ echo "#" >> $CONFIG echo "/*" > $CONFIG_H echo " * Automatically generated C config: don't edit" >> $CONFIG_H echo " */" >> $CONFIG_H +echo "#ifndef INCLUDED_config_h" >> $CONFIG_H +echo "#define INCLUDED_config_h" >> $CONFIG_H +echo "#ifndef INCLUDED_setup_h" >> $CONFIG_H +echo "#include \"setup.h\"">> $CONFIG_H +echo "#endif" >> $CONFIG_H echo "#define AUTOCONF_INCLUDED" >> $CONFIG_H CONFIG_IN=./config-sh @@ -510,6 +515,8 @@ fi . $CONFIG_IN +echo "#endif /* INCLUDED_config_h */" >> $CONFIG_H + mv $CONFIG_H config.h $RM -f .config.old if [ -f .config ]; then diff --git a/config/config-sh.in b/config/config-sh.in index b2033a6..9d27eb6 100644 --- a/config/config-sh.in +++ b/config/config-sh.in @@ -57,6 +57,21 @@ mainmenu_option next_comment fi endmenu +mainmenu_option next_comment +comment 'Debugging (do not define this on production servers)' + bool 'Do you want to enable debugging output' DEBUGMODE + bool 'Do you want to enable asserts and memory allocation checking' CONFIG_NDEBUG + EXTRA_CPPFLAGS="" + if [ "$CONFIG_NDEBUG" = "n" ]; then + if [ -z "$EXTRA_CPPFLAGS" ]; then + EXTRA_CPPFLAGS="-DNDEBUG" + else + EXTRA_CPPFLAGS="-DNDEBUG $EXTRA_CPPFLAGS" + fi + fi + bool 'Are you testing on a host without DNS' NODNS +endmenu + mainmenu_option next_comment comment 'Compile stuff' if [ "$prefix" = "NONE" ]; then @@ -111,7 +126,6 @@ comment 'Compile stuff' if [ "$IRCDLIBS" = "none" ]; then IRCDLIBS="" fi - EXTRA_CPPFLAGS="" if [ -n "$EXTRA_INCLUDEDIRS" ]; then for i in $EXTRA_INCLUDEDIRS; do if [ -z "$EXTRA_CPPFLAGS" ]; then @@ -122,9 +136,9 @@ comment 'Compile stuff' done fi if [ -z "$EXTRA_CPPFLAGS" ]; then - CPPFLAGS=-I../include + CPPFLAGS="-I../include -I../config" else - CPPFLAGS="-I../include $EXTRA_CPPFLAGS" + CPPFLAGS="-I../include -I../config $EXTRA_CPPFLAGS" fi echo "EXTRA_CPPFLAGS=\"$EXTRA_CPPFLAGS\"" >>$CONFIG echo "CPPFLAGS=\"$CPPFLAGS\"" >>$CONFIG @@ -170,7 +184,6 @@ comment 'General defines' echo " SECURITY: Then don't install the daemon SUID or SGID !" fi fi - bool 'Set up a Unix domain socket to connect clients/servers' UNIXPORT bool 'Do you need virtual hosting' VIRTUAL_HOST PREV_HUB=$HUB bool 'Will you connect to more then one server at a time' HUB @@ -179,36 +192,12 @@ comment 'General defines' fi endmenu -mainmenu_option next_comment -comment 'Debugging (do not define this on production servers)' - bool 'Do you want to enable debugging output' DEBUGMODE - bool 'Do you want memory- allocation and/or leak checking' DEBUGMALLOC - if [ "$DEBUGMALLOC" = "y" ]; then - bool 'Do you want to have boundary checking' MEMMAGICNUMS - bool 'Do you want memory leak testing (stats M)' MEMLEAKSTATS y - if [ "$MEMLEAKSTATS" = "y" ]; then - if [ "$MEMMAGICNUMS" = "y" ]; then - echo "You will have extra info on allocated sizes too (MEMSIZESTATS)" - define_bool MEMSIZESTATS $MEMSIZESTATS - else - bool 'Do you want extra info on allocated sizes' MEMSIZESTATS y - fi - bool 'Do you want support for a time interval with /stats M' MEMTIMESTATS y - fi - else - define_bool MEMMAGICNUMS $MEMMAGICNUMS - define_bool MEMLEAKSTATS $MEMLEAKSTATS - define_bool MEMSIZESTATS $MEMSIZESTATS - define_bool MEMTIMESTATS $MEMTIMESTATS - fi - bool 'Are you testing on a host without DNS' NODNS -endmenu mainmenu_option next_comment comment 'Paths and files' eval DPATH_DEFAULT="${prefix}/lib/ircd" string 'Directory where all ircd stuff resides' DPATH $DPATH_DEFAULT - define_string SPATH "$BINDIR/ircd" + define_string SPATH "$BINDIR/$SYMLINK" echo "The following filenames are either full paths or files within DPATH" string 'Server configuration file' CPATH 'ircd.conf' string 'Server MOTD file' MPATH 'ircd.motd' @@ -228,7 +217,8 @@ comment 'Logging (filenames are either full paths or files within DPATH)' string ' Give the path and(or) filename of this log file' WPATH 'whox.log' fi - comment 'Bad Channel G-Lines allow operators to add channel masks to a list which prohibits local clients from being able joining channels which match the mask. Remote BadChan Glines allow Uworld to add or remove channels from the servers internal list of badchans' +comment 'Bad Channel G-Lines allow operators to add channel masks to a list which prohibits local clients from being able joining channels which match the mask. Remote BadChan Glines allow Uworld to add or remove channels from the servers internal list of badchans' + BADCHAN=y bool 'Do you want to enable Bad Channel G-lines' BADCHAN y if [ "$BADCHAN" = "y" ]; then echo " " @@ -294,7 +284,6 @@ endmenu mainmenu_option next_comment comment 'Configuration' - bool 'Use crypted passwords for N: lines' CRYPT_LINK_PASSWORD y bool 'Use crypted passwords for operators' CRYPT_OPER_PASSWORD y DUMMY=`echo "$BUFFERPOOL" | sed -e 's/[0-9]//g'` if [ "$DUMMY" != "" ]; then @@ -307,7 +296,7 @@ comment 'Configuration' fi int 'Max receive queue for clients (bytes)' CLIENT_FLOOD 1024 int 'Maximum number of network connections (23 - (FD_SETSIZE-4))' MAXCONNECTIONS 252 - int 'Default client listen port' PORTNUM 6667 + int 'Default port for connections to other servers' SERVER_PORT 4400 int 'Nickname history length' NICKNAMEHISTORYLENGTH 800 bool 'Allow Opers to see (dis)connects of local clients' ALLOW_SNO_CONNEXIT if [ "$ALLOW_SNO_CONNEXIT" = "y" ]; then @@ -323,6 +312,7 @@ comment 'Configuration' fi bool 'Do you want support for the old I:*:ONE:*:: construct (read help text!)' USEONE n bool 'Send a short message instead of the MOTD to connecting clients' NODEFAULTMOTD y + bool 'Kill connecting clients when forward and reverse DNS mismatch' KILL_IPMISMATCH n endmenu mainmenu_option next_comment @@ -350,6 +340,7 @@ comment 'Oper commands' bool 'Allow local/global opers to set modes on local channels' OPER_MODE_LCHAN y bool 'Allow local/global opers to walk through local channels modes' OPER_WALK_THROUGH_LMODES n bool 'Prevent local/global opers from being kicked or deoped on local channels' NO_OPER_DEOP_LCHAN n + endmenu mainmenu_option next_comment @@ -369,11 +360,6 @@ endmenu mainmenu_option next_comment comment 'Mandatory defines (you should leave these untouched)' int 'Max auto connects per class (1!)' MAXIMUM_LINKS 1 - echo '* Never define this on a production server:' - bool 'Enable message logging' MSGLOG_ENABLED - if [ "$MSGLOG_ENABLED" = "y" ]; then - int 'Message log size' MSGLOG_SIZE 128 - fi if [ "$OPER_KILL" = "y" ]; then bool 'Only allow KILLs of local clients' LOCAL_KILL_ONLY else diff --git a/config/configure b/config/configure index 62f9400..94fe6ff 100644 --- a/config/configure +++ b/config/configure @@ -769,185 +769,11 @@ else fi -echo $ac_n "checking how to run the C preprocessor""... $ac_c" 1>&6 -echo "configure:774: checking how to run the C preprocessor" >&5 -# On Suns, sometimes $CPP names a directory. -if test -n "$CPP" && test -d "$CPP"; then - CPP= -fi -if test -z "$CPP"; then -if eval "test \"`echo '$''{'ac_cv_prog_CPP'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 -else - # This must be in double quotes, not single quotes, because CPP may get - # substituted into the Makefile and "${CC-cc}" will confuse make. - CPP="${CC-cc} -E" - # On the NeXT, cc -E runs the code through the compiler's parser, - # not just through cpp. - cat > conftest.$ac_ext < -Syntax Error -EOF -ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" -{ (eval echo configure:795: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } -ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` -if test -z "$ac_err"; then - : -else - echo "$ac_err" >&5 - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 - rm -rf conftest* - CPP="${CC-cc} -E -traditional-cpp" - cat > conftest.$ac_ext < -Syntax Error -EOF -ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" -{ (eval echo configure:812: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } -ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` -if test -z "$ac_err"; then - : -else - echo "$ac_err" >&5 - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 - rm -rf conftest* - CPP="${CC-cc} -nologo -E" - cat > conftest.$ac_ext < -Syntax Error -EOF -ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" -{ (eval echo configure:829: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } -ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` -if test -z "$ac_err"; then - : -else - echo "$ac_err" >&5 - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 - rm -rf conftest* - CPP=/lib/cpp -fi -rm -f conftest* -fi -rm -f conftest* -fi -rm -f conftest* - ac_cv_prog_CPP="$CPP" -fi - CPP="$ac_cv_prog_CPP" -else - ac_cv_prog_CPP="$CPP" -fi -echo "$ac_t""$CPP" 1>&6 - -echo $ac_n "checking for AIX""... $ac_c" 1>&6 -echo "configure:854: checking for AIX" >&5 -cat > conftest.$ac_ext <&5 | - egrep "yes" >/dev/null 2>&1; then - rm -rf conftest* - echo "$ac_t""yes" 1>&6; cat >> confdefs.h <<\EOF -#define _ALL_SOURCE 1 -EOF - -else - rm -rf conftest* - echo "$ac_t""no" 1>&6 -fi -rm -f conftest* - - -echo $ac_n "checking for POSIXized ISC""... $ac_c" 1>&6 -echo "configure:878: checking for POSIXized ISC" >&5 -if test -d /etc/conf/kconfig.d && - grep _POSIX_VERSION /usr/include/sys/unistd.h >/dev/null 2>&1 -then - echo "$ac_t""yes" 1>&6 - ISC=yes # If later tests want to check for ISC. - cat >> confdefs.h <<\EOF -#define _POSIX_SOURCE 1 -EOF - - if test "$GCC" = yes; then - CC="$CC -posix" - else - CC="$CC -Xp" - fi -else - echo "$ac_t""no" 1>&6 - ISC= -fi - -ac_safe=`echo "minix/config.h" | sed 'y%./+-%__p_%'` -echo $ac_n "checking for minix/config.h""... $ac_c" 1>&6 -echo "configure:900: checking for minix/config.h" >&5 -if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 -else - cat > conftest.$ac_ext < -EOF -ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" -{ (eval echo configure:910: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } -ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` -if test -z "$ac_err"; then - rm -rf conftest* - eval "ac_cv_header_$ac_safe=yes" -else - echo "$ac_err" >&5 - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 - rm -rf conftest* - eval "ac_cv_header_$ac_safe=no" -fi -rm -f conftest* -fi -if eval "test \"`echo '$ac_cv_header_'$ac_safe`\" = yes"; then - echo "$ac_t""yes" 1>&6 - MINIX=yes -else - echo "$ac_t""no" 1>&6 -MINIX= -fi - -if test "$MINIX" = yes; then - cat >> confdefs.h <<\EOF -#define _POSIX_SOURCE 1 -EOF - - cat >> confdefs.h <<\EOF -#define _POSIX_1_SOURCE 2 -EOF - - cat >> confdefs.h <<\EOF -#define _MINIX 1 -EOF - -fi - echo $ac_n "checking for ${CC-cc} option to accept ANSI C""... $ac_c" 1>&6 -echo "configure:951: checking for ${CC-cc} option to accept ANSI C" >&5 +echo "configure:777: checking for ${CC-cc} option to accept ANSI C" >&5 if eval "test \"`echo '$''{'am_cv_prog_cc_stdc'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -963,7 +789,7 @@ for ac_arg in "" -qlanglvl=ansi -std1 "-Aa -D_HPUX_SOURCE" "-Xc -D__EXTENSIONS__ do CC="$ac_save_CC $ac_arg" cat > conftest.$ac_ext < #include @@ -1000,7 +826,7 @@ return f (e, argv, 0) != argv[0] || f (e, argv, 1) != argv[1]; ; return 0; } EOF -if { (eval echo configure:1004: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:830: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* am_cv_prog_cc_stdc="$ac_arg"; break else @@ -1031,7 +857,7 @@ if test "$CFLAGS" != "" ; then fi echo $ac_n "checking for crypt in -lc""... $ac_c" 1>&6 -echo "configure:1035: checking for crypt in -lc" >&5 +echo "configure:861: checking for crypt in -lc" >&5 ac_lib_var=`echo c'_'crypt | sed 'y%./+-%__p_%'` if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 @@ -1039,7 +865,7 @@ else ac_save_LIBS="$LIBS" LIBS="-lc $LIBS" cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then +if { (eval echo configure:880: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_lib_$ac_lib_var=yes" else @@ -1069,7 +895,7 @@ if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then else echo "$ac_t""no" 1>&6 echo $ac_n "checking for crypt in -ldescrypt""... $ac_c" 1>&6 -echo "configure:1073: checking for crypt in -ldescrypt" >&5 +echo "configure:899: checking for crypt in -ldescrypt" >&5 ac_lib_var=`echo descrypt'_'crypt | sed 'y%./+-%__p_%'` if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 @@ -1077,7 +903,7 @@ else ac_save_LIBS="$LIBS" LIBS="-ldescrypt $LIBS" cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then +if { (eval echo configure:918: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_lib_$ac_lib_var=yes" else @@ -1107,7 +933,7 @@ if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then else echo "$ac_t""no" 1>&6 echo $ac_n "checking for crypt in -lcrypt""... $ac_c" 1>&6 -echo "configure:1111: checking for crypt in -lcrypt" >&5 +echo "configure:937: checking for crypt in -lcrypt" >&5 ac_lib_var=`echo crypt'_'crypt | sed 'y%./+-%__p_%'` if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 @@ -1115,7 +941,7 @@ else ac_save_LIBS="$LIBS" LIBS="-lcrypt $LIBS" cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then +if { (eval echo configure:956: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_lib_$ac_lib_var=yes" else @@ -1158,7 +984,7 @@ fi fi echo $ac_n "checking for gethostbyname in -lc""... $ac_c" 1>&6 -echo "configure:1162: checking for gethostbyname in -lc" >&5 +echo "configure:988: checking for gethostbyname in -lc" >&5 ac_lib_var=`echo c'_'gethostbyname | sed 'y%./+-%__p_%'` if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 @@ -1166,7 +992,7 @@ else ac_save_LIBS="$LIBS" LIBS="-lc $LIBS" cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then +if { (eval echo configure:1007: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_lib_$ac_lib_var=yes" else @@ -1196,7 +1022,7 @@ if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then else echo "$ac_t""no" 1>&6 echo $ac_n "checking for gethostbyaddr in -lnsl""... $ac_c" 1>&6 -echo "configure:1200: checking for gethostbyaddr in -lnsl" >&5 +echo "configure:1026: checking for gethostbyaddr in -lnsl" >&5 ac_lib_var=`echo nsl'_'gethostbyaddr | sed 'y%./+-%__p_%'` if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 @@ -1204,7 +1030,7 @@ else ac_save_LIBS="$LIBS" LIBS="-lnsl $LIBS" cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then +if { (eval echo configure:1045: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_lib_$ac_lib_var=yes" else @@ -1238,7 +1064,7 @@ fi fi echo $ac_n "checking for socket in -lc""... $ac_c" 1>&6 -echo "configure:1242: checking for socket in -lc" >&5 +echo "configure:1068: checking for socket in -lc" >&5 ac_lib_var=`echo c'_'socket | sed 'y%./+-%__p_%'` if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 @@ -1246,7 +1072,7 @@ else ac_save_LIBS="$LIBS" LIBS="-lc $LIBS" cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then +if { (eval echo configure:1087: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_lib_$ac_lib_var=yes" else @@ -1276,7 +1102,7 @@ if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes"; then else echo "$ac_t""no" 1>&6 echo $ac_n "checking for socket in -lsocket""... $ac_c" 1>&6 -echo "configure:1280: checking for socket in -lsocket" >&5 +echo "configure:1106: checking for socket in -lsocket" >&5 ac_lib_var=`echo socket'_'socket | sed 'y%./+-%__p_%'` if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 @@ -1284,7 +1110,7 @@ else ac_save_LIBS="$LIBS" LIBS="-lsocket $LIBS" cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then +if { (eval echo configure:1125: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_lib_$ac_lib_var=yes" else @@ -1318,12 +1144,12 @@ fi fi echo $ac_n "checking for res_mkquery in -lresolv""... $ac_c" 1>&6 -echo "configure:1322: checking for res_mkquery in -lresolv" >&5 +echo "configure:1148: checking for res_mkquery in -lresolv" >&5 if eval "test \"`echo '$''{'unet_cv_lib_resolv'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then +if { (eval echo configure:1170: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* unet_cv_lib_resolv=no else @@ -1350,14 +1176,14 @@ else OLD_LIBS="$LIBS" LIBS="$LIBS -lresolv" cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then +if { (eval echo configure:1187: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* unet_cv_lib_resolv=yes else @@ -1381,13 +1207,93 @@ EOF LIBS="$LIBS -lresolv" fi +echo $ac_n "checking how to run the C preprocessor""... $ac_c" 1>&6 +echo "configure:1212: checking how to run the C preprocessor" >&5 +# On Suns, sometimes $CPP names a directory. +if test -n "$CPP" && test -d "$CPP"; then + CPP= +fi +if test -z "$CPP"; then +if eval "test \"`echo '$''{'ac_cv_prog_CPP'+set}'`\" = set"; then + echo $ac_n "(cached) $ac_c" 1>&6 +else + # This must be in double quotes, not single quotes, because CPP may get + # substituted into the Makefile and "${CC-cc}" will confuse make. + CPP="${CC-cc} -E" + # On the NeXT, cc -E runs the code through the compiler's parser, + # not just through cpp. + cat > conftest.$ac_ext < +Syntax Error +EOF +ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" +{ (eval echo configure:1233: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } +ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` +if test -z "$ac_err"; then + : +else + echo "$ac_err" >&5 + echo "configure: failed program was:" >&5 + cat conftest.$ac_ext >&5 + rm -rf conftest* + CPP="${CC-cc} -E -traditional-cpp" + cat > conftest.$ac_ext < +Syntax Error +EOF +ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" +{ (eval echo configure:1250: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } +ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` +if test -z "$ac_err"; then + : +else + echo "$ac_err" >&5 + echo "configure: failed program was:" >&5 + cat conftest.$ac_ext >&5 + rm -rf conftest* + CPP="${CC-cc} -nologo -E" + cat > conftest.$ac_ext < +Syntax Error +EOF +ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" +{ (eval echo configure:1267: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } +ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` +if test -z "$ac_err"; then + : +else + echo "$ac_err" >&5 + echo "configure: failed program was:" >&5 + cat conftest.$ac_ext >&5 + rm -rf conftest* + CPP=/lib/cpp +fi +rm -f conftest* +fi +rm -f conftest* +fi +rm -f conftest* + ac_cv_prog_CPP="$CPP" +fi + CPP="$ac_cv_prog_CPP" +else + ac_cv_prog_CPP="$CPP" +fi +echo "$ac_t""$CPP" 1>&6 + echo $ac_n "checking for ANSI C header files""... $ac_c" 1>&6 -echo "configure:1386: checking for ANSI C header files" >&5 +echo "configure:1292: checking for ANSI C header files" >&5 if eval "test \"`echo '$''{'ac_cv_header_stdc'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #include @@ -1395,7 +1301,7 @@ else #include EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" -{ (eval echo configure:1399: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } +{ (eval echo configure:1305: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* @@ -1412,7 +1318,7 @@ rm -f conftest* if test $ac_cv_header_stdc = yes; then # SunOS 4.x string.h does not declare mem*, contrary to ANSI. cat > conftest.$ac_ext < EOF @@ -1430,7 +1336,7 @@ fi if test $ac_cv_header_stdc = yes; then # ISC 2.0.2 stdlib.h does not declare free, contrary to ANSI. cat > conftest.$ac_ext < EOF @@ -1451,7 +1357,7 @@ if test "$cross_compiling" = yes; then : else cat > conftest.$ac_ext < #define ISLOWER(c) ('a' <= (c) && (c) <= 'z') @@ -1462,7 +1368,7 @@ if (XOR (islower (i), ISLOWER (i)) || toupper (i) != TOUPPER (i)) exit(2); exit (0); } EOF -if { (eval echo configure:1466: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null +if { (eval echo configure:1372: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then : else @@ -1485,219 +1391,62 @@ EOF fi -echo $ac_n "checking for sys/wait.h that is POSIX.1 compatible""... $ac_c" 1>&6 -echo "configure:1490: checking for sys/wait.h that is POSIX.1 compatible" >&5 -if eval "test \"`echo '$''{'ac_cv_header_sys_wait_h'+set}'`\" = set"; then + +echo $ac_n "checking whether byte ordering is bigendian""... $ac_c" 1>&6 +echo "configure:1397: checking whether byte ordering is bigendian" >&5 +if eval "test \"`echo '$''{'ac_cv_c_bigendian'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else - cat > conftest.$ac_ext < conftest.$ac_ext < -#include -#ifndef WEXITSTATUS -#define WEXITSTATUS(stat_val) ((unsigned)(stat_val) >> 8) -#endif -#ifndef WIFEXITED -#define WIFEXITED(stat_val) (((stat_val) & 255) == 0) +#include +int main() { + +#if !BYTE_ORDER || !BIG_ENDIAN || !LITTLE_ENDIAN + bogus endian macros #endif +; return 0; } +EOF +if { (eval echo configure:1415: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then + rm -rf conftest* + # It does; now see whether it defined to BIG_ENDIAN or not. +cat > conftest.$ac_ext < +#include int main() { -int s; -wait (&s); -s = WIFEXITED (s) ? WEXITSTATUS (s) : 1; + +#if BYTE_ORDER != BIG_ENDIAN + not big endian +#endif ; return 0; } EOF -if { (eval echo configure:1511: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:1430: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* - ac_cv_header_sys_wait_h=yes + ac_cv_c_bigendian=yes else echo "configure: failed program was:" >&5 cat conftest.$ac_ext >&5 rm -rf conftest* - ac_cv_header_sys_wait_h=no + ac_cv_c_bigendian=no fi rm -f conftest* +else + echo "configure: failed program was:" >&5 + cat conftest.$ac_ext >&5 fi - -echo "$ac_t""$ac_cv_header_sys_wait_h" 1>&6 -if test $ac_cv_header_sys_wait_h = yes; then - cat >> confdefs.h <<\EOF -#define HAVE_SYS_WAIT_H 1 -EOF - -fi - -for ac_hdr in malloc.h sys/malloc.h fcntl.h string.h strings.h sys/file.h sys/ioctl.h sys/time.h syslog.h unistd.h memory.h errno.h net/errno.h sys/cdefs.h -do -ac_safe=`echo "$ac_hdr" | sed 'y%./+-%__p_%'` -echo $ac_n "checking for $ac_hdr""... $ac_c" 1>&6 -echo "configure:1535: checking for $ac_hdr" >&5 -if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 +rm -f conftest* +if test $ac_cv_c_bigendian = unknown; then +if test "$cross_compiling" = yes; then + { echo "configure: error: can not run test program while cross compiling" 1>&2; exit 1; } else cat > conftest.$ac_ext < -EOF -ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" -{ (eval echo configure:1545: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } -ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` -if test -z "$ac_err"; then - rm -rf conftest* - eval "ac_cv_header_$ac_safe=yes" -else - echo "$ac_err" >&5 - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 - rm -rf conftest* - eval "ac_cv_header_$ac_safe=no" -fi -rm -f conftest* -fi -if eval "test \"`echo '$ac_cv_header_'$ac_safe`\" = yes"; then - echo "$ac_t""yes" 1>&6 - ac_tr_hdr=HAVE_`echo $ac_hdr | sed 'y%abcdefghijklmnopqrstuvwxyz./-%ABCDEFGHIJKLMNOPQRSTUVWXYZ___%'` - cat >> confdefs.h <&6 -fi -done - - -echo $ac_n "checking for working const""... $ac_c" 1>&6 -echo "configure:1573: checking for working const" >&5 -if eval "test \"`echo '$''{'ac_cv_c_const'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 -else - cat > conftest.$ac_ext <j = 5; -} -{ /* ULTRIX-32 V3.1 (Rev 9) vcc rejects this */ - const int foo = 10; -} - -; return 0; } -EOF -if { (eval echo configure:1627: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then - rm -rf conftest* - ac_cv_c_const=yes -else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 - rm -rf conftest* - ac_cv_c_const=no -fi -rm -f conftest* -fi - -echo "$ac_t""$ac_cv_c_const" 1>&6 -if test $ac_cv_c_const = no; then - cat >> confdefs.h <<\EOF -#define const -EOF - -fi - -echo $ac_n "checking whether byte ordering is bigendian""... $ac_c" 1>&6 -echo "configure:1648: checking whether byte ordering is bigendian" >&5 -if eval "test \"`echo '$''{'ac_cv_c_bigendian'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 -else - ac_cv_c_bigendian=unknown -# See if sys/param.h defines the BYTE_ORDER macro. -cat > conftest.$ac_ext < -#include -int main() { - -#if !BYTE_ORDER || !BIG_ENDIAN || !LITTLE_ENDIAN - bogus endian macros -#endif -; return 0; } -EOF -if { (eval echo configure:1666: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then - rm -rf conftest* - # It does; now see whether it defined to BIG_ENDIAN or not. -cat > conftest.$ac_ext < -#include -int main() { - -#if BYTE_ORDER != BIG_ENDIAN - not big endian -#endif -; return 0; } -EOF -if { (eval echo configure:1681: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then - rm -rf conftest* - ac_cv_c_bigendian=yes -else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 - rm -rf conftest* - ac_cv_c_bigendian=no -fi -rm -f conftest* -else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 -fi -rm -f conftest* -if test $ac_cv_c_bigendian = unknown; then -if test "$cross_compiling" = yes; then - { echo "configure: error: can not run test program while cross compiling" 1>&2; exit 1; } -else - cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null +if { (eval echo configure:1463: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_c_bigendian=no else @@ -1734,12 +1483,12 @@ EOF fi echo $ac_n "checking for size_t""... $ac_c" 1>&6 -echo "configure:1738: checking for size_t" >&5 +echo "configure:1487: checking for size_t" >&5 if eval "test \"`echo '$''{'ac_cv_type_size_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #if STDC_HEADERS @@ -1767,12 +1516,12 @@ EOF fi echo $ac_n "checking whether time.h and sys/time.h may both be included""... $ac_c" 1>&6 -echo "configure:1771: checking whether time.h and sys/time.h may both be included" >&5 +echo "configure:1520: checking whether time.h and sys/time.h may both be included" >&5 if eval "test \"`echo '$''{'ac_cv_header_time'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #include @@ -1781,7 +1530,7 @@ int main() { struct tm *tp; ; return 0; } EOF -if { (eval echo configure:1785: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:1534: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* ac_cv_header_time=yes else @@ -1802,12 +1551,12 @@ EOF fi echo $ac_n "checking whether struct tm is in sys/time.h or time.h""... $ac_c" 1>&6 -echo "configure:1806: checking whether struct tm is in sys/time.h or time.h" >&5 +echo "configure:1555: checking whether struct tm is in sys/time.h or time.h" >&5 if eval "test \"`echo '$''{'ac_cv_struct_tm'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #include @@ -1815,7 +1564,7 @@ int main() { struct tm *tp; tp->tm_sec; ; return 0; } EOF -if { (eval echo configure:1819: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:1568: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* ac_cv_struct_tm=time.h else @@ -1836,12 +1585,12 @@ EOF fi echo $ac_n "checking for uid_t in sys/types.h""... $ac_c" 1>&6 -echo "configure:1840: checking for uid_t in sys/types.h" >&5 +echo "configure:1589: checking for uid_t in sys/types.h" >&5 if eval "test \"`echo '$''{'ac_cv_type_uid_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < EOF @@ -1870,7 +1619,7 @@ EOF fi echo $ac_n "checking size of short""... $ac_c" 1>&6 -echo "configure:1874: checking size of short" >&5 +echo "configure:1623: checking size of short" >&5 if eval "test \"`echo '$''{'ac_cv_sizeof_short'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1878,7 +1627,7 @@ else { echo "configure: error: can not run test program while cross compiling" 1>&2; exit 1; } else cat > conftest.$ac_ext < main() @@ -1889,7 +1638,7 @@ main() exit(0); } EOF -if { (eval echo configure:1893: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null +if { (eval echo configure:1642: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_sizeof_short=`cat conftestval` else @@ -1909,7 +1658,7 @@ EOF echo $ac_n "checking size of int""... $ac_c" 1>&6 -echo "configure:1913: checking size of int" >&5 +echo "configure:1662: checking size of int" >&5 if eval "test \"`echo '$''{'ac_cv_sizeof_int'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1917,7 +1666,7 @@ else { echo "configure: error: can not run test program while cross compiling" 1>&2; exit 1; } else cat > conftest.$ac_ext < main() @@ -1928,7 +1677,7 @@ main() exit(0); } EOF -if { (eval echo configure:1932: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null +if { (eval echo configure:1681: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_sizeof_int=`cat conftestval` else @@ -1948,7 +1697,7 @@ EOF echo $ac_n "checking size of long""... $ac_c" 1>&6 -echo "configure:1952: checking size of long" >&5 +echo "configure:1701: checking size of long" >&5 if eval "test \"`echo '$''{'ac_cv_sizeof_long'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -1956,7 +1705,7 @@ else { echo "configure: error: can not run test program while cross compiling" 1>&2; exit 1; } else cat > conftest.$ac_ext < main() @@ -1967,7 +1716,7 @@ main() exit(0); } EOF -if { (eval echo configure:1971: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null +if { (eval echo configure:1720: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_sizeof_long=`cat conftestval` else @@ -1988,12 +1737,12 @@ EOF if test "$ac_cv_sizeof_int" = 2 ; then echo $ac_n "checking for int16_t""... $ac_c" 1>&6 -echo "configure:1992: checking for int16_t" >&5 +echo "configure:1741: checking for int16_t" >&5 if eval "test \"`echo '$''{'ac_cv_type_int16_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #if STDC_HEADERS @@ -2021,12 +1770,12 @@ EOF fi echo $ac_n "checking for u_int16_t""... $ac_c" 1>&6 -echo "configure:2025: checking for u_int16_t" >&5 +echo "configure:1774: checking for u_int16_t" >&5 if eval "test \"`echo '$''{'ac_cv_type_u_int16_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #if STDC_HEADERS @@ -2055,12 +1804,12 @@ fi elif test "$ac_cv_sizeof_short" = 2 ; then echo $ac_n "checking for int16_t""... $ac_c" 1>&6 -echo "configure:2059: checking for int16_t" >&5 +echo "configure:1808: checking for int16_t" >&5 if eval "test \"`echo '$''{'ac_cv_type_int16_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #if STDC_HEADERS @@ -2088,12 +1837,12 @@ EOF fi echo $ac_n "checking for u_int16_t""... $ac_c" 1>&6 -echo "configure:2092: checking for u_int16_t" >&5 +echo "configure:1841: checking for u_int16_t" >&5 if eval "test \"`echo '$''{'ac_cv_type_u_int16_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #if STDC_HEADERS @@ -2125,12 +1874,12 @@ else fi if test "$ac_cv_sizeof_int" = 4 ; then echo $ac_n "checking for int32_t""... $ac_c" 1>&6 -echo "configure:2129: checking for int32_t" >&5 +echo "configure:1878: checking for int32_t" >&5 if eval "test \"`echo '$''{'ac_cv_type_int32_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #if STDC_HEADERS @@ -2158,12 +1907,12 @@ EOF fi echo $ac_n "checking for u_int32_t""... $ac_c" 1>&6 -echo "configure:2162: checking for u_int32_t" >&5 +echo "configure:1911: checking for u_int32_t" >&5 if eval "test \"`echo '$''{'ac_cv_type_u_int32_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #if STDC_HEADERS @@ -2192,79 +1941,12 @@ fi elif test "$ac_cv_sizeof_short" = 4 ; then echo $ac_n "checking for int32_t""... $ac_c" 1>&6 -echo "configure:2196: checking for int32_t" >&5 -if eval "test \"`echo '$''{'ac_cv_type_int32_t'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 -else - cat > conftest.$ac_ext < -#if STDC_HEADERS -#include -#include -#endif -EOF -if (eval "$ac_cpp conftest.$ac_ext") 2>&5 | - egrep "(^|[^a-zA-Z_0-9])int32_t[^a-zA-Z_0-9]" >/dev/null 2>&1; then - rm -rf conftest* - ac_cv_type_int32_t=yes -else - rm -rf conftest* - ac_cv_type_int32_t=no -fi -rm -f conftest* - -fi -echo "$ac_t""$ac_cv_type_int32_t" 1>&6 -if test $ac_cv_type_int32_t = no; then - cat >> confdefs.h <<\EOF -#define int32_t short -EOF - -fi - - echo $ac_n "checking for u_int32_t""... $ac_c" 1>&6 -echo "configure:2229: checking for u_int32_t" >&5 -if eval "test \"`echo '$''{'ac_cv_type_u_int32_t'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 -else - cat > conftest.$ac_ext < -#if STDC_HEADERS -#include -#include -#endif -EOF -if (eval "$ac_cpp conftest.$ac_ext") 2>&5 | - egrep "(^|[^a-zA-Z_0-9])u_int32_t[^a-zA-Z_0-9]" >/dev/null 2>&1; then - rm -rf conftest* - ac_cv_type_u_int32_t=yes -else - rm -rf conftest* - ac_cv_type_u_int32_t=no -fi -rm -f conftest* - -fi -echo "$ac_t""$ac_cv_type_u_int32_t" 1>&6 -if test $ac_cv_type_u_int32_t = no; then - cat >> confdefs.h <<\EOF -#define u_int32_t unsigned short -EOF - -fi - -elif test "$ac_cv_sizeof_long" = 4 ; then - echo $ac_n "checking for int32_t""... $ac_c" 1>&6 -echo "configure:2263: checking for int32_t" >&5 +echo "configure:1945: checking for int32_t" >&5 if eval "test \"`echo '$''{'ac_cv_type_int32_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #if STDC_HEADERS @@ -2272,698 +1954,270 @@ else #include #endif EOF -if (eval "$ac_cpp conftest.$ac_ext") 2>&5 | - egrep "(^|[^a-zA-Z_0-9])int32_t[^a-zA-Z_0-9]" >/dev/null 2>&1; then - rm -rf conftest* - ac_cv_type_int32_t=yes -else - rm -rf conftest* - ac_cv_type_int32_t=no -fi -rm -f conftest* - -fi -echo "$ac_t""$ac_cv_type_int32_t" 1>&6 -if test $ac_cv_type_int32_t = no; then - cat >> confdefs.h <<\EOF -#define int32_t long -EOF - -fi - - echo $ac_n "checking for u_int32_t""... $ac_c" 1>&6 -echo "configure:2296: checking for u_int32_t" >&5 -if eval "test \"`echo '$''{'ac_cv_type_u_int32_t'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 -else - cat > conftest.$ac_ext < -#if STDC_HEADERS -#include -#include -#endif -EOF -if (eval "$ac_cpp conftest.$ac_ext") 2>&5 | - egrep "(^|[^a-zA-Z_0-9])u_int32_t[^a-zA-Z_0-9]" >/dev/null 2>&1; then - rm -rf conftest* - ac_cv_type_u_int32_t=yes -else - rm -rf conftest* - ac_cv_type_u_int32_t=no -fi -rm -f conftest* - -fi -echo "$ac_t""$ac_cv_type_u_int32_t" 1>&6 -if test $ac_cv_type_u_int32_t = no; then - cat >> confdefs.h <<\EOF -#define u_int32_t unsigned long -EOF - -fi - -else - { echo "configure: error: Cannot find a type with size of 32 bits" 1>&2; exit 1; } -fi - -echo $ac_n "checking size of size_t""... $ac_c" 1>&6 -echo "configure:2333: checking size of size_t" >&5 -if eval "test \"`echo '$''{'ac_cv_sizeof_size_t'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 -else - if test "$cross_compiling" = yes; then - { echo "configure: error: can not run test program while cross compiling" 1>&2; exit 1; } -else - cat > conftest.$ac_ext < -main() -{ - FILE *f=fopen("conftestval", "w"); - if (!f) exit(1); - fprintf(f, "%d\n", sizeof(size_t)); - exit(0); -} -EOF -if { (eval echo configure:2352: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null -then - ac_cv_sizeof_size_t=`cat conftestval` -else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 - rm -fr conftest* - ac_cv_sizeof_size_t=0 -fi -rm -fr conftest* -fi - -fi -echo "$ac_t""$ac_cv_sizeof_size_t" 1>&6 -cat >> confdefs.h <&6 -echo "configure:2371: checking printf format of size_t" >&5 -if test "$ac_cv_sizeof_size_t" = 4 ; then - echo "$ac_t"""%u"" 1>&6 - cat >> confdefs.h <<\EOF -#define SIZE_T_FMT "%u" -EOF - -else - echo "$ac_t"""%lu"" 1>&6 - cat >> confdefs.h <<\EOF -#define SIZE_T_FMT "%lu" -EOF - -fi -echo $ac_n "checking size of time_t""... $ac_c" 1>&6 -echo "configure:2386: checking size of time_t" >&5 -if eval "test \"`echo '$''{'unet_cv_sizeof_time_t'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 -else - if test "$cross_compiling" = yes; then - unet_cv_sizeof_time_t=0 -else - cat > conftest.$ac_ext < -#include -main() -{ - FILE *f=fopen("conftestval", "w"); - if (!f) exit(1); - fprintf(f, "%d\n", sizeof(time_t)); - exit(0); -} -EOF -if { (eval echo configure:2406: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null -then - unet_cv_sizeof_time_t=`cat conftestval` -else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 - rm -fr conftest* - unet_cv_sizeof_time_t=0 -fi -rm -fr conftest* -fi - -fi - -if test "$unet_cv_sizeof_time_t" = 0 ; then - echo "$ac_t""unknown" 1>&6 - cat >> confdefs.h <<\EOF -#define TIME_T_FMT "%lu" -EOF - - cat >> confdefs.h <<\EOF -#define STIME_T_FMT "%ld" -EOF - -else - echo "$ac_t""$unet_cv_sizeof_time_t" 1>&6 - echo $ac_n "checking printf format of time_t""... $ac_c" 1>&6 -echo "configure:2433: checking printf format of time_t" >&5 - if test "$unet_cv_sizeof_time_t" = "$ac_cv_sizeof_long" ; then - echo "$ac_t"""%lu"" 1>&6 - cat >> confdefs.h <<\EOF -#define TIME_T_FMT "%lu" -EOF - - cat >> confdefs.h <<\EOF -#define STIME_T_FMT "%ld" -EOF - - else - echo "$ac_t"""%u"" 1>&6 - cat >> confdefs.h <<\EOF -#define TIME_T_FMT "%u" -EOF - - cat >> confdefs.h <<\EOF -#define STIME_T_FMT "%d" -EOF - - fi -fi - -if test $ac_cv_prog_gcc = yes; then - echo $ac_n "checking whether ${CC-cc} needs -traditional""... $ac_c" 1>&6 -echo "configure:2459: checking whether ${CC-cc} needs -traditional" >&5 -if eval "test \"`echo '$''{'ac_cv_prog_gcc_traditional'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 -else - ac_pattern="Autoconf.*'x'" - cat > conftest.$ac_ext < -Autoconf TIOCGETP -EOF -if (eval "$ac_cpp conftest.$ac_ext") 2>&5 | - egrep "$ac_pattern" >/dev/null 2>&1; then - rm -rf conftest* - ac_cv_prog_gcc_traditional=yes -else - rm -rf conftest* - ac_cv_prog_gcc_traditional=no -fi -rm -f conftest* - - - if test $ac_cv_prog_gcc_traditional = no; then - cat > conftest.$ac_ext < -Autoconf TCGETA -EOF -if (eval "$ac_cpp conftest.$ac_ext") 2>&5 | - egrep "$ac_pattern" >/dev/null 2>&1; then - rm -rf conftest* - ac_cv_prog_gcc_traditional=yes -fi -rm -f conftest* - - fi -fi - -echo "$ac_t""$ac_cv_prog_gcc_traditional" 1>&6 - if test $ac_cv_prog_gcc_traditional = yes; then - CC="$CC -traditional" - fi -fi - -echo $ac_n "checking for 8-bit clean memcmp""... $ac_c" 1>&6 -echo "configure:2505: checking for 8-bit clean memcmp" >&5 -if eval "test \"`echo '$''{'ac_cv_func_memcmp_clean'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 -else - if test "$cross_compiling" = yes; then - ac_cv_func_memcmp_clean=no -else - cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null -then - ac_cv_func_memcmp_clean=yes -else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 - rm -fr conftest* - ac_cv_func_memcmp_clean=no -fi -rm -fr conftest* -fi - -fi - -echo "$ac_t""$ac_cv_func_memcmp_clean" 1>&6 -test $ac_cv_func_memcmp_clean = no && LIBOBJS="$LIBOBJS memcmp.${ac_objext}" - -echo $ac_n "checking whether setvbuf arguments are reversed""... $ac_c" 1>&6 -echo "configure:2541: checking whether setvbuf arguments are reversed" >&5 -if eval "test \"`echo '$''{'ac_cv_func_setvbuf_reversed'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 -else - if test "$cross_compiling" = yes; then - { echo "configure: error: can not run test program while cross compiling" 1>&2; exit 1; } -else - cat > conftest.$ac_ext < -/* If setvbuf has the reversed format, exit 0. */ -main () { - /* This call has the arguments reversed. - A reversed system may check and see that the address of main - is not _IOLBF, _IONBF, or _IOFBF, and return nonzero. */ - if (setvbuf(stdout, _IOLBF, (char *) main, BUFSIZ) != 0) - exit(1); - putc('\r', stdout); - exit(0); /* Non-reversed systems segv here. */ -} -EOF -if { (eval echo configure:2563: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null -then - ac_cv_func_setvbuf_reversed=yes -else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 - rm -fr conftest* - ac_cv_func_setvbuf_reversed=no -fi -rm -fr conftest* -fi - -rm -f core core.* *.core -fi - -echo "$ac_t""$ac_cv_func_setvbuf_reversed" 1>&6 -if test $ac_cv_func_setvbuf_reversed = yes; then - cat >> confdefs.h <<\EOF -#define SETVBUF_REVERSED 1 -EOF - -fi - -echo $ac_n "checking return type of signal handlers""... $ac_c" 1>&6 -echo "configure:2587: checking return type of signal handlers" >&5 -if eval "test \"`echo '$''{'ac_cv_type_signal'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 -else - cat > conftest.$ac_ext < -#include -#ifdef signal -#undef signal -#endif -#ifdef __cplusplus -extern "C" void (*signal (int, void (*)(int)))(int); -#else -void (*signal ()) (); -#endif - -int main() { -int i; -; return 0; } -EOF -if { (eval echo configure:2609: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then - rm -rf conftest* - ac_cv_type_signal=void -else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 - rm -rf conftest* - ac_cv_type_signal=int -fi -rm -f conftest* -fi - -echo "$ac_t""$ac_cv_type_signal" 1>&6 -cat >> confdefs.h <&6 -echo "configure:2628: checking for vprintf" >&5 -if eval "test \"`echo '$''{'ac_cv_func_vprintf'+set}'`\" = set"; then - echo $ac_n "(cached) $ac_c" 1>&6 -else - cat > conftest.$ac_ext < -/* Override any gcc2 internal prototype to avoid an error. */ -/* We use char because int might match the return type of a gcc2 - builtin and then its argument prototype would still apply. */ -char vprintf(); - -int main() { - -/* The GNU C library defines this for functions which it implements - to always fail with ENOSYS. Some functions are actually named - something starting with __ and the normal name is an alias. */ -#if defined (__stub_vprintf) || defined (__stub___vprintf) -choke me -#else -vprintf(); -#endif - -; return 0; } -EOF -if { (eval echo configure:2656: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then +if (eval "$ac_cpp conftest.$ac_ext") 2>&5 | + egrep "(^|[^a-zA-Z_0-9])int32_t[^a-zA-Z_0-9]" >/dev/null 2>&1; then rm -rf conftest* - eval "ac_cv_func_vprintf=yes" + ac_cv_type_int32_t=yes else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 rm -rf conftest* - eval "ac_cv_func_vprintf=no" + ac_cv_type_int32_t=no fi rm -f conftest* -fi -if eval "test \"`echo '$ac_cv_func_'vprintf`\" = yes"; then - echo "$ac_t""yes" 1>&6 +fi +echo "$ac_t""$ac_cv_type_int32_t" 1>&6 +if test $ac_cv_type_int32_t = no; then cat >> confdefs.h <<\EOF -#define HAVE_VPRINTF 1 +#define int32_t short EOF -else - echo "$ac_t""no" 1>&6 fi -if test "$ac_cv_func_vprintf" != yes; then -echo $ac_n "checking for _doprnt""... $ac_c" 1>&6 -echo "configure:2680: checking for _doprnt" >&5 -if eval "test \"`echo '$''{'ac_cv_func__doprnt'+set}'`\" = set"; then + echo $ac_n "checking for u_int32_t""... $ac_c" 1>&6 +echo "configure:1978: checking for u_int32_t" >&5 +if eval "test \"`echo '$''{'ac_cv_type_u_int32_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < -/* Override any gcc2 internal prototype to avoid an error. */ -/* We use char because int might match the return type of a gcc2 - builtin and then its argument prototype would still apply. */ -char _doprnt(); - -int main() { - -/* The GNU C library defines this for functions which it implements - to always fail with ENOSYS. Some functions are actually named - something starting with __ and the normal name is an alias. */ -#if defined (__stub__doprnt) || defined (__stub____doprnt) -choke me -#else -_doprnt(); +#include +#if STDC_HEADERS +#include +#include #endif - -; return 0; } EOF -if { (eval echo configure:2708: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then +if (eval "$ac_cpp conftest.$ac_ext") 2>&5 | + egrep "(^|[^a-zA-Z_0-9])u_int32_t[^a-zA-Z_0-9]" >/dev/null 2>&1; then rm -rf conftest* - eval "ac_cv_func__doprnt=yes" + ac_cv_type_u_int32_t=yes else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 rm -rf conftest* - eval "ac_cv_func__doprnt=no" + ac_cv_type_u_int32_t=no fi rm -f conftest* -fi -if eval "test \"`echo '$ac_cv_func_'_doprnt`\" = yes"; then - echo "$ac_t""yes" 1>&6 +fi +echo "$ac_t""$ac_cv_type_u_int32_t" 1>&6 +if test $ac_cv_type_u_int32_t = no; then cat >> confdefs.h <<\EOF -#define HAVE_DOPRNT 1 +#define u_int32_t unsigned short EOF -else - echo "$ac_t""no" 1>&6 -fi - fi -for ac_func in strchr memcpy memmove -do -echo $ac_n "checking for $ac_func""... $ac_c" 1>&6 -echo "configure:2735: checking for $ac_func" >&5 -if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then +elif test "$ac_cv_sizeof_long" = 4 ; then + echo $ac_n "checking for int32_t""... $ac_c" 1>&6 +echo "configure:2012: checking for int32_t" >&5 +if eval "test \"`echo '$''{'ac_cv_type_int32_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < -/* Override any gcc2 internal prototype to avoid an error. */ -/* We use char because int might match the return type of a gcc2 - builtin and then its argument prototype would still apply. */ -char $ac_func(); - -int main() { - -/* The GNU C library defines this for functions which it implements - to always fail with ENOSYS. Some functions are actually named - something starting with __ and the normal name is an alias. */ -#if defined (__stub_$ac_func) || defined (__stub___$ac_func) -choke me -#else -$ac_func(); +#include +#if STDC_HEADERS +#include +#include #endif - -; return 0; } EOF -if { (eval echo configure:2763: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then +if (eval "$ac_cpp conftest.$ac_ext") 2>&5 | + egrep "(^|[^a-zA-Z_0-9])int32_t[^a-zA-Z_0-9]" >/dev/null 2>&1; then rm -rf conftest* - eval "ac_cv_func_$ac_func=yes" + ac_cv_type_int32_t=yes else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 rm -rf conftest* - eval "ac_cv_func_$ac_func=no" + ac_cv_type_int32_t=no fi rm -f conftest* -fi -if eval "test \"`echo '$ac_cv_func_'$ac_func`\" = yes"; then - echo "$ac_t""yes" 1>&6 - ac_tr_func=HAVE_`echo $ac_func | tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'` - cat >> confdefs.h <&6 +if test $ac_cv_type_int32_t = no; then + cat >> confdefs.h <<\EOF +#define int32_t long EOF - -else - echo "$ac_t""no" 1>&6 + fi -done -for ac_func in gethostname gettimeofday mkdir strerror strtoken -do -echo $ac_n "checking for $ac_func""... $ac_c" 1>&6 -echo "configure:2790: checking for $ac_func" >&5 -if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then + echo $ac_n "checking for u_int32_t""... $ac_c" 1>&6 +echo "configure:2045: checking for u_int32_t" >&5 +if eval "test \"`echo '$''{'ac_cv_type_u_int32_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < -/* Override any gcc2 internal prototype to avoid an error. */ -/* We use char because int might match the return type of a gcc2 - builtin and then its argument prototype would still apply. */ -char $ac_func(); - -int main() { - -/* The GNU C library defines this for functions which it implements - to always fail with ENOSYS. Some functions are actually named - something starting with __ and the normal name is an alias. */ -#if defined (__stub_$ac_func) || defined (__stub___$ac_func) -choke me -#else -$ac_func(); +#include +#if STDC_HEADERS +#include +#include #endif - -; return 0; } EOF -if { (eval echo configure:2818: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then +if (eval "$ac_cpp conftest.$ac_ext") 2>&5 | + egrep "(^|[^a-zA-Z_0-9])u_int32_t[^a-zA-Z_0-9]" >/dev/null 2>&1; then rm -rf conftest* - eval "ac_cv_func_$ac_func=yes" + ac_cv_type_u_int32_t=yes else - echo "configure: failed program was:" >&5 - cat conftest.$ac_ext >&5 rm -rf conftest* - eval "ac_cv_func_$ac_func=no" + ac_cv_type_u_int32_t=no fi rm -f conftest* -fi -if eval "test \"`echo '$ac_cv_func_'$ac_func`\" = yes"; then - echo "$ac_t""yes" 1>&6 - ac_tr_func=HAVE_`echo $ac_func | tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'` - cat >> confdefs.h <&6 +if test $ac_cv_type_u_int32_t = no; then + cat >> confdefs.h <<\EOF +#define u_int32_t unsigned long EOF - + +fi + else - echo "$ac_t""no" 1>&6 + { echo "configure: error: Cannot find a type with size of 32 bits" 1>&2; exit 1; } fi -done -for ac_func in select socket uname -do -echo $ac_n "checking for $ac_func""... $ac_c" 1>&6 -echo "configure:2845: checking for $ac_func" >&5 -if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then +echo $ac_n "checking size of size_t""... $ac_c" 1>&6 +echo "configure:2082: checking size of size_t" >&5 +if eval "test \"`echo '$''{'ac_cv_sizeof_size_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 +else + if test "$cross_compiling" = yes; then + { echo "configure: error: can not run test program while cross compiling" 1>&2; exit 1; } else cat > conftest.$ac_ext < -/* Override any gcc2 internal prototype to avoid an error. */ -/* We use char because int might match the return type of a gcc2 - builtin and then its argument prototype would still apply. */ -char $ac_func(); - -int main() { - -/* The GNU C library defines this for functions which it implements - to always fail with ENOSYS. Some functions are actually named - something starting with __ and the normal name is an alias. */ -#if defined (__stub_$ac_func) || defined (__stub___$ac_func) -choke me -#else -$ac_func(); -#endif - -; return 0; } +#include +main() +{ + FILE *f=fopen("conftestval", "w"); + if (!f) exit(1); + fprintf(f, "%d\n", sizeof(size_t)); + exit(0); +} EOF -if { (eval echo configure:2873: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then - rm -rf conftest* - eval "ac_cv_func_$ac_func=yes" +if { (eval echo configure:2101: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null +then + ac_cv_sizeof_size_t=`cat conftestval` else echo "configure: failed program was:" >&5 cat conftest.$ac_ext >&5 - rm -rf conftest* - eval "ac_cv_func_$ac_func=no" + rm -fr conftest* + ac_cv_sizeof_size_t=0 fi -rm -f conftest* +rm -fr conftest* fi -if eval "test \"`echo '$ac_cv_func_'$ac_func`\" = yes"; then - echo "$ac_t""yes" 1>&6 - ac_tr_func=HAVE_`echo $ac_func | tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'` - cat >> confdefs.h <&6 +cat >> confdefs.h <&6 +echo "configure:2120: checking printf format of size_t" >&5 +if test "$ac_cv_sizeof_size_t" = 4 ; then + echo "$ac_t"""%u"" 1>&6 + cat >> confdefs.h <<\EOF +#define SIZE_T_FMT "%u" +EOF + else - echo "$ac_t""no" 1>&6 -fi -done + echo "$ac_t"""%lu"" 1>&6 + cat >> confdefs.h <<\EOF +#define SIZE_T_FMT "%lu" +EOF -for ac_func in setrlimit inet_netof getrusage times res_init -do -echo $ac_n "checking for $ac_func""... $ac_c" 1>&6 -echo "configure:2900: checking for $ac_func" >&5 -if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then +fi +echo $ac_n "checking size of time_t""... $ac_c" 1>&6 +echo "configure:2135: checking size of time_t" >&5 +if eval "test \"`echo '$''{'unet_cv_sizeof_time_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 +else + if test "$cross_compiling" = yes; then + unet_cv_sizeof_time_t=0 else cat > conftest.$ac_ext < -/* Override any gcc2 internal prototype to avoid an error. */ -/* We use char because int might match the return type of a gcc2 - builtin and then its argument prototype would still apply. */ -char $ac_func(); - -int main() { - -/* The GNU C library defines this for functions which it implements - to always fail with ENOSYS. Some functions are actually named - something starting with __ and the normal name is an alias. */ -#if defined (__stub_$ac_func) || defined (__stub___$ac_func) -choke me -#else -$ac_func(); -#endif - -; return 0; } +#include +#include +main() +{ + FILE *f=fopen("conftestval", "w"); + if (!f) exit(1); + fprintf(f, "%d\n", sizeof(time_t)); + exit(0); +} EOF -if { (eval echo configure:2928: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then - rm -rf conftest* - eval "ac_cv_func_$ac_func=yes" +if { (eval echo configure:2155: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null +then + unet_cv_sizeof_time_t=`cat conftestval` else echo "configure: failed program was:" >&5 cat conftest.$ac_ext >&5 - rm -rf conftest* - eval "ac_cv_func_$ac_func=no" + rm -fr conftest* + unet_cv_sizeof_time_t=0 fi -rm -f conftest* +rm -fr conftest* fi -if eval "test \"`echo '$ac_cv_func_'$ac_func`\" = yes"; then - echo "$ac_t""yes" 1>&6 - ac_tr_func=HAVE_`echo $ac_func | tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'` - cat >> confdefs.h <&6 + cat >> confdefs.h <<\EOF +#define TIME_T_FMT "%lu" EOF - + + cat >> confdefs.h <<\EOF +#define STIME_T_FMT "%ld" +EOF + else - echo "$ac_t""no" 1>&6 + echo "$ac_t""$unet_cv_sizeof_time_t" 1>&6 + echo $ac_n "checking printf format of time_t""... $ac_c" 1>&6 +echo "configure:2182: checking printf format of time_t" >&5 + if test "$unet_cv_sizeof_time_t" = "$ac_cv_sizeof_long" ; then + echo "$ac_t"""%lu"" 1>&6 + cat >> confdefs.h <<\EOF +#define TIME_T_FMT "%lu" +EOF + + cat >> confdefs.h <<\EOF +#define STIME_T_FMT "%ld" +EOF + + else + echo "$ac_t"""%u"" 1>&6 + cat >> confdefs.h <<\EOF +#define TIME_T_FMT "%u" +EOF + + cat >> confdefs.h <<\EOF +#define STIME_T_FMT "%d" +EOF + + fi fi -done for ac_hdr in poll.h do ac_safe=`echo "$ac_hdr" | sed 'y%./+-%__p_%'` echo $ac_n "checking for $ac_hdr""... $ac_c" 1>&6 -echo "configure:2957: checking for $ac_hdr" >&5 +echo "configure:2211: checking for $ac_hdr" >&5 if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" -{ (eval echo configure:2967: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } +{ (eval echo configure:2221: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* @@ -2990,10 +2244,10 @@ fi done if test -z "$unet_cv_func_poll_syscall" ; then echo $ac_n "checking if poll is a system call (please wait)""... $ac_c" 1>&6 -echo "configure:2994: checking if poll is a system call (please wait)" >&5 +echo "configure:2248: checking if poll is a system call (please wait)" >&5 else echo $ac_n "checking if poll is a system call""... $ac_c" 1>&6 -echo "configure:2997: checking if poll is a system call" >&5 +echo "configure:2251: checking if poll is a system call" >&5 fi if eval "test \"`echo '$''{'unet_cv_func_poll_syscall'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 @@ -3029,7 +2283,7 @@ echo "$ac_t""$unet_cv_func_poll_syscall" 1>&6 echo $ac_n "checking for restartable system calls""... $ac_c" 1>&6 -echo "configure:3033: checking for restartable system calls" >&5 +echo "configure:2287: checking for restartable system calls" >&5 if eval "test \"`echo '$''{'ac_cv_sys_restartable_syscalls'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -3037,7 +2291,7 @@ else { echo "configure: error: can not run test program while cross compiling" 1>&2; exit 1; } else cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null +if { (eval echo configure:2313: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_sys_restartable_syscalls=yes else @@ -3078,12 +2332,12 @@ EOF fi -for ac_prog in mawk gawk nawk awk +for ac_prog in gawk mawk nawk awk do # Extract the first word of "$ac_prog", so it can be a program name with args. set dummy $ac_prog; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 -echo "configure:3087: checking for $ac_word" >&5 +echo "configure:2341: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_AWK'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -3113,7 +2367,7 @@ test -n "$AWK" && break done echo $ac_n "checking whether ${MAKE-make} sets \${MAKE}""... $ac_c" 1>&6 -echo "configure:3117: checking whether ${MAKE-make} sets \${MAKE}" >&5 +echo "configure:2371: checking whether ${MAKE-make} sets \${MAKE}" >&5 set dummy ${MAKE-make}; ac_make=`echo "$2" | sed 'y%./+-%__p_%'` if eval "test \"`echo '$''{'ac_cv_prog_make_${ac_make}_set'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 @@ -3151,7 +2405,7 @@ fi # SVR4 /usr/ucb/install, which tries to use the nonexistent group "staff" # ./install, which can be erroneously created by make from ./install.sh. echo $ac_n "checking for a BSD compatible install""... $ac_c" 1>&6 -echo "configure:3155: checking for a BSD compatible install" >&5 +echo "configure:2409: checking for a BSD compatible install" >&5 if test -z "$INSTALL"; then if eval "test \"`echo '$''{'ac_cv_path_install'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 @@ -3204,7 +2458,7 @@ test -z "$INSTALL_SCRIPT" && INSTALL_SCRIPT='${INSTALL_PROGRAM}' test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644' echo $ac_n "checking whether ln -s works""... $ac_c" 1>&6 -echo "configure:3208: checking whether ln -s works" >&5 +echo "configure:2462: checking whether ln -s works" >&5 if eval "test \"`echo '$''{'ac_cv_prog_LN_S'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -3229,7 +2483,7 @@ do # Extract the first word of "$ac_prog", so it can be a program name with args. set dummy $ac_prog; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 -echo "configure:3233: checking for $ac_word" >&5 +echo "configure:2487: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_path_RMPROG'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -3270,7 +2524,7 @@ do # Extract the first word of "$ac_prog", so it can be a program name with args. set dummy $ac_prog; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 -echo "configure:3274: checking for $ac_word" >&5 +echo "configure:2528: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_path_SHPROG'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -3308,7 +2562,7 @@ test -n "$SHPROG" || SHPROG="/bin/sh" echo $ac_n "checking for set -h""... $ac_c" 1>&6 -echo "configure:3312: checking for set -h" >&5 +echo "configure:2566: checking for set -h" >&5 if eval "test \"`echo '$''{'unet_cv_sys_set_h'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -3327,7 +2581,7 @@ echo "$ac_t""$unet_cv_sys_set_h" 1>&6 echo $ac_n "checking for posix non-blocking""... $ac_c" 1>&6 -echo "configure:3331: checking for posix non-blocking" >&5 +echo "configure:2585: checking for posix non-blocking" >&5 if eval "test \"`echo '$''{'unet_cv_sys_nonblocking_posix'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -3335,7 +2589,7 @@ else { echo "configure: error: can not run test program while cross compiling" 1>&2; exit 1; } else cat > conftest.$ac_ext < #include @@ -3361,7 +2615,7 @@ int main(void) exit(1); } EOF -if { (eval echo configure:3365: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null +if { (eval echo configure:2619: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then unet_cv_sys_nonblocking_posix=yes else @@ -3383,7 +2637,7 @@ EOF else echo $ac_n "checking for bsd non-blocking""... $ac_c" 1>&6 -echo "configure:3387: checking for bsd non-blocking" >&5 +echo "configure:2641: checking for bsd non-blocking" >&5 if eval "test \"`echo '$''{'unet_cv_sys_nonblocking_bsd'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -3391,7 +2645,7 @@ else { echo "configure: error: can not run test program while cross compiling" 1>&2; exit 1; } else cat > conftest.$ac_ext < #include @@ -3417,7 +2671,7 @@ int main(void) exit(1); } EOF -if { (eval echo configure:3421: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null +if { (eval echo configure:2675: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then unet_cv_sys_nonblocking_bsd=yes else @@ -3445,19 +2699,19 @@ EOF fi fi echo $ac_n "checking for posix signals""... $ac_c" 1>&6 -echo "configure:3449: checking for posix signals" >&5 +echo "configure:2703: checking for posix signals" >&5 if eval "test \"`echo '$''{'unet_cv_sys_signal_posix'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < int main() { sigaction(SIGTERM, (struct sigaction *)0L, (struct sigaction *)0L) ; return 0; } EOF -if { (eval echo configure:3461: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:2715: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* unet_cv_sys_signal_posix=yes else @@ -3477,7 +2731,7 @@ EOF else echo $ac_n "checking for bsd reliable signals""... $ac_c" 1>&6 -echo "configure:3481: checking for bsd reliable signals" >&5 +echo "configure:2735: checking for bsd reliable signals" >&5 if eval "test \"`echo '$''{'unet_cv_sys_signal_bsd'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else @@ -3485,7 +2739,7 @@ else { echo "configure: error: can not run test program while cross compiling" 1>&2; exit 1; } else cat > conftest.$ac_ext < int calls = 0; @@ -3503,7 +2757,7 @@ int main(void) exit (0); } EOF -if { (eval echo configure:3507: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null +if { (eval echo configure:2761: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then unet_cv_sys_signal_bsd=yes else @@ -3532,20 +2786,20 @@ fi fi echo $ac_n "checking if the compiler understands -pipe""... $ac_c" 1>&6 -echo "configure:3536: checking if the compiler understands -pipe" >&5 +echo "configure:2790: checking if the compiler understands -pipe" >&5 unet_cv_pipe_flags="$ac_cv_prog_gcc" if test "$ac_cv_prog_gcc" = no; then OLDCFLAGS="$CFLAGS" CFLAGS="$CFLAGS -pipe" cat > conftest.$ac_ext <&5; (eval $ac_compile) 2>&5; }; then +if { (eval echo configure:2803: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* unet_cv_pipe_flags=yes else @@ -3568,6 +2822,33 @@ fi +uname=`uname` +echo $ac_n "checking for OS type""... $ac_c" 1>&6 +echo "configure:2828: checking for OS type" >&5 +case "$uname" in + *inux*) + echo "$ac_t""$uname found." 1>&6 + OSDEP_C="os_linux.c" + ;; + *olaris*) + echo "$ac_t""$uname found." 1>&6 + OSDEP_C="os_solaris.c" + ;; + *SunOS*) + echo "$ac_t""$uname found." 1>&6 + OSDEP_C="os_solaris.c" + ;; + *BSD*) + echo "$ac_t""$uname found." 1>&6 + OSDEP_C="os_bsd.c" + ;; + *) + echo "$ac_t""Unknown OS. Using generic routines." 1>&6 + OSDEP_C="os_generic.c" + ;; +esac + + trap '' 1 2 15 cat > confcache <<\EOF # This file is a shell script that caches the results of configure @@ -3703,7 +2984,6 @@ s%@infodir@%$infodir%g s%@mandir@%$mandir%g s%@CC@%$CC%g s%@CPP@%$CPP%g -s%@LIBOBJS@%$LIBOBJS%g s%@AWK@%$AWK%g s%@SET_MAKE@%$SET_MAKE%g s%@INSTALL_PROGRAM@%$INSTALL_PROGRAM%g @@ -3716,6 +2996,7 @@ s%@unet_cv_sys_set_h@%$unet_cv_sys_set_h%g s%@ac_cv_header_poll_h@%$ac_cv_header_poll_h%g s%@ac_cv_header_syslog_h@%$ac_cv_header_syslog_h%g s%@unet_cv_func_poll_syscall@%$unet_cv_func_poll_syscall%g +s%@OSDEP_C@%$OSDEP_C%g CEOF EOF diff --git a/config/configure.in b/config/configure.in index 2459635..5c2e776 100644 --- a/config/configure.in +++ b/config/configure.in @@ -22,10 +22,9 @@ AC_PROG_CC dnl UNIX Variants dnl Allow the use of BSD functions on AIX. -AC_AIX +dnl AC_AIX dnl Allow the use of POSIX functions on several OS. -AC_ISC_POSIX -AC_MINIX +dnl AC_ISC_POSIX dnl ANSIfy the C compiler whenever possible. AM_PROG_CC_STDC dnl Use -O3 instead of -O2. @@ -50,11 +49,9 @@ unet_CHECK_LIB_RESOLV dnl Checks for header files. AC_HEADER_STDC -AC_HEADER_SYS_WAIT -AC_CHECK_HEADERS(malloc.h sys/malloc.h fcntl.h string.h strings.h sys/file.h sys/ioctl.h sys/time.h syslog.h unistd.h memory.h errno.h net/errno.h sys/cdefs.h) dnl Checks for typedefs, structures, and compiler characteristics. -AC_C_CONST +dnl AC_C_CONST AC_C_BIGENDIAN AC_TYPE_SIZE_T AC_HEADER_TIME @@ -68,15 +65,9 @@ unet_DEFINE_SIZE_T_FMT unet_DEFINE_TIME_T_FMT dnl Checks for library functions. -AC_PROG_GCC_TRADITIONAL -AC_FUNC_MEMCMP -AC_FUNC_SETVBUF_REVERSED -AC_TYPE_SIGNAL -AC_FUNC_VPRINTF -AC_CHECK_FUNCS(strchr memcpy memmove) -AC_CHECK_FUNCS(gethostname gettimeofday mkdir strerror strtoken) -AC_CHECK_FUNCS(select socket uname) -AC_CHECK_FUNCS(setrlimit inet_netof getrusage times res_init) +dnl AC_PROG_GCC_TRADITIONAL +dnl AC_FUNC_MEMCMP +dnl AC_FUNC_VPRINTF dnl Do we have a system call poll? unet_FUNC_POLL_SYSCALL @@ -117,5 +108,32 @@ AC_SUBST(ac_cv_header_poll_h) AC_SUBST(ac_cv_header_syslog_h) AC_SUBST(unet_cv_func_poll_syscall) +dnl Check OS for os_dep files. +uname=`uname` +AC_MSG_CHECKING(for OS type) +case "$uname" in + *inux*) + AC_MSG_RESULT($uname found.) + OSDEP_C="os_linux.c" + ;; + *olaris*) + AC_MSG_RESULT($uname found.) + OSDEP_C="os_solaris.c" + ;; + *SunOS*) + AC_MSG_RESULT($uname found.) + OSDEP_C="os_solaris.c" + ;; + *BSD*) + AC_MSG_RESULT($uname found.) + OSDEP_C="os_bsd.c" + ;; + *) + AC_MSG_RESULT(Unknown OS. Using generic routines.) + OSDEP_C="os_generic.c" + ;; +esac +AC_SUBST(OSDEP_C) + dnl Finally really generate all output files: AC_OUTPUT(config-sh Configure ../Makefile ../ircd/Makefile ../doc/Makefile Makefile, [echo timestamp > stamp-h;],) diff --git a/config/setup.h.in b/config/setup.h.in index 84e336e..c1a3a39 100644 --- a/config/setup.h.in +++ b/config/setup.h.in @@ -17,50 +17,13 @@ * 02111-1307, USA. */ -/* Define if on AIX 3. - System headers sometimes define this. - We just want to avoid a redefinition error message. */ -#ifndef _ALL_SOURCE -#undef _ALL_SOURCE -#endif - -/* Define to empty if the keyword does not work. */ -#undef const - /* Define to `int' if doesn't define. */ #undef gid_t -/* Define if you don't have vprintf but do have _doprnt. */ -#undef HAVE_DOPRNT - /* Define if system calls automatically restart after interruption by a signal. */ #undef HAVE_RESTARTABLE_SYSCALLS -/* Define if you have that is POSIX.1 compatible. */ -#undef HAVE_SYS_WAIT_H - -/* Define if you have the vprintf function. */ -#undef HAVE_VPRINTF - -/* Define if on MINIX. */ -#undef _MINIX - -/* Define if the system does not provide POSIX.1 features except - with this defined. */ -#undef _POSIX_1_SOURCE - -/* Define if you need to in order for stat and other things to work. */ -#undef _POSIX_SOURCE - -/* Define as the return type of signal handlers (int or void). */ -#undef RETSIGTYPE - -/* Define if the setvbuf function takes the buffering type as its second - argument and the buffer pointer as the third, as on System V - before release 3. */ -#undef SETVBUF_REVERSED - /* Define to `unsigned' if doesn't define. */ #undef size_t @@ -122,98 +85,8 @@ /* The number of bytes in a size_t. */ #undef SIZEOF_SIZE_T -/* Define if you have the gethostname function. */ -#undef HAVE_GETHOSTNAME - -/* Define if you have the getrusage function. */ -#undef HAVE_GETRUSAGE - -/* Define if you have the gettimeofday function. */ -#undef HAVE_GETTIMEOFDAY - -/* Define if you have the inet_netof function. */ -#undef HAVE_INET_NETOF - -/* Define if you have the memcpy function. */ -#undef HAVE_MEMCPY - -/* Define if you have the memmove function. */ -#undef HAVE_MEMMOVE - -/* Define if you have the mkdir function. */ -#undef HAVE_MKDIR - -/* Define if you have the res_init function. */ -#undef HAVE_RES_INIT - -/* Define if you have the select function. */ -#undef HAVE_SELECT - -/* Define if you have the setrlimit function. */ -#undef HAVE_SETRLIMIT - -/* Define if you have the socket function. */ -#undef HAVE_SOCKET - -/* Define if you have the strchr function. */ -#undef HAVE_STRCHR - -/* Define if you have the strerror function. */ -#undef HAVE_STRERROR - -/* Define if you have the strtoken function. */ -#undef HAVE_STRTOKEN - -/* Define if you have the times function. */ -#undef HAVE_TIMES - -/* Define if you have the uname function. */ -#undef HAVE_UNAME - -/* Define if you have the header file. */ -#undef HAVE_ERRNO_H - -/* Define if you have the header file. */ -#undef HAVE_FCNTL_H - -/* Define if you have the header file. */ -#undef HAVE_MALLOC_H - -/* Define if you have the header file. */ -#undef HAVE_MEMORY_H - -/* Define if you have the header file. */ -#undef HAVE_NET_ERRNO_H - /* Define if you have the header file. */ #undef HAVE_POLL_H -/* Define if you have the header file. */ -#undef HAVE_STRING_H - -/* Define if you have the header file. */ -#undef HAVE_STRINGS_H - -/* Define if you have the header file. */ -#undef HAVE_SYS_CDEFS_H - -/* Define if you have the header file. */ -#undef HAVE_SYS_FILE_H - -/* Define if you have the header file. */ -#undef HAVE_SYS_IOCTL_H - -/* Define if you have the header file. */ -#undef HAVE_SYS_MALLOC_H - -/* Define if you have the header file. */ -#undef HAVE_SYS_TIME_H - -/* Define if you have the header file. */ -#undef HAVE_SYSLOG_H - -/* Define if you have the header file. */ -#undef HAVE_UNISTD_H - /* Define if you have the crypt library (-lcrypt). */ #undef HAVE_LIBCRYPT diff --git a/doc/Authors b/doc/Authors index 31076f5..2d85f30 100644 --- a/doc/Authors +++ b/doc/Authors @@ -142,13 +142,19 @@ UNDERNET (1991 - 1999) The Undernet versions (TSpre8, u2.9 and u2.10) are based on ircd-2.8.10 and contain thousands of hours of work by Carlo Wood -(Run on IRC). The number of protocol enhancements, changes and additions that -have been added are too many to summarize. All patches are kept in the patch -repository at http://www.xs4all.nl/~carlo17/ircd-dev/ +(Run on IRC). The number of protocol enhancements, changes and additions +that have been added are too many to summarize. All patches are kept in the +cvs repository at http://coder-com.undernet.org/. Discussions on this +server code are currently on the mailing list coder-com@undernet.org, or in +#coder-com on undernet. + +The current maintainer is Bleep. Various additions and bugfixes have been contributed by: Aaron +Bleep +CaptJay CapVideo Chaos Cym @@ -156,11 +162,14 @@ Derrick Ensor flux Ghostwolf +Gte- +Isomer Jamey Jarle Kev Nemesi Niels +Run record smg SeKs diff --git a/doc/exaconf.2 b/doc/exaconf.2 new file mode 100644 index 0000000..6e8ece2 --- /dev/null +++ b/doc/exaconf.2 @@ -0,0 +1,211 @@ +# Set the name of the server, its numeric, and the server info field +serverinfo { + name "test.server.undernet.org"; + capacity 6124; + numeric 18; + description "A test server for the next generation"; + + # this is an optional parameter to specify where outbound + # connections should originate from + addr "18.177.0.118"; +} + +# Select a seed from /dev/random or the appropriate local alternative. +# If /dev/random doesn't exist, use a seed +# Note: on Linux, /dev/urandom should probably be used--it won't block. +seedfile "/dev/random"; + +# Let's set up some logging +logging { + syslog daemon; # set the syslog facility to daemon + + logpath "/home/irc/logs" # path prepended to log file names + + log kill syslog notice; # log kills to syslog at priority "notice" + log squit syslog notice; + log connect syslog debug; + + log oper file "opers.log"; # log /opers to file "opers.log" + log gline file "gline.log"; + + nolog users; # turn off logging for users (default, but illustrative) + + pid "ircd.pid"; +} + +binpath "/home/irc/bin/ircd"; # binary to exec() when we /restart +libpath "/home/irc/lib"; # directory to chdir() to on start-up + +# Here's an authorization record--defines who is permitted on the server +# and what special information needs to be remembered about them. +auth everyone { + host "*@*"; # hosts this auth record matches + maxusers 1200; # Max users for this auth record + perhost 2; # Maximum of 2 users per host on this server + global 3; # Maximum of 2 users per host on the entire network + ping 120; # ping them once every 120 seconds if link inactive + sendq 270000; # max sendq for everyone in the auth record +} + +# Here's another one for miters people +auth miters { + host "*@*.mit.edu"; + host "*@18.*"; + maxusers 1200; + perhost 1; + global 1; + ping 300; + sendq 120000; +} + +# And here's a back door for my operators--perhaps to be used in an emergency +auth opers { + host "*@*"; + unset ident; # no identd + unset banable; # no denial rules + unset limit; # ignore any limits + set ipspoof; # hostname is spoofed to protect the guilty + password "MybacKd004!"; # password-only access + motd "opers.motd"; # a special MOTD for opers +} + +port { + accept opers; # auth records are tried in order listed + accept miters; + accept everyone; + + port 6660-6669 "18.177.0.118"; # ports to open + port 6660-6669 "18.177.0.119"; +} + +port { + set hide; + + accept opers; + + port 7000; # IP is optional and defaults to 0.0.0.0 +} + +port { + set hide; + set serveronly; + + port 4400 "18.177.0.118"; +} + +# allow channel hacks and glines +server uworld.undernet.org { + set channelhack; + set gline; +} + +server uworld2.undernet.org { + set channelhack; + set gline; +} + +server uworld.eu.undernet.org { + set channelhack; + set gline; +} + +# allow channel hacks only +server channels.undernet.org { + set channelhack; +} + +server channels2.undernet.org { + set channelhack; +} + +# here's some link class definitions for servers (only) +class hubs { + limit 2; # Max connection attempts per class + freq 600; # Connect frequency + ping 300; # how often to ping them + sendq 2700000; # sendq +} + +# Here's a hub link +server santaclara.ca.us.undernet.org { + class hubs; # this is in the hubs link class + + link 4400 "205.158.23.3"; # link address + password "toysrus"; # link password + set auto; # we'll auto to it + set hub; # it's a hub +} + +server dallas-r.tx.us.undernet.org { + class hubs; + + link 4400 "204.178.73.175"; + password "areyouready?"; + set auto; + set hub; + + deny "linked(santaclara.ca.us.undernet.org)"; # a d-line +} + +# here's a leaf +server vancouver.bc.ca.undernet.org { + link 4400 "199.60.228.129"; + password "toylink"; + set auto; + + denyoper "linked(santaclara.ca.us.undernet.org)"; # a D-line +} + +# here's a set of default flags for opers +# +# the part before the '.' specifies the namespace the flags are from-- +# not necessary inside the user record itself, but we don't otherwise +# know the namespace here. The part after the '.' is a label. +flagset user.oper { + set kill; # allow kills... + set kline; # allow kline/unkline + set gline; # allow local glines + set rehash; # can use /rehash + set restart; # can use /restart + set die; # can use /die + set wallops; # can use /wallops + set connect; # can use /connect and /squit + set stats; # can use /stats + set info; # can use /info + set opernotice; # can see oper-only notices + set massmsg; # can use mass messages +} + +# here's an operator +user Kev { + default oper; # a set of flags for the user + cryptpass "J/7oDe78NhQ+/"; # password must be given to activate + host "*.mit.edu"; # must be from the listed hosts + host "*.ne.mediaone.net"; + host "18.*"; + host "168.159.*"; +} + +# nick jupes +user Uworld { + set juped; +} + +user Uworld2 { + set juped; +} + +user EUworld { + set juped; +} + +user X { + set juped; +} + +user W { + set juped; +} + +# File deny records are kept in; this can be modified from online +denyfile "klines.conf"; diff --git a/doc/example.conf b/doc/example.conf index 8d8d023..77da1d5 100644 --- a/doc/example.conf +++ b/doc/example.conf @@ -34,20 +34,25 @@ # # First some information about the server. -# M::::: +# M::::: # -# The must be either be empty, contain a "*", or contain -# the IP address of an interface on your system. If it contains an address, -# the address will be bound to if you have specified virtual hosting. +# must contain either a * or a valid IPv4 address in +# dotted quad notation. (127.0.0.1) The address MUST be the address +# of a physical interface on the host. This address is used for outgoing +# connections only, see P:lines for listener virtual hosting. +# If in doubt put a * or the IP of your primary interface here. +# The server must be compiled with virtual hosting turned on to get this +# to work correctly. # -# The is the port that other servers can connect to. -# Client ports need to be specified with a P: line, see below. +# The is no longer used. +# Ports need to be specified with a P: line, see below. +# At some point in the future we may want to use the port value for +# server capacity. --Bleep # # Note that has to be unique on the network your server # is running on, must be between 1 and 64, and is not updated on a rehash. -# M:London.UK.Eu.UnderNet.org:127.0.0.1:University of London, England:4400:1 -M:London.UK.Eu.UnderNet.org:*:University of London, England:4400:1 +M:London.UK.Eu.UnderNet.org:*:University of London, England:0:1 # # This sets information that can be retrieved with the /ADMIN command. @@ -225,16 +230,6 @@ K:unixbox.flooder.co.uk:!kline/youflooded.txt:*luser # even if an IP address has a properly resolving host name. k:192.168.*:!klines/martians:* -# -# A more flexible way of restricting access to your server is the use -# of "restriction lines". These tell the server to start up an (external) -# program, upon whose output is decided whether the client is allowed -# access. The program should print "Y" or "N " on its stdout. -# Note that the use of R: lines is discouraged and deprecated, needs a -# compile-time define, eats CPU cycles and may well be taken out in -# future releases of ircd. -# R::: - # # You probably want your server connected to other servers, so your users # have other users to chat with. @@ -247,28 +242,16 @@ k:192.168.*:!klines/martians:* # server links is provided for ircd to decide what links to allow, what # to let humans do themselves, and what links to (forcefully) disallow. # -# The Connection and Allowing connection lines (also known as C/N lines) +# The Connection lines (also known as C lines) # define what servers the server connect to, and which servers are -# allowed to connect. Note that they come in pairs; they do not work if -# one if present and the other is absent. +# allowed to connect. # C::::: -# N::::: # -# If you wish to use ident, prepend "username@" to the hostname or IP -# address (the first field). # If the "port" field is omitted, the server will not attempt to # establish a link with that server ("not autoconnecting"). -# The (optional) "host mask" field tells the server to represent itself -# with "hostmask" dot-seperateed fields stripped from its servername -# and replace it with "*.". -# For example, if hostmask == 2 and the local server name is -# "irc.sub.domain.com" it would be sent as "*.domain.com". This allows -# for easier routing and linking of new servers. -# This feature is not used on Undernet. # Our primary uplink. C:1.2.3.4:passwd:Amsterdam.NL.Eu.UnderNet.org:4400:90 -N:1.2.3.4:passwd:Amsterdam.NL.Eu.UnderNet.org::90 # # If your server starts on a bit larger network, you'll probably get @@ -289,11 +272,11 @@ H:*.*::Amsterdam.NL.Eu.UnderNet.org # you can use Disallow lines. For more information, see doc/readme.crules. # D::: # d::: -D:*.US.UnderNet.org::connected(*.US.UnderNet.org) -d:*.EU.UnderNet.org::connected(Amsterdam.NL.EU.*) +# D:*.US.UnderNet.org::connected(*.US.UnderNet.org) +# d:*.EU.UnderNet.org::connected(Amsterdam.NL.EU.*) # The following line is recommended for leaf servers: -d:*::directcon(*) +# d:*::directcon(*) # # Inevitably, you have reached the part about "IRC Operators". Oper status @@ -323,31 +306,48 @@ O:*@*.cs.vu.nl:VRKLKuGKn0jLs:Niels::10 # then use a connection class that allows more then one connection, # for example (using class 10 as in the example above): # Y:10:90:0:100:160000 -# + +# [P:lines] # When your server gets fuller, you will notice delays when trying to # connect to your server's primary listening port. Via the Port lines -# it is possible to specify additional ports (both AF_UNIX and AF_INET) -# for ircd to listen to. +# it is possible to specify additional ports for ircd to listen to. # De facto ports are: 6667 - standard; 6660-6669 - additional client # ports; -# +# Undernet uses 4400 for server listener ports. # These are just hints, they are in no way official IANA or IETF policies. # -# On a side note, the /UPING command uses port 7007/udp. If your server -# is located behind a firewall, you may want to make another hole in it -# for this port. +# The interface setting allows multiply homed hosts to specify which +# interface to use on a port by port basis, if an interface is not specified +# the default interface will be used. The interface MUST be the complete +# IP address for a real hardware interface on the machine running ircd. +# +# The [CS][H] field is an optional field to specify that a port is a +# server port or a client port and whether it's hidden or not. +# If used the first character MUST be either a C or S. +# If you want to hide a port from /stats p from non-opers follow the C +# or S with an H # -# P:::: +# P:::<[CS][H]>: +# +# This is a normal server port, you need to have at least one server +# port defined if you want to connect your server to other servers. +P:::S:4400 +# This is a Server port that is Hidden +#P:::SH:4401 -P::::6667 +# The following are normal client ports +P:::C:6667 P::::6668 P:*.nl:::6666 -P:/tmp/.ircd:::6667 + +# This is a hidden client port, listening on the interface associated +# with the IP address 168.8.21.107 +#P:*:168.8.21.107:CH:7000 # # Well, you have now reached the end of this sample configuration file # If you have any questions, feel free to mail -# or . +# or . # If you are interested in linking your server to the Undernet IRC network # visit http://www.routing-com.undernet.org/, and if there are any problems # then contact asking for information. diff --git a/doc/fda.txt b/doc/fda.txt new file mode 100644 index 0000000..d993ae5 --- /dev/null +++ b/doc/fda.txt @@ -0,0 +1,151 @@ +fdaman.txt - brief usage information for FDA (Free Debug Allocator) + +Copyright (C) 1998 Thomas Helvey + +1. Base Functionality +Basic use of the fda tools is as simple as including the header +and source file with your source defining DEBUG and using capitalized +versions of malloc(), calloc(), realloc(), and free(). +The fda allocation functions verify all your arguments and will call +assert() if something is wrong. FDA trashes all allocated memory +in a predictable manner and applies prefix and postfix bounds checking +signatures to every allocation. When a pointer is freed it's validated, +and checked for overflows and underflows. The fda Realloc function +does not allow malloc or free through realloc and forces reallocation +if the required memory is larger than the current allocation. + +In both the DEBUG and non-debug versions of fda, if a memory allocation +fails once, a low memory callback function is called to allow you to +release some memory and allow malloc to succeed, the default version +prints a warning message to stderr. If the low memory callback returns +the allocation is attempted again, if the second allocation fails a +no memory callback function is called to allow you to clean up before +terminating the application, if you allow the no memory callback to +return the results are undefined. (a NULL ptr will be returned from the +allocation call) The default no memory handler prints an error message +to stderr and calls abort(). The DEBUG version will assert if you allow +the no memory function to return. +Both the low memory and no memory callbacks have the signature of: +void handler(void) + +The debug version of fda will not allow you to do the following: +Allocate a zero length chunk of memory. +Free a non-allocated pointer. +Free a pointer twice. +Free a pointer at the wrong offset. +Use realloc to free memory. (realloc(p, 0)) +Use realloc to malloc memory. (realloc(0, s)) +Overwrite the bounds of the memory you allocated. (checked on free) + +The base functions for fda are: +void* malloc(size_t) +void* realloc(void*, size_t) +void* calloc(size_t, size_t) +void free(void*) +char* strdup(const char*) +void set_lowmem_handler(void (*fn)(void)) +void set_nomem_handler(void (*fn)(void)) + +FDA uses a hash table to lookup pointers. The size of the hash table can +be changed at compile time by using -DFDA_HASH_TABLE_SIZE +where prime is a prime number somewhere around the number of allocations +expected. The default hash table size is 16339 which should be large enough +to hold most medium sized applications. FDA allocates memory for it's +debugging records so if your application uses a lot of memory you +may want to make sure you have enough memory available to use the debug +version. FDA allocates 20 bytes to store each allocation and 20 bytes +to store location information (file and line info). This overhead only +applies if you have DEBUG or _DEBUG defined. + +2. Extended functionality +FDA provides a few handy functions for validating pointers and +checking for overruns before they occur when debugging. +The first function fda_sizeof(ptr) returns the size of the buffer +pointed to by ptr, this allows you to verify that your pointer +is what it says it is. fda_sizeof() will call assert() if the +pointer you pass it is not at the start of an allocation. + +The second function valid_ptr(ptr, size) verifies that ptr lies within +allocated memory and there are at least size bytes available in the buffer. +You can pass valid_ptr() a pointer to any location in allocated memory. +valid_ptr() calls assert if the pointer points outside of allocated memory +or the remaining size is less than the size specified. +valid_ptr() is more efficient if the pointer argument is the value +returned from malloc because it's a simple hash table lookup, a more +exhaustive algorithm is used if it's not found in the hash table. + +FDA extended functions: +size_t fda_sizeof(const void*) +int valid_ptr(const void*, size_t) + +Typical usage for the fda extended functions: +Note: the assert macro compiles to nothing if NDEBUG is defined. +Verify a foo_ptr: +assert(sizeof(struct foo) == fda_sizeof(foo_ptr)); +assert(valid_ptr(foo_ptr, sizeof(struct foo))); +Check for room to write: +assert(valid_ptr(buf, len)); + +3. Leak checking and block validation +FDA has several functions for leak checking, and reference marking. +fda_clear_refs() iterates through all of the allocated blocks of +memory and clears the referenced flag. +fda_set_ref() marks a single allocation(block) as being referenced or +in use by somebody. +fda_assert_refs() iterates through all the allocated blocks of +memory and calls assert() if it finds one that's not referenced. + +Typical usage of the block validation functions: +fda_clear_refs(); /* clear all block references */ + +for each allocation do +fda_set_ref(allocation); /* mark allocation in use */ +done + +fda_assert_refs(); /* this will assert if a leak is found */ + +4. Reporting functions: +FDA has 4 functions for reporting various aspects of allocation +status. +fda_get_byte_count() tells you the current total number of bytes +your application has allocated. (this does not include debugging records) +This will give you an idea of how much memory your application is +using at any given time. + +fda_get_block_count() returns the total count of current allocations. + +fda_enum_locations() calls a user supplied enumeration function with +file, line, count information, this allows you to see your file by +file allocation density. ;) fda_enum_locations() returns the total +number of locations that have memory allocated. + +fda_enum_leaks() calls a user supplied enumeration function with +file, line, size, and ptr for every block not marked as referenced. +One use for fda_enum_leaks() is checking for leaks when your program +exits: +void enum_fn(const char* file, int line, size_t size, void* ptr) +{ + printf("Memory leak: %s: %d - %d bytes at (%p)\n", file, line, size, ptr); +} + +int main(void) +{ + ... +#if defined(DEBUG) + /* check for memory leaks before exiting */ + fda_clear_refs(); + fda_enum_leaks(enum_fn); +#endif + return 0; /* return from main */ +} + +The test file fdatest.c gives examples of usage for most of the functions +available with FDA. + +Please let me know if you encounter any problems with FDA. +So far FDA has been built and tested on linux and Windows NT. +If you find that it works with or without change on other platforms +please let me know so I can make the appropriate changes to the +code and add it to the list of tested platforms. + + diff --git a/doc/features.txt b/doc/features.txt new file mode 100644 index 0000000..9b486ea --- /dev/null +++ b/doc/features.txt @@ -0,0 +1,208 @@ +Undernet server features. +------------------------- + +This document is supposed to list the features that undernet supports and +provides to clients, and which version of ircu this was added. Additional +numeric replies should be added here too. + +Extended Who information: (WHOX) + Version: unknown, but at least 2.10.07+ + + This is described in the file 'readme.who' + +USERIP: + Version: unknown, but at least 2.10.07+ + + This works the same as userhost, but returns the IP instead, useful for + setting a ban on someones IP address instead of their nick. + usage: + USERIP nick[,nick...] + returns: + RPL_USERIP (307) + :server.name 307 target nick[*]=[+|-]user@host... + +RPL_ISUPPORT: + version: 2.10.08+ + + This sends a numeric during client signon that lists various features that + ircu supports. This allows client and script writers to know what features + they can use, and various parameters about the irc server. The numeric + used is '005' to try and maintain some semblance of compatibility with + dalnet which has a similar feature. The 005 numeric may be split across + multiple lines if the length exceeds 512 characters. + + The format is: + :servername 005 target feature1 feature2... :are supported by this server. + :servername 005 target feature200... :are supported by this server. + + features are either a word describing the feature eg: 'SILENCE', or a word + describing the feature and an equals and a list of parameters. + eg: SILENCE=15 (says that we support silence, and we support up to 15 of + them per user), or FOO=12,3 (says we support FOO with parameters 12 and 3) + for example 2.10.08 lists: + + :test.undernet.org 005 test SILENCE=15 WHOX WALLCHOPS USERIP CPRIVMSG + CNOTICE MODES=6 MAXCHANNELS=10 MAXBANS=30 NICKLEN=9 TOPICLEN=160 + KICKLEN=160 + + NOTE: Versions prior to 2.10.08+ use numeric 005 as part of 'MAP', so + 005 should be /not/ be used after the server registration has occured. + (ie: after END_OF_MOTD has arrived). + +MAP: + Version: unknown, but since 2.9.30 at least, updated in 2.10.08 + + /map shows the servers as the server percieves them, who's connected + to who in a pretty display. In version 2.10.08 it also lists the + amount time time it takes a message to get /from/ a server to the local + server - this measures the one way lag only, in 2.10.08 it also lists + the number of clients that are currently on that server. + The lag estimation is very approximate and depends on people changing nick + and joining channels, so the less clients on a server the less reliable the + lag estimation is. + + Map prior to 2.10.08 uses: + RPL_MAP 005 + RPL_MAPMORE 006 + RPL_MAPEND 007 + Map changed in 2.10.08 to allow for ISUPPORT on numeric 005, the new + numerics are: + RPL_MAP 015 + RPL_MAPMORE 016 + RPL_MAPEND 017 + +WALLCHOPS: + Version: unknown, but since 2.10.07 + + WALLCHOPS sends a message to all channel operators (@)'s on a channel. + It does /not/ require you to be op'd (@'d) to do so. This is a feature. + + syntax: + WALLCHOPS #channel :message + or: + NOTICE @#channel :message + + this sends: + :user NOTICE @#channel :message + to clients that are @'d on the channel. + +CPRIVMSG/CNOTICE: + Version: unknown, but since 2.10.07 + + CPRIVMSG/CNOTICE are a way around target limiting in recent undernet + servers. Undernet servers prevent you from sending messages to too many + people at once in an attempt to help cut down the amount of spam that + occurs on the network. Because there are several situations where you want + to send messages to lots of people that are on the same channel as you + (autogreet's and gamebots for example) an 'escape' was made in the form + of CPRIVMSG/CNOTICE. These allow you to send a privmsg/notice to a person + on a common channel if you are op'd (@'d) without incuring a target + penalty. If you see 'Target changed too fast' messages, you should + probably be using these commands. + + Syntax: + CPRIVMSG #channel nick :Message + CNOTICE #channel nick :Message + + Results are the same as for 'PRIVMSG' and 'NOTICE' respectively. + +SILENCE: + Version: unknown, 2.9.32 at least. + + Silence is a server side ignore. You can /silence +hostmask or + /silence +nick, to add someone to your silence list, or use /silence + -hostmask to remove it. /silence will list your 'silence list'. + you can /silence nick, to see someone elses silence list (useful for + helping someone). Silence is preferably used as a last resort as it + tends to use server CPU time. Undernet typically only allows 15 silences + per user. in 2.10.08+ this information is available in the RPL_ISUPPORT + line. + + Syntax: + SILENCE +hostmask + SILENCE +nick + SILENCE -hostmask + SILENCE -nick + SILENCE nick + + reply: + RPL_SILELIST 217 + RPL_ENDOFSILELIST 218 + +User modes: + Version: various + + Undernet supports these additional user modes: + +d: Deaf & Dumb. This user will not get any channel traffic. Used for + bots. + +k: This user cannot be kicked, deop'd or /kill'd. This usermode may only + be set by a server, it may not be set by a user. This is used by + undernet service bots (X/W/UWorld etc) + +g: List channel HACK:'s + +s: Server messages - takes a parameter of which masks to send, see + 'snomask.html' for more details. (2.10.0+) + +LIST: + Version: Unknown + + List now takes various parameters to allow you to quickly and efficiently + find interesting channels. These are: + + >n or n or Cn or C + + + + + Undernet P10 Protocol and Interface Specification + + + +

+Undernet P10 Protocol and Interface Specification

+(As of ircu 2.10.10) +

+Undernet Coder-com, coder-com@undernet.org

+v0.10, 2nd March 2000. +

+

This document aims to be a practical +guide for implementing and maintaining the protocol, not just a reference +manual. +

This document is "work in progress" and being continually updated :) +

+
1. Introduction +

2. General concepts and background +

2.1 Concepts. +
2.2 Token Table.
+ +

+3. Registration and syncronisation

+ + + +

+4. Continous operation

+ +
    +
  • +4.1 Channel operations.
    • + +
  • +4.2 Messaging.
    • + +
  • +4.3 Setting G-Lines.
    • + +
  • +4.4 ...
    • +
+ +

+4. Programmers reference: Function headers

+ +
    +
  • +4.1 ms_nick
    • + +
  • +4.2 m_burst
    • + +
  • +4.3 ..etc
    • +
+ +

+5. Programmers reference: Client/Server Structures

+ +

+6. FAQ

+ +

+7. Acknowledgements and disclaimer

+ +

+8. Update History

+ +
+
  • +TODO List
    • +
    + +
    +
    + +

    1. Introduction +

    [Back] +
    +

    +

    2. General concepts and background +

    2.1 Concepts +

    The undernet P10 protocol uses a scheme of "Numerics" to uniquenly identify +a client or server within the network. Each server has its own unique numeric +(0 -> 4095) and each client has its own numeric within that server (0->262,143). +

    The numerics are encoded into a Base64 stream to maintain human readable +data flow and reduce the size of the messages. The Base64 character set +used in ircu is included below, this defines all valid characters allowed +in a Base64 numeric with "A" representing 0 and "]" representing 63. +

    +
    ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789[]
    +
    +Server numerics consist of 2 characters, with the minimum, 0, being represented +by "AA", and the maximum, 4095, being represented by "]]". Client numerics +are 3 characters long, with the minimum, 0, being represented by "AAA", +and the maximum, 262,143, being represented by "]]]". The unique identifier +of a client on the network consists of a combination of both the server +and client numeric in the format SSCCC. +

    As an example, consider a server "irc.undernet.org" which has a numeric +of 2, translating to "AC" in Base64. On this server exists a client, whom +has been allocated the numeric 63 (which translates to "AA]" in Base64). +Therefore, the unique identifier of this client on the network is "ACAA]". +From this, we can determine which server the message came from, aswell +as the client who sent it. +

    These numerics are used to prefix every message issued on the stream +except for the initial "PASS" or "SERVER" message, which are not prefixed. +Therefore, every message that can be recieved from a server will consist +of the format: +

    +
    [NUMERIC PREFIX] [TOKEN] [DATA]
    +
    +For Example: +
    +
    A[A5j P ABAAA :Foo.
    +
    +2.2 Token Table +

    The following table lists all the acceptable messages, along with their +relevant "Token", which is used in the server<>server protocol. The +aim of tokenisation is to reduce the bandwidth used during network communication +by reducing the length of common message identifiers. +
      +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    MessageToken
    PRIVMSGP
    WHOH
    WHOISW
    WHOWASX
    USERUSER
    NICKN
    SERVERS
    LISTLIST
    TOPICT
    INVITEI
    VERSIONV
    QUITQ
    SQUITSQ
    KILLD
    INFOF
    LINKSLI
    STATSR
    HELPHELP
    ERRORY
    AWAYA
    CONNECTCO
    MAPMAP
    PINGG
    PONGZ
    OPEROPER
    PASSPA
    WALLOPSWA
    DESYNCHDS
    TIMETI
    SETTIMESE
    RPINGRI
    RPONGRO
    NAMESE
    ADMINAD
    TRACETR
    NOTICEO
    WALLCHOPSWC
    CPRIVMSGCP
    CNOTICECN
    JOINJ
    PARTL
    LUSERSLU
    MOTDMO
    MODEM
    KICKK
    USERHOSTUSERHOST
    USERIPUSERIP
    ISONISON
    SQUERYSQUERY
    SERVLISTSERVLIST
    SERVSETSERVSET
    REHASHREHASH
    RESTARTRESTART
    CLOSECLOSE
    DIEDIE
    HASHHASH
    DNSDNS
    SILENCEU
    GLINEGL
    BURSTB
    CREATEC
    DESTRUCTDE
    END_OF_BURSTEB
    END_OF_BURST_ACKEA
    PROTOPROTO
    +[Back] +
    +
    +

    3. Registration and syncronisation +

    3.1 Server registration and authentication +

    After a TCP connection has been established, the server initally introduces +itself via a "PASS" message as follows: +

    +
    PASS :[PASSWORD]
    +
    +"PASSWORD" is simply compared with the password present in the destination +servers config file, and is used to confirm credentials after the "SERVER" +message has been recieved, as follows: +
    +
    SERVER [SERVERNAME] [HOPCOUNT] [START TIME] [LINK TIME] [PROTOCOL] [NUMERIC/MAXCONN] :[DESCRIPTION]
    +
    +For Example: +
    +
    1      2                3 4         5         6   7     8 
+SERVER irc.undernet.org 1 933022556 947908144 J10 AA]]] :[127.0.0.1] A Undernet Server.
    +
    +Notes: +
      +
    1. +The SERVER message, indicating this connection wishes to introduce a new +server to the network.
      2. + +
    2. + The name of the server you are introducing, a valid server name consists +of [..defn..].
      3. + +
    3. + The hop count of the server you are introducing, this is always 1 +when you are introducing yourself.
      4. + +
    4. + The epoch timestamp specifying when the ircd was started.
      5. + +
    5. + The epoch timestamp specifying the time the server initiated the +link to the network.
      6. + +
    6. + The Protocol identifier of this server.
      7. + +
        +
      1. +This token informs the network which protocol it is compliant with, eg: +If it is a P10 compliant server, then the token will be "P10".
        2. + +
      2. + If the server being introduced has not yet successfully synced its +database with the network (Completed its net.burst - see 3.2), then the +Protocol token should be prefixed with a J, instead of a P (Eg: J10) to +indicate it is currently still joining the network.
        3. + +
      3. + The protocol token should always be JXX when the server is introducing +itself.
        4. +
      + +
    7. +The numeric, and maximum connections identifier for this server.
      8. + +
        +
      1. +This token is formatted exactly the same as a client numeric is formatted. +The first 2 characters identify the server's numeric, whilst in this situation, +the final 3 characters define the maximum number of clients that this server +can hold (and more importantly, the maximum number of numerics it will +generate).
        2. + +
      2. + The example "AA]]]" shows that this is a server with numeric 0, which +will generate client numerics up to 262,143.
        3. +
      + +
    8. +This final parameter simply consists of a textual description of the server +prefixed by a colon. This is displayed in a clients WHOIS line, aswell +as in the LINKS reply.
      9. +
    +3.2 Network Database resyncronisation +

    After the connection has been established and verified, the next step +is to syncronise the database of client/server/channel information between +the two servers. +

    3.2.1 - SERVER Messages
    + +
    Server details are transmitted via "SERVER" messages similar +to the initial introduction message, with the following format:
    + +
    +
    [OWNING SERVER PREFIX] S [SERVERNAME] +[HOPCOUNT] [START TIME] [LINK TIME] [PROTOCOL] [NUMERIC/MAXCONN] 0 :[DESCRIPTION]
    +The syntax of this message is almost identical to +the originally recieved server message, with the only exception being that +the message is numeric prefixed, to indicate which server sent this message +(and also therefore, which hub this new server is linked too). There is +also a fixed "0" present before the Description field, this is a placeholder +for future use and currently unused. +

    3.2.2 - NICK Messages

    + +
    Client information is transmitted via "NICK" messages, of the +following format:
    + +
    +
    +
    [NUMERIC PREFIX] N [NICK] [HOPCOUNT] [TIMESTAMP] [USERNAME] [HOST] <+modes> [BASE64 IP] [NUMERIC] :[USERINFO]
    +
    +For Example: +
    1  2 3       +4 5         6     +7            8     +9      10    11 +
    AF N Client1 1 947957573 User userhost.net ++oiwg DAqAoB AFAAA :Generic Client.
    +Notes: +
      +
    1. +The numeric of the server sending this message. (And hence, owning this +client).
      2. + +
    2. +The "NICK" token.
      3. + +
    3. +The nickname of this client, currently max 9 chars.
      4. + +
    4. +The "Hopcount" of this client, Ie: how many servers away it is on.
      5. + +
    5. +The epoch timestamp indicating when the user was created.
      6. + +
    6. +The "User" part of the user@host mask.
      7. + +
    7. +the "Host" part of the user@host mask.
      8. + +
    8. +[Optional]: User modes. If present, this is always +<user modes +for this client>.
      9. + +
    9. +The real IP address of this client, a Base64 encoded 32bit int.
      10. + +
    10. +This client's numeric, in SSCCC format.
      11. + +
    11. +Free format user info line.
      12. + +
       
    +
    + +
    3.2.3 - BURST Messages
    + +
    Channel details and membership information is synchronised +in one (or more) BURST messages for each channel that exists, formatted +as follows:
    + +
    +
    +
    [NUMERIC PREFIX] B [CHANNEL] [CREATION TIMESTAMP] <+MODES> <ARG1> <ARG2> [MEMBER LIST] <:%BANS>
    +
    +
    + +
    For Example:
    + +
    +
    +
    1  2 3          4         5      6   7  8                                         9
+AZ B #coder-com 949217470 +tinkl key 56 AAAAA,AAAAB,AAAAC,ABAAA,ABAAB,ABAAC,ACAAA :%*!*@*.net
    +
    +
    + +
    Notes:
    + +
      +
    1. +The numeric of the server sending this message.
      2. + +
    2. +The "BURST" token.
      3. + +
    3. +The name of the channel to which this data belongs. Currently #Channel +and +Channel names can be sent in a BURST message, &Channels are not +because by definition they are local to the server.
      4. + +
    4. +The epoch timestamp indicating when the channel was created.
      5. + +
    5. +[Optional]: Channel Modes.
      6. + +
        +
      1. +The channel may have a number of modes set, aswell as relevant mode arguments +in the following 2 parameters.
        2. +
      + +
    6. +[Optional]: Channel Key, this parameter is present if the channel +modes contain a "k" mode.
      7. + +
    7. +[Optional]: Channel Limit, this parameter is present if the channel +modes contain a "l" mode.
      8. + +
    8. + A comma seperated list of client numerics, with the following +specific formatting rules to indicate +o, +v and +ov channel members.
      9. + +
        +
      1. +Numerics can have the following symbols appended on them; ":ov", +":v" or ":o". These indicate that this numeric is either +Opped (:o), Voiced (:v) or both (:ov). This state +applies to the numeric it is attached too, and all subsequent numerics +until another state is encountered. For Example:
        2. + +
      2. +AAABA:ov, AAABB:o,AAABC,AAABD,AAABE:v,AAABZ
        3. + +
        Here, AAABA is both opped, and voiced, AAABB, AAABC and AAABD are opped +leaving AAABE and AAABZ voiced. +
      3. + The first numeric of the member list will always contain a state +symbol.
        4. +
      + +
    9. +A space seperated list of bans present in the channel. The start +of the ban stream is indicated by a ":%", everything following the ":%" +is the ban list.
      10. + +
      For Example: +
      :%*!*@*.foobar.net another!ban@*.com *!*fred@a.host.co.uk +
      Would add the following bans to the channel: +

      *!*@*.foobar.net +
      another!ban@*.com +
      *!*fred@a.host.co.uk

    + +
    If the length of a BURST message exceeds the maximum lenght +of a line (512 characters) then the remaining channel members/bans are +sent in subsequent BURST lines. The subsequent burst lines are only +used to add additional members to the channel, and if neccessary, channel +bans. There will be no "Mode" parameters present. A sample additional burst +line would be:
    + +
    +
    +
    AZ BURST #coder-com 949217470 ACAAB:o,ACAAD :%*!*another@*.ban.com
    +
    +
    + +
    Which adds two more opped members and a ban to the channel.
    +3.3 Summary +

    The following table summarises the sequence of events that occur when +a server connects to another server. S1 is our server, and S2 is a HUB +on the target network. +

    S1: Sends Password. +
    S1: Sends initial SERVER message. +

    S2 Confirms S1 has the correct credentials, and if so, proceeds. +If not, S1 is squit with a relevant reason. +

    S2: Sends Password. +
    S2: Sends initial SERVER message. +

    S1 Confirms S2 has the correct credentials, and if so, proceeds. +If not, S2 is squit with a relevant reason. +

    The follow occur asynchronously, however they have been shown +seperately below for simplicity. +

    S1: Sends all the servers it is aware of as a stream of SERVER messages. +
    S1: Sends all the clients it is aware of as a stream of NICK messages. +
    S1: Sends the database of channel states on the network, as a stream +of BURST messages. +
    S1: Sends a END_OF_BURST token (EB) to indicate it has finished sending. +

    S2: Sends all the servers it is aware of as a stream of SERVER messages. +
    S2: Sends all the clients it is aware of as a stream of NICK messages. +
    S2: Sends the database of channel states on the network, as a stream +of BURST messages. +
    S2: Sends a END_OF_BURST token (EB) to indicate it has finished sending. +

    S2: Sends an EOB_ACK token (EA) to indicate it has succesfully recieved +the END_OF_BURST from S1 +
    S1: Sends an EOB_ACK token (EA) to indicate it has succesfully recieved +the END_OF_BURST from S2 +

    Example Session: +

    [WRITE]: PASS :54321
+[WRITE]: SERVER irc.undernet.org 1 947957852 947957852 J10 AB]]] :Undernet Client Server.
+[WRITE]: AB N MrFoo 1 947957852 ~me myhost.foobar.net +diksw DAqAoB ABAAA :Mr Foo (foo@bar.com).
+[WRITE]: AB B #mychannel 946101324 ABAAA:o
+[WRITE]: AB EB
+[ READ]: PASS :54321
+[ READ]: SERVER server1.undernet.org 1 947901540 947958150 J10 AFAD] :A Generic Server.
+[ READ]: AF S server2.undernet.org 2 0 947957585 P10 AZAD] 0 :[192.168.10.3] A Generic Server.
+[ READ]: AZ S server3.undernet.org 3 0 947957607 P10 AIAD] 0 :[192.168.10.5] A Generic Server.
+[ READ]: AF N Client1 1 947957573 Ident userhost.net +oiwg DAqAoB AFAAA :Generic Client.
+[ READ]: AZ N Client2 2 947957719 Ident userhost.net +iwg DAqAoB AZAAA :Generic Client.
+[ READ]: AI N Client3 3 947957742 Ident userhost.net +iwg DAqAoB AIAAA :Generic Client.
+[ READ]: AI N Client4 3 947958121 Ident userhost.net +iwg DAqAoB AIAAB :Generic Client.
+[ READ]: AF B #foobar 947957734 +tink akey AIAAB,AIAAA:v,AZAAA:o :%*!*another@*.ban.com *!*foo@bar.net
+[ READ]: AF B #coder-com 947957727 AIAAB,AZAAA:o
+[ READ]: AF B #another 946101321 AFAAA
+[ READ]: AF EB
+[WRITE]: AB EA
+[ READ]: AF EA
    +[Back] +
    +
    +
    4. Continuous Operation +

    [Back] +
    +

    +

    5. Programmers reference: Client/Server +Structures +

    This section provides information on the standard Client/Server structures, +for easy reference during development. +

    [..Link to autogenerated struct.html..] +

    [Back] +
    +

    +
    7. FAQ +

    Frequently asked questions. +

      +
    • +Q. How..
      • + +
    • +A. ...
      • +
    +[Back] +
    +
    +

    8. Update History +

    [20/01/2000]: Initial draft, structure, background info. +
    [13/02/2000]: Added initial BURST documentation. +
    [14/02/2000]: Continued BURST documentation / Begin NICK and SERVER +documentation. +
    [26/02/2000]: Continued chapter 5, few example fixes, added token table +from msg.h. --Gte. +
    [02/03/2000]: Added NICK spec. --Gte. +

    8.1 TODO +

      +
    • +Finish Chapter 5.
      • + +
    • +Go through examples, and ensure they are all correct.
      • + +
    • +Add common function headers, with argv listings.
      • + +
    • +Add description of further server<>server messages, with special cases +and outcomes.
      • + +
    • +Add FAQ Section.
      • +
    +[Back] + + diff --git a/doc/readme.who b/doc/readme.who index 419abbe..d0acefa 100644 --- a/doc/readme.who +++ b/doc/readme.who @@ -1,62 +1,56 @@ WHO documentation, updated on 02 Jan 1999. -Since ircu2.10.02 the WHO command had been changed from what -described in RFC1459, while still keeping backward compatibility, -actually it has been changed again in u2.10.05 so that since this -release the format of the who query is now: +Since ircu2.10.02 the WHO command had been changed from what described in +RFC1459, while still keeping backward compatibility, actually it has been +changed again in u2.10.05 so that since this release the format of the who +query is now: [:source] WHO [ []] - is optional, if mask2 is present it's used for matching and -mask1 is ignored, otherwise mask1 is used for matching, since mask2 -is the last parameter it *can* contain a space and this can help -when trying to match a "realname". + is optional, if mask2 is present it's used for matching and mask1 is +ignored, otherwise mask1 is used for matching, since mask2 is the last +parameter it *can* contain a space and this can help when trying to match a +"realname". When matching IP numbers the can be in 3 forms: - The old and well known IRC masks using * and ? as wanted - The IPmask form a.b.c.d/e.f.g.h as used in most firewalls and - system configurations, where what is before the / are the bits - we expect in the IP number and what is after the / is the - "filter mask" telling wich bits whould be considered and wich - should be ignored. -- The IPmask form a.b.c.d/bitcount where bitcount is an integer - between 0 and 31 (inclusive), the matching will be for the IPs - whose first "bitcount" bits are equal to those in a.b.c.d + system configurations, where what is before the / are the bits we expect + in the IP number and what is after the / is the "filter mask" telling wich + bits whould be considered and wich should be ignored. +- The IPmask form a.b.c.d/bitcount where bitcount is an integer between 0 + and 31 (inclusive), the matching will be for the IPs whose first + "bitcount" bits are equal to those in a.b.c.d Note that: . The bitcount must be between 0 and 31, 32 is NOT good (and - makes no sense to use it... just match against the static IP - a.b.c.d) -. The missing pieces of both the bitmask and the ipnumber in - the forms ipnumber/bitmask and ipnumber/bitcount default to - zero from right to left, this is NOT what inet_aton and most - tools do but makes more sense here IMO, in example /who 194.243/16 - is taken as /who 194.243.0.0/255.255.0.0 (inet_aton whould - take 194.243 as 194.0.0.243). -. For the above reason and specified validity limits 1.2.3.4/31 - becomes 1.2.3.4/255.255.255.254 while 1.2.3.4/32 becomes - 1.2.3.4/32.0.0.0 :) - -For all the other fields th match happens as has always been, -i.e. it's only considered the IRC mask with * and ? (that is: -don't expect to catch an user with "realname" = "1.2.3.4" when -doing "/who 1.2/16 h" :) - -For both the masks and the options (and thus for all flags) case is -NOT significative (so "/who o" is exactly the same as -"/who O". - -The "options2 part can be as follows: + makes no sense to use it... just match against the static IP a.b.c.d) +. The missing pieces of both the bitmask and the ipnumber in the forms + ipnumber/bitmask and ipnumber/bitcount default to zero from right to left, + this is NOT what inet_aton and most tools do but makes more sense here + IMO, in example /who 194.243/16 is taken as /who 194.243.0.0/255.255.0.0 + (inet_aton whould take 194.243 as 194.0.0.243). +. For the above reason and specified validity limits 1.2.3.4/31 becomes + 1.2.3.4/255.255.255.254 while 1.2.3.4/32 becomes 1.2.3.4/32.0.0.0 :) + +For all the other fields th match happens as has always been, i.e. it's only +considered the IRC mask with * and ? (that is: don't expect to catch an user +with "realname" = "1.2.3.4" when doing "/who 1.2/16 h" :) + +For both the masks and the options (and thus for all flags) case is NOT +significative (so "/who o" is exactly the same as "/who O". + +The "options2" part can be as follows: [][%[[,]]] -in wich: +in which: - : can be a sequence of field matching flags, use mode matching - flags and special purpose flags + : can be a sequence of field matching flags, use mode matching flags + and special purpose flags - Field matching flags, when one of these is specified the field in + Field matching flags, when one of these is specified the field in question is matched against the mask, otherwise it's not matched. n Nick (in nick!user@host) @@ -66,12 +60,11 @@ in wich: s Servername (the canonic name of the server the guy is on) r Info text (formerly "Realname") - If no field-matching flags are specified they default to what - old servers used to do: nuhsr (= everything except the numeric IP) + If no field-matching flags are specified they default to what old servers + used to do: nuhsr (= everything except the numeric IP) - User mode matching flags (specifying one of these means that only - clients with that umode are considered, what is not specified - is always matched): + User mode matching flags (specifying one of these means that only clients + with that umode are considered, what is not specified is always matched): o Irc operator [In the future more flags will be supported, basically all @@ -79,20 +72,19 @@ in wich: Special purpose flags: - x If this is specified the extended visibility of information - for opers is applied, what this means depends on the fact that - you are local or global operator and on how the admin configured - the server (global and eventually local irc opers might be - allowed with this flag to see +i local users, to see all +i users, - to see users into +p and/or +s channels, and so on). Using the 'x' - flag while not beeing irc operator is meaningless (it will be - ignored), using it while oper'd means that the query is almost - certainly logged and the admin might (rightfully) ask you an - explanation on why you did. - - The rest, what follows the %, that is [%[fields[,]]], - is as it has always been since the first who.patch, the part - specifies wich fields to include in the output as: + x If this is specified the extended visibility of information for opers + is applied, what this means depends on the fact that you are local or + global operator and on how the admin configured the server (global + and eventually local irc opers might be allowed with this flag to see + +i local users, to see all +i users, to see users into +p and/or +s + channels, and so on). Using the 'x' flag while not being an irc + operator is meaningless (it will be ignored), using it while oper'd + means that the query is almost certainly logged and the admin might + (rightfully) ask you an explanation on why you did. + + The rest, what follows the %, that is [%[fields[,]]], is as it + has always been since the first who.patch, the part specifies + wich fields to include in the output as: c : Include (first) channel name d : Include "distance" in hops (hopcount) @@ -105,16 +97,16 @@ in wich: t : Include the querytype in the reply u : Include userID with eventual ~ -And the , final option can be used to specify what you want -the server to say in the querytype field of the output, useful to -filter the output in scripts that do a kind of "on 354 ..." +And the , final option can be used to specify what you want the +server to say in the querytype field of the output, useful to filter the +output in scripts that do a kind of "on 354 ..." -If no %fields are specified the reply is _exactly_ the same as -has always been, numeric 352, same fields, same order. +If no %fields are specified the reply is _exactly_ the same as has always +been, numeric 352, same fields, same order. -If one or more %fields are specified the reply uses a new numeric, -since an out-of-standard 352 crashes EPIC and confuses several other -clients. I used 354. +If one or more %fields are specified the reply uses a new numeric, since an +out-of-standard 352 crashes EPIC and confuses several other clients. I used +354. :"source" 354 "target" ["querytype"] ["channel"] ["user"] ["IP"] ["host"] ["server"] ["nick"] @@ -122,35 +114,34 @@ clients. I used 354. Where only the fields specified in the %fields options are present. -"querytype" is the same value passed in the /who command, it -is provided to simplify scripting, in example one could pass -a certain value in the query and have that value "signal" back -what is to be done with those replies. - -The number of lines in the reply is still limited to avoid self-flooding -and sooner or later another limitation will be added: you will be forced -to do no more than one /who query every 'n' seconds where 'n' depends -on the number of fields you actually match (the field-match flags specified -before % in the option, defaulting to 6 if you don't specify an option -at all), infact matching against many fields as the default query does -severely affects the CPU usage of the server and is *much* better to -specify with the field-atching flags what you are looking for, in example -when you are looking for all french users a "/who *.fr h" is A LOT -better than just "/who *.fr" (and actually you want users that have the +"querytype" is the same value passed in the /who command, it is provided to +simplify scripting, in example one could pass a certain value in the query +and have that value "signal" back what is to be done with those replies. + +The number of lines in the reply is still limited to avoid self-flooding and +sooner or later another limitation will be added: you will be forced to do +no more than one /who query every 'n' seconds where 'n' depends on the +number of fields you actually match (the field-match flags specified before +% in the option, defaulting to 6 if you don't specify an option at all), +infact matching against many fields as the default query does severely +affects the CPU usage of the server and is *much* better to specify with the +field-matching flags what you are looking for, in example when you are +looking for all french users a "/who *.fr h" is A LOT better than just "/who +*.fr" (and actually you want users that have the _hostname_ matching *.fr, you wouldn't want to match a japanese user that has the realname "ku fung-kay aj.fr" in example...) Note that: - An user doing a "/who whatever" or a "/who whatever o" - will not see any change (except for the anti-flood limit - and sooner or later the CPU usage limit) + will not see any change (except for the anti-flood limit and sooner or + later the CPU usage limit) -- An user doing a "/who #wasteland %n" will get just a list - of nicks (lame, very lame way of doing it :-) +- An user doing a "/who #wasteland %n" will get just a list of nicks (lame, + very lame way of doing it :-) -- An user doing a "/who 0 o%nuhs" will get a list of the opers - with Nick, userID, server and hostname like: +- An user doing a "/who 0 o%nuhs" will get a list of the opers with Nick, + userID, server and hostname like: :Amst* 354 Nemesi #wasteland nbakker pc73.a.sn.no Oslo*.org Niels @@ -165,12 +156,12 @@ Note that: "on 354 * 166" display "There is an oper ..." - The client will have to sort/format the fields by itself, - the _order_ in wich flags are passed is not significant, - the fields in the reply will always have the same order. + the _order_ in which flags are passed is not significant, the fields in the + reply will always have the same order. - The maximum number of _lines_ reported as reply for a query - is 2048/(n+4) where 'n' is the number of flags "enabled" - that is the number of fields included in each reply. + is 2048/(n+4) where 'n' is the number of flags "enabled" that is the + number of fields included in each reply. Actually: 1 field returned = maximum 409 replies 2 fields returned = maximum 341 replies @@ -183,63 +174,61 @@ Note that: 9 fields returned = maximum 157 replies 10 fields returned = maximum 146 replies - If the limit is reached before completing the query the - reply is truncated and a new numeric error is issued after - the "End of WHO", anyway the "end of" numeric is _always_ - sent (otherwise some scripts and clients get crazy). + If the limit is reached before completing the query the reply is truncated + and a new numeric error is issued after the "End of WHO", anyway the "end + of" numeric is _always_ sent (otherwise some scripts and clients go + crazy). The actual "mask" to match can have one of the two following forms: - A comma-separated list of elements: in this case each element - is treated as a flat channel or nick name and is not matched - to the other elements. Nicks do count in the limit of output - lines (they should not be that many anyway), channels count - if who asks the query is not on the channel. (That is: a /who - #channel gives unlimited output if you are in there). - -- A _single_ mask: in this case (no commas, only one element) the - mask is first checked to be a full channel or nickname, then - it is matched against all relevant fiels as already known. - These happens in different steps with replicates-removal so - that if one has (?) something like "#wasteland" as "real name" - or is on a channel named "#***MyChan***" it all works nicely. + is treated as a flat channel or nick name and is not matched to the other + elements. Nicks do count in the limit of output lines (they should not be + that many anyway), channels count if who asks the query is not on the + channel. (That is: a /who #channel gives unlimited output if you are in + there). + +- A _single_ mask: in this case (no commas, only one element) the mask is + first checked to be a full channel or nickname, then it is matched against + all relevant fiels as already known. These happens in different steps + with replicates-removal so that if one has (?) something like "#wasteland" + as "real name" or is on a channel named "#***MyChan***" it all works + nicely. Miscellaneous bug fixes / "undocumented feature" changes: -- /who NickName did not show the user with nick = NickName when it - was invisible, even if the nick was given completely (without - wildchars) now it does, since one could always see him as /whois - NickName. - It does not report him twice if he also has in example the - userID == NickName and is -i. - -- ":source WHO :The Black Hacker" did not report an user having - "The Black Hacker" as real name, now it does. Since this can only - be done without the flags/format specificator because that would - become the "last parameter" an escape has been provided: if you - pass to m_who _3_ parameters the first one will be ignored and the - last one used for matching, like in example - ":source WHO foo %nuh :*Black Hacker*" where "foo" will not - be used and the match will happen on "*Black Hacker*". - (It was passed through clean_channelname() that prevented the mask - from containing spaces and such...) +- /who NickName did not show the user with nick = NickName when it was + invisible, even if the nick was given completely (without wildchars) now + it does, since one could always see him as /whois NickName. It does not + report him twice if he also has in example the userID == NickName and is + -i. + +- ":source WHO :The Black Hacker" did not report an user having "The Black + Hacker" as real name, now it does. Since this can only be done without the + flags/format specificator because that would become the "last parameter" + an escape has been provided: if you pass to m_who _3_ parameters the first + one will be ignored and the last one used for matching, like in example + ":source WHO foo %nuh :*Black Hacker*" where "foo" will not be used and + the match will happen on "*Black Hacker*". (It was passed through + clean_channelname() that prevented the mask from containing spaces and + such...) - When one user was umode -i he was shown or not depending on the - fact he was on a +p or +s channel... since we are doing a lookup - on the _user_ this makes no sense to me, example: + fact he was on a +p or +s channel... since we are doing a lookup on the + _user_ this makes no sense to me, example: Neme1 : umode -i, on no channels, was SEEN with a /who 0 Neme2 : umode -i, on channel #p with chmode +p, was NOT SEEN by /who 0 Neme3 : umode -i, on channel #s with chmode +s, was NOT SEEN by /who 0 - Now all users "-i" are matched with a "/who mask", the +i users - instead must bee on a _common_ channel to be seen. + Now all users "-i" are matched with a "/who mask", the +i users instead + must be on a _common_ channel to be seen. - Basically beeing on "one" +s|p channel "forced" a +i status while - one might want to be on #secret (mode +s) and have nobody know that - he is in there but on the other side stay -i so others can find him. - Of course a +s|p channel is never shown in the reply unless who asks - the query is in there, if no "visible" channels are available for - a -i user he is shown on "channel *". + Basically being on "one" +s|p channel "forced" a +i status while one might + want to be on #secret (mode +s) and have nobody know that he is in there + but on the other side stay -i so others can find him. Of course a +s|p + channel is never shown in the reply unless who asks the query is in there, + if no "visible" channels are available for a -i user he is shown on + "channel *". - When one user is +i is shown _only_ if there is a common channel, the first common channel found is shown in the reply. @@ -268,22 +257,21 @@ Miscellaneous bug fixes / "undocumented feature" changes: now it does (and does NOT report him twice if he is ALSO on a channel named #John, strange but true: this can happen). -- "/who a,b,c,d" where a b c and d are channelnames/nicks now uses - an hash lookup and therefore is extremely efficient, if _only_ one - field is specified it is looked in all the fields; who really wants - _only_ users on a specific channel or a single nick (without looking - for a match in the other fields) can force the server to consider - the parameter as a list adding a comma somewhere, like: +- "/who a,b,c,d" where a b c and d are channelnames/nicks now uses an hash + lookup and therefore is extremely efficient, if _only_ one field is + specified it is looked in all the fields; who really wants _only_ users on + a specific channel or a single nick (without looking for a match in the + other fields) can force the server to consider the parameter as a list + adding a comma somewhere, like: "/who #Italia," or "/who ,Nemesi" Or even better to avoid misbehaviour with other servers: "/who #Italia %... #Italia," or "/who Nemesi %... Nemesi," - This will make old servers act properly and new ones and should - be the reccomended way for GUI based clients to get - a channel's userlist and all the infos they want about users - on the channel. + This will make old servers act properly and new ones and should be the + recomended way for GUI based clients to get a channel's userlist and all + the infos they want about users on the channel. Regards, Andrea aka Nemesi diff --git a/doc/rfc1413.txt b/doc/rfc1413.txt new file mode 100644 index 0000000..0522c7b --- /dev/null +++ b/doc/rfc1413.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group M. St. Johns +Request for Comments: 1413 US Department of Defense +Obsoletes: 931 February 1993 + + + Identification Protocol + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +1. INTRODUCTION + + The Identification Protocol (a.k.a., "ident", a.k.a., "the Ident + Protocol") provides a means to determine the identity of a user of a + particular TCP connection. Given a TCP port number pair, it returns + a character string which identifies the owner of that connection on + the server's system. + + The Identification Protocol was formerly called the Authentication + Server Protocol. It has been renamed to better reflect its function. + This document is a product of the TCP Client Identity Protocol + Working Group of the Internet Engineering Task Force (IETF). + +2. OVERVIEW + + This is a connection based application on TCP. A server listens for + TCP connections on TCP port 113 (decimal). Once a connection is + established, the server reads a line of data which specifies the + connection of interest. If it exists, the system dependent user + identifier of the connection of interest is sent as the reply. The + server may then either shut the connection down or it may continue to + read/respond to multiple queries. + + The server should close the connection down after a configurable + amount of time with no queries - a 60-180 second idle timeout is + recommended. The client may close the connection down at any time; + however to allow for network delays the client should wait at least + 30 seconds (or longer) after a query before abandoning the query and + closing the connection. + + + + + + + +St. Johns [Page 1] + +RFC 1413 Identification Protocol February 1993 + + +3. RESTRICTIONS + + Queries are permitted only for fully specified connections. The + query contains the local/foreign port pair -- the local/foreign + address pair used to fully specify the connection is taken from the + local and foreign address of query connection. This means a user on + address A may only query the server on address B about connections + between A and B. + +4. QUERY/RESPONSE FORMAT + + The server accepts simple text query requests of the form: + + , + + where is the TCP port (decimal) on the target (where + the "ident" server is running) system, and is the + TCP port (decimal) on the source (client) system. + + N.B - If a client on host A wants to ask a server on host B about a + connection specified locally (on the client's machine) as 23, 6191 + (an inbound TELNET connection), the client must actually ask about + 6191, 23 - which is how the connection would be specified on host B. + + For example: + + 6191, 23 + + The response is of the form + + , : : + + where , are the same pair as the + query, is a keyword identifying the type of response, and + is context dependent. + + The information returned is that associated with the fully specified + TCP connection identified by , , + , , where and + are the local and foreign IP addresses of the + querying connection -- i.e., the TCP connection to the Identification + Protocol Server. ( and are taken + from the query.) + + For example: + + 6193, 23 : USERID : UNIX : stjohns + 6195, 23 : ERROR : NO-USER + + + +St. Johns [Page 2] + +RFC 1413 Identification Protocol February 1993 + + +5. RESPONSE TYPES + +A response can be one of two types: + +USERID + + In this case, is a string consisting of an + operating system name (with an optional character set + identifier), followed by ":", followed by an + identification string. + + The character set (if present) is separated from the + operating system name by ",". The character set + identifier is used to indicate the character set of the + identification string. The character set identifier, + if omitted, defaults to "US-ASCII" (see below). + + Permitted operating system names and character set + names are specified in RFC 1340, "Assigned Numbers" or + its successors. + + In addition to those operating system and character set + names specified in "Assigned Numbers" there is one + special case operating system identifier - "OTHER". + + Unless "OTHER" is specified as the operating system + type, the server is expected to return the "normal" + user identification of the owner of this connection. + "Normal" in this context may be taken to mean a string + of characters which uniquely identifies the connection + owner such as a user identifier assigned by the system + administrator and used by such user as a mail + identifier, or as the "user" part of a user/password + pair used to gain access to system resources. When an + operating system is specified (e.g., anything but + "OTHER"), the user identifier is expected to be in a + more or less immediately useful form - e.g., something + that could be used as an argument to "finger" or as a + mail address. + + "OTHER" indicates the identifier is an unformatted + character string consisting of printable characters in + the specified character set. "OTHER" should be + specified if the user identifier does not meet the + constraints of the previous paragraph. Sending an + encrypted audit token, or returning other non-userid + information about a user (such as the real name and + phone number of a user from a UNIX passwd file) are + + + +St. Johns [Page 3] + +RFC 1413 Identification Protocol February 1993 + + + both examples of when "OTHER" should be used. + + Returned user identifiers are expected to be printable + in the character set indicated. + + The identifier is an unformatted octet string - - all + octets are permissible EXCEPT octal 000 (NUL), 012 (LF) + and 015 (CR). N.B. - space characters (040) following the + colon separator ARE part of the identifier string and + may not be ignored. A response string is still + terminated normally by a CR/LF. N.B. A string may be + printable, but is not *necessarily* printable. + +ERROR + + For some reason the port owner could not be determined, + tells why. The following are the permitted values of and + their meanings: + + INVALID-PORT + + Either the local or foreign port was improperly + specified. This should be returned if either or + both of the port ids were out of range (TCP port + numbers are from 1-65535), negative integers, reals or + in any fashion not recognized as a non-negative + integer. + + NO-USER + + The connection specified by the port pair is not + currently in use or currently not owned by an + identifiable entity. + + HIDDEN-USER + + The server was able to identify the user of this + port, but the information was not returned at the + request of the user. + + UNKNOWN-ERROR + + Can't determine connection owner; reason unknown. + Any error not covered above should return this + error code value. Optionally, this code MAY be + returned in lieu of any other specific error code + if, for example, the server desires to hide + information implied by the return of that error + + + +St. Johns [Page 4] + +RFC 1413 Identification Protocol February 1993 + + + code, or for any other reason. If a server + implements such a feature, it MUST be configurable + and it MUST default to returning the proper error + message. + + Other values may eventually be specified and defined in future + revisions to this document. If an implementer has a need to specify + a non-standard error code, that code must begin with "X". + + In addition, the server is allowed to drop the query connection + without responding. Any premature close (i.e., one where the client + does not receive the EOL, whether graceful or an abort should be + considered to have the same meaning as "ERROR : UNKNOWN-ERROR". + +FORMAL SYNTAX + + ::= + + ::= "," + + ::= + + ::= "015 012" ; CR-LF End of Line Indicator + + ::= | + + ::= ":" "ERROR" ":" + + ::= ":" "USERID" ":" + ":" + + ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR" + | "HIDDEN-USER" | + + ::= [ "," ] + + ::= "OTHER" | "UNIX" | ...etc. + ; (See "Assigned Numbers") + + ::= "US-ASCII" | ...etc. + ; (See "Assigned Numbers") + + ::= + + ::= 1*64 ; 1-64 characters + + ::= "X"1*63 + ; 2-64 chars beginning w/X + + + +St. Johns [Page 5] + +RFC 1413 Identification Protocol February 1993 + + + ::= 1*5 ; 1-5 digits. + + ::= "0" | "1" ... "8" | "9" ; 0-9 + + ::= + /?"'~`{}[]; > + ; upper and lowercase a-z plus + ; printables minus the colon ":" + ; character. + + ::= 1*512 + + ::= + + +Notes on Syntax: + + 1) To promote interoperability among variant + implementations, with respect to white space the above + syntax is understood to embody the "be conservative in + what you send and be liberal in what you accept" + philosophy. Clients and servers should not generate + unnecessary white space (space and tab characters) but + should accept white space anywhere except within a + token. In parsing responses, white space may occur + anywhere, except within a token. Specifically, any + amount of white space is permitted at the beginning or + end of a line both for queries and responses. This + does not apply for responses that contain a user ID + because everything after the colon after the operating + system type until the terminating CR/LF is taken as + part of the user ID. The terminating CR/LF is NOT + considered part of the user ID. + + 2) The above notwithstanding, servers should restrict the + amount of inter-token white space they send to the + smallest amount reasonable or useful. Clients should + feel free to abort a connection if they receive 1000 + characters without receiving an . + + 3) The 512 character limit on user IDs and the 64 + character limit on tokens should be understood to mean + as follows: a) No new token (i.e., OPSYS or ERROR-TYPE) + token will be defined that has a length greater than 64 + and b) a server SHOULD NOT send more than 512 octets of + user ID and a client MUST accept at least 512 octets of + + + +St. Johns [Page 6] + +RFC 1413 Identification Protocol February 1993 + + + user ID. Because of this limitation, a server MUST + return the most significant portion of the user ID in + the first 512 octets. + + 4) The character sets and character set identifiers should + map directly to those defined in or referenced by RFC 1340, + "Assigned Numbers" or its successors. Character set + identifiers only apply to the user identification field + - all other fields will be defined in and must be sent + as US-ASCII. + + 5) Although is defined as an + above, it must follow the format and character set + constraints implied by the ; see the + discussion above. + + 6) The character set provides context for the client to + print or store the returned user identification string. + If the client does not recognize or implement the + returned character set, it should handle the returned + identification string as OCTET, but should in addition + store or report the character set. An OCTET string + should be printed, stored or handled in hex notation + (0-9a-f) in addition to any other representation the + client implements - this provides a standard + representation among differing implementations. + +6. Security Considerations + + The information returned by this protocol is at most as trustworthy + as the host providing it OR the organization operating the host. For + example, a PC in an open lab has few if any controls on it to prevent + a user from having this protocol return any identifier the user + wants. Likewise, if the host has been compromised the information + returned may be completely erroneous and misleading. + + The Identification Protocol is not intended as an authorization or + access control protocol. At best, it provides some additional + auditing information with respect to TCP connections. At worst, it + can provide misleading, incorrect, or maliciously incorrect + information. + + The use of the information returned by this protocol for other than + auditing is strongly discouraged. Specifically, using Identification + Protocol information to make access control decisions - either as the + primary method (i.e., no other checks) or as an adjunct to other + methods may result in a weakening of normal host security. + + + + +St. Johns [Page 7] + +RFC 1413 Identification Protocol February 1993 + + + An Identification server may reveal information about users, + entities, objects or processes which might normally be considered + private. An Identification server provides service which is a rough + analog of the CallerID services provided by some phone companies and + many of the same privacy considerations and arguments that apply to + the CallerID service apply to Identification. If you wouldn't run a + "finger" server due to privacy considerations you may not want to run + this protocol. + +7. ACKNOWLEDGEMENTS + + Acknowledgement is given to Dan Bernstein who is primarily + responsible for renewing interest in this protocol and for pointing + out some annoying errors in RFC 931. + +References + + [1] St. Johns, M., "Authentication Server", RFC 931, TPSC, January + 1985. + + [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, + USC/Information Sciences Institute, July 1992. + +Author's Address + + Michael C. St. Johns + DARPA/CSTO + 3701 N. Fairfax Dr + Arlington, VA 22203 + + Phone: (703) 696-2271 + EMail: stjohns@DARPA.MIL + + + + + + + + + + + + + + + + + + + +St. Johns [Page 8] + diff --git a/doc/rfc1459.unet b/doc/rfc1459.unet new file mode 100644 index 0000000..98fe3dd --- /dev/null +++ b/doc/rfc1459.unet @@ -0,0 +1,3642 @@ +Network Working Group J. Oikarinen +Request for Comments: 1459 D. Reed + May 1993 + + + Internet Relay Chat Protocol + +Undernet Specific Annotations and Changes + This document exists here in order to attempt to describe the existing + protocol that is currently in use on the Undernet IRC Network. Since + the original standard was released, many networks have made + significant changes and enhancements to the protocol described in the + original version of this document. This version of the standard should + be updated by the current maintainers of the Undernet server software + distribution as changes are made that affect the protocol. Please be + aware that some sections may be out of date. + +Status of This Memo + + This memo defines an Experimental Protocol for the Internet + community. Discussion and suggestions for improvement are requested. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +Abstract + + The IRC protocol was developed over the last 4 years since it was + first implemented as a means for users on a BBS to chat amongst + themselves. Now it supports a world-wide network of servers and + clients, and is stringing to cope with growth. Over the past 2 years, + the average number of users connected to the main IRC network has + grown by a factor of 10. + + The IRC protocol is a text-based protocol, with the simplest client + being any socket program capable of connecting to the server. + +Table of Contents + + 1. INTRODUCTION ............................................... 4 + 1.1 Servers ................................................ 4 + 1.2 Clients ................................................ 5 + 1.2.1 Operators .......................................... 5 + 1.3 Channels ................................................ 5 + 1.3.1 Channel Operators .................................... 6 + 2. THE IRC SPECIFICATION ....................................... 7 + 2.1 Overview ................................................ 7 + 2.2 Character codes ......................................... 7 + 2.3 Messages ................................................ 7 + 2.3.1 Message format in 'pseudo' BNF .................... 8 + 2.4 Numeric replies ......................................... 10 + 3. IRC Concepts ................................................ 10 + 3.1 One-to-one communication ................................ 10 + 3.2 One-to-many ............................................. 11 + 3.2.1 To a list .......................................... 11 + 3.2.2 To a group (channel) ............................... 11 + 3.2.3 To a host/server mask .............................. 12 + 3.3 One to all .............................................. 12 + + + +Oikarinen & Reed [Page 1] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 3.3.1 Client to Client ................................... 12 + 3.3.2 Clients to Server .................................. 12 + 3.3.3 Server to Server ................................... 12 + 4. MESSAGE DETAILS ............................................. 13 + 4.1 Connection Registration ................................. 13 + 4.1.1 Password message ................................... 14 + 4.1.2 Nickname message ................................... 14 + 4.1.3 User message ....................................... 15 + 4.1.4 Server message ..................................... 16 + 4.1.5 Operator message ................................... 17 + 4.1.6 Quit message ....................................... 17 + 4.1.7 Server Quit message ................................ 18 + 4.2 Channel operations ...................................... 19 + 4.2.1 Join message ....................................... 19 + 4.2.2 Part message ....................................... 20 + 4.2.3 Mode message ....................................... 21 + 4.2.3.1 Channel modes ................................. 21 + 4.2.3.2 User modes .................................... 22 + 4.2.4 Topic message ...................................... 23 + 4.2.5 Names message ...................................... 24 + 4.2.6 List message ....................................... 24 + 4.2.7 Invite message ..................................... 25 + 4.2.8 Kick message ....................................... 25 + 4.3 Server queries and commands ............................. 26 + 4.3.1 Version message .................................... 26 + 4.3.2 Stats message ...................................... 27 + 4.3.3 Links message ...................................... 28 + 4.3.4 Time message ....................................... 29 + 4.3.5 Connect message .................................... 29 + 4.3.6 Trace message ...................................... 30 + 4.3.7 Admin message ...................................... 31 + 4.3.8 Info message ....................................... 31 + 4.4 Sending messages ........................................ 32 + 4.4.1 Private messages ................................... 32 + 4.4.2 Notice messages .................................... 33 + 4.5 User-based queries ...................................... 33 + 4.5.1 Who query .......................................... 33 + 4.5.2 Whois query ........................................ 34 + 4.5.3 Whowas message ..................................... 35 + 4.6 Miscellaneous messages .................................. 35 + 4.6.1 Kill message ....................................... 36 + 4.6.2 Ping message ....................................... 37 + 4.6.3 Pong message ....................................... 37 + 4.6.4 Error message ...................................... 38 + 5. OPTIONAL MESSAGES ........................................... 38 + 5.1 Away message ............................................ 38 + 5.2 Rehash command .......................................... 39 + 5.3 Restart command ......................................... 39 + + + +Oikarinen & Reed [Page 2] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 5.4 Summon message .......................................... 40 + 5.5 Users message ........................................... 40 + 5.6 Operwall command ........................................ 41 + 5.7 Userhost message ........................................ 42 + 5.8 Ison message ............................................ 42 + 6. REPLIES ..................................................... 43 + 6.1 Error Replies ........................................... 43 + 6.2 Command responses ....................................... 48 + 6.3 Reserved numerics ....................................... 56 + 7. Client and server authentication ............................ 56 + 8. Current Implementations Details ............................. 56 + 8.1 Network protocol: TCP ................................... 57 + 8.1.1 Support of Unix sockets ............................ 57 + 8.2 Command Parsing ......................................... 57 + 8.3 Message delivery ........................................ 57 + 8.4 Connection 'Liveness' ................................... 58 + 8.5 Establishing a server-client connection ................. 58 + 8.6 Establishing a server-server connection ................. 58 + 8.6.1 State information exchange when connecting ......... 59 + 8.7 Terminating server-client connections ................... 59 + 8.8 Terminating server-server connections ................... 59 + 8.9 Tracking nickname changes ............................... 60 + 8.10 Flood control of clients ............................... 60 + 8.11 Non-blocking lookups ................................... 61 + 8.11.1 Hostname (DNS) lookups ............................ 61 + 8.11.2 Username (Ident) lookups .......................... 61 + 8.12 Configuration file ..................................... 61 + 8.12.1 Allowing clients to connect ....................... 62 + 8.12.2 Operators ......................................... 62 + 8.12.3 Allowing servers to connect ....................... 62 + 8.12.4 Administrivia ..................................... 63 + 8.13 Channel membership ..................................... 63 + 9. Current problems ............................................ 63 + 9.1 Scalability ............................................. 63 + 9.2 Labels .................................................. 63 + 9.2.1 Nicknames .......................................... 63 + 9.2.2 Channels ........................................... 64 + 9.2.3 Servers ............................................ 64 + 9.3 Algorithms .............................................. 64 + 10. Support and availability ................................... 64 + 11. Security Considerations .................................... 65 + 12. Authors' Addresses ......................................... 65 + + + + + + + + + +Oikarinen & Reed [Page 3] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +1. INTRODUCTION + + The IRC (Internet Relay Chat) protocol has been designed over a + number of years for use with text based conferencing. This document + describes the current IRC protocol. + + The IRC protocol has been developed on systems using the TCP/IP + network protocol, although there is no requirement that this remain + the only sphere in which it operates. + + IRC itself is a teleconferencing system, which (through the use of + the client-server model) is well-suited to running on many machines + in a distributed fashion. A typical setup involves a single process + (the server) forming a central point for clients (or other servers) + to connect to, performing the required message delivery/multiplexing + and other functions. + +1.1 Servers + + The server forms the backbone of IRC, providing a point to which + clients may connect to to talk to each other, and a point for other + servers to connect to, forming an IRC network. The only network + configuration allowed for IRC servers is that of a spanning tree [see + Fig. 1] where each server acts as a central node for the rest of the + net it sees. + + + [ Server 15 ] [ Server 13 ] [ Server 14] + / \ / + / \ / + [ Server 11 ] ------ [ Server 1 ] [ Server 12] + / \ / + / \ / + [ Server 2 ] [ Server 3 ] + / \ \ + / \ \ + [ Server 4 ] [ Server 5 ] [ Server 6 ] + / | \ / + / | \ / + / | \____ / + / | \ / + [ Server 7 ] [ Server 8 ] [ Server 9 ] [ Server 10 ] + + : + [ etc. ] + : + + [ Fig. 1. Format of IRC server network ] + + + +Oikarinen & Reed [Page 4] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +1.2 Clients + + A client is anything connecting to a server that is not another + server. Each client is distinguished from other clients by a unique + nickname having a maximum length of nine (9) characters. See the + protocol grammar rules for what may and may not be used in a + nickname. In addition to the nickname, all servers must have the + following information about all clients: the real name of the host + that the client is running on, the username of the client on that + host, and the server to which the client is connected. + +1.2.1 Operators + + To allow a reasonable amount of order to be kept within the IRC + network, a special class of clients (operators) is allowed to perform + general maintenance functions on the network. Although the powers + granted to an operator can be considered as 'dangerous', they are + nonetheless required. Operators should be able to perform basic + network tasks such as disconnecting and reconnecting servers as + needed to prevent long-term use of bad network routing. In + recognition of this need, the protocol discussed herein provides for + operators only to be able to perform such functions. See sections + 4.1.7 (SQUIT) and 4.3.5 (CONNECT). + + A more controversial power of operators is the ability to remove a + user from the connected network by 'force', i.e. operators are able + to close the connection between any client and server. The + justification for this is delicate since its abuse is both + destructive and annoying. For further details on this type of + action, see section 4.6.1 (KILL). + +1.3 Channels + + A channel is a named group of one or more clients which will all + receive messages addressed to that channel. The channel is created + implicitly when the first client joins it, and the channel ceases to + exist when the last client leaves it. While channel exists, any + client can reference the channel using the name of the channel. + + Channels names are strings (beginning with a '&' or '#' character) of + length up to 200 characters. Apart from the the requirement that the + first character being either '&' or '#'; the only restriction on a + channel name is that it may not contain any spaces (' '), a control G + (^G or ASCII 7), or a comma (',' which is used as a list item + separator by the protocol). + + There are two types of channels allowed by this protocol. One is a + distributed channel which is known to all the servers that are + + + +Oikarinen & Reed [Page 5] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + connected to the network. These channels are marked by the first + character being a only clients on the server where it exists may join + it. These are distinguished by a leading '&' character. On top of + these two types, there are the various channel modes available to + alter the characteristics of individual channels. See section 4.2.3 + (MODE command) for more details on this. + + To create a new channel or become part of an existing channel, a user + is required to JOIN the channel. If the channel doesn't exist prior + to joining, the channel is created and the creating user becomes a + channel operator. If the channel already exists, whether or not your + request to JOIN that channel is honoured depends on the current modes + of the channel. For example, if the channel is invite-only, (+i), + then you may only join if invited. As part of the protocol, a user + may be a part of several channels at once, but a limit of ten (10) + channels is recommended as being ample for both experienced and + novice users. See section 8.13 for more information on this. + + If the IRC network becomes disjoint because of a split between two + servers, the channel on each side is only composed of those clients + which are connected to servers on the respective sides of the split, + possibly ceasing to exist on one side of the split. When the split + is healed, the connecting servers announce to each other who they + think is in each channel and the mode of that channel. If the + channel exists on both sides, the JOINs and MODEs are interpreted in + an inclusive manner so that both sides of the new connection will + agree about which clients are in the channel and what modes the + channel has. + +1.3.1 Channel Operators + + The channel operator (also referred to as a "chop" or "chanop") on a + given channel is considered to 'own' that channel. In recognition of + this status, channel operators are endowed with certain powers which + enable them to keep control and some sort of sanity in their channel. + As an owner of a channel, a channel operator is not required to have + reasons for their actions, although if their actions are generally + antisocial or otherwise abusive, it might be reasonable to ask an IRC + operator to intervene, or for the usersjust leave and go elsewhere + and form their own channel. + + The commands which may only be used by channel operators are: + + KICK - Eject a client from the channel + MODE - Change the channel's mode + INVITE - Invite a client to an invite-only channel (mode +i) + TOPIC - Change the channel topic in a mode +t channel + + + + +Oikarinen & Reed [Page 6] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + A channel operator is identified by the '@' symbol next to their + nickname whenever it is associated with a channel (ie replies to the + NAMES, WHO and WHOIS commands). + +2. The IRC Specification + +2.1 Overview + + The protocol as described herein is for use both with server to + server and client to server connections. There are, however, more + restrictions on client connections (which are considered to be + untrustworthy) than on server connections. + +2.2 Character codes + + No specific character set is specified. The protocol is based on a a + set of codes which are composed of eight (8) bits, making up an + octet. Each message may be composed of any number of these octets; + however, some octet values are used for control codes which act as + message delimiters. + + Regardless of being an 8-bit protocol, the delimiters and keywords + are such that protocol is mostly usable from USASCII terminal and a + telnet connection. + + Because of IRC's scandanavian origin, the characters {}| are + considered to be the lower case equivalents of the characters []\, + respectively. This is a critical issue when determining the + equivalence of two nicknames. + +2.3 Messages + + Servers and clients send eachother messages which may or may not + generate a reply. If the message contains a valid command, as + described in later sections, the client should expect a reply as + specified but it is not advised to wait forever for the reply; client + to server and server to server communication is essentially + asynchronous in nature. + + Each IRC message may consist of up to three main parts: the prefix + (optional), the command, and the command parameters (of which there + may be up to 15). The prefix, command, and all parameters are + separated by one (or more) ASCII space character(s) (0x20). + + The presence of a prefix is indicated with a single leading ASCII + colon character (':', 0x3b), which must be the first character of the + message itself. There must be no gap (whitespace) between the colon + and the prefix. The prefix is used by servers to indicate the true + + + +Oikarinen & Reed [Page 7] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + origin of the message. If the prefix is missing from the message, it + is assumed to have originated from the connection from which it was + received. Clients should not use prefix when sending a message from + themselves; if they use a prefix, the only valid prefix is the + registered nickname associated with the client. If the source + identified by the prefix cannot be found from the server's internal + database, or if the source is registered from a different link than + from which the message arrived, the server must ignore the message + silently. + + The command must either be a valid IRC command or a three (3) digit + number represented in ASCII text. + + IRC messages are always lines of characters terminated with a CR-LF + (Carriage Return - Line Feed) pair, and these messages shall not + exceed 512 characters in length, counting all characters including + the trailing CR-LF. Thus, there are 510 characters maximum allowed + for the command and its parameters. There is no provision for + continuation message lines. See section 7 for more details about + current implementations. + +2.3.1 Message format in 'pseudo' BNF + + The protocol messages must be extracted from the contiguous stream of + octets. The current solution is to designate two characters, CR and + LF, as message separators. Empty messages are silently ignored, + which permits use of the sequence CR-LF between messages + without extra problems. + + The extracted message is parsed into the components , + and list of parameters matched either by or + components. + + The BNF representation for this is: + + + ::= + ::= [':' ] + ::= | [ '!' ] [ '@' ] + ::= { } | + ::= ' ' { ' ' } + ::= [ ':' | ] + ::= { | | '[' | ']' } + + ::= + ::= + + ::= CR LF + + + +Oikarinen & Reed [Page 8] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +NOTES: + + 1) is consists only of SPACE character(s) (0x20). + Specially notice that TABULATION, and all other control + characters are considered NON-WHITE-SPACE. + + 2) After extracting the parameter list, all parameters are equal, + whether matched by or . is just + a syntactic trick to allow SPACE within parameter. + + 3) The fact that CR and LF cannot appear in parameter strings is + just artifact of the message framing. This might change later. + + 4) The NUL character is not special in message framing, and + basically could end up inside a parameter, but as it would + cause extra complexities in normal C string handling. Therefore + NUL is not allowed within messages. + + 5) The last parameter may be an empty string. + + 6) Use of the extended prefix (['!' ] ['@' ]) must + not be used in server to server communications and is only + intended for server to client messages in order to provide + clients with more useful information about who a message is + from without the need for additional queries. + + Most protocol messages specify additional semantics and syntax for + the extracted parameter strings dictated by their position in the + list. For example, many server commands will assume that the first + parameter after the command is the list of targets, which can be + described with: + + ::= [ "," ] + ::= | '@' | | + ::= ('#' | '&' | '+') + ::= + ::= see RFC 952 [DNS:4] for details on allowed hostnames + ::= { | | } + ::= $( | @) + ::= + + Other parameter syntaxes are: + + ::= { } + ::= 'a' ... 'z' | 'A' ... 'Z' + ::= '0' ... '9' + ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}' + + + +Oikarinen & Reed [Page 9] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + ::= + +2.4 Numeric replies + + Most of the messages sent to the server generate a reply of some + sort. The most common reply is the numeric reply, used for both + errors and normal replies. The numeric reply must be sent as one + message consisting of the sender prefix, the three digit numeric, and + the target of the reply. A numeric reply is not allowed to originate + from a client; any such messages received by a server are silently + dropped. In all other respects, a numeric reply is just like a normal + message, except that the keyword is made up of 3 numeric digits + rather than a string of letters. A list of different replies is + supplied in section 6. + +3. IRC Concepts. + + This section is devoted to describing the actual concepts behind the + organization of the IRC protocol and how the current + implementations deliver different classes of messages. + + + + 1--\ + A D---4 + 2--/ \ / + B----C + / \ + 3 E + + Servers: A, B, C, D, E Clients: 1, 2, 3, 4 + + [ Fig. 2. Sample small IRC network ] + +3.1 One-to-one communication + + Communication on a one-to-one basis is usually only performed by + clients, since most server-server traffic is not a result of servers + talking only to each other. To provide a secure means for clients to + talk to each other, it is required that all servers be able to send a + message in exactly one direction along the spanning tree in order to + reach any client. The path of a message being delivered is the + shortest path between any two points on the spanning tree. + + The following examples all refer to Figure 2 above. + + + + + +Oikarinen & Reed [Page 10] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +Example 1: + A message between clients 1 and 2 is only seen by server A, which + sends it straight to client 2. + +Example 2: + A message between clients 1 and 3 is seen by servers A & B, and + client 3. No other clients or servers are allowed see the message. + +Example 3: + A message between clients 2 and 4 is seen by servers A, B, C & D + and client 4 only. + +3.2 One-to-many + + The main goal of IRC is to provide a forum which allows easy and + efficient conferencing (one to many conversations). IRC offers + several means to achieve this, each serving its own purpose. + +3.2.1 To a list + + The least efficient style of one-to-many conversation is through + clients talking to a 'list' of users. How this is done is almost + self explanatory: the client gives a list of destinations to which + the message is to be delivered and the server breaks it up and + dispatches a separate copy of the message to each given destination. + This isn't as efficient as using a group since the destination list + is broken up and the dispatch sent without checking to make sure + duplicates aren't sent down each path. + +3.2.2 To a group (channel) + + In IRC the channel has a role equivalent to that of the multicast + group; their existence is dynamic (coming and going as people join + and leave channels) and the actual conversation carried out on a + channel is only sent to servers which are supporting users on a given + channel. If there are multiple users on a server in the same + channel, the message text is sent only once to that server and then + sent to each client on the channel. This action is then repeated for + each client-server combination until the original message has fanned + out and reached each member of the channel. + + The following examples all refer to Figure 2. + +Example 4: + Any channel with 1 client in it. Messages to the channel go to the + server and then nowhere else. + + + + + +Oikarinen & Reed [Page 11] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +Example 5: + 2 clients in a channel. All messages traverse a path as if they + were private messages between the two clients outside a channel. + +Example 6: + Clients 1, 2 and 3 in a channel. All messages to the channel are + sent to all clients and only those servers which must be traversed + by the message if it were a private message to a single client. If + client 1 sends a message, it goes back to client 2 and then via + server B to client 3. + +3.2.3 To a host/server mask + + To provide IRC operators with some mechanism to send messages to a + large body of related users, host and server mask messages are + provided. These messages are sent to users whose host or server + information match that of the mask. The messages are only sent to + locations where users are, in a fashion similar to that of channels. + +3.3 One-to-all + + The one-to-all type of message is better described as a broadcast + message, sent to all clients or servers or both. On a large network + of users and servers, a single message can result in a lot of traffic + being sent over the network in an effort to reach all of the desired + destinations. + + For some messages, there is no option but to broadcast it to all + servers so that the state information held by each server is + reasonably consistent between servers. + +3.3.1 Client-to-Client + + There is no class of message which, from a single message, results in + a message being sent to every other client. + +3.3.2 Client-to-Server + + Most of the commands which result in a change of state information + (such as channel membership, channel mode, user status, etc) must be + sent to all servers by default, and this distribution may not be + changed by the client. + +3.3.3 Server-to-Server. + + While most messages between servers are distributed to all 'other' + servers, this is only required for any message that affects either a + user, channel or server. Since these are the basic items found in + + + +Oikarinen & Reed [Page 12] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + IRC, nearly all messages originating from a server are broadcast to + all other connected servers. + +4. Message details + + On the following pages are descriptions of each message recognized by + the IRC server and client. All commands described in this section + must be implemented by any server for this protocol. + + Where the reply ERR_NOSUCHSERVER is listed, it means that the + parameter could not be found. The server must not send any + other replies after this for that command. + + The server to which a client is connected is required to parse the + complete message, returning any appropriate errors. If the server + encounters a fatal error while parsing a message, an error must be + sent back to the client and the parsing terminated. A fatal error + may be considered to be incorrect command, a destination which is + otherwise unknown to the server (server, nick or channel names fit + this category), not enough parameters or incorrect privileges. + + If a full set of parameters is presented, then each must be checked + for validity and appropriate responses sent back to the client. In + the case of messages which use parameter lists using the comma as an + item separator, a reply must be sent for each item. + + In the examples below, some messages appear using the full format: + + :Name COMMAND parameter list + + Such examples represent a message from "Name" in transit between + servers, where it is essential to include the name of the original + sender of the message so remote servers may send back a reply along + the correct path. + +4.1 Connection Registration + + The commands described here are used to register a connection with an + IRC server as either a user or a server as well as correctly + disconnect. + + A "PASS" command is not required for either client or server + connection to be registered, but it must precede the server message + or the latter of the NICK/USER combination. It is strongly + recommended that all server connections have a password in order to + give some level of security to the actual connections. The + recommended order for a client to register is as follows: + + + + +Oikarinen & Reed [Page 13] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 1. Pass message + 2. Nick message + 3. User message + +4.1.1 Password message + + + Command: PASS + Parameters: + + The PASS command is used to set a 'connection password'. The + password can and must be set before any attempt to register the + connection is made. Currently this requires that clients send a PASS + command before sending the NICK/USER combination and servers *must* + send a PASS command before any SERVER command. The password supplied + must match the one contained in the C/N lines (for servers) or I + lines (for clients). It is possible to send multiple PASS commands + before registering but only the last one sent is used for + verification and it may not be changed once registered. Numeric + Replies: + + ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED + + Example: + + PASS secretpasswordhere + +4.1.2 Nick message + + Command: NICK + Parameters: [ ] + + NICK message is used to give user a nickname or change the previous + one. The parameter is only used by servers to indicate + how far away a nick is from its home server. A local connection has + a hopcount of 0. If supplied by a client, it must be ignored. + + If a NICK message arrives at a server which already knows about an + identical nickname for another client, a nickname collision occurs. + As a result of a nickname collision, all instances of the nickname + are removed from the server's database, and a KILL command is issued + to remove the nickname from all other server's database. If the NICK + message causing the collision was a nickname change, then the + original (old) nick must be removed as well. + + If the server recieves an identical NICK from a client which is + directly connected, it may issue an ERR_NICKCOLLISION to the local + client, drop the NICK command, and not generate any kills. + + + +Oikarinen & Reed [Page 14] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + Numeric Replies: + + ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME + ERR_NICKNAMEINUSE ERR_NICKCOLLISION + + Example: + + NICK Wiz ; Introducing new nick "Wiz". + + :WiZ NICK Kilroy ; WiZ changed his nickname to Kilroy. + +4.1.3 User message + + Command: USER + Parameters: + + The USER message is used at the beginning of connection to specify + the username, usermod, snomask and information of a new user. Servers + use the NICK command to send all information once USER and NICK have + been received from the client. Only after both USER and NICK have been + received from a client does a user become registered. + + Undernet does not send USER between servers, NICK is used to send + all information about a user. The usermode parameter allows clients to + set their initial user mode (see MODE) upon registration, the snomask + parameter allows the user to specify a specific set of server notices + they wish to receive. If the usermode and snomasks look like host names + they are ignored. If a valid ident response is received from the + client's host upon connection, the name returned from the ident server + is used and username is ignored. + + It must be noted that info parameter must be the last parameter, + because it may contain space characters and must be prefixed with a + colon (':') to make sure this is recognised as such. + + Since it is easy for a client to lie about its username by relying + solely on the USER message, the use of an "Identity Server" is + recommended. If the host which a user connects from has such a + server enabled the username is set to that as in the reply from the + "Identity Server". + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED + + Examples: + + + USER guest tolmoon tolsun :Ronnie Reagan + + + +Oikarinen & Reed [Page 15] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + ; User registering themselves with a + username of "guest" and real name + "Ronnie Reagan". + + + :testnick USER guest tolmoon tolsun :Ronnie Reagan + ; message between servers with the + nickname for which the USER command + belongs to + +4.1.4 Server message + + Command: SERVER + Parameters: + + The server message is used to tell a server that the other end of a + new connection is a server. This message is also used to pass server + data over whole net. When a new server is connected to net, + information about it be broadcast to the whole network. + is used to give all servers some internal information on how far away + all servers are. With a full server list, it would be possible to + construct a map of the entire server tree, but hostmasks prevent this + from being done. + + The SERVER message must only be accepted from either (a) a connection + which is yet to be registered and is attempting to register as a + server, or (b) an existing connection to another server, in which + case the SERVER message is introducing a new server behind that + server. + + Most errors that occur with the receipt of a SERVER command result in + the connection being terminated by the destination host (target + SERVER). Error replies are usually sent using the "ERROR" command + rather than the numeric since the ERROR command has several useful + properties which make it useful here. + + If a SERVER message is parsed and attempts to introduce a server + which is already known to the receiving server, the connection from + which that message must be closed (following the correct procedures), + since a duplicate route to a server has formed and the acyclic nature + of the IRC tree broken. + + Numeric Replies: + + ERR_ALREADYREGISTRED + + Example: + + + + +Oikarinen & Reed [Page 16] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server + ; New server test.oulu.fi introducing + itself and attempting to register. The + name in []'s is the hostname for the + host running test.oulu.fi. + + +:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server + ; Server tolsun.oulu.fi is our uplink + for csd.bu.edu which is 5 hops away. + +4.1.5 Oper + + Command: OPER + Parameters: + + OPER message is used by a normal user to obtain operator privileges. + The combination of and are required to gain + Operator privileges. + + If the client sending the OPER command supplies the correct password + for the given user, the server then informs the rest of the network + of the new operator by issuing a "MODE +o" for the clients nickname. + + The OPER message is client-server only. + + Numeric Replies: + + ERR_NEEDMOREPARAMS RPL_YOUREOPER + ERR_NOOPERHOST ERR_PASSWDMISMATCH + + Example: + + OPER foo bar ; Attempt to register as an operator + using a username of "foo" and "bar" as + the password. + +4.1.6 Quit + + Command: QUIT + Parameters: [] + + A client session is ended with a quit message. The server must close + the connection to a client which sends a QUIT message. If a "Quit + Message" is given, this will be sent instead of the default message, + the nickname. + + When netsplits (disconnecting of two servers) occur, the quit message + + + +Oikarinen & Reed [Page 17] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + is composed of the names of two servers involved, separated by a + space. The first name is that of the server which is still connected + and the second name is that of the server that has become + disconnected. + + If, for some other reason, a client connection is closed without the + client issuing a QUIT command (e.g. client dies and EOF occurs + on socket), the server is required to fill in the quit message with + some sort of message reflecting the nature of the event which + caused it to happen. + + Numeric Replies: + + None. + + Examples: + + QUIT :Gone to have lunch ; Preferred message format. + +4.1.7 Server quit message + + Command: SQUIT + Parameters: + + The SQUIT message is needed to tell about quitting or dead servers. + If a server wishes to break the connection to another server it must + send a SQUIT message to the other server, using the the name of the + other server as the server parameter, which then closes its + connection to the quitting server. + + This command is also available operators to help keep a network of + IRC servers connected in an orderly fashion. Operators may also + issue an SQUIT message for a remote server connection. In this case, + the SQUIT must be parsed by each server inbetween the operator and + the remote server, updating the view of the network held by each + server as explained below. + + The should be supplied by all operators who execute a SQUIT + for a remote server (that is not connected to the server they are + currently on) so that other operators are aware for the reason of + this action. The is also filled in by servers which may + place an error or similar message here. + + Both of the servers which are on either side of the connection being + closed are required to to send out a SQUIT message (to all its other + server connections) for all other servers which are considered to be + behind that link. + + + + +Oikarinen & Reed [Page 18] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + Similarly, a QUIT message must be sent to the other connected servers + rest of the network on behalf of all clients behind that link. In + addition to this, all channel members of a channel which lost a + member due to the split must be sent a QUIT message. + + If a server connection is terminated prematurely (e.g. the server on + the other end of the link died), the server which detects + this disconnection is required to inform the rest of the network + that the connection has closed and fill in the comment field + with something appropriate. + + Numeric replies: + + ERR_NOPRIVILEGES ERR_NOSUCHSERVER + + Example: + + SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi has + been terminated because of "Bad Link". + + :Trillian SQUIT cm22.eng.umd.edu :Server out of control + ; message from Trillian to disconnect + "cm22.eng.umd.edu" from the net + because "Server out of control". + +4.2 Channel operations + + This group of messages is concerned with manipulating channels, their + properties (channel modes), and their contents (typically clients). + In implementing these, a number of race conditions are inevitable + when clients at opposing ends of a network send commands which will + ultimately clash. It is also required that servers keep a nickname + history to ensure that wherever a parameter is given, the + server check its history in case it has recently been changed. + +4.2.1 Join message + + Command: JOIN + Parameters: {,} [{,}] + + The JOIN command is used by client to start listening a specific + channel. Whether or not a client is allowed to join a channel is + checked only by the server the client is connected to; all other + servers automatically add the user to the channel when it is received + from other servers. The conditions which affect this are as follows: + + 1. the user must be invited if the channel is invite-only; + + + + +Oikarinen & Reed [Page 19] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 2. the user's nick/username/hostname must not match any + active bans; + + 3. the correct key (password) must be given if it is set. + + These are discussed in more detail under the MODE command (see + section 4.2.3 for more details). + + Once a user has joined a channel, they receive notice about all + commands their server receives which affect the channel. This + includes MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE. The + JOIN command needs to be broadcast to all servers so that each server + knows where to find the users who are on the channel. This allows + optimal delivery of PRIVMSG/NOTICE messages to the channel. + + If a JOIN is successful, the user is then sent the channel's topic + (using RPL_TOPIC) and the list of users who are on the channel (using + RPL_NAMREPLY), which must include the user joining. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN + ERR_INVITEONLYCHAN ERR_BADCHANNELKEY + ERR_CHANNELISFULL ERR_BADCHANMASK + ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS + RPL_TOPIC + + Examples: + + JOIN #foobar ; join channel #foobar. + + JOIN &foo fubar ; join channel &foo using key "fubar". + + JOIN #foo,&bar fubar ; join channel #foo using key "fubar" + and &bar using no key. + + JOIN #foo,#bar fubar,foobar ; join channel #foo using key "fubar". + and channel #bar using key "foobar". + + JOIN #foo,#bar ; join channels #foo and #bar. + + :WiZ JOIN #Twilight_zone ; JOIN message from WiZ + +4.2.2 Part message + + Command: PART + Parameters: {,} + + + + +Oikarinen & Reed [Page 20] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + The PART message causes the client sending the message to be removed + from the list of active users for all given channels listed in the + parameter string. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL + ERR_NOTONCHANNEL + + Examples: + + PART #twilight_zone ; leave channel "#twilight_zone" + + PART #oz-ops,&group5 ; leave both channels "&group5" and + "#oz-ops". + +4.2.3 Mode message + + Command: MODE + + The MODE command is a dual-purpose command in IRC. It allows both + usernames and channels to have their mode changed. The rationale for + this choice is that one day nicknames will be obsolete and the + equivalent property will be the channel. + + When parsing MODE messages, it is recommended that the entire message + be parsed first and then the changes which resulted then passed on. + +4.2.3.1 Channel modes + + Parameters: {[+|-]|o|p|s|i|t|n|b|v} [] [] + [] + + The MODE command is provided so that channel operators may change the + characteristics of `their' channel. It is also required that servers + be able to change channel modes so that channel operators may be + created. + + The various modes available for channels are as follows: + + o - give/take channel operator privileges; + p - private channel flag; + s - secret channel flag; + i - invite-only channel flag; + t - topic settable by channel operator only flag; + n - no messages to channel from clients on the outside; + m - moderated channel; + l - set the user limit to channel; + + + +Oikarinen & Reed [Page 21] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + b - set a ban mask to keep users out; + v - give/take the ability to speak on a moderated channel; + k - set a channel key (password). + + When using the 'o' and 'b' options, a restriction on a total of three + per mode command has been imposed. That is, any combination of 'o' + and + +4.2.3.2 User modes + + Parameters: {[+|-]|i|w|s|o} + + The user MODEs are typically changes which affect either how the + client is seen by others or what 'extra' messages the client is sent. + A user MODE command may only be accepted if both the sender of the + message and the nickname given as a parameter are both the same. + + The available modes are as follows: + + i - marks a users as invisible; + s - marks a user for receipt of server notices; + w - user receives wallops; + o - operator flag. + + Additional modes may be available later on. + + If a user attempts to make themselves an operator using the "+o" + flag, the attempt should be ignored. There is no restriction, + however, on anyone `deopping' themselves (using "-o"). Numeric + Replies: + + ERR_NEEDMOREPARAMS RPL_CHANNELMODEIS + ERR_CHANOPRIVSNEEDED ERR_NOSUCHNICK + ERR_NOTONCHANNEL ERR_KEYSET + RPL_BANLIST RPL_ENDOFBANLIST + ERR_UNKNOWNMODE ERR_NOSUCHCHANNEL + + ERR_USERSDONTMATCH RPL_UMODEIS + ERR_UMODEUNKNOWNFLAG + + Examples: + + Use of Channel Modes: + +MODE #Finnish +im ; Makes #Finnish channel moderated and + 'invite-only'. + +MODE #Finnish +o Kilroy ; Gives 'chanop' privileges to Kilroy on + + + +Oikarinen & Reed [Page 22] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + channel #Finnish. + +MODE #Finnish +v Wiz ; Allow WiZ to speak on #Finnish. + +MODE #Fins -s ; Removes 'secret' flag from channel + #Fins. + +MODE #42 +k oulu ; Set the channel key to "oulu". + +MODE #eu-opers +l 10 ; Set the limit for the number of users + on channel to 10. + +MODE &oulu +b ; list ban masks set for channel. + +MODE &oulu +b *!*@* ; prevent all users from joining. + +MODE &oulu +b *!*@*.edu ; prevent any user from a hostname + matching *.edu from joining. + + Use of user Modes: + +:MODE WiZ -w ; turns reception of WALLOPS messages + off for WiZ. + +:Angel MODE Angel +i ; Message from Angel to make themselves + invisible. + +MODE WiZ -o ; WiZ 'deopping' (removing operator + status). The plain reverse of this + command ("MODE WiZ +o") must not be + allowed from users since would bypass + the OPER command. + +4.2.4 Topic message + + Command: TOPIC + Parameters: [] + + The TOPIC message is used to change or view the topic of a channel. + The topic for channel is returned if there is no + given. If the parameter is present, the topic for that + channel will be changed, if the channel modes permit this action. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL + RPL_NOTOPIC RPL_TOPIC + ERR_CHANOPRIVSNEEDED + + + +Oikarinen & Reed [Page 23] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + Examples: + + :Wiz TOPIC #test :New topic ;User Wiz setting the topic. + + TOPIC #test :another topic ;set the topic on #test to "another + topic". + + TOPIC #test ; check the topic for #test. + +4.2.5 Names message + + Command: NAMES + Parameters: [{,}] + + By using the NAMES command, a user can list all nicknames that are + visible to them on any channel that they can see. Channel names + which they can see are those which aren't private (+p) or secret (+s) + or those which they are actually on. The parameter + specifies which channel(s) to return information about if valid. + There is no error reply for bad channel names. + + If no parameter is given, a list of all channels and their + occupants is returned. At the end of this list, a list of users who + are visible but either not on any channel or not on a visible channel + are listed as being on `channel' "*". + + Numerics: + + RPL_NAMREPLY RPL_ENDOFNAMES + + Examples: + + NAMES #twilight_zone,#42 ; list visible users on #twilight_zone + and #42 if the channels are visible to + you. + + NAMES ; list all visible channels and users + +4.2.6 List message + + Command: LIST + Parameters: [{,} []] + + The list message is used to list channels and their topics. If the + parameter is used, only the status of that channel + is displayed. Private channels are listed (without their + topics) as channel "Prv" unless the client generating the query is + actually on that channel. Likewise, secret channels are not listed + + + +Oikarinen & Reed [Page 24] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + at all unless the client is a member of the channel in question. + + Numeric Replies: + + ERR_NOSUCHSERVER RPL_LISTSTART + RPL_LIST RPL_LISTEND + + Examples: + + LIST ; List all channels. + + LIST #twilight_zone,#42 ; List channels #twilight_zone and #42 + +4.2.7 Invite message + + Command: INVITE + Parameters: + + The INVITE message is used to invite users to a channel. The + parameter is the nickname of the person to be invited to + the target channel . There is no requirement that the + channel the target user is being invited to must exist or be a valid + channel. To invite a user to a channel which is invite only (MODE + +i), the client sending the invite must be recognised as being a + channel operator on the given channel. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_NOSUCHNICK + ERR_NOTONCHANNEL ERR_USERONCHANNEL + ERR_CHANOPRIVSNEEDED + RPL_INVITING RPL_AWAY + + Examples: + + :Angel INVITE Wiz #Dust ; User Angel inviting WiZ to channel + #Dust + + INVITE Wiz #Twilight_Zone ; Command to invite WiZ to + #Twilight_zone + +4.2.8 Kick command + + Command: KICK + Parameters: [] + + The KICK command can be used to forcibly remove a user from a + channel. It 'kicks them out' of the channel (forced PART). + + + +Oikarinen & Reed [Page 25] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + Only a channel operator may kick another user out of a channel. + Each server that receives a KICK message checks that it is valid + (ie the sender is actually a channel operator) before removing + the victim from the channel. + + Numeric Replies: + + ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL + ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED + ERR_NOTONCHANNEL + + Examples: + +KICK &Melbourne Matthew ; Kick Matthew from &Melbourne + +KICK #Finnish John :Speaking English + ; Kick John from #Finnish using + "Speaking English" as the reason + (comment). + +:WiZ KICK #Finnish John ; KICK message from WiZ to remove John + from channel #Finnish + +NOTE: + It is possible to extend the KICK command parameters to the +following: + +{,} {,} [] + +4.3 Server queries and commands + + The server query group of commands has been designed to return + information about any server which is connected to the network. All + servers connected must respond to these queries and respond + correctly. Any invalid response (or lack thereof) must be considered + a sign of a broken server and it must be disconnected/disabled as + soon as possible until the situation is remedied. + + In these queries, where a parameter appears as "", it will + usually mean it can be a nickname or a server or a wildcard name of + some sort. For each parameter, however, only one query and set of + replies is to be generated. + +4.3.1 Version message + + Command: VERSION + Parameters: [] + + + + +Oikarinen & Reed [Page 26] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + The VERSION message is used to query the version of the server + program. An optional parameter is used to query the version + of the server program which a client is not directly connected to. + + Numeric Replies: + + ERR_NOSUCHSERVER RPL_VERSION + + Examples: + + :Wiz VERSION *.se ; message from Wiz to check the version + of a server matching "*.se" + + VERSION tolsun.oulu.fi ; check the version of server + "tolsun.oulu.fi". + +4.3.2 Stats message + + Command: STATS + Parameters: [ []] + + Many stats commands are only available to opers, please document + which ones are available to users and which are available to opers. + + The stats message is used to query statistics of certain server. If + parameter is omitted, only the end of stats reply is sent + back. The implementation of this command is highly dependent on the + server which replies, although the server must be able to supply + information as described by the queries below (or similar). + + A query may be given by any single letter which is only checked by + the destination server (if given as the parameter) and is + otherwise passed on by intermediate servers, ignored and unaltered. + The following queries are those found in the current IRC + implementation and provide a large portion of the setup information + for that server. Although these may not be supported in the same way + by other versions, all servers should be able to supply a valid reply + to a STATS query which is consistent with the reply formats currently + used and the purpose of the query. + + The currently supported queries are: + + c - returns a list of servers which the server may connect + to or allow connections from; + h - returns a list of servers which are either forced to be + treated as leaves or allowed to act as hubs; + i - returns a list of hosts which the server allows a client + to connect from; + k - returns a list of banned username/hostname combinations + for that server; + l - returns a list of the server's connections, showing how + + + +Oikarinen & Reed [Page 27] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + long each connection has been established and the traffic + over that connection in bytes and messages for each + direction; + m - returns a list of commands supported by the server and + the usage count for each if the usage count is non zero; + o - returns a list of hosts from which normal clients may + become operators; + y - show Y (Class) lines from server's configuration file; + u - returns a string showing how long the server has been up. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_STATSCLINE RPL_STATSNLINE + RPL_STATSILINE RPL_STATSKLINE + RPL_STATSQLINE RPL_STATSLLINE + RPL_STATSLINKINFO RPL_STATSUPTIME + RPL_STATSCOMMANDS RPL_STATSOLINE + RPL_STATSHLINE RPL_ENDOFSTATS + + Examples: + +STATS m ; check the command usage for the server + you are connected to + +:Wiz STATS c eff.org ; request by WiZ for C/N line + information from server eff.org + +4.3.3 Links message + + Command: LINKS + Parameters: [[] ] + + With LINKS, a user can list all servers which are known by the server + answering the query. The returned list of servers must match the + mask, or if no mask is given, the full list is returned. + + If is given in addition to , the LINKS + command is forwarded to the first server found that matches that name + (if any), and that server is then required to answer the query. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_LINKS RPL_ENDOFLINKS + + Examples: + + + + +Oikarinen & Reed [Page 28] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +LINKS *.au ; list all servers which have a name + that matches *.au; + +:WiZ LINKS *.bu.edu *.edu ; LINKS message from WiZ to the first + server matching *.edu for a list of + servers matching *.bu.edu. + +4.3.4 Time message + + Command: TIME + Parameters: [] + + The time message is used to query local time from the specified + server. If the server parameter is not given, the server handling the + command must reply to the query. + + Numeric Replies: + + ERR_NOSUCHSERVER RPL_TIME + + Examples: + + TIME tolsun.oulu.fi ; check the time on the server + "tolson.oulu.fi" + + Angel TIME *.au ; user angel checking the time on a + server matching "*.au" + +4.3.5 Connect message + + Command: CONNECT + Parameters: [ []] + + The CONNECT command can be used to force a server to try to establish + a new connection to another server immediately. CONNECT is a + privileged command and is to be available only to IRC Operators. If + a remote server is given then the CONNECT attempt is made by that + server to and . + + Numeric Replies: + + ERR_NOSUCHSERVER ERR_NOPRIVILEGES + ERR_NEEDMOREPARAMS + + Examples: + +CONNECT tolsun.oulu.fi ; Attempt to connect a server to + tolsun.oulu.fi + + + +Oikarinen & Reed [Page 29] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +:WiZ CONNECT eff.org 6667 csd.bu.edu + ; CONNECT attempt by WiZ to get servers + eff.org and csd.bu.edu connected on port + 6667. + +4.3.6 Trace message + + Command: TRACE + Parameters: [] + + TRACE command is used to find the route to specific server. Each + server that processes this message must tell the sender about it by + sending a reply indicating it is a pass-through link, forming a chain + of replies similar to that gained from using "traceroute". After + sending this reply back, it must then send the TRACE message to the + next server until given server is reached. If the parameter + is omitted, it is recommended that TRACE command send a message to + the sender telling which servers the current server has direct + connection to. + + If the destination given by "" is an actual server, then the + destination server is required to report all servers and users which + are connected to it, although only operators are permitted to see + users present. If the destination given by is a nickname, + they only a reply for that nickname is given. + + Numeric Replies: + + ERR_NOSUCHSERVER + + If the TRACE message is destined for another server, all intermediate + servers must return a RPL_TRACELINK reply to indicate that the TRACE + passed through it and where its going next. + + RPL_TRACELINK + A TRACE reply may be composed of any number of the following numeric + replies. + + RPL_TRACECONNECTING RPL_TRACEHANDSHAKE + RPL_TRACEUNKNOWN RPL_TRACEOPERATOR + RPL_TRACEUSER RPL_TRACESERVER + RPL_TRACESERVICE RPL_TRACENEWTYPE + RPL_TRACECLASS + + Examples: + +TRACE *.oulu.fi ; TRACE to a server matching *.oulu.fi + + + + +Oikarinen & Reed [Page 30] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +:WiZ TRACE AngelDust ; TRACE issued by WiZ to nick AngelDust + +4.3.7 Admin command + + Command: ADMIN + Parameters: [] + + The admin message is used to find the name of the administrator of + the given server, or current server if parameter is omitted. + Each server must have the ability to forward ADMIN messages to other + servers. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_ADMINME RPL_ADMINLOC1 + RPL_ADMINLOC2 RPL_ADMINEMAIL + + Examples: + + ADMIN tolsun.oulu.fi ; request an ADMIN reply from + tolsun.oulu.fi + + :WiZ ADMIN *.edu ; ADMIN request from WiZ for first + server found to match *.edu. + +4.3.8 Info command + + Command: INFO + Parameters: [] + + The INFO command is required to return information which describes + the server: its version, when it was compiled, the patchlevel, when + it was started, and any other miscellaneous information which may be + considered to be relevant. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_INFO RPL_ENDOFINFO + + Examples: + + INFO csd.bu.edu ; request an INFO reply from + csd.bu.edu + + :Avalon INFO *.fi ; INFO request from Avalon for first + server found to match *.fi. + + + +Oikarinen & Reed [Page 31] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + INFO Angel ; request info from the server that + Angel is connected to. + +4.4 Sending messages + + The main purpose of the IRC protocol is to provide a base for clients + to communicate with each other. PRIVMSG and NOTICE are the only + messages available which actually perform delivery of a text message + from one client to another - the rest just make it possible and try + to ensure it happens in a reliable and structured manner. + +4.4.1 Private messages + + Command: PRIVMSG + Parameters: {,} + + PRIVMSG is used to send private messages between users. + is the nickname of the receiver of the message. can also + be a list of names or channels separated with commas. + + The parameter may also me a host mask ($@mask) or server + mask ($mask). In both cases the server will only send the PRIVMSG + to those who have a server or host matching the mask. The mask must + have at least 1 (one) "." in it and no wildcards following the + last ".". This requirement exists to prevent people sending messages + to "$@*" or "$*", which would broadcast to all users; from + experience, this is abused more than used responsibly and properly. + Wildcards are the '*' and '?' characters. This extension to + the PRIVMSG command is only available to Operators. + + Numeric Replies: + + ERR_NORECIPIENT ERR_NOTEXTTOSEND + ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL + ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS + ERR_NOSUCHNICK + RPL_AWAY + + Examples: + +:Angel PRIVMSG Wiz :Hello are you receiving this message ? + ; Message from Angel to Wiz. + +PRIVMSG Angel :yes I'm receiving it !receiving it !'u>(768u+1n) .br ; + Message to Angel. + +PRIVMSG jto@tolsun.oulu.fi :Hello ! + ; Message to a client on server + + + +Oikarinen & Reed [Page 32] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + tolsun.oulu.fi with username of "jto". + +PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting. + ; Message to everyone on a server which + has a name matching *.fi. + +PRIVMSG $@*.edu :NSFNet is undergoing work, expect interruptions + ; Message to all users who come from a + host which has a name matching *.edu. + +4.4.2 Notice + + Command: NOTICE + Parameters: + + The NOTICE message is used similarly to PRIVMSG. The difference + between NOTICE and PRIVMSG is that automatic replies must never be + sent in response to a NOTICE message. This rule applies to servers + too - they must not send any error reply back to the client on + receipt of a notice. The object of this rule is to avoid loops + between a client automatically sending something in response to + something it received. This is typically used by automatons (clients + with either an AI or other interactive program controlling their + actions) which are always seen to be replying lest they end up in a + loop with another automaton. + + See PRIVMSG for more details on replies and examples. + +4.5 User based queries + + User queries are a group of commands which are primarily concerned + with finding details on a particular user or group users. When using + wildcards with any of these commands, if they match, they will only + return information on users who are 'visible' to you. The visibility + of a user is determined as a combination of the user's mode and the + common set of channels you are both on. + +4.5.1 Who query + + Command: WHO + Parameters: [ []] + + The WHO message is used by a client to generate a query which returns + a list of information which 'matches' the parameter given by + the client. In the absence of the parameter, all visible + (users who aren't invisible (user mode +i) and who don't have a + common channel with the requesting client) are listed. The same + result can be achieved by using a of "0" or any wildcard which + + + +Oikarinen & Reed [Page 33] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + will end up matching every entry possible. + + The passed to WHO is matched against users' host, server, real + name and nickname if the channel cannot be found. + + If the "o" parameter is passed only operators are returned according + to the name mask supplied. + + Numeric Replies: + + ERR_NOSUCHSERVER + RPL_WHOREPLY RPL_ENDOFWHO + + Examples: + + WHO *.fi ; List all users who match against + "*.fi". + + WHO jto* o ; List all users with a match against + "jto*" if they are an operator. + +4.5.2 Whois query + + Command: WHOIS + Parameters: [] [,[,...]] + + This message is used to query information about particular user. The + server will answer this message with several numeric messages + indicating different statuses of each user which matches the nickmask + (if you are entitled to see them). If no wildcard is present in the + , any information about that nick which you are allowed to + see is presented. A comma (',') separated list of nicknames may be + given. + + The latter version sends the query to a specific server. It is + useful if you want to know how long the user in question has been + idle as only local server (ie. the server the user is directly + connected to) knows that information, while everything else is + globally known. + + Numeric Replies: + + ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN + RPL_WHOISUSER RPL_WHOISCHANNELS + RPL_WHOISCHANNELS RPL_WHOISSERVER + RPL_AWAY RPL_WHOISOPERATOR + RPL_WHOISIDLE ERR_NOSUCHNICK + RPL_ENDOFWHOIS + + + +Oikarinen & Reed [Page 34] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + Examples: + + WHOIS wiz ; return available user information + about nick WiZ + + WHOIS eff.org trillian ; ask server eff.org for user + information about trillian + +4.5.3 Whowas + + Command: WHOWAS + Parameters: [ []] + + Whowas asks for information about a nickname which no longer exists. + This may either be due to a nickname change or the user leaving IRC. + In response to this query, the server searches through its nickname + history, looking for any nicks which are lexically the same (no wild + card matching here). The history is searched backward, returning the + most recent entry first. If there are multiple entries, up to + replies will be returned (or all of them if no + parameter is given). If a non-positive number is passed as being + , then a full search is done. + + Numeric Replies: + + ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK + RPL_WHOWASUSER RPL_WHOISSERVER + RPL_ENDOFWHOWAS + + Examples: + + WHOWAS Wiz ; return all information in the nick + history about nick "WiZ"; + + WHOWAS Mermaid 9 ; return at most, the 9 most recent + entries in the nick history for + "Mermaid"; + + WHOWAS Trillian 1 *.edu ; return the most recent history for + "Trillian" from the first server found + to match "*.edu". + +4.6 Miscellaneous messages + + Messages in this category do not fit into any of the above categories + but are nonetheless still a part of and required by the protocol. + + + + + +Oikarinen & Reed [Page 35] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +4.6.1 Kill message + + Command: KILL + Parameters: + + The KILL message is used to cause a client-server connection to be + closed by the server which has the actual connection. KILL is used + by servers when they encounter a duplicate entry in the list of valid + nicknames and is used to remove both entries. It is also available + to operators. + + Clients which have automatic reconnect algorithms effectively make + this command useless since the disconnection is only brief. It does + however break the flow of data and can be used to stop large amounts + of being abused, any user may elect to receive KILL messages + generated for others to keep an 'eye' on would be trouble spots. + + In an arena where nicknames are required to be globally unique at all + times, KILL messages are sent whenever 'duplicates' are detected + (that is an attempt to register two users with the same nickname) in + the hope that both of them will disappear and only 1 reappear. + + The comment given must reflect the actual reason for the KILL. For + server-generated KILLs it usually is made up of details concerning + the origins of the two conflicting nicknames. For users it is left + up to them to provide an adequate reason to satisfy others who see + it. To prevent/discourage fake KILLs from being generated to hide + the identify of the KILLer, the comment also shows a 'kill-path' + which is updated by each server it passes through, each prepending + its name to the path. + + Numeric Replies: + + ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS + ERR_NOSUCHNICK ERR_CANTKILLSERVER + + + KILL David (csd.bu.edu <- tolsun.oulu.fi) + ; Nickname collision between csd.bu.edu + and tolson.oulu.fi + + + NOTE: + It is recommended that only Operators be allowed to kill other users + with KILL message. In an ideal world not even operators would need + to do this and it would be left to servers to deal with. + + + + + +Oikarinen & Reed [Page 36] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +4.6.2 Ping message + + Command: PING + Parameters: [] + + The PING message is used to test the presence of an active client at + the other end of the connection. A PING message is sent at regular + intervals if no other activity detected coming from a connection. If + a connection fails to respond to a PING command within a set amount + of time, that connection is closed. + + Any client which receives a PING message must respond to + (server which sent the PING message out) as quickly as possible with + an appropriate PONG message to indicate it is still there and alive. + Servers should not respond to PING commands but rely on PINGs from + the other end of the connection to indicate the connection is alive. + If the parameter is specified, the PING message gets + forwarded there. + + Numeric Replies: + + ERR_NOORIGIN ERR_NOSUCHSERVER + + Examples: + + PING tolsun.oulu.fi ; server sending a PING message to + another server to indicate it is still + alive. + + PING WiZ ; PING message being sent to nick WiZ + +4.6.3 Pong message + + Command: PONG + Parameters: [] + + PONG message is a reply to ping message. If parameter is + given this message must be forwarded to given daemon. The + parameter is the name of the daemon who has responded to PING message + and generated this message. + + Numeric Replies: + + ERR_NOORIGIN ERR_NOSUCHSERVER + + Examples: + + PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to + + + +Oikarinen & Reed [Page 37] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + tolsun.oulu.fi + +4.6.4 Error + + Command: ERROR + Parameters: + + The ERROR command is for use by servers when reporting a serious or + fatal error to its operators. It may also be sent from one server to + another but must not be accepted from any normal unknown clients. + + An ERROR message is for use for reporting errors which occur with a + server-to-server link only. An ERROR message is sent to the server + at the other end (which sends it to all of its connected operators) + and to all operators currently connected. It is not to be passed + onto any other servers by a server if it is received from a server. + + When a server sends a received ERROR message to its operators, the + message should be encapsulated inside a NOTICE message, indicating + that the client was not responsible for the error. + + Numerics: + + None. + + Examples: + + ERROR :Server *.fi already exists; ERROR message to the other server + which caused this error. + + NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists + ; Same ERROR message as above but sent + to user WiZ on the other server. + +5. OPTIONALS + + This section describes OPTIONAL messages. They are not required in a + working server implementation of the protocol described herein. In + the absence of the option, an error reply message must be generated + or an unknown command error. If the message is destined for another + server to answer then it must be passed on (elementary parsing + required) The allocated numerics for this are listed with the + messages below. + +5.1 Away + + Command: AWAY + Parameters: [message] + + + +Oikarinen & Reed [Page 38] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + With the AWAY message, clients can set an automatic reply string for + any PRIVMSG commands directed at them (not to a channel they are on). + The automatic reply is sent by the server to client sending the + PRIVMSG command. The only replying server is the one to which the + sending client is connected to. + + The AWAY message is used either with one parameter (to set an AWAY + message) or with no parameters (to remove the AWAY message). + + Numeric Replies: + + RPL_UNAWAY RPL_NOWAWAY + + Examples: + + AWAY :Gone to lunch. Back in 5 ; set away message to "Gone to lunch. + Back in 5". + + :WiZ AWAY ; unmark WiZ as being away. + + +5.2 Rehash message + + Command: REHASH + Parameters: None + + The rehash message can be used by the operator to force the server to + re-read and process its configuration file. + + Numeric Replies: + + RPL_REHASHING ERR_NOPRIVILEGES + +Examples: + +REHASH ; message from client with operator + status to server asking it to reread its + configuration file. + +5.3 Restart message + + Command: RESTART + Parameters: None + + The restart message can only be used by an operator to force a server + restart itself. This message is optional since it may be viewed as a + risk to allow arbitrary people to connect to a server as an operator + and execute this command, causing (at least) a disruption to service. + + + +Oikarinen & Reed [Page 39] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + The RESTART command must always be fully processed by the server to + which the sending client is connected and not be passed onto other + connected servers. + + Numeric Replies: + + ERR_NOPRIVILEGES + + Examples: + + RESTART ; no parameters required. + + running. + +5.5 Users + + Command: USERS + Parameters: [] + + + +Oikarinen & Reed [Page 40] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + The USERS command returns a list of users logged into the server in a + similar format to who(1), rusers(1) and finger(1). Some people + may disable this command on their server for security related + reasons. If disabled, the correct numeric must be returned to + indicate this. + + Numeric Replies: + + ERR_NOSUCHSERVER ERR_FILEERROR + RPL_USERSSTART RPL_USERS + RPL_NOUSERS RPL_ENDOFUSERS + ERR_USERSDISABLED + + Disabled Reply: + + ERR_USERSDISABLED + + Examples: + +USERS eff.org ; request a list of users logged in on + server eff.org + +:John USERS tolsun.oulu.fi ; request from John for a list of users + logged in on server tolsun.oulu.fi + +5.6 Operwall message + + Command: WALLOPS + Parameters: Text to be sent to all operators currently online + + Sends a message to all operators currently online. After + implementing WALLOPS as a user command it was found that it was + often and commonly abused as a means of sending a message to a lot + of people (much similar to WALL). Due to this it is recommended + that the current implementation of WALLOPS be used as an + example by allowing and recognising only servers as the senders of + WALLOPS. + + Numeric Replies: + + ERR_NEEDMOREPARAMS + + Examples: + + :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua; WALLOPS + message from csd.bu.edu announcing a + CONNECT message it received and acted + upon from Joshua. + + + +Oikarinen & Reed [Page 41] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +5.7 Userhost message + + Command: USERHOST + Parameters: {} + + The USERHOST command takes a list of up to 5 nicknames, each + separated by a space character and returns a list of information + about each nickname that it found. The returned list has each reply + separated by a space. + + Numeric Replies: + + RPL_USERHOST ERR_NEEDMOREPARAMS + + Examples: + + USERHOST Wiz Michael Marty p ;USERHOST request for information on + nicks "Wiz", "Michael", "Marty" and "p" + +5.7.1 Userip message + + Command: USERIP + Parameters: {} + + The USERHOST command takes a list of up to 5 nicknames, each + separated by a space character and returns a list of information + about each nickname that it found. The returned list has each reply + separated by a space. + + Numeric Replies: + + RPL_USERIP ERR_NEEDMOREPARAMS + + Examples: + + USERIP Wiz Michael Marty p ;USERIP request for information on + nicks "Wiz", "Michael", "Marty" and "p" + +5.8 Ison message + + Command: ISON + Parameters: {} + + The ISON command was implemented to provide a quick and efficient + means to get a response about whether a given nickname was currently + on IRC. ISON only takes one (1) parameter: a space-separated list of + nicks. For each nickname in the list that is present, the server + adds that to its reply string. Thus the reply string may return + empty (none of the given nicks are present), an exact copy of the + parameter string (all of them present) or as any other subset of the + set of nicks given in the parameter. The only limit on the number + of nicks that may be checked is that the combined length must not be + too large as to cause the server to chop it off so it fits in 512 + characters. + + ISON is only be processed by the server local to the client sending + the command and thus not passed onto other servers for further + processing. + + Numeric Replies: + + RPL_ISON ERR_NEEDMOREPARAMS + + Examples: + + ISON phone trillian WiZ jarlek Avalon Angel Monstah + ; Sample ISON request for 7 nicks. + + + +Oikarinen & Reed [Page 42] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + +6. REPLIES + + The following is a list of numeric replies which are generated in + response to the commands given above. Each numeric is given with its + number, name and reply string. + +6.1 Error Replies. + + 401 ERR_NOSUCHNICK + " :No such nick/channel" + + - Used to indicate the nickname parameter supplied to a + command is currently unused. + + 402 ERR_NOSUCHSERVER + " :No such server" + + - Used to indicate the server name given currently + doesn't exist. + + 403 ERR_NOSUCHCHANNEL + " :No such channel" + + - Used to indicate the given channel name is invalid. + + 404 ERR_CANNOTSENDTOCHAN + " :Cannot send to channel" + + - Sent to a user who is either (a) not on a channel + which is mode +n or (b) not a chanop (or mode +v) on + a channel which has mode +m set and is trying to send + a PRIVMSG message to that channel. + + 405 ERR_TOOMANYCHANNELS + " :You have joined too many \ + channels" + - Sent to a user when they have joined the maximum + number of allowed channels and they try to join + another channel. + + 406 ERR_WASNOSUCHNICK + " :There was no such nickname" + + - Returned by WHOWAS to indicate there is no history + information for that nickname. + + 407 ERR_TOOMANYTARGETS + " :Duplicate recipients. No message \ + + + +Oikarinen & Reed [Page 43] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + delivered" + + - Returned to a client which is attempting to send a + PRIVMSG/NOTICE using the user@host destination format + and for a user@host which has several occurrences. + + 409 ERR_NOORIGIN + ":No origin specified" + + - PING or PONG message missing the originator parameter + which is required since these commands must work + without valid prefixes. + + 411 ERR_NORECIPIENT + ":No recipient given ()" + 412 ERR_NOTEXTTOSEND + ":No text to send" + 413 ERR_NOTOPLEVEL + " :No toplevel domain specified" + 414 ERR_WILDTOPLEVEL + " :Wildcard in toplevel domain" + + - 412 - 414 are returned by PRIVMSG to indicate that + the message wasn't delivered for some reason. + ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that + are returned when an invalid use of + "PRIVMSG $" or "PRIVMSG #" is attempted. + + 421 ERR_UNKNOWNCOMMAND + " :Unknown command" + + - Returned to a registered client to indicate that the + command sent is unknown by the server. + + 422 ERR_NOMOTD + ":MOTD File is missing" + + - Server's MOTD file could not be opened by the server. + + 423 ERR_NOADMININFO + " :No administrative info available" + + - Returned by a server in response to an ADMIN message + when there is an error in finding the appropriate + information. + + 424 ERR_FILEERROR + ":File error doing on " + + + +Oikarinen & Reed [Page 44] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + - Generic error message used to report a failed file + operation during the processing of a message. + + 431 ERR_NONICKNAMEGIVEN + ":No nickname given" + + - Returned when a nickname parameter expected for a + command and isn't found. + + 432 ERR_ERRONEUSNICKNAME + " :Erroneus nickname" + + - Returned after receiving a NICK message which contains + characters which do not fall in the defined set. See + section x.x.x for details on valid nicknames. + + 433 ERR_NICKNAMEINUSE + " :Nickname is already in use" + + - Returned when a NICK message is processed that results + in an attempt to change to a currently existing + nickname. + + 436 ERR_NICKCOLLISION + " :Nickname collision KILL" + + - Returned by a server to a client when it detects a + nickname collision (registered of a NICK that + already exists by another server). + + 441 ERR_USERNOTINCHANNEL + " :They aren't on that channel" + + - Returned by the server to indicate that the target + user of the command is not on the given channel. + + 442 ERR_NOTONCHANNEL + " :You're not on that channel" + + - Returned by the server whenever a client tries to + perform a channel effecting command for which the + client isn't a member. + + 443 ERR_USERONCHANNEL + " :is already on channel" + + - Returned when a client tries to invite a user to a + channel they are already on. + + + +Oikarinen & Reed [Page 45] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 444 ERR_NOLOGIN + " :User not logged in" + + - Returned by the summon after a SUMMON command for a + user was unable to be performed since they were not + logged in. + + 445 ERR_SUMMONDISABLED + ":SUMMON has been disabled" + + - Returned as a response to the SUMMON command. Must be + returned by any server which does not implement it. + + 446 ERR_USERSDISABLED + ":USERS has been disabled" + + - Returned as a response to the USERS command. Must be + returned by any server which does not implement it. + + 451 ERR_NOTREGISTERED + ":You have not registered" + + - Returned by the server to indicate that the client + must be registered before the server will allow it + to be parsed in detail. + + 461 ERR_NEEDMOREPARAMS + " :Not enough parameters" + + - Returned by the server by numerous commands to + indicate to the client that it didn't supply enough + parameters. + + 462 ERR_ALREADYREGISTRED + ":You may not reregister" + + - Returned by the server to any link which tries to + change part of the registered details (such as + password or user details from second USER message). + + + 463 ERR_NOPERMFORHOST + ":Your host isn't among the privileged" + + - Returned to a client which attempts to register with + a server which does not been setup to allow + connections from the host the attempted connection + is tried. + + + +Oikarinen & Reed [Page 46] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 464 ERR_PASSWDMISMATCH + ":Password incorrect" + + - Returned to indicate a failed attempt at registering + a connection for which a password was required and + was either not given or incorrect. + + 465 ERR_YOUREBANNEDCREEP + ":You are banned from this server" + + - Returned after an attempt to connect and register + yourself with a server which has been setup to + explicitly deny connections to you. + + 467 ERR_KEYSET + " :Channel key already set" + 471 ERR_CHANNELISFULL + " :Cannot join channel (+l)" + 472 ERR_UNKNOWNMODE + " :is unknown mode char to me" + 473 ERR_INVITEONLYCHAN + " :Cannot join channel (+i)" + 474 ERR_BANNEDFROMCHAN + " :Cannot join channel (+b)" + 475 ERR_BADCHANNELKEY + " :Cannot join channel (+k)" + 481 ERR_NOPRIVILEGES + ":Permission Denied- You're not an IRC operator" + + - Any command requiring operator privileges to operate + must return this error to indicate the attempt was + unsuccessful. + + 482 ERR_CHANOPRIVSNEEDED + " :You're not channel operator" + + - Any command requiring 'chanop' privileges (such as + MODE messages) must return this error if the client + making the attempt is not a chanop on the specified + channel. + + 483 ERR_CANTKILLSERVER + ":You cant kill a server!" + + - Any attempts to use the KILL command on a server + are to be refused and this error returned directly + to the client. + + + + +Oikarinen & Reed [Page 47] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 491 ERR_NOOPERHOST + ":No O-lines for your host" + + - If a client sends an OPER message and the server has + not been configured to allow connections from the + client's host as an operator, this error must be + returned. + + 501 ERR_UMODEUNKNOWNFLAG + ":Unknown MODE flag" + + - Returned by the server to indicate that a MODE + message was sent with a nickname parameter and that + the a mode flag sent was not recognized. + + 502 ERR_USERSDONTMATCH + ":Cant change mode for other users" + + - Error sent to any user trying to view or change the + user mode for a user other than themselves. + +6.2 Command responses. + + 300 RPL_NONE + Dummy reply number. Not used. + + 302 RPL_USERHOST + ":[{}]" + + - Reply format used by USERHOST to list replies to + the query list. The reply string is composed as + follows: + + ::= ['*'] '=' <'+'|'-'> + + The '*' indicates whether the client has registered + as an Operator. The '-' or '+' characters represent + whether the client has set an AWAY message or not + respectively. + + 303 RPL_ISON + ":[ {}]" + + - Reply format used by ISON to list replies to the + query list. + + 301 RPL_AWAY + " :" + + + +Oikarinen & Reed [Page 48] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + 305 RPL_UNAWAY + ":You are no longer marked as being away" + 306 RPL_NOWAWAY + ":You have been marked as being away" + + - These replies are used with the AWAY command (if + allowed). RPL_AWAY is sent to any client sending a + PRIVMSG to a client which is away. RPL_AWAY is only + sent by the server to which the client is connected. + Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the + client removes and sets an AWAY message. + + 311 RPL_WHOISUSER + " * :" + 312 RPL_WHOISSERVER + " :" + 313 RPL_WHOISOPERATOR + " :is an IRC operator" + 317 RPL_WHOISIDLE + " :seconds idle" + 318 RPL_ENDOFWHOIS + " :End of /WHOIS list" + 319 RPL_WHOISCHANNELS + " :{[@|+]}" + + - Replies 311 - 313, 317 - 319 are all replies + generated in response to a WHOIS message. Given that + there are enough parameters present, the answering + server must either formulate a reply out of the above + numerics (if the query nick is found) or return an + error reply. The '*' in RPL_WHOISUSER is there as + the literal character and not as a wild card. For + each reply set, only RPL_WHOISCHANNELS may appear + more than once (for long lists of channel names). + The '@' and '+' characters next to the channel name + indicate whether a client is a channel operator or + has been granted permission to speak on a moderated + channel. The RPL_ENDOFWHOIS reply is used to mark + the end of processing a WHOIS message. + + 314 RPL_WHOWASUSER + " * :" + 369 RPL_ENDOFWHOWAS + " :End of WHOWAS" + + - When replying to a WHOWAS message, a server must use + the replies RPL_WHOWASUSER, RPL_WHOISSERVER or + ERR_WASNOSUCHNICK for each nickname in the presented + + + +Oikarinen & Reed [Page 49] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + list. At the end of all reply batches, there must + be RPL_ENDOFWHOWAS (even if there was only one reply + and it was an error). + + 321 RPL_LISTSTART + "Channel :Users Name" + 322 RPL_LIST + " <# visible> :" + 323 RPL_LISTEND + ":End of /LIST" + + - Replies RPL_LISTSTART, RPL_LIST, RPL_LISTEND mark + the start, actual replies with data and end of the + server's response to a LIST command. If there are + no channels available to return, only the start + and end reply must be sent. + + 324 RPL_CHANNELMODEIS + " " + + 331 RPL_NOTOPIC + " :No topic is set" + 332 RPL_TOPIC + " :" + + - When sending a TOPIC message to determine the + channel topic, one of two replies is sent. If + the topic is set, RPL_TOPIC is sent back else + RPL_NOTOPIC. + + 341 RPL_INVITING + " " + + - Returned by the server to indicate that the + attempted INVITE message was successful and is + being passed onto the end client. + + 342 RPL_SUMMONING + " :Summoning user to IRC" + + - Returned by a server answering a SUMMON message to + indicate that it is summoning that user. + + 351 RPL_VERSION + ". :" + + - Reply by the server showing its version details. + The is the version of the software being + + + +Oikarinen & Reed [Page 50] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + used (including any patchlevel revisions) and the + is used to indicate if the server is + running in "debug mode". + + The "comments" field may contain any comments about + the version or further version details. + + 352 RPL_WHOREPLY + " \ + [*][@|+] : " + 315 RPL_ENDOFWHO + " :End of /WHO list" + + - The RPL_WHOREPLY and RPL_ENDOFWHO pair are used + to answer a WHO message. The RPL_WHOREPLY is only + sent if there is an appropriate match to the WHO + query. If there is a list of parameters supplied + with a WHO message, a RPL_ENDOFWHO must be sent + after processing each list item with being + the item. + + 353 RPL_NAMREPLY + " :[[@|+] [[@|+] [...]]]" + 366 RPL_ENDOFNAMES + " :End of /NAMES list" + + - To reply to a NAMES message, a reply pair consisting + of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the + server back to the client. If there is no channel + found as in the query, then only RPL_ENDOFNAMES is + returned. The exception to this is when a NAMES + message is sent with no parameters and all visible + channels and contents are sent back in a series of + RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark + the end. + + 364 RPL_LINKS + " : " + 365 RPL_ENDOFLINKS + " :End of /LINKS list" + + - In replying to the LINKS message, a server must send + replies back using the RPL_LINKS numeric and mark the + end of the list using an RPL_ENDOFLINKS reply. + + 367 RPL_BANLIST + " " + 368 RPL_ENDOFBANLIST + + + +Oikarinen & Reed [Page 51] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + " :End of channel ban list" + + - When listing the active 'bans' for a given channel, + a server is required to send the list back using the + RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate + RPL_BANLIST is sent for each active banid. After the + banids have been listed (or if none present) a + RPL_ENDOFBANLIST must be sent. + + 371 RPL_INFO + ":" + 374 RPL_ENDOFINFO + ":End of /INFO list" + + - A server responding to an INFO message is required to + send all its 'info' in a series of RPL_INFO messages + with a RPL_ENDOFINFO reply to indicate the end of the + replies. + + 375 RPL_MOTDSTART + ":- Message of the day - " + 372 RPL_MOTD + ":- " + 376 RPL_ENDOFMOTD + ":End of /MOTD command" + + - When responding to the MOTD message and the MOTD file + is found, the file is displayed line by line, with + each line no longer than 80 characters, using + RPL_MOTD format replies. These should be surrounded + by a RPL_MOTDSTART (before the RPL_MOTDs) and an + RPL_ENDOFMOTD (after). + + 381 RPL_YOUREOPER + ":You are now an IRC operator" + + - RPL_YOUREOPER is sent back to a client which has + just successfully issued an OPER message and gained + operator status. + + 382 RPL_REHASHING + " :Rehashing" + + - If the REHASH option is used and an operator sends + a REHASH message, an RPL_REHASHING is sent back to + the operator. + + 391 RPL_TIME + + + +Oikarinen & Reed [Page 52] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + " :" + + - When replying to the TIME message, a server must send + the reply using the RPL_TIME format above. The string + showing the time need only contain the correct day and + time there. There is no further requirement for the + time string. + + 392 RPL_USERSSTART + ":UserID Terminal Host" + 393 RPL_USERS + ":%-8s %-9s %-8s" + 394 RPL_ENDOFUSERS + ":End of users" + 395 RPL_NOUSERS + ":Nobody logged in" + + - If the USERS message is handled by a server, the + replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and + RPL_NOUSERS are used. RPL_USERSSTART must be sent + first, following by either a sequence of RPL_USERS + or a single RPL_NOUSER. Following this is + RPL_ENDOFUSERS. + + 200 RPL_TRACELINK + "Link \ + " + 201 RPL_TRACECONNECTING + "Try. " + 202 RPL_TRACEHANDSHAKE + "H.S. " + 203 RPL_TRACEUNKNOWN + "???? []" + 204 RPL_TRACEOPERATOR + "Oper " + 205 RPL_TRACEUSER + "User " + 206 RPL_TRACESERVER + "Serv S C \ + @" + 208 RPL_TRACENEWTYPE + " 0 " + 261 RPL_TRACELOG + "File " + + - The RPL_TRACE* are all returned by the server in + response to the TRACE message. How many are + returned is dependent on the the TRACE message and + + + +Oikarinen & Reed [Page 53] + +RFC 1459 Internet Relay Chat Protocol May 1993 + + + whether it was sent by an operator or not. There + is no predefined order for which occurs first. + Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and + RPL_TRACEHANDSHAKE are all used for connections + which have not been fully established and are either + unknown, still attempting to connect or in the + process of completing the 'server handshake'. + RPL_TRACELINK is sent by any server which handles + a TRACE message and has to pass it on to another + server. The list of RPL_TRACELINKs sent in + response to a TRACE command traversing the IRC + network should reflect the actual connectivity of + the servers themselves along that path. + RPL_TRACENEWTYPE is to be used for any connection + which does not fit in the other categories but is + being displayed anyway. + + 211 RPL_STATSLINKINFO + " \ + \ +