The other day I was copying a customer's files and settings from a old laptop to a new one. Much of this tedious task was handled automatically by Fab's Autobackup (https://fpnet.fr/, and 25% until Valentines Day BTW), but I was disappointed that his dozen WiFi access point profiles and passwords were not one among the settings that Fab's copied for me. For a family laptop, you usually just have to re-enter the password for just the home router, and maybe once again for your work wireless. If your are a tech for an enterprise, and the new mobile workstation needs to connect to multiple access points, you always wind up walking around the business or campus, connecting to each in SSID in turn and entering a different key. This time, the laptop would be used in multiple remote offices. The user would have been able to re-create those connections as he traveled to each office, but he asked me if it wouldn't be possible instead to transfer the profiles with the rest of his data.
I had no doubt that I would be able to find a free tool to backup and restore wireless connections, but I have become wary of Windows utilities that can be found at the end of a Google search but have not been recommended by other techs or a trusted website. I was surprised to find my answer in some functions added to the DOS
netsh, (or "net shell") command, starting with Windows Vista.
Open a Windows command prompt on the laptop that already has the WiFi keys set up, ergo the old one, and type:
netsh wlan show profiles
then press return. This will give you a list of your existing wireless connection profiles by name (i.e. by SSID). Now you can pick a WiFi profile name and enter on the command line:
netsh wlan export profile name="SSID_above_in_quotes" folder="C:\destination"
Quotes are required for the WiFi profile name, but not for the destination folder unless you use spaces in your Windows directory names. If you want to create export files for all your wireless connections, you may omit the "name=" part.
netsh wlan export profile folder=<destination_path>
Omitting "file=" of course creates export files in the current directory.
netsh wlan export profile command generates a .XML export file for each selected profile. Each export file contains an SSID, channel, encryption type and a hash of the encryption key to be transferred to the new laptop, except that it doesn't work, at least not for me and several others who posted articles to the web. On my first try, I was able to import everything but the encryption key, all the access points showed up in "Manage Wireless Networks", but I was prompted for a key when I tried to connect. I thought maybe this was Microsoft's attempt at security, but I could see a field for the hash in the .XML and when I went back to the article on netsh and it was clear I was supposed to get the keys too. A little more googlsearch revealed a second article on netsh that gave me an argument the first one omitted, adding key=clear at the very end of the netsh command causes the keys to be exported in clear text! Our command now looks like:
netsh wlan export profile folder=<destination_path> key=clear
Copy your .XML profile files to the new laptop (I am assuming via USB key). The filenames will be in the format:
Wireless Network connection-<profile-name-same-as-SSID>.xml
You understood me correctly, this DOS command generates file names with spaces in them. Copy the .XML files to the new system and import the profiles with:
netsh add profile filename="<file name in quotes to account for spaces>.xml"
It's not quite as odious as it looks because DOS now supports TAB completion, so you just have to type:
netsh add profile filename="Wi and press <TAB>
The rest of the name of the first profile will be filled in, complete with the terminating quote. Press <ENTER> and you should get a message that wireless profile has been imported. To import the remaining profiles, just use <F3> or the up arrow and edit the last command. Since it was set to auto-connect, the laptop I was working on made a connection to the local access point the instant the corresponding profile was imported.
Learning these new netsh functions may make configuring WiFi more convenient (I can maintain a library of wireless profiles for the organizations I service, or I could implement an encryption key update via a batch file). I can also see ominous security implications for networks where users aren't supposed to be privy to the connection keys and have access to pre-configured laptops, such as schools. One could whitelist the MAC addresses of only the organization's equipment, but there is always that visiting dignitary to whom you are expected to provide unfettered network access. Besides, anyone with access to the command line can use ipconfig to display the laptop's trusted MAC address, which can be cloned for access from the parking lot or from across the street. The only way I see to secure the connection from someone with physical access to a connected laptop is to install kiosk software that disables the command line.
Installing Skype on 64-bit Fedora
Last week I decided to install Skype as an alternative way to contact people with land lines. I haven't played with Skype since I had it on my Windows workstation, so I downloaded and installed the .rpm for Fedora 13+. All Skype has is a 32-bit package for Fedora, and sure enough, when I tried to launch Skype, the icon bounced around Compiz fashion, then the application item on the taskbar closed without doing anything. I looked for information in troubleshooting Skype from the logs, and an Arch wiki article told me I might have to create
~/.Skype/Logs, which I did. The application continued to crash without generating a log. I heard someone mention once in a call-in podcast that they'd had to perform additional steps to make 32-bit Skype work in 64 bit Fedora 15, and a Google search took me to the khAttAm blog (link below). I experienced some trepidation because the steps involve installing additional 32 bit libraries (if you heard me on the Hacker Public Radio New Years Eve shows, you might have heard me say I've experienced a bit of dependency hell over conflicts between 32 and 64 bit libraries) but the instructions in the article went flawlessly (I don't know if khattam.info represents one person or more than one, but you rock!).
First, as root run
Next, add the following line to /etc/rpm/macros (create it if it doesn't exist):
Finally, install these 32-bit libraries:
yum install qt.i686 qt-x11.i686 libXv.i686 libXScrnSaver.i686
After that, I was able to launch the application and log into my Skype account.