Recovering Your Wireless Pre-Shared Key On An Apple MacBook

This might not be anything new to some of you Mac veterans, but I stumbled across this the other day and felt compelled to share it.

If you are like me, you connect to a wide variety of wireless networks. Sometimes, you need to share the pre-shared key to a particular network, but don’t remember what it was. Your laptop just automatically connects to it without prompting you. There is a way to see what password is used for each wireless network you connect to using a pre-shared key for authorization. Using the following steps, you can recover the actual password used:

1. Open the “Keychain Access” program under one of the following methods:

A) Select”Applications” and then “Utilities”:

KeychainAccess-4

B) Select “Launchpad” from the dock, followed by “Other” and then “Keychain Access”.

KeychainAccess-1 KeychainAccess-2KeychainAccess-3

***Note – I realize there are other ways to get to the Keychain Access program via the CLI and GUI. I chose the 2 methods that I thought were easiest to find.

2. Once the “Keychain Access” program opens, select the “login” keychain, and then select “Passwords” under the category section on the bottom left of the window.

Screen Shot 2013-03-25 at 12.29.57 AM
3. Select the network you want to recover the pre-shared key from and either double-click it, or select it and hit return/enter.

4. The next screen you see, should look like this:

Screen Shot 2013-03-25 at 12.33.20 AM

5. Check the “Show password:” box, and you should get prompted for additional access. This will look like the following 2 windows. It might only be a single window that prompts you. In any case, enter your account password you use to login to your Mac or the password you use for sudo/root access.

Screen Shot 2013-03-25 at 12.33.40 AM Screen Shot 2013-03-25 at 12.34.00 AM

6. After successfully authenticating with your account password, you should see the plain text password in the “Show password:” field.

Screen Shot 2013-03-25 at 12.34.14 AM

That’s all there is to it! Now you can share the PSK with another device or person.

Posted in troubleshooting, wireless | Leave a comment

Aerohive’s Latest Product Release

Aerohive LogoThis is going to sound bad, but I don’t really care that Aerohive announced new switches. I thought I did. I knew they were coming and I longed for the day they would be here, but then they showed up, and my enthusiasm quickly waned.

I changed my mind though. I stopped thinking about it from an enterprise or large business perspective and started to think about it from a mid-market or SMB perspective. Then, it started to make sense and I started to get excited once again. Like a hormone raging teenager with bi-polar tendencies and no medication, I went from happiness, to dismay, and back to happiness.

What’s The Big Deal?

The fact that a wireless company just announced switches should not be earth shattering news. Aruba did it some time ago. Meraki did as well. Cisco and HP have always had them, but they do so much more than wireless, so it is hard to count them in that group.

I thought it was interesting when Meraki announced their switches, but that was because they were cloud managed, unlike Aruba’s switches. It had nothing to do with the hardware itself. Most access switches are boring. 24 or 48 ports of 10/100/1000 with some or all being PoE or PoE+. It doesn’t quite have the pull with the masses that it used to.

For larger networks, cloud managed switches aren’t a big deal. For smaller companies with distributed environments, it is a big deal.

Why Is It A Big Deal?

My sister has an Aerohive access point in her house. Nothing fancy. An older AP 110 model, so she can either run 5GHz or 2.4GHz, but not both at the same time. She had a smaller Netgear unit before switching to Aerohive, but that AP was not getting the job done. I gave the AP to my brother-in-law and told him to just plug it in to their Internet connection at home. I would do the rest without coming by their house. My sister texted me a day or two later while I was at home sitting on the couch and I remotely configured her AP, texted her the SSID and PSK and that was it. Later on, she had issues on 2.4GHz due to interference from the surrounding neighbors, so I switched her over to 5GHz, since all she needed was connectivity for her iPad. Problem solved, and I didn’t have to do more than about 10-15 minutes of work. I even used the remote spectrum analysis tool to figure out what was happening on the 2.4GHz band prior to shifting her to 5GHz.

Imagine that on a larger scale. What if I had a dozen locations that needed a single AP or a few AP’s? Using a cloud based management platform like Aerohive’s HiveManager Online(HMOL) means I don’t really have to even touch hardware before it gets sent to whatever location it will be operating at. As long as there is an Internet connection, I will be able to access that hardware remotely.

That’s great for wireless AP’s, but what about the other gear? My remote locations probably have a router and a switch. It is fairly common for the service provider to take care of the router for companies will little or no IT staff. It is one less thing they have to worry about. With Aerohive announcing switches, that run the HiveOS code that the AP’s do, guess what I am also able to do? You guessed it. Deploy switches without necessarily having to pre-configure them. All the interesting things I did on the AP’s from a security perspective, I can now do on the switch side. That may not seem like a big deal, but remember that in the mid-market or SMB space, this will help out tremendously.

In short, this is about time and resources. I don’t have to spend a lot of time staging equipment before sending it out via FedEx/UPS. I can ship it direct to the site and then remotely configure the gear. I also have the ability to monitor everything through HMOL. No separate management systems for wired and wireless. You can get this functionality with Cisco, HP, and Aruba, but it isn’t going to be as trouble-free and it will most likely cost a lot more. The one exception to Cisco being that they now own Meraki, and Meraki has switches and AP’s that are managed via the Internet in a similar manner to Aerohive’s HMOL platform. I can get similar functionality to what the larger networks are getting with their management/monitoring systems.

But Wait. There’s More!

It doesn’t end with the switches though. Aerohive has also announced Application Visibility and Control(AVC). If you follow the networking space, you know this has been a big deal for several years. On the firewall side, Palo Alto came out swinging a few years ago with a firewall that could peer into the network traffic and determine what applications were in use and let you filter based on that. You want to block Netflix? No problem. Want to allow Facebook timeline, but no games like Farmville? No problem.

Other vendors followed suit and released their own application aware capabilities. For all I know, they were working on it long before Palo Alto. Doesn’t really matter. Cisco, Juniper, Checkpoint, Palo Alto, and others have application visibility baked into their firewalls now. The wireless industry followed suit. First, it was Meraki. Then, Aruba and Cisco came out with their own application visibility solution. Now, Aerohive has announced theirs.

I could mention a bit about Aerohive’s AVC solution, but I would rather you just read my friend Chris’ post instead. I’ll simply add that AVC gives smaller customers insight that the larger ones probably already have. It levels the playing field. Expect to see more information about this in the near future from others.

Here are a few articles about this announcement from others:

Aerohive Is Switching Things Up – The Networking Nerd

Aerohive Launches Cloud Managed Switches - Lee Badman

 

 

Posted in aerohive, wireless | 1 Comment

Getting Your Money’s Worth Out Of Your Links

bro_wing-r_1c-red_pos_rgbI was fortunate enough to attend the Brocade Analyst and Technology Day event back in September at their corporate headquarters in California. I have a dual interest in Brocade as I follow them from a general technology perspective and I also happen to work for a Brocade reseller.

This event was centered around the data center and the main attraction, at least for me, was the unveiling of the 8770 VDX switch. This was a big addition to their already flourishing VDX line of switches. They discussed some other things during that event like their involvement with OpenStack as well as the advantages of using their ADX line of ADC’s/load balancers.

Another Switch?

Yes. Another switch. Not just any switch though. This is not old Foundry gear or old technology. This is a platform that has been built with the future in mind. I say that for a few reasons.

1. Each slot has up to 4Tbps capacity.
2. 8 slots for power supplies at 3000W each. You don’t need more than 3 to power the switch today.
3. 100Gig ready.
4. 3.6 microseconds any-to-any port latency.

I took a few pictures of this switch. It looks very heavy. I poked and prodded it without actually pulling line cards out and it seemed pretty sturdy. Every knob or lever seemed to be durable metal.

8770_Front_View8770_Rear_Fans

 

 

 

 

 

 

 

Of particular note are the humongous fans on the back of the chassis.

8770-Intake-CloseUp

 

 

 

 

 

Here is a close up of the intake slot on the front. Hard to believe this little guy sucks in all the cold air.

8770-PowerSupplies

 

 

 

 

 

This chassis can support up to 8 3000W power supplies. You won’t need 8 of them for years to come. However, the capability is there so that the chassis can be used as the line cards get upgraded in the future.

8770_Fabric_Modules

 

 

 

 

 

 

 

A close up shot of all 6 fabric modules.

Okay, so that isn’t impressing you is it? If you want more speeds and feeds regarding the 8770 VDX platform, read Greg Ferro’s post here. He also has some pictures. In fact, you can see me in the front of the switch, gut and all, taking my pictures while he was taking the picture of the fans in the back.

But Wait! There’s more…….

There was one feature on the 8770 that I thought was extremely interesting. Load balancing across multiple inter-switch links on a per frame basis.

Before I go into more detail on that, allow me to explain how load balancing across multiple links typically works. I’m aware that different vendors use different terms. You’ll see me do the same. No matter the term being used, we are talking about aggregating multiple physical links connecting switches to each other into a single logical interface.

Link Balancing Basics

Traffic is balanced across redundant or bonded inter-switch links using a few different criteria, but the major ones I am aware of are the following:

Source MAC Address
Destination MAC Address
Source IP Address
Destination IP Address
Source TCP/UDP Port
Destination TCP/UDP Port

This will vary according to the vendor and intelligence of the platform. Some switches might only support source/dest MAC address to determine which link to use. One thing should stand out with the above list though. The link chosen is going to be flow based. The more unique you can get, the better. That probably means you are going to favor using the TCP/UDP ports if your switch supports it.

Considering that an entire flow goes across a single link, you can see how this could result in uneven load. A 4 link bond between 2 switches could result in 1 link getting high usage while the other 3 links have much less traffic on them. In reality, if you were to logically group 4 x 10Gbps interfaces together, you wouldn’t have a single true 40Gbps interface. You would have 4 x 10Gbps interfaces that are 1 logical interface and can failover to each other should a link go down.

Reference the drawing below. I used the term “trunk group” to represent the logical interface created by combining 2 or more physical links together. That’s the term Brocade uses. For Cisco enthusiasts, that would be a port-channel interface.  4 x 10Gbps interfaces are bonded together using LACP or some other mechanism to present themselves as a single logical interface. The various colored rectangles coming into the switch represent individual flows. Notice the red flow going into port 2 while the purple and orange flows go into ports 4 and 5. If each rectangle is a single Ethernet frame, then you can see the imbalance. In the case of port 7, it has 2 different flows going across. This is a very basic representation of link balancing, but it should give you the general idea. If you want more info on this from a Cisco switch perspective, read Ethan Banks’ post from 2010 here.

Standard Link Balancing

A Better Way

The neatest thing I saw regarding the 8770 was the layer 1 link bonding. That’s right. Using layer 1 to merge links together. They called it “frame spraying”, although it is referenced in a slide deck from the event as “frame striping”. In any event, they are able to balance traffic across all ports in a trunk group on a per frame basis. That’s as close as you are going to get to ideal load balancing. You don’t have to modify a hashing algorithm to make this happen. It does it automatically. The only caveat is that all ports in the trunk group have to be tied to the same port ASIC and it is limited to 8 ports in a trunk group. Using 10Gig interfaces, that’s an 80Gbps trunk group that can exist between two 8770′s. I should point out that this existed prior to the 8770. I just wasn’t paying close enough attention to it until the 8770.

The diagram below shows traffic flow when using Brocade’s frame spraying technology. In this example, I used 4 x 10Gbps interfaces to make 1 logical 40Gbps connection between 2 switches. You can see that each frame is sent across the 4 links in a round robin fashion.

FrameSpray

How Does It Work?

Unfortunately, I have to speculate on how they are doing this. Brocade won’t actually tell you. Not that there aren’t hints of course. Ivan Pepelnjak wondered the same thing and mentioned in his post about Brocade’s VCS fabric load balancing that the answer lies in the patents. Brocade is already doing something similar to this in their Fibre Channel hardware, so naturally it was easy for them to just port it over to the Ethernet side of things.

I read through several of those patents. All I got was a headache and more confusion. It was better than reading RFCs though. I still don’t know for sure how it works, but I am going to take a guess.

The fact that all members of the trunk group have to be tied to the same ASIC should help us speculate as to what is going on. My guess is that some sort of low level probe or primitive goes out each port. The neighbor switch is doing the same thing. When these probes are received, the ASICs can very quickly figure out which ports are talking to the same ASIC on the other end. Some sort of tag might be used saying: “I am port X, tied to ASIC X, and tied to switch X.” I would probably compare this to a lower level form of LLDP, FDP, or CDP. I could be COMPLETELY wrong on this, but we’ll never really know unless someone can find the hidden method by reading a bunch of patents or Brocade decides to publish the method themselves.

Closing Thoughts

I could have focused on other things that I saw at the Brocade tech day event, but chose to focus on the “frame spray” feature instead due to the “neat” factor of it. This has significant real world application. I was recently involved in a network congestion issue around FCoE performance. The fix action was to change the algorithm that the switch used for load balancing across bonded links to another switch from the default source-destination MAC to the more granular TCP/UDP port. Performance increased dramatically after that change. Imagine if that wasn’t an issue at all and near perfect load balancing was occurring? With Brocade’s VCS technology, which is a part of their VDX line of switches, you don’t have to worry about it as long as you plan out your physical connections properly.

Here are a few posts from others who were at the Brocade event with me:

Brocade Tech Day – Data Centers Made SimpleTom Hollingsworth

Much Ado About Something: Brocade’s Tech DayJoe Onisick

Brocade’s Data Centre Ethernet StrategyGreg Ferro

Posted in brocade, data center, load balancing, switching | Comments Off