All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rennie deGraaf <degraaf@cpsc.ucalgary.ca>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@lists.netfilter.org
Subject: Re: ip_rt_bug in mangle/OUTPUT
Date: Tue, 05 Jun 2007 14:20:26 -0600	[thread overview]
Message-ID: <4665C58A.6070401@cpsc.ucalgary.ca> (raw)
In-Reply-To: <4655D083.8070309@trash.net>

[-- Attachment #1: Type: text/plain, Size: 2094 bytes --]

Patrick McHardy wrote:
> Rennie deGraaf wrote:
>> I seem to be getting the error message
>>     ip_rt_bug: 10.1.1.1 -> 10.0.1.2, ?
>> whenever I attempt to send a packet with a non-local source IP address
>> (my local IP address is 10.0.1.2) from libipq in mangle/OUTPUT.  I have
>> observed this behaviour under Linux kernels 2.6.20.7 and
>> 2.6.18-1.2257.fc5smp (Fedora Core 5), and iptables versions 1.3.5 and
>> 1.3.7.
>>
>> I'm trying to simulate connections with remote hosts by redirecting
>> packets to servers listening on localhost.  My strategy is to send
>> packets to IP_QUEUE from rules in the mangle/OUTPUT chain: destination
>> addresses are re-written on packets that I want to redirect, source
>> addresses are re-written on packets on responses to redirected packets,
>> and other packets are passed without modification.  A simplified, highly
>> stripped down version of my program is attached.
>>
>> To run my example program, you need rules in your mangle/OUTPUT chain
>> forwarding packets to 10.1.1.1:123/TCP and from 127.0.0.1:22/TCP to
>> QUEUE, and something listening on 127.0.0.1:22/TCP.  If it worked
>> properly, a connection could be successfully established to
>> 127.0.0.1:22/TCP by connecting to 10.1.1.1:123/TCP (using telnet, for
>> instance).
>>
>> Do any of the gurus on this list know how I might fix or work around
>> this issue?
> 
> 
> If you don't need the rerouting to be happen (you only change the
> source address and don't use routing rules based on that) you can
> simply return NF_STOP instead of NF_ACCEPT. It will do exactly
> the same thing but avoid rerouting.

That solution worked well on recent kernels.  Unfortunately, my boss now
wants my code to work on Linux 2.6.9, which doesn't appear to have
NF_STOP.  (It seems to have been added in 2.6.12.)  Can you think of any
other work-arounds, short of dropping the packets and re-injecting the
modified versions through raw sockets?

In the meantime, I'll try to convince my boss to upgrade to a more
modern kernel.

Thanks,
Rennie deGraaf


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2007-06-05 20:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-23 21:12 ip_rt_bug in mangle/OUTPUT Rennie deGraaf
2007-05-24 17:50 ` Patrick McHardy
2007-05-24 21:22   ` Rennie deGraaf
2007-06-05 20:20   ` Rennie deGraaf [this message]
2007-06-06 11:36     ` Patrick McHardy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4665C58A.6070401@cpsc.ucalgary.ca \
    --to=degraaf@cpsc.ucalgary.ca \
    --cc=kaber@trash.net \
    --cc=netfilter-devel@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.