mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Apr 2018
Posts: 83
E
Babel fish
OP Offline
Babel fish
E
Joined: Apr 2018
Posts: 83
I have been working for a while on masking lots of useless (to normal/casual users of mIRC) that appear during the connection process and have been largely sucessful in this endevour with lots of haltdef commands.

One message, however, appears to be unmaskable, and appear to originate from within the mIRC client itself (I guess).

It is the (in green text) 'Local host:<your local host name>' followed by your external IP address inside brackets.

It appears between 'End of message of the day.' (raw 376) and 'There are nnn users and nnn invisible on n servers' (raw 251).

I have checked /debug output files and cannot find any trace of this message, therefore, I assume that mIRC is generating it having harvested the host info from the (in this case InspIRC 2.0 server daemon)
'NOTICE Auth :*** Looking up your hostname...'
and
NOTICE Auth :*** Found your hostname (<your hostname>)
pairing at the actual registration/ident section at the start of the connection.

Is there any way to capture and mask this message ?

As an extra, can I ask where/how mIRC is working out the external IP address when it cant see it, only seeing my internal (private lan) IP address ?

Oops, another extra please. When exactly does On Connect operate ?
I used to think it was after the user counts section (raw 251-255, 265, 266 and 396) of the registration process (before you do anything with nickserv etc.), but recently realised that my script is auto authenticating my nick before the On Connect section of my script 'kicks in'.

I would be greatful for any help on this/these matters.

Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Play with the settings under Alt+O > Connect > Local, aka the /localinfo -[u|h] command. You might not be able to prevent this information from displaying upon connect. There are a number of non-halting outputs intended to preserve sanity for users.

On Connect starts after 001 or 005 or there about. You can write your own script to figure that out while viewing the @debug window.

On *:Connect: echo @debug ON CONNECT!


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Apr 2018
Posts: 83
E
Babel fish
OP Offline
Babel fish
E
Joined: Apr 2018
Posts: 83
Thanks Raccoon

Quote:
Play with the settings under Alt+O > Connect > Local, aka the /localinfo -[u|h] command


Hmmm I missed that. I spent a lot of time looking for an option to diplay/show the info or not that I missed the obvious. Hitting the 'help' button there is extremely helpfull.

Quote:
On Connect starts after 001 or 005 or there about. You can write your own script to figure that out while viewing the @debug window.


I had done something similar with my own custom window and sending data to that window informing me of what part of the script was running at each point along with a $tick count to check timings (save initial tick count as %tock at raw 1, then use $tick - %tock to get a relative timing at each stage in [approx] millisecs.

It was through using this tht I noticed the peculiarity of when on connect actually activates.

Server I use used to run unreal 2.3.9 and it activated after the end of MOTD (raw 376). WikiChip agrees - 'The ON CONNECT event triggers when mIRC has successfully connected to an IRC server and that IRC server has displayed its MOTD.'

All was well until after a physical server crash, and a new server was put in place. It was decided to update the IRC daemon, and InspIRCd 2.0 was installed (along with Anope 2.0).

It was through a debug session that I noticed that the user, opertors and channel count info, which preceeded the MOTD was now being sent after the MOTD, and on connected occured after that.

Thats not quite true. On a normal connection (no ghosted connection) Nickserv sends out the 'you need to identfy message', my script responds, and after that, the on connect is activated. This was only spotted through the use of my timings diagnostic window. That was when I started to wonder about what actually activates the on connect

example of the diagnostic output. Notice when On Connect is activated.
Code:
 31/01/19 - 08:49:41      0 Time check started @ Raw 1 - Welcome
 31/01/19 - 08:49:41      0 Request Server Time
 31/01/19 - 08:49:41     15 Setting Invisible mode
 31/01/19 - 08:49:41     31 Start MotD
 31/01/19 - 08:49:41    140 End MotD
 31/01/19 - 08:49:41    156 Online User Counts
 31/01/19 - 08:49:41    156 End of Server Registration
 31/01/19 - 08:49:41    156 User Mode change: +x
 31/01/19 - 08:49:41    156 Identifying to NickServ - Script Line Num: 1067
 31/01/19 - 08:49:41    172 Received Server Time
 31/01/19 - 08:49:41    562 Prosessing on Connect
 31/01/19 - 08:49:42   1172 User Mode change: +i
 31/01/19 - 08:49:43   1984 Password Accepted. Authentication Verified. - Script Line Num: 1125

FYI the server time bits are due to me sending a /time command during processing of raw 001.
User Mode +x is set by the server, while +i is set by my script ( yes I know about options, Connect Options). Both are 'captured' and signaled to the diagnostic window using ON UserMode.

Last edited by Erasimus; 01/02/19 11:05 AM.
Joined: Apr 2018
Posts: 83
E
Babel fish
OP Offline
Babel fish
E
Joined: Apr 2018
Posts: 83
Update:

regarding the display of the local host info. I have 'played around' with the settings in Tools, Options, Connect, Options and have tried every combination possible, All that is affected there is how the information is collected and, as a result, it still displays. It is the displaying of that info that I want to mask, irrespective of which method mIRC uses to obtain it.

Slight tie in withe the on Connect query; I have found that this host name: message is sent from the mIRC client just after end of MotD (raw 376) so that may be it's 'trigger'. irrespective of the server/network user count info being displayed before or after MotD.

Further to this the message will never show up in any debug session since it not sent or recieved from the server. This makes it extremely hard to see what any possible trigger is. The only way I found to locaate it was with the old
Code:
raw *:*: { echo 6 -st raw event debugger: $network raw $numeric : (1) $1 (2) $2 (3) $3 (4) $4 (5) $5 (6-) $6- }

which displays in the status window (echo 6 -st) so I can see what happens immedietly before and after the message.

Thankfully I had lots of these (and debug sesssion) saved as log files.


Link Copied to Clipboard