> It was deliberate breaking. The problem was that tdev jumps, when
> real route to peer changes. tunnel->pa_addr could be set equal to
> tdev->pa_addr, if you believe that route is static. Particularly, it
> means that the host with tunnel cannot talk over tunnel itself.
But using dev->pa_addr means that you can't tunnel a private network over the
public internet (or vice versa) without using invalid source addresses on the
host network - for example if I set up a 10.x.x.x private network which is
tunnelled across the internet, then the IPIP packets will appear to come from
the invalid 10.x.x.x source address, and will generally get firewalled out
somewhere along the line before they reach the destination decapsulator!
Surely the IPIP packets should have valid source addresses on the host
network, which means using tdev->pa_addr? In fact, can't this be done
automatically by the IP output code? Normal IP packets get given the IP
address of the output device when they're sent, don't they?
If using the output device's IP address isn't deemed suitable because it may
confuse the filter at the other end if it changes with dynamic routing, then
IMHO the problem is with the filter - maybe we should use a private ioctl to
set a list of addresses from which the decapsulator will accept packets?
Another thing I'd like to do is add IPIP compression to the tunnel driver. What's the best way to go about it? Is there an alternative protocol to IPPROTO_IPIP which indicates that the encapsulated packet is compressed, or should I just compress the original packet before packaging it and rely on the IPIP decapsulator to notice that it's not a valid IP packet, but is in fact compressed data? If I'm doing such things, I suppose I ought to add hooks for encryption, too.
-- David Woodhouse, CB3 9AN http://dwmw2.robinson.cam.ac.uk/ dwmw2@cam.ac.uk Tel: 0976 658355 D.W.Woodhouse@nortel.co.uk Tel: 01279 402332