Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Creating a kill switch for the OSX VPN client Network
I live in China so I have to use VPN all the time if I want any kind of stable connection to sites in the west. Unfortunately the VPN will at times randomly disconnect and then all traffic will immediately start going over chinese Internet again. While this is not a big deal really, I would just prefer not to be logged in to Facebook or Gmail and have my traffic open to be sniffed by the great firewall. It also occurred to me that many people use VPNs in the states in order to safely torrent.

I know some VPN providers have 'Internet kill switches' for their VPN that will cut your Internet connection incase of a disconnect and make sure you are not leaking anything. The problem with these is that they are almost all using openVPN, while I use L2TP over IPSec for my VPN. I searched for a long time for a way to do this and could not find one so I thought of a way to do it on my own. The following is how I set my system up. Please keep in mind that I am not an experienced Terminal user or power user so if anyone knows of a better way to do this please let me know.
read more (1,035 words)   Post a comment  •  Comments (0)  
  • Currently 1.19 / 5
  You rated: 4 / 5 (54 votes cast)
[15,467 views]  View Printable Version
10.9: Enable experimental network commands Network
Many advanced network configuration commands can be reached with the scutil command line tool. Launch and run:

ENABLE_EXPERIMENTAL_SCUTIL_COMMANDS=1 scutil --net, then type help and press the Return key to see the available options.

For example:
localhost:~ user$ ENABLE_EXPERIMENTAL_SCUTIL_COMMANDS=1 scutil --net
set "Automatic" selected
> help

Available commands:

 help                          : list available commands file                   : process commands from file
 quit [!]                      : quit

 commit                        : commit any changes
 apply                         : apply any changes

 create interface  [  |  ]
 create protocol 
 create service [  |  [  ]]
 create set [setName]

 disable protocol [  ]
 disable service  [  |  ]

 enable protocol  [  ]
 enable service   [  |  ]

 remove protocol  [  ]
 remove service   [  |  ]
 remove set       [  |  ]

 select interface  |  | $child | $service | $vlan | $bond  | $bridge 
 select protocol  
 select service    | 
 select set        | 

 set interface context-sensitive-arguments (or ? for help)
 set protocol  context-sensitive-arguments (or ? for help)
 set service   [ name  ] [ order new-order ] [ rank ( | First | Last | Never) [temp] ]
 set set       [ name setName ] | [ current ]

 show interfaces
 show interface [  |  ]
 show protocols
 show protocol  [  ]
 show services  [ all ]
 show service   [  |  ]
 show sets

 show set       [  |  ]

 update                        : update the network configuration


[crarko adds: I haven't tested this one. Obviously be careful before using the commands. I'd suggest making a log of any changes made, and understand how to undo them. This would be a good time to do a full system backup.]
  Post a comment  •  Comments (1)  
  • Currently 1.28 / 5
  You rated: 1 / 5 (25 votes cast)
[15,974 views]  View Printable Version
Make Time Machine use a Local Volume as a Network Volume Network
This procedure shows you how to prevent Time Machine from using all available free space on a local volume by backing up to a sparse disk image bundle stored on a shared folder on a local volume.

Time machine uses a feature of the HFS+ filesystem that was introduced in Mac OS X 10.5 (Leopard) called 'directory hard links.' Like file hard links, a directory that is hard linked to another directory is not actually a distinct directory, but is instead a pointer to the original directory. Time Machine uses these directory hard links to reduce duplication and save space by making references to entire directory trees whose contained files have not been modified. To properly copy or duplicate a Time Machine backup, these directory hard links must be preserved. Unfortunately, directory hard links are proprietary to Apple. Apple discourages their casual use by third party developers because, if used incorrectly, they could create recursive directory structures that would render a volume effectively useless. This introduces obstacles to anyone wishing to make copies of a Time Machine volume.

Time Machine may be configured to back up to a local volume that is connected directly to a Mac (either internally, or externally with a Firewire or USB connection), where it creates a Backups.backupdb folder at the root of the volume, storing all of the backup data in the volume's native file system using the previously mentioned directory hard links. Unfortunately, Time Machine will not back up to a local directory, but instead requires an entire volume be dedicated to backups. Further, Time Machine will utilize as much free space as possible on the volume. To prevent Time Machine from filling a disk, you could partition the disk to create multiple volumes, dedicating only one of the partitions to Time Machine backups. Yet you would still have no easy way to copy the backup data off the partition, due to the directory hard links.

Time Machine may also be configured to back up to volume that exists on a remote Mac and is mounted locally as a shared network volume. In this configuration, Time Machine creates a sparse disk image bundle which contains its own internal file system where backup data is stored. Since the backup data (with directory hard links) is stored within a self-contained disk image, one can easily make a copy of the entire disk image without worrying about effecting the directory hard links contained within the disk image. For this reason, backing up to a shared volume could be preferable for those who don't want to dedicate an entire volume to backups, or who want to be able to easily make file system level copies of the backup data for added security.
read more (475 words)   Post a comment  •  Comments (9)  
  • Currently 3.17 / 5
  You rated: 3 / 5 (6 votes cast)
[9,045 views]  View Printable Version
Mount a SanDisk Connect Wireless Flash Drive Network
The SanDisk Connect Wireless Flash Drive includes all the benefits of a regular flash drive plus wireless mobile access.

Sandisk gives you an app that allows you to connect to the Flash Drive's WiFi and transfer files. You can either connect via USB on the Mac or connect using a WiFi network. But what was not very clear was how to do this if you wanted to connect to the drive and upload or download files to and from your Mac wirelessly.

I tried to do this once I had connected to the drive's WiFi network and using a browser (as they suggest) to connect to the given URL. The address is served from the Flash Drive's WiFi network and in turn shows you the files on the drive. But I could not see my files and realised the page was being directed via my Ethernet connection across the Internet to a SandDisk page telling me the drive was not connected.

Turning off the Ethernet connection fixed this but it was not especially convenient. And the webpage that shows the files on the Disk is basic HTML which does not allow you to upload files.

The goal was to not have to disconnect the ethernet and have the SanDisk URL only connect over WiFi. And then to be able to upload or download files on the Mac over WiFi and not have to plug the drive into a USB port. The flash drive uses a simple server so using its IP address I then tried to connect to it via my FTP program (Transmit). The connection was refused. So instead of using FTP protocol I tried WebDav.

I had set already set a password using the Sandisk app but the connection just ignored this fact and just connected. The folders and files where listed and I could send and pull files no problem, and I did not need to disconnect from ethernet.

The other thing to note is you can use Bonjour and connect to the flash drive within Safari. But you will not be able to do much. The best way is to use an FTP program that can use Bonjour or WebDav. The drive it seems has a .local name along the lines of sandiskxxx.local. The xxx is probably part of its MAC address.

[crarko adds: This sounds like a cool, if somewhat pricey, device. It looks like it's also intended to be used with iOS, Android, and Kindle. It would be worth also trying an SMB connection, although WebDAV looks like it is the native protocol. SanDisk says it supports Snow Leopard and up.]
  Post a comment  •  Comments (11)  
  • Currently 2.43 / 5
  You rated: 2 / 5 (7 votes cast)
[11,840 views]  View Printable Version
Let VNC viewers connect to currently logged in user Network
Want to connect with the currently logged in user when using a VNC viewer rather than seeing the Login Window (ARD 3.5/OS X 10.7 and later)?

sudo defaults write /Library/Preferences/ VNCAlwaysStartOnConsole -bool true
  Post a comment  •  Comments (4)  
  • Currently 3.33 / 5
  You rated: 2 / 5 (6 votes cast)
[12,284 views]  View Printable Version
Find devices connected to your AirPort base station without AirPort Utility 5.6 Network

AirPort Utility 5.6 could show you all the devices connected to your AirPort base station—wired and wireless alike. AirPort Utility 6.x, however, only lists devices connected to your base station over Wi-Fi. There’s no way to use the app to list off the IP addresses and names of devices plugged directly into the base station.

You can stil grab the old version of the utility from Apple, though you need a little help to install the app on Mountain Lion, since the installer (falsely) reports that AirPort Utility 5.6 is incompatible with Mac OS X 10.8.

But while you can force AirPort Utility 5.6 to install on Mountain Lion, there’s no guarantee that the app will continue to work on OS X 10.9 Mavericks or beyond. So if you want to find the IP addresses of other devices connected directly to your base station, you might prefer another option.

There are several.

In Terminal, you can use the arp -na command, which will list out devices it finds using the address resolution protocol. You won’t necessarily see friendly names for the devices it finds, but you’ll at least get a list of all the local IP addresses in use that it discovers.

You can also turn to multiple third-party apps. One such app, iNet, is available on the Mac App Store. There are iOS apps for the same purpose, like the free Fing and the $3 LAN Scan.

Those apps will, if possible, list off friendlier device names (in addition to IP addresses) than arp -na offers.

  Post a comment  •  Comments (9)  
  • Currently 3.00 / 5
  You rated: 5 / 5 (7 votes cast)
[36,908 views]  View Printable Version
How to set up a Mac as a PXE boot server, with Debian Live Network
Here is how to set up a Mac, running OS X Client 10.5 or later, as a PXE boot server.  We will configure OS X's built-in DHCP, TFTP, and NFS servers, start the servers, and put the client boot files in place.  (The NFS server may be optional, depending on the operating system we are booting.)

You'll need the Mac, a PXE-capable PC, and an ethernet cable.  Some steps will require being logged in as an administrator on the Mac.

We'll boot Debian Live on the client PC as an example.  We'll show a regular setup with NFS, an alternate setup without NFS, and how to uninstall.
Regular setup (with NFS):
  1. Connect the Mac and the client PC with the ethernet cable.

  2. On the Mac, in System Preferences > Network, click "Ethernet" and enter the following settings:
    Configure IPv4: Manually
    IP Address:
    Subnet Mask:
    (All others can be left blank)
    Note the status may read "Cable Unplugged" at this point, which is ok.

  3. In Terminal, make new directories /srv and /srv/debian-live (we'll be sharing /srv/debian-live over NFS) with the following commands:
    $ sudo mkdir /srv
    $ sudo mkdir /srv/debian-live
  4. To create the NFS configuration file, enter the following command:
    $ sudo nano /etc/exports
    paste the following text into the editor:
    /srv/debian-live -ro -network -mask
    and press Control-O to save and Control-X to exit nano.

    This will share /srv/debian-live to the ethernet network as read-only.

    For more information, type man nfsd and man exports in Terminal, and see this hint.

  5. Check the /etc/exports file created in step 4 (no output means ok):
    $ nfsd checkexports
    check the status of the NFS server (should say enabled and running):
    $ nfsd status
    and check the server's exports list (should show the /srv/debian-live directory):
    $ showmount -e
    For more information, see man nfsd and man showmount.

  6. To create the DHCP configuration file, enter the following command:
    $ sudo nano /etc/bootpd.plist
    paste the following text into the editor:
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
    <plist version="1.0">

    and press Control-O to save and Control-X to exit nano.


    • If the file /etc/bootpd.plist already exists, turn off Internet Sharing in System Preferences > Sharing.  Then the file will be removed, and you can create it as in this step.

      (Make sure to move /etc/bootpd.plist to the Trash and disable the DHCP server before turning Internet Sharing back on.  See "Uninstall steps" below.)

    • If you are using an ethernet port other than en0 (see System Information or System Profiler for the port name), change the value for the dhcp_enabled key to the port you are using.

    • The data for the dhcp_option_67 key is the bootloader filename "pxelinux.0" (see step 9 below), null terminated and encoded into base64.  This can be generated with the free DHCP Option Code Utility, or by entering the following command in Terminal:
      $ printf %s00 `echo -n pxelinux.0 | xxd -p` | xxd -r -p | openssl base64
      (See this discussion thread.)

    • The string for the dhcp_option_66 key is the IP address of the tftp server, i.e. the address of the Mac from step 2.

    • See man bootpd and man tftpd.

  7. Enable the DHCP and TFTP servers with the following commands:
    $ sudo launchctl load -w /System/Library/LaunchDaemons/bootps.plist
    $ sudo launchctl load -w /System/Library/LaunchDaemons/tftp.plist
    See man launchd, man launchctl, man launchd.plist, and this article.

  8. Download a Debian Live netboot archive, gnome-desktop or another flavor, from one of the following (choose i386 or amd64 depending on the client PC's architecture):

    Place the .tar.gz file on the Desktop (or anywhere convenient), then double-click it to expand the archive.

  9. Open the folder that is created (with a name like "debian-live-6.0.7-i386-gnome-desktop-net"), open the "tftpboot" subdirectory, select all of the files, and move them to /private/tftpboot.  (This includes the pxelinux.0 file mentioned in step 6, and other boot menu and kernel files.)

    Note that files in /private/tftpboot should be readable by everyone (so they will transfer), but not writeable by everyone (so they can't be modified).  Check permissions with Get Info or ls -l if needed.

  10. Click the Back button to leave the "tftpboot" subdirectory, then open the "debian-live" subdirectory, then select the folder called "live" and move it to /srv/debian-live.  (When Debian Live is booting, it will look for the file /srv/debian-live/live/filesystem.squashfs over NFS, which contains the root filesystem.)

  11. Optionally, test the TFTP server:
    $ tftp localhost
    tftp> get pxelinux.0
    tftp> quit
    $ ls -l pxelinux.0
    You should see that a copy of the file pxelinux.0 has been downloaded to the current directory.

  12. Turn on the client PC, and press or hold the key to bring up the boot options (something like F2 or F12; check the documentation for your machine or look for a message onscreen).

  13. Choose to boot from the network (PXE).  The PC receives an IP address from the DHCP server, loads pxelinux from the TFTP server, and displays the Debian Live boot menu.

  14. Choose a boot option, and after the kernel is downloaded, the root filesystem is accessed over NFS, and the operating system is loaded, you'll end up at your graphical desktop or shell prompt of choice!
To uninstall, see "Uninstall steps" below.

Alternate setup (no NFS):

This is a shorter method, because NFS is not required.  Debian Live will download its root filesystem over TFTP.  (However, the largest file that can be downloaded is limited by a bug.)
  1. Follow steps 1, 2, 6, and 7 of the regular setup, and skip steps 3, 4, and 5.

  2. In step 8, choose a smaller archive, like the standard flavor from 6.0.7, or the lxde-desktop flavor from 5.0.10.  (A bug causes some of the larger versions to stall when downloading the root filesystem over TFTP.)  Place the .tar.gz file on the Desktop, then double-click it to expand the archive.

  3. Follow step 9 of the regular setup.

  4. In step 10, instead of moving the folder "live", open it and move the file "filesystem.squashfs" to /private/tftpboot.

  5. Open the file /private/tftpboot/debian-live/i386/boot-screens/live.cfg in TextEdit.  Edit the kernel parameters for the boot menu option you'll be using, replacing the two parameters
    netboot=nfs nfsroot=
    with a single parameter
    then save the file and quit TextEdit.

  6. Follow the regular setup steps 11, 12, 13, and 14.  The root filesystem may take some time to download in step 14 (1 to 2 minutes over 100mbps ethernet), but when it finishes, you'll end up booted into Debian Live!
To uninstall, follow steps 1, 3, and 4 under "Uninstall steps", but ignore the /etc/exports file in step 1, and the /srv/debian-live directory in step 4.  Skip steps 2 and 5.

Uninstall steps:
  1. Move the files /etc/bootpd.plist and /etc/exports to the Trash.

  2. Restart the NFS server:
    $ sudo nfsd restart
    and check the status of the server (should say enabled, not running):
    $ nfsd status
  3. Disable the DHCP and TFTP servers:
    $ sudo launchctl unload -w /System/Library/LaunchDaemons/bootps.plist
    $ sudo launchctl unload -w /System/Library/LaunchDaemons/tftp.plist
  4. Move the files and folders from /private/tftpboot and /srv/debian-live to the Trash.

  5. Remove the /srv/debian-live and /srv directories:
    $ sudo rmdir /srv/debian-live
    $ sudo rmdir /srv
Lex adds: I haven't tested this one.
  Post a comment  •  Comments (6)  
  • Currently 2.80 / 5
  You rated: 5 / 5 (5 votes cast)
[18,705 views]  View Printable Version
Making Juniper Network Connect use Keychain Network
Password managers are a good thing, as they encourage you to maintain strong passwords. Just the sort of thing you’d want if you were opening every port on every computer on your enterprise network. Unfortunately, Juniper doesn’t see it this way. This can be resolved with some crafty scripting.

First, we need a scripting addition called Useable Keychain Scripting. Download it and copy it to /Library/Scripting Additions. You'll need to type your password to do this.

Next, you need to be able to connect to your VPN, so do this, then disconnect. Network Connect should retain the address of your server (e.g.

Now create a password item for the server (, and grant access to Usable Keychain Scripting. Or not, your call.

Now fire up the script. It will get the address of the server from Network Connect, get your username and password from Keychain Access, and log you in.

Modified from
property appName : "Network Connect"

on main()
	tell application "Network Connect"
		if connected then
			sign out
			delay 5
			tell application "System Events"
				-- Recover the name of the VPN from Network Connect.
			set myAddress to value of combo box 1 of group 2 of tool bar 1 of 
				window appName of application process appName
				set ASTID to AppleScript's text item delimiters
				set AppleScript's text item delimiters to "://"
				-- Get just the server address
				set vpnName to (text items 2 through -1 of myAddress) as text
				set AppleScript's text item delimiters to ASTID
			end tell
			tell application "Usable Keychain Scripting" to tell current keychain
			-- Recover the username and password from the login keychain
				set myPass to password of first internet password 
					whose name contains vpnName
				set myAccount to account of first internet password 
					whose name contains vpnName
			end tell
			connect to vpnName
			delay 5
			tell application "System Events"
			-- enter the account name and password in the dialog box and click 'Sign In"
			set value of text field 1 of group 7 of UI element 1 of scroll area 1 of 
				window appName of application process appName to myAccount of
			set value of text field 1 of group 10 of UI element 1 of scroll area 1
				window appName of application process appName to myPass
			click button "Sign In" of group 14 of UI element 1 of scroll area 1 of 
				window appName of application process appName
			end tell
			-- Could launch an application here if it's scriptable.
		end if
	end tell
end main

Lex adds: I haven't tested this one.
  Post a comment  •  Comments (4)  
  • Currently 2.00 / 5
  You rated: 3 / 5 (5 votes cast)
[6,359 views]  View Printable Version
"Airplane mode" for OS X Network
A reader at Stack Exchange asked an interesting question about whether it was possible to set up an "airplane mode" for OS X. The idea was to ensure that there is no network activity through any possible network interfaces.

It's actually pretty simple to do this. If you go to the Network pane of System Preferences, you'll see a Location popup menu at the top of the window. Click on that menu and choose Edit Locations. Click on the + icon to add a new location, then enter a name, such as AirplaneMode. Click on Done.

Next, choose that location in the Location menu, and click on each available network interface in the list at the left of the window. Click on the Configure iPv4 menu, and choose Off. For Wi-Fi, just click on the Turn Wi-Fi Off button. Click Apply, and this location will block all network activity.

To activate the location, there are two ways. You can click on the Apple menu, then Location, and choose the location. Or, if you wish to do this from the command line, as the poster had requested, you can run this command:

networksetup -switchtolocation AirplaneMode

Replace AirplaneMode with the name you've chosen for the location.

Using airplane mode can be useful if you're worried about security when using a laptop in public places. It can also save battery power, as Wi-Fi will go off, and your Mac will no longer search for networks.
  Post a comment  •  Comments (17)  
  • Currently 2.91 / 5
  You rated: 5 / 5 (11 votes cast)
[12,840 views]  View Printable Version
Generate list of wi-fi networks a Mac has used Network
You can find out which wi-fi networks a Mac has connected to by going to the Network preference pane, then clicking on Advanced, then on the Wi-Fi tab; they'll be listed in Preferred Networks. But if you want to do this from Terminal - say for a Mac you've connected to via ssh - this hint, posted on OS X Daily, can do it as well:
defaults read /Library/Preferences/SystemConfiguration/ RememberedNetworks | egrep -o '(SSID_STR|_timeStamp).+' | sed 's/^.*= \(.*\);$/\1/' | sed 's/^"\(.*\)"$/\1/' | sed 's/\([0-9]\{4\}-..-..\).*/\1/'
The list will be the same as that in Preferred Networks, and you can't alter it, but it my be useful in some situations.
  Post a comment  •  Comments (4)  
  • Currently 1.63 / 5
  You rated: 5 / 5 (32 votes cast)
[9,828 views]  View Printable Version