mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Feb 2012
Posts: 1
I
Mostly harmless
OP Offline
Mostly harmless
I
Joined: Feb 2012
Posts: 1
I'm using an IRC proxy, and mIRC (and only mIRC) is having trouble connecting to it. Upon investigation with Wireshark, it turns out that mIRC is sending IRC commands terminating them only with line feed (LF).

The IRC protocol, however, demands that commands be terminated with carriage return + line feed (CR+LF).

Any reason for this issue? mIRC has been around for so long that it seems unlikely this is just an oversight...

Joined: Aug 2006
Posts: 167
P
Vogon poet
Offline
Vogon poet
P
Joined: Aug 2006
Posts: 167
The only proxy types mIRC supports are SOCKS4, SOCKS5, and HTTP CONNECT (the one it calls "Proxy"). SOCKS4 and SOCKS5 tunnels are setup with pure binary interactions, making linefeeds irrelevant in their cases. And while HTTP CONNECT does establish tunnels with linefeed-terminated text commands, I checked, and mIRC send them CRLF-terminated lines.

So I'll assume that by "IRC proxy," you must actually mean a bouncer (BNC), and that your bouncer itself is not accepting mIRC's LF line termination. All I can say to that is this. Very often, when a protocol (like IRC) demands that lines be terminated with a specific line termination sequence (like CRLF), the authors of the relevant server softwares will ignore that demand and code their daemons to accept CR, LF, or CRLF, anticipating clients which will inevitably break the protocol in that regard. (Attempts at linefeed format conformance have historically been like herding cats, and because of that, many software authors quietly ignore them in favor of coding support for every format permutation.) Anyway, I don't know why mIRC was written to send LF-terminated lines, but it has sent them that way for as long as I can remember. And since I've never seen reports of IRC servers refusing its non-compliant linefeeds, it seems reasonable to assume that in the IRC world, all servers accept LF termination.

I guess you have three options:

1. Report this as a bug in this forum's bug reports area, and name as many BNC(s) as you can think of which refuse LF line termination to emphasize the need for getting this problem fixed.

2. Ask the author of your BNC to make it compatible with non-compliant clients (the way IRC servers themselves all seem to be).

3. If you know how, use mIRC scripting to create a listening TCP socket on 127.0.0.1 which tunnels inbound connections to your BNC and which adds a CR before every LF in any data going in the you-->bnc direction. Maybe someone can help you with this in the forum's scripting area. The basic idea is, you would type "/server 127.0.0.1:12345," and then due to your script, mIRC would intercept its own server connection, forward it to the real destination, and patch it for IRC protocol compliance as it goes. smile

(I have never used it, but there is already a scripting package capable of turning mIRC into a generalized proxy server at http://www.mircscripts.org/comments.php?cid=2120. As opposed to rolling your own socket calls, you could try that and merely modify it to perform unidirectional LF -> CRLF patching. Plus, this way, since you would be configuring mIRC to use it via ALT-O > Connect > Proxy, you would be able to use the /server command as you normally would.)


Link Copied to Clipboard