Up until now, I’ve been a happy Openfire user and enjoyed Jabber on the desktop with Pidgin. The transports are nice although not being able to connect to more than one account at the same time hasn’t been fun… the IRC plugin is also a pain, with it not being able to connect to a user-specifiable network… but anyway…
In my quest for an “entirely console-based system” (a la everything being done in one or more urxvt windows, with hardly any graphical apps visible) I’ve switched - or more accurately tried to switch - from Pidgin to the Bitlbee IRC to IM gateway so I could connect to all my accounts - including my Jabber account, running on my own personal server - from irssi. Yes, it’s a great idea… that would actually be great if only Openfire would play along. 
If you don’t know what Bitlbee is, read this paragraph, otherwise you can skip it to save time. Bitlbee works on the concept/principle that you connect to a non-standard IRC server, and are joined to a channel with a pseudo-bot in it that you give commands to, and much like Jabber transports that connect from the server, the Bitlbee gateway connects from the server to whereever your destination protocol is (be it MSN, ICQ, AOL, or Jabber …hm, did I forget one?). Ok, Very good.
Since I wouldn’t really know where to start with explaining what’s going on, I’ll just demonstrate what happens in Bitlbee when I try to connect. Note that this demo is from testing.bitlbee.org, which is running the latest testing/dev build of Bitlbee. The latest stable build of the gateway (1.0.4 at time of writing) will actually CRASH when I try to connect to my Openfire server with it under some circumstances. (!!!1!11!!) That can’t be good.
Note also that I’m running the latest copy of Openfire (3.4.5 at time of writing).
With Client Connection Security at both “Required” and “Optional”, I get the following. I ensured that the password was correct by resetting it.
01:23 <@dav7> account add jabber test@dav7.net test
01:23 <@root> Account successfully added
01:23 <@dav7> account on
01:23 <@root> Trying to get all accounts connected…
01:23 <@root> jabber - Logging in: Connecting
01:23 <@root> jabber - Logging in: Connected to server, logging in
01:23 <@root> jabber - Logging in: Converting stream to TLS
01:23 <@root> jabber - Logging in: Connected to server, logging in
01:23 <@root> jabber - Couldn’t log in: Authentication failure
01:23 <@root> jabber - Logging in: Signing off…
With Client Connection Security at Optional, I tried to connect to the “old” SSL port (5223):
01:26 <@dav7> account add jabber test@dav7.net test dav7.net:5223:ssl
01:26 <@root> Warning: Passing a servername/other flags to `account add’ is now
deprecated. Use `account set’ instead.
01:26 <@root> Account successfully added
01:26 <@dav7> account on
01:26 <@root> Trying to get all accounts connected…
01:26 <@root> jabber - Logging in: Connecting
01:27 <@root> jabber - Logging in: Connected to server, logging in
01:27 <@root> jabber - Couldn’t log in: Authentication failure
01:27 <@root> jabber - Logging in: Signing off…
(I’m not sure how to avoid the warning, but it worked, so I’m not concerned for now. Augh, I hate interface changes…)
What about using the old port, but without SSL?
01:28 <@dav7> account add jabber test@dav7.net test dav7.net:5223
01:28 <@root> Warning: Passing a servername/other flags to `account add’ is now
deprecated. Use `account set’ instead.
01:28 <@root> Account successfully added
01:28 <@dav7> account on
01:28 <@root> Trying to get all accounts connected…
01:28 <@root> jabber - Logging in: Connecting
01:28 <@root> jabber - Logging in: Connected to server, logging in
(hang)
01:29 <@dav7> account off
01:29 <@root> Deactivating all active (re)connections…
01:29 <@root> jabber - Logging in: Signing off…
Note: As I mentioned above, with the latest stable copy of Bitlbee, the last 3 lines of the last ‘conversation’ listed was actually replaced by an effective nothingness because the (hang) was actually the point at which the server would become unresponsive. I would actually need to /quit irssi in order to fix the issue, and even then CTRL+C the client as it hung at “Waiting for servers to close connections…”.
In the latest testing build the gateway does still hang as in “not produce any more output” but as you can see I’m able to enter commands to kill the connection, and if I /quit the testing version irssi will wait for a fraction of a second for the gateway to (properly) kill the link and quit (which shouldn’t even be happening in the first place).
So, as you can see, Openfire and Bitlbee do NOT like each other. If I were to file this as a bug, I’d set it as a “Blocker”, but I’m instead giving this the benefit of the doubt and am asking you guys what’s going on first just in case I did something wrong.
I’d appreciate you checking this out and telling me if this is indeed a bug, and whatever the reason - be it a bug or not… I’m really looking forward to this issue not existing anymore.
-dav7