2010-01-12

Mac OSX: shell-script to get Network configuration

If you have different "locations" configured in your network environment on mac os x, it could be useful to retrieve what environment is currently selected, to allow different behaviour (in a script for instance) depending on the location/environment.

Mac has an instruction with which you can get this informatio:
networksetup -getcurrentlocation

This command (networksetup) however has to be executed with administrative privileges. This means only a user that's allowed to administer the machine, can execute:
sudo networksetup -getcurrentlocation

A non-administrative user could be interested for this information too. And since this instruction does not change the system configuration, one could think it advisable to set the set-user-ID-on-execution bit of networksetup, using
sudo chmod u+s /usr/sbin/networksetup

However this solution would open up your networsetup for other actions. So this option seems not advisable.
One could write create a script that executes this instruction, and chmod & chown that script to execute as root:
TARGET=GetCurrentLocation.sh;
cat <<EOSCRIPT >GetCurrentLocation.sh
#!/bin/bash
networksetup -getcurrentlocation;
EOSCRIPT
chown root ${TARGET};
sudo chmod 5755 ${TARGET};


Aforementioned snippit will create a script GetCurrentLocation.sh, that does just that.

Another solution is examining /Library/Preferences/SystemConfiguration/preferences.plist
This file holds the required information.

Following script evaluates the contents of that file, and extracts what location is currently selected, without the need for any superuser stuff.

#!/bin/bash
# Filename : GetCurrentNetworkLocation.sh
# Version : $Revision: 1.1 $
# Author : Dieter Demerre
# Copyright: (c) 2010- Dieter Demerre
# Licence : (g) GPL2 (http://www.gnu.org/licenses/)
# Package : Mac Os X system scripts
# Project : Network and configuration
# History :
# 2010-01-12 ddemerre 0.1 Initial implementation
#----------------------------------------------------------------------
# Description
# script that will (try to) determine what's the current network location
#----------------------------------------------------------------------
INPUT=/Library/Preferences/SystemConfiguration/preferences.plist;

function error
{
echo ${@} >&2;
}
if [ ! -r "${INPUT}" ]; then
error "cannot read plist file ${INPUT}"
exit -1;
fi

#Get key of Currently selected Set
setInfo=$(grep -A 1 "CurrentSet" "${INPUT}");
if [ 0 -ne ${?} ]; then
error "could not retrieve CurrentSet info (${?})."
exit -2;
fi
currentSet=$(echo ${setInfo}|sed 's/[^ ]* *//;s/\/Sets\/\(.*\)<\/string>/\1/;');

#Get line number in file for (start) of definition of the selected set
notBefore=$(grep -n "<key>${currentSet}</key>" "${INPUT}"|cut -d':' -f 1);
if [ -z ${notBefore} ] || [ ${notBefore} -le 0 ]; then
error "did not find key reference ${currentSet} in input (result ${notBefore})";
exit -2;
fi

# Consider only all lines following the definition-start of the set
lines=$(wc -l "${INPUT}"|awk '{print $1;}');
tail=$(( (lines - notBefore + 1) * 1));
nameInfo=$(tail -n ${tail} "${INPUT}" | grep -A 1 '<key>UserDefinedName</key>');

# And get the string value of the UserDefinedName key.
echo ${nameInfo}|sed 's/[^ ]* *//;s/<string>\([^<]*\)<\/string>.*/\1/;';

Labels: , ,

2010-01-02

Airport Extreme, loosing WAN (adsl2 bridged) unnoticed on regular basis

in 2007, I bought an Apple Airport Extreme access point. This is connected with an ADSL modem to my ISP.
I discovered that at irregular intervals, the Internet connection would be lost, but the airport extreme would not discover this (the green led continues staring at me defiantly, even though the logging in the airport extreme would also indicate a line stating the apple ntp server could not be used to synchronize the time (whereas this synchronization is logged working fine some time before [logging states: Severity:5 Clock synchronized to network time server time.euro.apple.com (adjusted +0 seconds).]).


When I switched to ADSL2, these recurring hickups became more regular. Whenever these connection droppings occurred, a reboot (using the airport utility) of the base station (menu item "Base Station", option "Reboot") would fix the problem, after some reboot time (where the switch and airport functionality temporarily becomes unavailable (so network shares are lost, opened network files closed)) the network and the internet connection would become available again.
When replacing the airport extreme with a mac mini (and dhcp client on the mac mini activated), the internet connection (adsl2) becomes available, and is not dropped (for at least 6 days (2 test runs)).
Convinced this experience prooved the airport extreme was faulty, I contacted the apple store. There someone told me that the airport extreme must be faulty, but since the warranty period is over, the price for a repair would equal the price for a new device.

I bought myself a new time capsule, and replaced the airport extreme by it. The Internet is connected to the ADSL2 modem configured with bridging. The Time Capsule is configured to receive a DHCP response at WAN (which in fact is a fixed Internet Address). The Time Capsule also manages the local wifi with hidden ESSID and WPA2 encryption. The dhcp server in the time capsule provides configured addresses to potentially 5 LAN UTP clients, and 7 WIFI clients. Access control lists based on MAC address protects one small step further.

Although I'm happy with the increased switch speed (now 1000/100/10 instead of the 100/10MB), and the included 1TB time machine, the new machine displays the same unwanted behaviour. After about 2 to 4 hours, the Internet connection is lost without the access point discovering this loss. The access point A testrun again with the mac mini shows the mini not loosing connection (the mini however is not providing dhcp addresses to the intranet, which the extreme is).

I now run a script that at an interval tries to contact 5 websites. If all 5 consecutively fail to be contacted, an apple script is launched that will reboot the base station. These actions are logged, and show me the regularity of the failures:


20100101 165524 lost
20100101 170105 reboot
20100101 170556 OK
20100101 200953 lost [3h4m]
20100101 201533 reboot
20100101 202024 OK
20100101 220443 lost [1h45]
20100101 221009 reboot
20100101 221500 OK
20100101 234550 lost
20100101 235131 reboot
20100101 235623 OK

20100101 010000 suspended script
20100102 120000 launched script again

20100102 134558 lost
20100102 135138 erboot
20100102 135633 OK
20100102 161055 lost
20100102 161619 reboot
20100102 162107 OK
20100102 184857 lost
20010102 185437 reboot
20100102 185924 OK

This rebooting however is just a fixer,... always clears the logfile of the airport.

Labels: , , , , , ,