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: Nicholas Riley <email@hidden>
- Date: Thu, 2 Jun 2005 20:19:31 -0500
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.
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?
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.
Thanks again,
--Nicholas
_______________________________________________
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