On Jun 1, 2005, at 11:10 PM, Allan Nathanson wrote:
As in the past, the network configuration agents post information
to the SCDynamicStore (on a per-service basis) which reflects the
requested and derived DNS configuration. A configd plugin,
IPMonitor, collects all of this information and builds a DNS
configuration based on the current state. The change for Tiger is
that we have a new way of passing around the actual DNS
configuration to the resolver code. We left the /etc/resolv.conf
file in place to help any legacy code which looked at its contents
but the file is essentially a read-only copy of the configuration.
Makes sense.
Again, the State:/Network/Global/DNS key in the SCDynamicStore
reflects the generated configuration. Changing the value (which
you shouldn't have been doing anyway) won't have any effect.
I wasn't able to find anywhere that said you weren't supposed to
change these - but now I know.
Your VPN configuration agent/tool should publish a network service
with its desired DNS configuration.
Since the VPN tunnel interface doesn't show up in
SCNetworkInterfaceCopyAll(), and I need an interface before I can
create a service, should I use kSCNetworkInterfaceIPv4 or the current
primary interface as a parameter to
SCNetworkInterfaceCreateWithInterface (or something else?).
SCNetworkServiceCreate(scPrefs, kSCNetworkInterfaceIPv4) crashes, so
I imagine that is totally wrong.
Which kSCNetworkInterfaceType should I be using? (The VPN is none of
the predefined types, e.g. kSCNetworkInterfaceTypePPTP or L2TP.)
SCNetworkInterfaceGetSupportedProtocolTypes(kSCNetworkInterfaceIPv4)
returns NULL, which seems to contradict the documentation.
Having your VPN tunnel become the primary service is the simplest
solution (you'll capture both the default route and the default
resolver configuration). Other options are also available but they
are a bit trickier.
I'm not sure what you mean by "capture"; if necessary I guess I could
manually reestablish the default route once the DNS changes take
effect. Sending all traffic over the VPN interface is not really an
option.
Note: it's best to work with the system/network configuration
agents than to try and change things behind the scenes.
That's what I'm trying to do. :-) I would have done so earlier but
we were able to reuse our generic Unix code, which made Mac OS X a
lot lower of a priority.
Thanks very much for the response.
--Nicholas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macnetworkprog/email@hidden
