• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: DHCP Renew
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DHCP Renew


  • Subject: Re: DHCP Renew
  • From: Matt Mashyna <email@hidden>
  • Date: Thu, 7 Feb 2008 15:50:06 -0500

I found the Apple example in MoreSCF to mark the primary interface inactive trick. It works but it sure is slow to recover from this exercise. I need to find out eventually why this one device gives me a problem. It only happens when connecting via wifi. I didn't see a good way to determine the type of device the primary interface is. Is there one beside trusting that the name will always be "Airport" ?

Oh, another question: When you do the inactive trick, how can you tell when the interface is back in a state with the IP address assigned ? I mean, how can I tell when it's ready to use again ?

Thanks,
Matt

On Feb 6, 2008, at 2:40 PM, Peter Sichel wrote:

On Feb 4, 2008, at 11:34 PM, Matt Mashyna wrote:

I'm working on a VPN client and I've come across a situation that only appears to affect wifi tunnels and I'm not sure why. After the connection is up and running the host at the other end pushes some dns settings to the client and the client updates the current primary network set with them. When the connection goes down it removes the settings it added.

Are you fully restoring the previous router and DNS settings, and then "applying" the change to update the network stack?


Works fine for the most part. For some wifi setups the client is left in a bad state. It seems loose its routes. If a user goes into the network control panel and clicks the "Renew DHCP" button everything works again.

Notice the System Configuration Framework is a database store that is used to configure the
underlying BSD network stack. Normally, the "primary" or first active interface listed
in the network service order determines the router and name server address used to
configure the underlying network stack. When you "Apply" changes to the System
Configuration Framework, this should reconfigure the underlying stack.


I haven't been able to discover why the clients are left in this state but in the short run I would like to be able to renew the dhcp lease so the client isn't left unable to connect to a network until the user jogs the network settings. These is more that a user would tolerate.

Anyone have any ideas why this could be happening or how I can renew the lease programatically ?

My own IPNetMonitorX allows you to force the DHCP Lease to renew programmatically.
See the DHCP Lease tool described here: <http://www.sustworks.com/site/prod_ipmx_help/html/DHCPLeaseHelp.html >


Here's how I do it: I find the corresponding DHCP configured network service
in the System Configuration Framework and temporarily set it to be inactive
so client releases the active lease. To "Rebind", I set the service to
be active again.


To do this I add or remove the key "__INACTIVE__" for the corresponding
service in the SCF and then "Commit" and "Apply" the change. To make
changes to the SCF, you'll need a helper tool that can run with root
privileges. I wrote a tiny "ConfigDHCP" helper tool that is set
to SUID root during the first run authentication process.


Kind Regards,

- Peter Sichel
Sustainable Softworks




_______________________________________________ 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
References: 
 >Fwd: DHCP Renew (From: Peter Sichel <email@hidden>)

  • Prev by Date: Message-ID: <email@hidden>
  • Next by Date: Persistent HTTP connections...
  • Previous by thread: Fwd: DHCP Renew
  • Next by thread: Message-ID: <email@hidden>
  • Index(es):
    • Date
    • Thread