Fri 22 Jan 2010 06:33:59 PM UTC, original submission:
WeeChat 0.3.0 introduces a behavioral regression with custom local hostname settings. To reproduce with version 0.3.0 using an all-default configuration:
1. Make sure you can connect using only default settings:
/connect freenode
(wait for successful connection)
/close
2. Set local_hostname to "test" and try to reconnect:
/set irc.server.freenode.local_hostname test
/connect freenode
WeeChat will fail to connect, giving the following messages:
freenode | irc: connecting to server chat.freenode.net/6667...
freenode =!= | irc: unable to set local hostname/IP
freenode | irc: reconnecting to server in 30 seconds
3. Configure the freenode server to use a proxy (in this example, a locally-running instance of Tor) and reconnect again:
/close
/proxy add tor socks5 127.0.0.1 9050
/set irc.server.freenode.proxy tor
/connect freenode
WeeChat connects successfully using a proxy. (After connection, if the server recognizes your proxy as a Tor node it will disconnect you as per freenode policy, but that isn't relevant to this bug.)
I'm not sure why an arbitrary local_hostname string should prevent connections when a proxy isn't used. WeeChat should not in any circumstance attempt to resolve the string to an actual host. The RFCs covering the IRC protocol do not require a client-to-server hostname string to be valid or of any particular use to the server -- the string is only specified for use in server-to-server communications and is only guaranteed to be valid for that use.
|