A "punchin" location (with all the appropriate nameservers, pointers to ipsec/ike files, etc and any other appropriate location configuration) seems to be the way to go. punchin activates this location as part of the "start" process. I've been thinking about this for a while but never got to it as nwamd still has issues and non-trivial bugs keep coming up.
Anurag Darren Kenny wrote: > On 10/06/2009 16:47, Paul Wernau wrote: > >>> The main one is the "Hangup caught" which is a likely refresh of the SMF >>> service, and it seems that punchin does this in the nwam_nss function in >>> cleanup.solaris.kshlib, which does a refresh of nwam, to get the update to >>> the >>> SMF property: >>> >>> nwamd/use_net_svc >>> >>> which isn't present for NWAM Phase 1... >>> >>> The attached patch to punchin fixes this by first checking that the property >>> exists, if not, then don't try set it or refresh nwam. >>> >> This parameter was added in NWAM phase 0 specifically for tools like >> punchin and netprof and other things that want control of things like >> resolv.conf, default routes, etc. to tell NWAM to "lay off until I tell >> you otherwise". >> >> I've integrated your change, but if we don't implement the new network >> profiles, will NWAM go merrily reconfiguring the network every time it >> gets a DHCP update? Or will this just work persistently? >> >> Note I am not opposed to changing the network setup to use a profile if >> that's what is required but want to make you aware of the original >> issues we saw. >> >> > Understood. > > My experience at the moment is this, but part of it is a bug in the wireless > handling: > > When I'm punched in, every couple of minutes my wireless is reconnecting > (a bug in nwamd) and as such, this causes the Automatic Location to > re-evaluate, which in turn does two things: > > a) Takes ike SMF service down > b) Re-populates the /etc/resolv.conf file with the interface's DHCP provided > DNS info. > > I've a hack around this, using the script below, but it's really a hack as I > say... > > If my network was more stable - e.g if I was using a wired connection, this > may not be necessary any more. > > I do know that at one point, before the latest changes to the nwamd state > machine internals, any time I brought up punchin, which created a tunnel, > then nwamd would react to this and re-evaluate the Automatic Location, thus > causing the same issue in that it stops ike and re-populates > /etc/resolv.conf - but in contrast, this used to only happen within a short > period of the initial connection, and I didn't need a looping script to > handle it since I only needed to do the change once for each > "punchin start". > > I don't know how to get the DNS information from the tunnel since it's not > using DHCP, but we would need to have nwamd use these settings instead but > since nwamd knows nothing about the ip tunnels right now, it's not clear how > to do that. > > I suppose that this is what the concept of an External Network Modifier (ENM) > is meant to be - but now that I think about it, I don't know how if nwamd > would behave any differently if an ENM was active that did similar things to > punchin... Especially when it comes to the DNS information and the Automatic > Location profile, but I'm no expert on the inner workings of nwamd. > > I guess it's over to the main NWAM developers to provide that side of things, > I think that I've reached my limits of knowledge here. > > Thanks, > > Darren. > > > --- Simple script to keep ike running and update /etc/resolv.conf --- > while true; do > if [ `svcs -H -o state ike` != online ]; then > if punchctl punched_in; then > echo "Re-enabling ike, and restoring resolv.conf : `date `" > svcadm enable ike > cp /etc/resolv.conf-GMP2 /etc/resolv.conf > fi > fi > sleep 15 > done > > _______________________________________________ > nwam-dev mailing list > nwam-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/nwam-dev >
