This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 180339 - xchat ssl defaults to wrong port number
xchat ssl defaults to wrong port number
Product: Fedora
Classification: Fedora
Component: xchat (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-02-07 08:30 EST by Benjamin LaHaise
Modified: 2013-08-14 19:47 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-21 00:55:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Benjamin LaHaise 2006-02-07 08:30:00 EST
Description of problem:
The command /server -ssl <some host> attempts to connect to port 9999 when the
port it should be trying to connect to is 994.

Version-Release number of selected component (if applicable):
2.6.0-3.1, but it seems to have been this way for all of 2.x
Comment 1 Rahul Sundaram 2006-02-20 06:18:26 EST

These bugs are being closed since a large number of updates have been released
after the FC5 test1 and test2 releases. Kindly update your system by running yum
update as root user or try out the third and final test version of FC5 being
released in a short while and verify if the bugs are still present on the system
.Reopen or file new bug reports as appropriate after confirming the presence of
this issue. Thanks
Comment 2 Matěj Cepl 2007-01-18 05:19:47 EST
Very much alive with xchat-2.6.6-8 and yes /etc/services point to port 994 for ircs.
Comment 3 Red Hat Bugzilla 2007-02-05 14:25:07 EST
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Comment 4 Kevin Kofler 2007-06-02 14:22:20 EDT
Who says this is a bug, i.e. that the port really should be 994? Port 9999 is 
very much in use for IRC over SSL out there in the real world.
Comment 5 Benjamin LaHaise 2007-06-03 14:16:12 EDT
According to /etc/services:

ircs            994/tcp
distinct        9999/tcp                        # distinct

Personally, I'm inclined to believe that 994 is the correctly assigned number
given that it is documented as such.
Comment 6 Kevin Kofler 2007-07-19 06:51:48 EDT
CCing upstream.

All this is nice in theory, but out there in the real world, 9999 is used a 
lot. Probably for the same reason almost nobody uses the official port 194 for 
unencrypted IRC, but usually 6667 or 7000: port numbers above 1024 don't 
require root privileges to bind.
Comment 7 Peter Zelezny 2007-07-19 07:29:50 EDT
I was actually thinking of changing the default ssl port to 6697. This seems to
be the defacto standard right now. 994 is no go, because no one actually uses it.

I don't think it matters much anyway, since you need to specify the port when
adding a SSL server to the list: e.g.
Comment 8 Kevin Kofler 2007-07-19 07:33:31 EDT
Well, at least uses 9999. But that's a small network. The 
large ones I checked (Freenode, EFNet, DalNET) don't appear to support SSL at 
all, so "let's just default to what the large networks use" won't work either.
Comment 9 Benjamin LaHaise 2007-07-19 09:22:24 EDT
994 is in use by a number of networks.  Regardless of what the port is, xchat
should default to whatever is specified in /etc/services which can be changed to
the appropriate default.
Comment 10 Kevin Kofler 2007-07-19 09:26:51 EDT
So do you also advocate defaulting unencrypted IRC to 194? That would make 
XChat completely out of touch with the real world.
Comment 11 Jeff Gustafson 2013-08-12 14:08:26 EDT
Can this issue be re-visited? It has been a few years now and it appears that all the major IRC networks have now jumped to 6697. Some are still accepting 9999 for backwards compatibility. 9999 needs to go away since other programs (aproxy for debian) use it.
Comment 12 Kevin Kofler 2013-08-14 19:47:44 EDT
I no longer comaintain XChat, I'll leave it up to the current maintainers to decide what to do about this.

Note You need to log in before you can comment on or make changes to this bug.