if (LOOPBACK(key.src) && !(dev_out->flags&IFF_LOOPBACK)) {
printk(KERN_DEBUG ... );
return -EINVAL;
}
i.e. if the source address starts with 127 and the destination
interface does not have the loopback flag we ignore the route
that got us here and dump the packet.
Now I can see why this might have been considered a good idea.
A remote host would not be able to reply to a 127 sourced address.
But who is to say that the interface *is* to a remote host or
network? Many people running diald with their provider giving
dynamic addresses have used things like 127.0.0.2:127.0.0.3 for
diald's proxy. This is perfectly ok - if the packets ever do
get sent out the real link they get their source address updated
(remember the dynaddr patch?). It is legal to send 127 sourced
packets on diald's proxy interface, we have no way of setting
the loopback flag on it, and setting the loopback flag would
be wrong anyway since code uses that to avoid talking to
themselves and thus would ignore the link.
This is another of those undocumented changes. It's a "2.2 breaks
my setup" situation which requires you to read the kernel source
to find out what is happening. Not funny...
And I thought we'd managed to reclaim some of the wasted address
space under 127 :-(.
Is there some good reason why this bloat is there? I mean, if you
don't want 127 addresses going out of an interface why not just
not route them there? Isn't the fact that a route exists an indication
it was wanted???
Mike
--
A train stops at a train station, a bus stops at a bus station.
On my desk I have a work station...
.----------------------------------------------------------------------.
| Mike Jagdis | Internet: mailto:mike@roan.co.uk |
| Roan Technology Ltd. | |
| 54A Peach Street, Wokingham | Telephone: +44 118 989 0403 |
| RG40 1XG, ENGLAND | Fax: +44 118 989 1195 |
`----------------------------------------------------------------------'
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/