/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting!
/* ALSO: Don't quote this header. It makes you look lame :-) */
Hi,
First: sorry this is one long slog of an e-mail, so
get yer tea / coffee / beer first ;-) ...
I've been trying to work out exactly why mIRC's dcc
resume doesn't work with ip masquerading for some time
now, and my hunt has led me to the source of the
ip_masq_irc module. After finding the newest version
from kernel 2.2.18 (is there a more recent version
than this?) and glancing through, it appeared to look
ok for dcc resume, but I've discovered that this is
not the case.
The problem (as far as I can tell) is that the
ip_masq_irc module still doesn't appear to recognise
the dcc resume and dcc accept strings properly. This
is largely due to the broken way which the mIRC
protocol has been devised, but to highlight the
differences (as I understand it, I'm no coding expert
but I know enough to see what's going on, I think):
>From the ip_masq_irc source:
* strlen("\1DCC ACCEPT F AAAAAAAA P S\1\n")=28
which in other words assumes the structure of the dcc
accept string to consist of a filename, address, port,
and filesize (or resume point). Likewise
>From the ip_masq_irc source:
* strlen("\1DCC RESUME chat AAAAAAAA P\1\n")=29
the assumption here being that the dcc resume string
consists of the tag 'chat' followed by an address and
port (please do correct me if I'm getting the wrong
end of the stick here).
The main problem I can see is that mIRC constructs
these strings in a different way. The help file for
mIRC describes the raw messages to look like this:
PRIVMSG User1 :DCC RESUME filename port position
PRIVMSG User2 :DCC ACCEPT filename port position
(which in the ip_masq_irc source lingo would be
* strlen("\1DCC RESUME F P S\1\n")=20
* strlen("\1DCC ACCEPT F P S\1\n")=20
)
It also states that the filename component is
redundant and is replaced by the generic name file.ext
in all newer versions of mIRC for backwards
compatability, thus relying on port number alone to
identify the send. Obviously without translation at
the masquerading point the port number won't get
changed in the dcc resume string so it won't match the
original send port number and the resume is rejected.
(I remark at this point that on one occasion the masq
module translated the internal port number to an
identical external port number, so that the masqed
computer's idea of the port number was the same as
that of the puter at the receiving end. The dcc resume
request succesfully negotiated and send transfer
comenced at the resume point as normal. Ironically my
modem cut before the send completed, but such is life
:-)
My question is: could this be (or has this been)
easily fixed? I lack sufficient understanding of the
detail of the source to be able to fix it myself and I
would very much like to get those dccs properly
working again :-)
--
>From Phil
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie
_______________________________________________
Masq maillist - [EMAIL PROTECTED]
Admin requests can be handled at http://www.indyramp.com/masq-list/ --
THIS INCLUDES UNSUBSCRIBING!
or email to [EMAIL PROTECTED]
PLEASE read the HOWTO and search the archives before posting.
You can start your search at http://www.indyramp.com/masq/
Please keep general linux/unix/pc/internet questions off the list.
