mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Mar 2018
Posts: 3
B
Self-satisified door
OP Offline
Self-satisified door
B
Joined: Mar 2018
Posts: 3
I ran into this issue in mIRC v7.52.

Starting with a clean installation:
Open mIRC
Under mIRC Options, open the Connect->Servers menu
Click Add to add a new server.
Description: Unencrypted
Address: unencrypted
Ports: 6667
(leave Group blank)
Click Add on the Add Server dialog.
Click Add again on the Connect->Servers menu to add another server.
Description: Encrypted
Address: encrypted
Ports: +6697
(leave Group blank)
Click Add on the Add Server dialog.

Select "Encrypted" from the list of IRC servers, and click the "Select" button.
Enter a nickname.
Click Connect.
Expect messages "Connecting to encrypted (+6697)" and "Unable to resolve server" (unless for some reason you have a host named "encrypted" somewhere on the network...)
Click the Disconnect icon and go back to mIRC Options.
Under the Connect->Servers menu, select "Unencrypted" from the list of IRC servers, and click the "Select" button.
Click Connect.
Expect message "Connecting to unencrypted (+6697)". This seems wrong. The user has asked to use port 6667 when connecting to the unencrypted server.


mIRC will correctly pick the desired port for "unencrypted" (6667) if you edit the "Unencrypted" server listing (saving without making any changes is fine), then select it and connect to it. This gets messed up again if you connect to "Encrypted" again.

Another way to resolve this issue is to edit the "Unencrypted" server listing and put it in its own Group. It seems like you get the same weird behaviors if the "Encrypted" listing is in the same group as "Unencrypted".

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for your bug report. This is by design although not intuitive. See here for a previous discussion on this issue.

Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
The problem I see here is that irc.alice.net uses 6667 and irc.bob.edu uses +6697, but for some reason mIRC tries to connect to irc.alice.net +6697 which could be anything. Why would mIRC try to connect to alice using bob's arbitrary SSL port? Or does mIRC know about "+6697" as some default SSL port? Shouldn't mIRC develop an aversion to connecting to alice entirely?


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
irc.alice.net uses 6667 and irc.bob.edu uses +6697

If you are able to reproduce this issue with a specific set of servers, I will need more information in order to try to reproduce this issue:

1) The full server entry for both of the addreses ie. description, address, port, group name, etc. so I can add them to an empty servers list.

2) The method you are using to connect to the servers ie. using the Servers dialog, or using /server group, or using /server address, etc.

Joined: Mar 2018
Posts: 3
B
Self-satisified door
OP Offline
Self-satisified door
B
Joined: Mar 2018
Posts: 3
I am running into this issue because my workplace has its own IRC server which does not support SSL.

If all of the IRC servers you are using support SSL connections on port 6697, this is not really an issue because your connection will still succeed, even though it is not using the port you asked for when adding the server listing.

Does anyone know of a public IRC server which does NOT support SSL?

Using the /server command works, I can usually specify the port with /server irc.alice.net 6667

"for some reason mIRC tries to connect to irc.alice.net +6697 which could be anything"
Raccoon brings up a good point. I could theoretically set up two different IRC servers on the same host, one running on port 6667 and another running on 6697. Connecting to the different port could connect you to a different server entirely.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
I did explain this in my previous post :-) If you connect to an SSL server, mIRC will maintain the SSL state of the status window from that point onwards for security reasons, unless you connect to a different network.

mIRC used to do what you are requesting. But users complained that if they connected to an SSL server and mIRC tried reconnecting to the server, and the server contained a range of ports some of which were not SSL, mIRC could switch to a non-secure port. So I changed mIRC to maintain a secure connection, which is a priority for security reasons.

To get around this, you can add servers with different group names.

Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
His example doesn't use group names at all. They're stand alone servers. Is leaving the Group name field blank part of the problem?


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Mar 2018
Posts: 3
B
Self-satisified door
OP Offline
Self-satisified door
B
Joined: Mar 2018
Posts: 3
I see. Yes, the simple solution for this problem is to use groups. Back to Raccoon's example. Maybe I use two different servers.

irc.alice.net:6667
irc.bob.edu:6697

The correct way to add these two servers to mIRC would be to add them to separate groups like an alice.net group and a bob.edu group.

My problem was that I was not separating these servers using groups. Adding these unrelated servers to the Servers list, without assigning them a group, actually creates an association between them. It is like they are both part of the same "anonymous" group together, and therefore connecting to one server can impact how mIRC connects to the other server.

The problem I have with the behavior that mIRC currently has, is that I never suggested that connecting to irc.alice.net:6697 would be a valid thing to do.

Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
I agree with this observation, and postulate that if a server window is in protected SSL mode then it should skip over all server entries within a group that contain no SSL defined ports. The current behavior is to recycle the SSL port from one server entry onto the IP address of another server entry, causing you to arrive at a mismatched and random server/port internet service.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!

Link Copied to Clipboard