If I understand it correctly, it's discarding packets unless the local IP address of the tunnel device is equal to the local address of the port on which the encapsulated packets arrive. If you're using tunnelling to provide a public network service over private IP addresses, or vice versa, that's not particularly useful.
Perhaps the call to ip_dev_find_tunnel should use the source address of the incoming packet (compared against the ptp address of the tunl device), but the destination address of the _encapsulated_ packet (compared against the local address of the tunl device)? Even this wouldn't do if packets for other than the local machine are being received over the tunnel.
Either way, it would have saved me a lot of time if I'd been able to find this behaviour explained in the documentation.
The following patch will return to the old behaviour by default, but if you define CONFIG_IP_DRACONIAN, it'll at least warn you that it's dropping the packets and not just broken. I suppose there ought to be a limit on the frequency with which it complains, to prevent a DOS attack, but...
--- ipip.c.virgin Tue Jul 29 17:36:00 1997
+++ ipip.c Tue Jul 29 17:36:06 1997
@@ -99,8 +99,16 @@
(vif=ip_mr_find_tunnel(iph->daddr, iph->saddr)) < 0)
{
#endif
+#ifdef CONFIG_IPIP_DRACONIAN
kfree_skb(skb, FREE_READ);
+ printk ("ipip: Received packet discarded - no symmetrical tunnel device.\n");
return -EINVAL;
+#else
+ dev = skb->dev;
+#ifdef TUNNEL_DEBUG
+ printk ("ipip: Received packet would have been discarded.\n");
+#endif
+#endif
#ifdef CONFIG_IP_MROUTE
}
IPCB(skb)->flags |= IPSKB_TUNNELED;
-- 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