On Fri, 2006-10-06 at 07:16 -0400, James Carlson wrote: > Kacheong Poon writes: > > Could Seb please comment on the IP tunnel service? I guess tunnel > > links can only be setup after there is network connectivity. So > > it makes sense to have the tunnel service dependent on milestone/ > > network. > > Requiring that network interfaces be set up before setting up tunnels > sounds to me like a bug, not a feature.
The only aspect of this that smells like a feature is the fact that if you fat-finger the source address of a tunnel, the UI will return an error rather than letting you figure that out later when you realize there is no connectivity through the tunnel. > A tunnel is a detached object. It doesn't explicitly use any > particular underlying network interface. It does explicitly use a particular underlying fixed IP source address, much like any application that binds to a specific local address, so it's not at all completely "detached" from other networking objects on the system. > This means that as routes and interfaces come and go with time, > a given tunnel may or may not actually be usable. The reachability of a tunnel destination through the forwarding table is not a currently factor when creating a tunnel. Regardless, your statement is true. I just wanted to make the current behavior of the system clear for the purpose of this discussion. > It might be nice to > have the dynamic local routing and interface state reflected in the > tunnel as IFF_RUNNING, but it seems like a mistake to me to require > this state to be present in order to configure the tunnel in the first > place. The only state currently required is the existence of the IP address that the administrator has chosen to use as the source address of the tunnel. > It's a mistake at least for the reason that it makes configuration > indeterminate: there's no way to know whether any given configuration > attempt will succeed or fail, as the required underlying facilities > might slip out from under you as you configure the tunnel. It makes > configuration itself unreliable. I see your point, although in 99.9% of cases, if you type "ifconfig -a" and see an IP address there, and you try to configure a tunnel using that IP address five seconds later, you'll succeed in creating the tunnel. If that IP address disappeared in the mean time, then I'd venture to say that this would normally not be what the administrator expects, and something needs to be fixed. An error condition being returned by the tunnel creation wouldn't be entirely unexpected or puzzling to the administrator. > Yes, I know that's how it works today. I think it's a bug, though. I > don't like the idea of codifying bugs and design errors into SMF > dependencies. Fixing the tunnel module's behavior isn't entirely obvious. The existing tunneling implementation is simple. When a tunnel is created, the tunnel module binds with ip to receive packets destined to a specific IP address (the tunnel's source). If that bind fails, then the creation also fails. To fix this, the tunnel module would need to register to receive events of IP address creation. When such an event is received, it would then need to see if any tunnels not currently bound need to be bound to that IP address. If so, then it needs to hurry up and bind before that IP address disappears again. ;-) This would probably be made easier using the netinfo stuff being provided by the Packet Filtering Hooks project... -Seb
