Date: Thu, 30 Jan 1997 08:25:43 +1100 (EDT) From: Darren Reed <avalon@coombs.anu.edu.au> To: cmott@srv.net (Charles Mott) Cc: hackers@freebsd.org Subject: Re: ipdivert & masqd Message-ID: <199701292125.NAA22302@freefall.freebsd.org> In-Reply-To: <Pine.BSF.3.91.970129134431.969D-100000@darkstar> from "Charles Mott" at Jan 29, 97 01:58:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Charles Mott, sie said: > > > But anything after the 512th data byte in the TCP payload will be ignored, > > so if your message is 512 bytes long, contains a DCC request in it, > > information will be lost that the sender is not aware about (this assumes > > the packet is just one IRC message) if the payload size must increase as > > a result. > > > > It is a *much* better idea to redirect IRC to a local TCP port and process > > it using a proxy agent. Same could also be said for FTP. > > > > Darren > > Darren, > > In theory, one can construct cases where the FTP logic in the packet > aliasing software won't work (IP fragmenting a PORT command, or where the > PORT command is split between TCP packets with different sequence numbers, > or where the PORT command is in the middle of a packet, and so forth). > > In practice, these situations are not seen, and the packet aliasing > software works for FTP. The system loading is very low, and the software > easily scales to situations where there are large numbers of users. > > I don't know about IRC, but my guess is that the real situation is simpler > than the theoretical. Whatever Linux does to handle IRC, I am told that > it looks fairly similar to what one does for FTP. Well, in practice, the TIS FWTK/Gauntlet was sending the FTP PORT command in two packets, so that Linux would break and so too did Firewall-1. Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701292125.NAA22302>