On Wed, Jan 09, 2008 at 07:36:41AM -0500, Robert Moskowitz wrote:
> But interesting
> that a redirect is a martian. Going to have to look that up. Martians
> is an area that I have not followed for years.
Martian tests are completely unrelated to the content of the
packets. They consider only the IP header itself and only those
elements which are relevant to routing decisions; with a normal system
and packet this is only the source and destination address fields. The
ICMP payload is not examined until after the packet has passed martian
tests.
Martian tests are not documented anywhere. The only place where the
behaviour is defined is the kernel source itself. I posted about this
last February; here's a repost of some of the more relevant bits
(archives suck too hard for me to find it):
On Fri, Feb 09, 2007 at 06:02:09PM -0500, Brian J. Murrell wrote:
> Lately I have been seeing "transient" (I say transient because the
> problem will persist for a while and then magically clear itself up some
> number of minutes later) situations where my gateway will log:
>
> Feb 9 17:23:45 gw.ilinx kernel: martian source 66.11.173.224 from
> 64.86.88.116, on dev eth1
> Feb 9 17:23:45 gw.ilinx kernel: ll header:
> 00:a0:24:2a:1f:72:00:13:5f:07:97:05:08:00
The message is somewhat obtusely phrased. The kernel has received a
packet from 64.86.88.116 to 66.11.173.224 on eth1, and it doesn't like
the source address for whatever reason, so it dropped the packet.
'Martian' is conceptually a collection of vaguely related objections
to the source address, at the time when the routing decision is made
(hence AFTER packet transformations in PREROUTING, so you can generate
it with sufficiently broken iptables rules).
In case it's of any use, here's the parts I do understand (2.6.19.1
behaviour, since I had that unpacked here):
The error message in question can be reached by two parts of the ipv4
routing code. The first is when fib_validate_source() returns an
error, and the second is the following bits of code from
ip_route_input_slow():
/* Check for the most weird martians, which can be not detected
by fib_lookup.
*/
if (MULTICAST(saddr) || BADCLASS(saddr) || LOOPBACK(saddr))
goto martian_source;
...
/* Accept zero addresses only to limited broadcast;
* I even do not know to fix it or not. Waiting for complains :-)
*/
if (ZERONET(saddr))
goto martian_source;
(I do not understand this comment, but the tests are all pretty
obvious - 0/8, 127/8, anything multicast, and anything in the
undefined space above multicast)
fib_validate_source() is sadly far harder to understand without going
through and figuring out how all the fib_* stuff works, which is quite
a lot of intricate, poorly commented code written by insane
people. Here's the sole comment, which hopefully resembles what this
function actually does:
/* Given (packet source, input interface) and optional (dst, oif, tos):
- (main) check, that source is valid i.e. not broadcast or our local
address.
- figure out what "logical" interface this packet arrived
and calculate "specific destination" address.
- check, that packet arrived from expected physical interface.
*/
This code corresponds to the rpfilter option on the interface, but it
does some other tests against the routing table even when rpfilter is
disabled - I don't know what to make of that.
As far as it makes sense to me (and this may be wrong), the algorithm
goes:
Swap the source and destination from the packet we're considering, and
look up the result in the routing table. If that doesn't work, reject
if rpfilter is enabled, otherwise accept.
If the route we find is not a gateway or direct route, reject (ie, if
it's multicast/blackhole/whatever).
If the route we find says to send the packet out the device on which
this packet was received OR (something I don't understand involving
multipath routes), then: reject if the scope of this route is 'host'
or 'nowhere', else accept.
If rpfilter is enabled on the interface where the packet arrived,
reject.
Modify the query (in some way I don't understand), and try looking it
up in the routing table again. If that doesn't work, accept.
If we did find a route this time, and it's not a gateway or direct
route, or its scope is 'host' or 'nowhere', reject.
Otherwise accept.
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
