On Fri, Feb 09, 2007 at 07:07:17PM -0800, Tom Eastep wrote:
> Brian J. Murrell wrote:
> > On Sat, 2007-02-10 at 02:29 +0000, Andrew Suffield wrote:
> >
> > If the kernel does essentially the same as this "ip route get" when
> > determining if an inbound packet is routable through the interface it
> > came in on I can see how it would fail and think it's a martian.
> >
>
> If you search the kernel source for the Martian message, you can read
> the relevant code.
I've read the code and I think this suggestion falls under "cruel and
unusual".
> When you understand it, I would be delighted if you
> could explain it to me.
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.
It's times like this when I remember why I make a point of never doing
any actual work on the kernel.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
