> > 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 -
...
>
> 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?
Sure, you are right, but reread the statement that I stressed above.
> 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?
You are absolutely right here.
> Another thing I'd like to do is add IPIP compression to the tunnel driver.
> What's the best way to go about it?
I believe you need to invent new protocol and register it to avoid
conflicts :-)
> Is there an alternative protocol to IPPROTO_IPIP which
> indicates that the encapsulated packet is compressed,
I never heard.
> 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?
Nope, it should not be IPIP. Unfortunately, IPIP protocol is
interpreted specially by several IP stacks. It is not worth
to confuse them.
> If I'm doing such things, I suppose I ought
> to add hooks for encryption, too.
What's about encryption it may be done by adding ESP header.
Alexey Kuznetsov.