Messages in this thread | | | Date | Thu, 18 Feb 1999 13:25:13 +0000 (GMT/BST) | From | Mike Jagdis <> | Subject | More 2.2.x routing fun |
| |
In net/ipv4/route.c: ip_route_output_slow() we have the following:
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/
| |