[This is an email copy of a Usenet post to "comp.unix.bsd.openbsd.misc"]
On Sat, 31 May 2003 02:36:17 +0800, Thorsten Glaser wrote: >>tun0 stay up at the old address? route? mtu? > > No. No. No. Took some time until I had the chance to investigate: Fresh install of 3.3 along FAQ, first reboot, nothing but bringing up PPPoE: ifconfig up xl0 route -n flush ppp -ddial pppoe You' re right, it disconnects, but how ! When I remove the phone cable: nothing happens, route stays, tun0 - config remains, pfctl remains. To a 'down' interface. Only after I reconnect the cable will ADSL-modem start to negotiate for a new address; still at the 'old' route; the PF at the 'old' (tun0), because it's still configured. After (!!) negociation of a new identity (IP) will the tunnel device be reconfigured, followed by PF and route. The 'clean' approach is doubtless: ppp detects link down, takes out the route and deconfigures; followed by PF removing the NAT address. A re-negotiation for a new identity *must* only start after tearing down the previous states; followed logically by (re-)configuring the tunnel device (IP), adding the new route and adopting the new IP in PF. No 'overlap' of former and current states, ids, configuration must be permitted. Any undefined state is an invitation to exploits. Personally, I perceive dead routes lying around as very annoying. At least to me - and I'm not alone here - this excludes production environment. On top of this, we have such undesired effects as the earlier reported > 56 data bytes ping: sendto: No buffer > space available ping: wrote 219.94.39.65 64 chars, ret=-1 ping: sendto: > No buffer space available ping: wrote 219.94.39.65 64 chars, ret=-1 > ping: sendto: No buffer space available ping: wrote 219.94.39.65 64 > chars, ret=-1 as consequence of dead routes. NAT-ing and routing to an IP that by then might belong to someone else is nothing I'd expect to see in OpenBSD. Uwe
