Dell Latitude ST and Windows 8 Wifi connectivity

Installing Windows 8 on this tablet went off without a hitch. For a severely under powered device it is actually running Windows 8 very well. After reading numerous comments around the net about how slow it was running Win8, I was curious to find out for myself.
So far I have only found 2 issues. The first being the Windows 7 N-Trig drivers were not compatible with Win8. Secondly the Dell Atheros Wifi drivers were also not compatible. The N-trig issue was an easy fix. N-Trig has drivers on their site at n-trig.com that are compatible with Win8. The wifi on the other hand took some more tinkering. After a couple hours of learning the new UI and figuring out where everything was I decided to take the time to get Wifi up and running. The Dell A06 driver install package as I mentioned above is not compatible with Win8. However it does have the required driver packaged up inside. Before unpacking the install application I tried to install it under Windows 7 compatibility mode which also did not work.

Here are the steps I took to get the wifi driver installed:
Execute the installer package and it will extract the files into your Temp folder and the Atheros Installer.msi will be located in one of the {insert random number and text here} folders. The installer itself will throw an error stating that you must be using Windows 7.
Before you hit OK, using windows explorer browse to your C:\Users\yourusername\AppData\Local\Temp\ folder and find the Atheros Installer.msi. Copy or move that file to wherever you want, just make sure you remember where you put it. It is now safe to hit OK on the Dell Installer.
The installer will most likely clean up the temp folder automatically and you would not be able to find the file after hitting OK.
Use msiexec to extract the contents of the installer.
Open up a command prompt with administrator privileges. Once there the following command will be used: msiexec /a filepath to MSI file /qb TARGETDIR=filepath to target folder.
Now look in your Device Manager you should have an exclamation point listed next to SDIO Device. Click on that and update driver. Choose the folder you extracted the msi to and Windows will take care of the rest.
If for some reason you already have a driver listed for your dell mini card you will have to uninstall the driver and reboot. Upon reboot follow the above instructions.

GFI MAX Service Provider Tool

I have no data to back this statement up but here goes: every IT has heard of LogMeIn.

I offer an alternative: GFI MAX. http://www.gfimax.com/remote-management

On the advice of himuraken I have been using MAX to support two Windows servers, one Windows desktop and (now in beta) a Debian server. I still have a ton to learn but the initial though it that this service is pretty solid. The main IT user interface is the dashboard which is very intuitive. Similar to LogMeIn Central, the monitored devices are split up in to client groupings. A big advantage of LMI is that all the cost is in the connected server/PC fee. There is no additional cost for the dashboard functionality.

Agent install is straight forward with multiple delivery options. You do have to configure the remote control separately from the monitoring agent.

Much more to come as I dig in to this service. Certainly interested in hearing from anyone that uses this.

– habanero_joe

12/30/12 Update

I am still using this service and I am really enjoying the notification system. Alerting is very easy to configure and can be applied to groups of systems that have similar needs.
The Linux agent is now in general release. Looking forward to getting more clients set up (and paying!) for this tool in 2013.

– habanero_joe

Product Review: EnGenius Access Point

Last week I ordered an EnGenius EAP300 access point from NewEgg (a vendor who deserves a review of it’s own) and it was waiting for me when I got home today. I have been having trouble with a NetGear WG103 and contact with support has been unsatisfactory.

The product design is very functional. It pretty much resembles a large smoke detector. I was looking for a small ceiling mountable device that supported PoE and this fits the bill. This device is advertised as a business-class, high power access point. Several standard security options are supported.

Configuration was fairly easy for anyone familiar with provisioning wireless devices. However, I do not like devices that come configured with a static IP. It is a minor hassle to reconfigure a laptop or other device to configure the access point. Once I got past that it was a simple matter of connecting to the device’s web GUI.

Initial tests included watching shows on NetFlix and Hulu Plus from an Apple TV. The streaming was flawless. The next test was streaming a .mkv movie to a PC. Again this worked flawlessly.

Next step will be to mount this device in its final spot and test out the PoE adapter. Stayed tuned for further info.

– habanero_joe

20121007-164232.jpg

Debian Squeeze & Broadcom b43 etc

So you like Debian, and why wouldn’t you, it is great after all. Unfortunately, many laptops come from the factory sporting Broadcom-based chipsets. So inevitably I complete a Debian install and Broadcom takes the wind out of my sales. I then trudge over to http://wiki.debian.org/wl#Squeeze and go through the paces. Why? I do it over and over. Well enough is enough, I mean this isn’t a tricky script to write. So for your enjoyment, I have put it all together into a small bash script to simplify things for future installs. First, be sure to add the non-free repo to your /etc/apt/sources.list file.
Then create and run a .sh file containting:

#!/bin/bash
aptitude update
aptitude install module-assistant wireless-tools
m-a a-i broadcom-sta
echo blacklist brcm80211 >> /etc/modprobe.d/broadcom-sta-common.conf
update-initramfs -u -k $(uname -r)
modprobe -r b44 b43 b43legacy ssb brcm80211
modprobe wl
iwconfig

Enjoy!

–himuraken

Public WiFi – what is the cost?

Question for the readership:

What is the true cost of providing public WiFi (unsecured) in say an airport?
Leave answers in the Comment section…

In this age of 3G, MiFi, etc. does anyone really need to pay to use WiFi service to get work accomplished? Sure I’ll connect all day long if it is free. A good WiFi connection is usually faster than my 3G BlackBerry or Droid Pro connection. But I refuse to pay for this.

On a recent trip, the hotel I was staying at, charged €6 for 30 minutes of WiFi which is close to $17 per hour. The Burger King less than a block away had it for free and served beer, cheap. Another hotel on the same trip had it free in the lobby. Good enough… Based on my fairly extensive domestic travel, it seems that the ‘higher-class’ the hotel, the more it charges for what is a simple service.

I realize that there are real non-recurring and recurring costs but these days, every business needs some sort of Internet connection for daily operations.

I will now step down from the soapbox.

– habanero_Joe

VMware ESX, NIC Teaming, and VLAN Trunking with HP ProCurve

Found this great article and thought I would share it with RH readers:

Original text from http://blog.scottlowe.org/

In an earlier article about VMware ESX, NIC teaming, and VLAN trunking, I described what the configuration should look like if one were using these features with Cisco switch hardware. It’s been a quite popular post, one I will probably need to update soon.

In this article, I’d like to discuss how to do the same thing, but using HP ProCurve switch hardware. The article is broken into three sections: using VLANs, using link aggregation (NIC teaming), and using both together.
Using VLAN Trunking

To my Cisco-oriented mind, VLANs with ProCurve switches are handled quite differently. Port-based VLANs, in which individual ports are assigned to one or more VLANs, allow a switch port to participate in that VLAN as either an untagged fashion or in a tagged fashion.

The difference here is really simpler than it may seem: the untagged VLAN can be considered the “native VLAN” from the Cisco world, meaning that the VLAN tags are not added to packets traversing that port. Putting a port in a VLAN in untagged mode is essentially equivalent to making that port an access port in the Cisco IOS world. Only one VLAN can be marked as untagged, which makes sense if you think about it.

Any port groups that should receive traffic from the untagged VLAN need to have VLAN ID 0 (no VLAN ID, in other words) assigned.

A tagged VLAN, on the other hand, adds the 802.1q VLAN tags to traffic moving through the port, like a VLAN trunk. If a user wants to use VST (virtual switch tagging) to host multiple VLANs on a single VMware ESX host, then the ProCurve ports need to have those VLANs marked as tagged. This will ensure that the VLAN tags are added to the packets and that VMware ESX can direct the traffic to the correct port group based on those VLAN tags.

In summary:

* Assign VLAN ID 0 to all port groups that need to receive traffic from the untagged VLAN (remember that a port can only be marked as untagged for a single VLAN). This correlates to the discussion about VMware ESX and the native VLAN, in which I reminded users that port groups intended to receive traffic for the native VLAN should not have a VLAN ID specified.
* Be sure that ports are marked as tagged for all other VLANs that VMware ESX should see. This will enable the use of VST and multiple port groups, each configured with an appropriate VLAN ID. (By the way, if users are unclear on VST vs. EST vs. VGT, see this article.)
* VLANs that VMware ESX should not see at all should be marked as “No” in the VLAN configuration of the ProCurve switch for those ports.

Using Link Aggregation

There’s not a whole lot to this part. In the ProCurve configuration, users will mark the ports that should participate in link aggregation as part of a trunk (say, Trk1) and then set the trunk type. Here’s the only real gotcha: the trunk must be configured as type “Trunk” and not type “LACP”.

In this context, LACP refers to dynamic LACP, which allows the switch and the server to dynamically negotiate the number of links in the bundle. VMware ESX doesn’t support dynamic LACP, only static LACP. To do static LACP, users will need to set the trunk type to Trunk.

Then, as has been discussed elsewhere in great depth, configure the VMware ESX vSwitch’s load balancing policy to “Route based on ip hash”. Once that’s done, everything should work as expected. This blog entry gives the CLI command to set the vSwitch load balancing policy, which would be necessary if configuring vSwitch0. For all other vSwitches, the changes can be made via VirtualCenter.

That’s really all there is to making link aggregation work between an HP ProCurve switch and VMware ESX.
Using VLANs and Link Aggregation Together

This section exists only to point out that when a trunk is created, the VLAN configuration for the members of that trunk disappears, and the trunk must be configured directly for VLAN support. In fact, users will note that the member ports don’t even appear in the list of ports to be configured for VLANs; only the trunks themselves appear.

Key point to remember: apply your VLAN configurations after your trunking configuration, or else you’ll just have to do it all over again.

With this information, users should now be pretty well prepared to configure HP ProCurve switches in a VMware ESX environment. Feel free to post any questions, clarifications, or corrections in the comments below, and thanks for reading!

VDI. Who Will Win?

The VDI marketplace has been heating up. VMware’s recent launch of View 4 seems to have sparked more interest overall.
Microsoft has further cemented its partnership with Citrix to provide virtual desktops. Microsoft has also simplified (and reduced pricing) on using desktop OS in a virtual environment.
Recent promotions by Citrix (and Microsoft) are geared towards taking customers away from VMware. Citrix, which has a large installed base in the remote access arena, should do well with the XenApp to XenDesktop trade-in.
Red Hat has just announced that it will offer desktop virtualization based on KVM.
I expect many companies may wait until their next desktop refresh cycle to implement VDI. Moving to low-cost thin and zero clients certainly makes sense from an administration perspective.
This is an exciting time for anyone involved in virtualization!

– habanero_joe