Re: Temporarily changing DNS servers and search domains in Tiger
Re: Temporarily changing DNS servers and search domains in Tiger
- Subject: Re: Temporarily changing DNS servers and search domains in Tiger
- From: Allan Nathanson <email@hidden>
- Date: Fri, 3 Jun 2005 20:23:02 -0400
On Jun 2, 2005, at 9:19 PM, Nicholas Riley wrote:
On Jun 2, 2005, at 1:35 PM, Allan Nathanson wrote:
What you probably want to do here is create an [VPN] interface
which is layered on top of IPv4.
vpn = SCNetworkInterfaceCreateWithInterface(
kSCNetworkInterfaceIPv4,
CFSTR("edu.uiuc.vpn"));
Unfortunately, there are a couple of gotchas.
1. The code that shipped with Tiger won't allow the above call (I
included all of the "supported" types but left out the code to
allow "non-supported" types).
2. The Network Prefs pane isn't ready for non-standard interface
types.
3. Your configuration agent would still need to most of the work.
You'd still need to read the preferences, create the network
interface, establish the tunnel, and post information about the
"state" of your service. For a VPN service, it's the "state"
that's key to making everything work. Yes, you "could" store some
configuration information along with the preferences but that
information could also be pulled from the application(s) that
bring the tunnel up/down.
It would be good to file a bug report / enhancement request to
help track the issues.
Will do once I figure out what the issues are.
OK.
You can configure an ethernet interface (e.g. en0). You can
configure a PPP interface (e.g. ppp0). What you can't do is
configure a IPv4 address.
OK, this makes sense.
As to the crash, can you please file a bug report?
Sure, once I figure out what's going on (see below).
Which kSCNetworkInterfaceType should I be using? (The VPN is none
of the predefined types, e.g. kSCNetworkInterfaceTypePPTP or L2TP.)
Ideally, you'd establish your own custom type.
SCNetworkInterfaceGetSupportedProtocolTypes
(kSCNetworkInterfaceIPv4) returns NULL, which seems to contradict
the documentation.
This is correct since you can't run any network protocol types
such as IPv4 on top of an [IP] address. What you need to do is
layer a network interface on top of IPv4.
Er, right, sorry, I knew that. I meant SupportedInterfaceTypes,
not SupportedProtocolTypes.
A call to SCNetworkInterfaceGetSupportedInterfaceTypes
(kSCNetworkInterfaceIPv4) will report that you can layer L2TP,
PPTP, and 6to4 interfaces on top of the kSCNetworkInterfaceIPv4
interface and it's these layered interfaces that support the
various protocol types.
So, I tried using an existing interface type. This crashes the
same way SCNetworkServiceCreate(scPrefs, kSCNetworkInterfaceIPv4) did:
SCPreferencesRef scPrefs = SCPreferencesCreate(NULL, CFSTR
("VPN"), NULL);
SCNetworkInterfaceRef vpnInterface =
SCNetworkInterfaceCreateWithInterface(kSCNetworkInterfaceIPv4,
kSCNetworkInterfaceTypeL2TP);
SCNetworkServiceRef service = SCNetworkServiceCreate(scPrefs,
vpnInterface);
(gdb) bt
#0 0x9072cf24 in CFRetain ()
#1 0x9136705c in __SCNetworkInterfaceCreateCopy ()
#2 0x91366ff8 in __SCNetworkInterfaceCreateCopy ()
#3 0x913682e4 in SCNetworkServiceCreate ()
I also tried PPTP and 6to4, and setting an empty configuration
dictionary with SCNetworkInterfaceSetConfiguration, thinking
perhaps that was what it was trying to retain. Is this supposed to
work?
Yes, it's supposed to work but there's a bug in the code (which I
just found). A bug report has been filed.
The IPMonitor.bundle looks at all of the active network services
and, based on the service order established in Network Prefs and
any "OverridePrimary" keys, determines which service should be
"primary". Both the default route and the default resolver
configuration track the primary service.
If you *DO NOT* want the default route pointing to your VPN tunnel
but you *DO* want to change the default resolver configuration
than you're best option would be to "OverridePrimary" but specify
the same default route.
Sounds clear enough.
Also, if you only want to direct DNS requests to an alternate
resolver for a specific [set of] domain name[s] than you might
consider using Tiger's new "supplemental" DNS support. Briefly,
this is a mechanism to say "send DNS queries for the foo.bar
domain to a different DNS server. I can provide more details if
needed.
Yes, some information would be great. There is only one domain for
which we care about sending requests to our DNS server, so this
would solve the important part of the problem; the additional
search domains are nice but not essential.
Your code which establishes the VPN tunnel should (minimally) post
the following SCDynamicStore keys.
1. A State:/Network/Service/<serviceID>/IPv4 key containing
information about the tunnel.
Note: an empty dictionary will result in the DNS information
(below) being ignored
2. A State:/Network/Service/<serviceID>/DNS key containing the
following :
kSCPropNetDNSServerAddresses
an array of DNS server addresses
kSCPropNetDNSSupplementalMatchDomains
an array of domain names that you'd like to have directed to
these
DNS servers.
and that's all you should need to do to direct DNS queries for the
specified supplemental domains off to the alternate set of servers.
- Allan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden