Atozed Forums

Hello,
i found a possible Bug in TIdIRC, everytime if i request Serverstats like this:

(using as an IRC Operator) RAW Command STATS

TIdIRC connected as a Client receive a complete Status List like this.

•06:59:43• <RAW> 210 fearcry :/Stats flags:
•06:59:43• <RAW> 210 fearcry :B - banversion - Send the ban version list
•06:59:43• <RAW> 210 fearcry :b - badword - Send the badwords list
•06:59:43• <RAW> 210 fearcry :C - link - Send the link block list
•06:59:43• <RAW> 210 fearcry :d - denylinkauto - Send the deny link (auto) block list
•06:59:43• <RAW> 210 fearcry :[D] - denylinkall - Send the deny link (all) block list
•06:59:43• <RAW> 210 fearcry :e - except - Send the ban exception list (ELINEs and in config))
•06:59:43• <RAW> 210 fearcry :f - spamfilter - Send the spamfilter list
•06:59:43• <RAW> 210 fearcry :F - denydcc - Send the deny dcc and allow dcc block lists
•06:59:43• <RAW> 210 fearcry :G - gline - Send the gline and gzline list
•06:59:43• <RAW> 210 fearcry :  Extended flags: [+/-mrs] [mask] [reason] [setby]
•06:59:43• <RAW> 210 fearcry :  m Return glines matching/not matching the specified mask
•06:59:43• <RAW> 210 fearcry :  r Return glines with a reason matching/not matching the specified reason
•06:59:43• <RAW> 210 fearcry :  s Return glines set by/not set by clients matching the specified name
•06:59:43• <RAW> 210 fearcry :I - allow - Send the allow block list
•06:59:43• <RAW> 210 fearcry :j - officialchans - Send the offical channels list
•06:59:43• <RAW> 210 fearcry :K - kline - Send the ban user/ban ip/except ban block list
•06:59:43• <RAW> 210 fearcry :l - linkinfo - Send link information
•06:59:43• <RAW> 210 fearcry :L - linkinfoall - Send all link information
•06:59:43• <RAW> 210 fearcry :M - command - Send list of how many times each command was used
•06:59:43• <RAW> 210 fearcry :n - banrealname - Send the ban realname block list
•06:59:43• <RAW> 210 fearcry :O - oper - Send the oper block list
•06:59:43• <RAW> 210 fearcry :[P] - port - Send information about ports
•06:59:43• <RAW> 210 fearcry :q - bannick - Send the ban nick block list
•06:59:43• <RAW> 210 fearcry :Q - sqline - Send the global qline list
•06:59:43• <RAW> 210 fearcry :r - chanrestrict - Send the channel deny/allow block list
•06:59:43• <RAW> 210 fearcry :S - set - Send the set block list
•06:59:43• <RAW> 210 fearcry :[s] - shun - Send the shun list
•06:59:43• <RAW> 210 fearcry :  Extended flags: [+/-mrs] [mask] [reason] [setby]
•06:59:43• <RAW> 210 fearcry :  m Return shuns matching/not matching the specified mask
•06:59:43• <RAW> 210 fearcry :  r Return shuns with a reason matching/not matching the specified reason
•06:59:43• <RAW> 210 fearcry :  s Return shuns set by/not set by clients matching the specified name
•06:59:43• <RAW> 210 fearcry :t - tld - Send the tld block list
•06:59:43• <RAW> 210 fearcry :T - traffic - Send traffic information
•06:59:43• <RAW> 210 fearcry :u - uptime - Send the server uptime and connection count
•06:59:43• <RAW> 210 fearcry :U - uline - Send the ulines block list
•06:59:43• <RAW> 210 fearcry :v - denyver - Send the deny version block list
•06:59:43• <RAW> 210 fearcry :V - vhost - Send the vhost block list
•06:59:43• <RAW> 210 fearcry :W - fdtable - Send the FD table listing
•06:59:43• <RAW> 210 fearcry :X - notlink - Send the list of servers that are not current linked
•06:59:43• <RAW> 210 fearcry :Y - class - Send the class block list
•06:59:43• <RAW> 219 fearcry * :End of /STATS report


*i use [] braces to hide the smileys

Everytimes if i reach the [219 End of STATS  Message, my TIdIRC-Client perform a regular QUIT without any Reason

•06:53:16• <IRC-Client> [QUIT] fearcry BSIRC@netadmin.baumannsoftware.com Reason: Quit: 
                                     BSIRC64 Version: 2.2.4.407 quit SSL Port Connection to irc.baumannsoftware.com


I have had the same Issues in the Past with the LIST/LIST END Command, 
i did post it to the old News-Server long Time ago and it turns fixed by the Indy Team . . .

Is there a Chance to check the Indy10 Source-Code for TIdIRC for this (Parser-Error)?


cheers

fearcry

Can you be more specific?

TIdIRC sends a QUIT command only when its own Disconnect() method is called by user code. TIdIRC does not call its own Disconnect() method for any reason (it calls the inherited TIdTCPClient.Disconnect() method instead). Certainly not when processing the server's 219 ENDOFSTATS message. Are you, by chance, calling Disconnect() yourself? Maybe in response to an error/exception?

TIdIRC does not currently process 210 status messages at all, they are simply ignored. In fact, I don't even see 210 defined in the original IRC protocol spec.

UPDATE: Oh wait, 210 is defined in a later update to the spec. But, it is defined as RPL_TRACERECONNECT, is marked as "unused", and is not listed as an allowed reply for the STATS command. So, I wonder why your IRC server is using 210 for its status infos?

Have you tried debugging TIdIRC's source code to see exactly what is failing while processing these messages?

Hello Remy,
i running an UnrealIRCd Version 5.06 (latest Version i guess) and started 2 TIdIRC-Clients, [Client A] send the STATS Command and lose the Connection after "End of Stats", [Client B] receive the QUIT-Message of [Client A] (this Quit-Message is predefined in Client A).

If Client B receiving the Quit-Message of Client A, the Quit must be performed by Client A and it's Quit-Message passing through the IRCd to Client B.

Lost Connection means Client A looks like a regular Click on the Disconnect-Button and it is really disconnected (not crashed).

Thats what i can say at the Moment, i try to get more Infos . . .


Greetings

(07-31-2020, 10:41 PM)fearcry Wrote: [ -> ]i running an UnrealIRCd Version 5.06 (latest Version i guess)

I looked through the source code for UnrealIRCd 5.06, and I found where the STATS command is being processed, and that the 210 replies are known as RPL_STATSHELP, which seems to be specific to Unreal, since 210 is RPL_TRACERECONNECT in the official IRC spec. There is another IRC server, aircd, that also apparently redefines 210, in its case 210 is known as RPL_STATS. Seems there are also other IRC reply codes that are specific to Unreal and different from other IRC servers, too. But that doesn't matter in this situation.

(07-31-2020, 10:41 PM)fearcry Wrote: [ -> ]started 2 TIdIRC-Clients, [Client A] send the STATS Command and lose the Connection after "End of Stats"

Again, have you tried debugging this to see why that is crashing? I have no way to test this myself, so you are going to have to do it for me. But even though Unreal redefines 210 for its own purposes, it shouldn't matter, since TIdIRC ignores 210 replies. Since the problem occurs only on 219 replies, which TIdIRC does process, I have to assume that the 219 reply is likely malformed in some way that is crashing TIdIRC. That is the only thing that makes sense to me right now.

Can you please show the RAW data that is actually being transmitted over TCP? Not what Unreal logs is being sent. If you are not using SSL/TLS, you can use a packet sniffer, like Wireshark, for that capture. Or, you can assign one of Indy's TIdLog... components to the TIdIRC.Intercept property. Or, you should be able to use the TIdIRC.OnRaw event (TIdIRC extracts and removes the SenderNick and SenderHost property values from the raw data before triggering the OnRaw event).

(07-31-2020, 10:41 PM)fearcry Wrote: [ -> ][Client B] receive the QUIT-Message of [Client A]

TIdIRC does not send a QUIT message (and certainly not to another client!) unless you ask it to, by calling Disconnect() on it. So you must be calling Disconnect() in your code somewhere when the 219 reply fails.

(07-31-2020, 10:41 PM)fearcry Wrote: [ -> ]this Quit-Message is predefined in Client A

What do you mean? There is no pre-defined text message for QUIT in TIdIRC. So, since you said that QUIT was being received with a reason text of "Quit", you must be calling Disconnect('Quit') yourself.

(07-31-2020, 10:41 PM)fearcry Wrote: [ -> ]If Client B receiving the Quit-Message of Client A, the Quit must be performed by Client A and it's Quit-Message passing through the IRCd to Client B.

What does your TIdIRC code actually look like?

Hello Remy,
>So, since you said that QUIT was being received with a reason text of "Quit", must be calling Disconnect('Quit') yourself.

thats true, i set the QuitMessage in Client A, so there must be a TIdIRC->Disconnect(MyQuitMessage); in my own Code . . .

I try to check my Code at all before write on here. . .

The only Chance to see this Issues is to be connected via SSL to admin the IRCD to get the Operator-Level to use the STATS Command, but it is responsible - just the receiving of [219 End of Stats] from Client A causes the TIdIRC->Disconnect(MyQuitMessage);

greetings

So i'm totally wrong, what is seen now is that there is no Disconnect perfomed automatically from Client A!

The Disconnect comes if i really self click the Disconnect-Button after that Issues.

I didn't recognize that 1st because Client B running on a Box with some Timelag.

But in Fact, the "End of Stats" on Client A do something with the Threads, after that - Client A get no more Responses from back from the Server but it is online and can still send Commands to the Server.



greetings

(08-01-2020, 11:50 AM)fearcry Wrote: [ -> ]thats true, i set the QuitMessage in Client A, so there must be a TIdIRC->Disconnect(MyQuitMessage);  in my own Code . .

OK, so WHERE exactly in your code are you making that call?

(08-01-2020, 11:50 AM)fearcry Wrote: [ -> ]The only Chance to see this Issues is to be connected via SSL to admin the IRCD to get the Operator-Level to use the STATS Command

Since I can't test that myself to begin with, I don't care about that. That is just an implementation detail of the server.

(08-01-2020, 11:50 AM)fearcry Wrote: [ -> ]but it is responsible - just the receiving of [219 End of Stats] from Client A causes the TIdIRC->Disconnect(MyQuitMessage);

I can't help you if you don't show me EXACTLY what is being transmitted. I don't want to see logs. I want to see the RAW DATA going over the connection TCP (at least the IRC data, not the SSL data). Or, at least a call stack trace leading up to the call to Disconnect(). I'm ASSUMING there is an exception being raised that you are catching to call Disconnect(), yes? If so, I would need to know what function inside of TIdIRC is actually raising the exception, and what kind of exception it is.

Hello Remy,

>I'm ASSUMING there is an exception being raised that you are catching to call Disconnect, yes ?

Thats Right!

Let me stay on this:

There is not a Disconnect, that was a wrong Information of me.

1.) ClientA send a Raw Command  "STATS C <server>" for example.
2.) The IRC Server responding like in my 1st Post
3.) ClientA receive the Server Messages until 219 End of Stats - then nothing more . . .

After that the Application get no longer Responses from the IRC Server, it seems frozen but it is not frozen, i can send Messages to another IRC Client but nothing comes into my Memo/RTF Controls. I also don't deal with 219 in my OnRaw EventHandler, so it looks
more like a Thread Deadlock for me . . .

The Disconnect() what i told former comes if i close the Application Window (thats the automated Thing in my own Code).
If i run the Application without a Debugger my OnException EventHandler doesn't show something, but this Scenario in the Debugger raising an Exception.

(Exactly the Moment if sent the "STATS" Command and 219 was received)
1st Occasion for Exception at $004B3B07. Exception-Class $C0000005 with Message 'access violation at 0x004b3b07: read of address 0x00000000'. Process indy10irc.exe (14668)

Thanks for Helping

(08-04-2020, 08:38 PM)fearcry Wrote: [ -> ]1.) ClientA send a Raw Command "STATS C <server>" for example.
2.) The IRC Server responding like in my 1st Post
3.) ClientA receive the Server Messages until 219 End of Stats - then nothing more . . .

After that the Application get no longer Responses from the IRC Server, it seems frozen but it is not frozen, i can send Messages to another IRC Client but nothing comes into my Memo/RTF Controls. I also don't deal with 219 in my OnRaw EventHandler, so it looks more like a Thread Deadlock for me . . .

Sounds more likely that the 219 may be malformed in some way, like if the terminating CRLF is missing, causing TIdIRC to expect more data to arrive than is actually being sent. That is why I need to see the actual raw TCP data that is being transmitted.

(08-04-2020, 08:38 PM)fearcry Wrote: [ -> ]If i run the Application without a Debugger my OnException EventHandler doesn't show something, but this Scenario in the Debugger raising an Exception.

(Exactly the Moment if sent the "STATS" Command and 219 was received)
1st Occasion for Exception at $004B3B07. Exception-Class $C0000005 with Message 'access violation at 0x004b3b07: read of address 0x00000000'. Process indy10irc.exe (14668)

All that tells me is that a nil pointer is being accessed, but not WHERE it is being accessed from. Again, I would need to see the call stack trace at the time the exception is raised.

Hello Remy,

i did placed a TIdLogFile as an Intercept, the Stats-Section looks like this:


The Commands after "End of Stats" are selfmade Code (performs before quit)

I translated the German Notes to Rec (Received) and Snd (Send) and did a new Line behind all <EOL> to make it better readable here.