[Coder-Com] Server kill question
Hi Am looking for a bit of advice regarding servers killing remote clients. Specifically, I am writing a NickServ type module for GNUworld and need to kill clients if they exceed their time without authing. The problem is that when I send the D token, the remote server bounces it back to me instead of quitting the user and sending a QUIT back. Here is a full transcript from the point of view of the gnuworld module (linked directly to the server with the user on): [IN]: AB N Jeekay 1 1009129948 ~rgh 10.1.1.103 AKAQFn ABAAD :Desc [IN]: ABAAD M Jeekay :+i [OUT]: A5AAA P #ns.console :Processing kill queue. [IN]: ABAAD N admin 1009129952 [OUT]: A5AAA P #ns.console :Processing kill queue. [OUT]: A5AAA O ABAAD :Your nickname is registered. Please login or change your nick. [OUT]: A5AAA P #ns.console :ABAAD - Warned [OUT]: A5AAA P #ns.console :Processing kill queue. [OUT]: A5AAA O ABAAD :You have not logged into NickServ. You will now be autokilled. [OUT]: A5 D ABAAD :ns.irc.blah.org!NickServ (AutoKill) [OUT]: A5AAA P #ns.console :ABAAD - Killed [IN]: AB D ABAAD :ns.irc.blah.org!ns.blah.rgh.org!NickServ (AutoKill) (Ghost 5 Numeric Collided) Here, 'admin' is a registered nick and the NS kills off the unauthed connection. But the remote server (AB) then returns the D token with the message (Ghost 5 Numeric Collided) appended. I read through m_kill.c to see under what conditions this could happen and couldnt quite decrypt the explanatory comments, but as far as I could see it should only ever happen if I am linking/delinking servers at the same time, which is not the case here. Can anyone shed some light on this and perhaps reveal a way to make it work 'properly' and return a Q for that user? I have tried various different reasons after the D token, including: A5 D ABAAD :[NickServ] AutoKill A5 D ABAAD :ns.irc.blah.org (NickServ AutoKill) And variations on the theme - none seemed to make any difference. Thanks in advance Ras
Re: [Coder-Com] Server kill question
On Wed, 26 Dec 2001, Perry Lorier wrote: > You should never see a Quit back. Kill's are kills they remove the > client immediately. However what ircu's trying to prevent is a quit and > a kill crossing and ending up with a desync, so it kill's the user again > from the local server, knowing that the kill won't get passed on if > it doesn't match a user, but if it does then it will clear out any > possible desync. But when, for example, an oper kills a remote user, the server that owns that user will then disconnect him and issue a QUIT, precisly so that all other servers know that user has been disconnected...?
Re: [Coder-Com] Server kill question
On Tue, 25 Dec 2001, nighty wrote: > Hello, > just my two cents ... > have you tried ... A5AAA D ABAAD :kill reason ? > i mean .. it "looked" like weird to me that you make the /kill issued by the server >(two first chars of numeric) > rather than by the NickServ client. The problem is that when its a user kill (YYXXX), the server notices all opers about the kill. When its a servre kill (YY), it doesnt. Since this is a NickServ and so is likely to be killing a lot of clients, I dont want the opers to be noticed every time it happens. Sorry guess I shouldve said that in the first mail :)
[Coder-Com] ircu 2.1.10pl18 bug?
OK.. have been tearing my hair out for a while now trying to figure out why this happens... Basically, I am writing a NickServ type GNUworld module, to protect peoples registered nicks. A nice easy way to prevent anyone from changing to that nick after the client has been killed, is to 'jupe' that nick by sending an N token to the network from the server, claiming that nickname. Unfortunately, this seems to make ircu very unhappy - as soon as the N token appears, the services client (NS) is quit from the ircd with the quit message 'Numeric nick collision (Ghost)'. Interestingly, if two services are on the one services server (two xClients on one xServer - nickserv and cservice), as soon as a 'jupe' N token is sent, the ircu forces NS to quit (it never actually sends a quit token to the network btw). If there is just one service, I can jupe 3 nicks, then on the fourth NS collides and disappears. GNUworld logs: [OUT]: SERVER cs.test.org 1 1012718658 1012718658 J10 A6ADJ :CService Server [OUT]: A6 N P 1 31337 cservice test.org +dki AA A6AAA :CService [OUT]: A6 N NS 1 31337 NickServ test.org +dki AA A6AAB :NickServ [OUT]: A6 EB [OUT]: A6 EA (for brevity Ive dropped the ircu handshake and the channels burst) Then I issue the jupe command: [IN]: ABAAR P A6AAB :jupe add test nickserv::jupeNick> Juping nick test [OUT]: A6 N test 1 31337 juped test.nick.name B]AAAB A6AAQ :Juped Nick At this point, three clients should be present on the services server. However, the second that N token hits the ircu, I get: -!- NS [[EMAIL PROTECTED]] has quit [Numeric nick collision (Ghost)] As you can see, the numerics of the test client and the actual NS client are clearly different. Why is NS being locally quit by the ircu? Thanks in advance, GK
Re: [Coder-Com] ircu 2.1.10pl18 bug?
Alas, I already did this. As can be seen in the SERVER out string in the logs I mailed, the connections are set to around 200 odd. The standard for gnuworld is AAz which is around 50 somewhere. Also, I should point out that evern with the 50 set, it still falls over with more than 4 or 5 clients. (And yes, both the numbers mentioned should be odd. '201' and '51' if you must :)) Any other ideas? Could really use the help :/ Thanks, GK On Sun, 3 Feb 2002, Kev wrote: > > > OK.. have been tearing my hair out for a while now trying to figure out > > why this happens... > > I triggered this while playing with X the other day. The basic problem is > that the client capacity information sent to ircu must be a number of the > form (2^n)-1. I'm not sure where that capacity value is set in GNUWorld, > but the basic solution to your problem is to change it to something like, > say, 15 or 31. >
