krypted.com

Tiny Deathstars of Foulness

Dropping network connections can be incredibly frustrating. And finding the source can be a challenge. Over the years, I’ve found a number of troubleshooting methods, but the intermittent drop can be the worse to troubleshoot around. When this happens, I’ve occasionally resorted to scripting around failures, and dumping information into a log file to find the issue. For example, you may find that when a network connection fails, you have a very strong signal somewhere, or that you have a very weak signal on all networks.

I’ve found there are three pretty simple commands to test joining/unjoining, and using networks (beyond the standard pings or port scans on hosts). The first is the airport command, along with –disassociate. This just unjoins all networks:

sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport --disassociate

The second is a quick scan. Here, I’ve grep’d out the network I’m after (aka SSIDofNetwork – a very likely wireless network name), but when looking for environmental issues, you might choose to parse this into a csv and output all networks:

sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -s | grep SSIDofNetwork

Finally, you can join a network. You might have to escape out special characters in a password and it’s never wise to put a password into a script, etc. But, quick and dirty, this will join that SSIDofNetwork network:

sudo networksetup -setairportnetwork en0 "SSIDofNetwork" mysecretpassword

Anyway, loop it, invoke it however you invoke it, etc. Hope this helps someone, and if you have other tricks you’ve found helpful, feel free to throw them in the ‘ole comments!

How Users Feel About Intermittent Networking Issues

August 26th, 2016

Posted In: Mac OS X, Mac OS X Server, Mac Security, Network Infrastructure, Programming

Tags: , , , , , , ,

Previously, I covered how to Programmatically Obtain Recent Wi-Fi Networks On A Mac. But, here I’m gonna’ go a step further and look at how to extract the password for a network as well. The two are stored in different locations. The recent networks are in the /Library/Preferences/SystemConfiguration/com.apple.airport.preferences defaults domain. If you pull one of those, then you can use the security command to extract the password itself.

security find-generic-password -ga "Krypted Home"

The output is as follows, showing everything that is tracked about this network in the keychain.

keychain: "/Library/Keychains/System.keychain"
class: "genp"
attributes:
0x00000007 <blob>="Krypted Home"
0x00000008 <blob>=<NULL>
"acct"<blob>="Krypted Home"
"cdat"<timedate>=0x32303135313230373135313731375A00 "20151207151717Z\000"
"crtr"<uint32>=<NULL>
"cusi"<sint32>=<NULL>
"desc"<blob>="AirPort network password"
"gena"<blob>=<NULL>
"icmt"<blob>=<NULL>
"invi"<sint32>=<NULL>
"mdat"<timedate>=0x32303135313230373135313731375A00 "20151207151717Z\000"
"nega"<sint32>=<NULL>
"prot"<blob>=<NULL>
"scrp"<sint32>=<NULL>
"svce"<blob>="AirPort"
"type"<uint32>=<NULL>
password: "test"

You can constrain the output with awk and grep so that you’d only see the password as the output of the command. Then, you can feed it back into other objects, like a new .mobileconfig.

December 11th, 2015

Posted In: Apple Configurator, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , ,

Bushel allows you to deploy settings for Wi-Fi networks to all of your users enrolled in Bushel. Bushel supports WEP, WPA, and WPA2.

For More On Adding Wi-Fi configurations with Bushel, Click Here

April 6th, 2015

Posted In: Bushel

Tags: , , , , ,

One of the more common requests we get for iOS devices is to restrict what sites on the web that a device can access. This can be done in a number of ways. The best, in my experience, has been using a proxy.

In Apple Configurator 1.2 there’s an option for a Global HTTP Proxy for Supervised devices. This allows you to have a proxy for HTTP traffic that is persistent across apps.

Each Wi-Fi network that you push to devices also has the ability to have a proxy associated as well. This is supported by pretty much every MDM solution, with screens similar to the following, which is how you do it in Apple Configurator.

The above has I am all about layered defense, though. Or if a proxy is not an option then having an alternative. Another way to disable access to certain sites is to outright disable Safari and use another browser. This can be done with most MDM solutions as well as using a profile. To see what this would look like using Apple Configurator, see the below profile.

Now, once Safari has been disabled, you then need to provide a different browser. There are a number of third party browsers available on the App Store. Some provide enhanced features such as Flash integration while others remove features or restrict site access.

In this example we’re using the K9 Web Protection Browser. This browser is going to just block sites based on what the K9 folks deem appropriate. Other browsers of this type include X3watch, Mobicip (which can be centrally managed and has a ton of pretty awesome features), bSecure (which ties in with their online offerings for reporting, etc) and others.

While this type of thing isn’t likely to be implemented at a lot of companies, it is common in education environments and even on kiosk types of devices. There are a number of reasons I’m a strong proponent of a layered approach to policy management for iOS. By leveraging proxies, application restrictions, reporting and when possible Mobile Device Management, it becomes very possible to control the user experience to an iOS device in such a way that you can limit access to web sites matching a certain criteria.

October 19th, 2012

Posted In: iPhone

Tags: , , , , , , , , , , , , , , , , ,

If you run networksetup and do a -listallhardwareports in OS X Snow Leopard, you’ll see that the Hardware Port: for en0 (on an MBA at least, but you should get the point even if it’s a MacPro) is AirPort. If you run the same command in Lion, you’ll notice the the hardware port is now Wi-Fi.

This change cascades to any commands like -listpreferredwirelessnetworks where the hardware port might get called on. For most of my scripts for assigning AirPort networks, etc I was able to mostly just find-and-replace AirPort for Wi-Fi, provided I didn’t use AirPort anywhere else (e.g.$AirPort, etc).

July 20th, 2011

Posted In: Mac OS X, Mass Deployment

Tags: , , , ,