On Fri, 16 Mar 2001 11:41:10 +0100 (MET), you wrote:
>On Fri, 16 Mar 2001, RoMaN SoFt / LLFB!! wrote:
>
>> On Thu, 15 Mar 2001 17:56:37 +0100 (MET), you wrote:
>>
>> >> 1) Could you exemplify this TOS field "hacking"?
>> >
>> >ipchains <yourmatchfields> -t 0x01 0x00
>>
>> Ummm. I don't get it to work... I've created the following test
>> ipchains rule (see log):
>>
>> goliat:~ # ipchains -F
>> goliat:~ # ipchains -A output -p tcp --source-port 20:21 -b -t 0x01
>> 0x00 -j ACCEPT -l
>
>Looks okay. Note that passive ftp return data is *not* necessarily on
>port 20 or 21...
>
>For testing I would try clearing the TOS field on *all* outgoing packets.
Another test:
- backup: another local machine routed via goliat (the multipath
gateway)
- goliat (the multipath gateway) configured as follows:
goliat:~ # ipchains -F
goliat:~ # ipchains -A output -t 0x01 0x00 -j ACCEPT -l
goliat:~ # ipchains -A forward -t 0x01 0x00 -j ACCEPT -l
goliat:~ # ipchains -A input -t 0x01 0x00 -j ACCEPT -l
(not all rules are really necessary but...)
Now:
backup:/usr/local/scripts # ftp 62.22.78.68
Connected to sniff.batmap.com.
220 Sniff FTP-Server ready
Name (62.22.78.68:roman):
421 Service not available, remote server has closed connection.
ftp: Login failed.
ftp: No control connection for command.
ftp> bye
backup:/usr/local/scripts #
Same error.
>> I only could imagine that TOS translation is being doing AFTER
>> multipath has acted. Is it possible? In this case, how to avoid it?
>
>Yes, that is theoretically possible, if you are ftp'ing directly from the
>machine that does the multipath routing.
I've demostrated the error persists although I use another machine.
>I've already paraphrased most of the complete config. What you may still
>need is rules and corresponding routing tables to do static non-multipath
>routing if you already have a source address for your packets. This would
I don't understand. What do you mean with "you have the source
address"? An normal IP packet always have a src address.
I think I'm going to write a new post detailing the problem with more
accurate logs and I'll post it to linux-kernel mailing list.
Ummm, I have another idea: as I did the TOS hacking upon launching
the previous ftp probes, perhaps "evil" routes keep on cached and
that's the reason TOS hack activation doesn't care. Could it be? I'll
have to re-look the adv.routing-howto, I don't remember how to clear
cached routes.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
** RoMaN SoFt / LLFB **
roman@xxxxxxxxxx
http://pagina.de/romansoft
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
