Blog: wireless

Like many new laptops, the new Apple MacBooks are too thin to have an onboard Ethernet adapter. After setting up a local account and connecting it to the internal wireless network (using WPA2 Enterprise), I was able to join the Macbook to the Active Directory domain without issues. However I quickly discovered that I couldn’t login to a domain account because by default wireless connections are not connected before login – remember, no Ethernet.
 
The immediate “fix” was to purchase a USB3 gigabit Ethernet adapter, but after some research later I discovered it's possible to enable WiFi before login. Here are the basic steps:

• Install the Apple Configurator utility from the App Store. This app is designed to create deployment profiles for iOS devices but can also be used to create 802.1x profiles for OS X systems.
• Run the Configurator and create a new profile. Update the WiFi section with the required connection information.
• Save this profile locally.
• Open the profile with a text editor and add XML text as outlined at http://www.ntsystems.it/post/Joining-WiFi-before-login-on-Mac-OS-X-108.aspx. This article is for an older version of OS X and refers to the discontinued iPhone Configuration Utility (which was replaced by the Apple Configurator), but the manual edits still apply to OS X 10.10 and 10.11.
• Double-Click the edited profile to import into System Preferences. You can see the loaded profile by going to the 802.1x section of the Network->Advanced settings in System Preferences.
• Logoff or reboot and you should be good to go.

I was wanting to create an ad-hoc network on a Windows 8 system, but discovered the “Create an ad hoc network” feature available on prior Windows OS systems is not available on Windows 8.  However, I found in Window 8 you can use the Network Shell (netsh) utility to create a virtual wireless network (WLAN).

1. First you need to verify your network interface supports virtualization.  Open a command prompt (with administrative privileges) and run “netsh wlan show drivers” – look to see if “Hosted network supported” is “Yes”
2. Enter the following command to configure the wireless network “netsh wlan set hostednetwork mode=allow ssid=<name> key=<password>
3. Now start the hosted network by running “netsh wlan start hostednetwork”

While installing a wireless network at a youth camp where I volunteer,  I was having issues getting the wireless distribution system to see the wireless access point in the building where the main router is located. If I place the WAP in the attic I could get a decent signal. So I moved the WAP to the end of the building, in the attic and mounted it inside the wood eave of the building. I was then getting a good signal to my other building. It wasn’t till after I had done this that I realized it never would of worked the first way I was trying. Most of the older buildings, such as the one the network originates from, have stucco exteriors. Part of the process of installing stucco (at least the old way) is to wrap the building in a wire mesh to help hold the stucco. It finally occurred to me that the wire mesh was creating a faraday cage around the building preventing the wireless signal from reaching outside.

Awhile back, we had a problem with two of our Cisco Aironet devices at a customer site that kept dropping their wireless connection to each other.  The old radios had been replaced by these newer aironet devices while still keeping the same antennas.

The error message, among many, in the logs stated: “Packet to client <clientname> reached max retries, removing the client”.

At first, we thought that they might be overshooting the other end by having their signal strength too high.  We tried lowering the signal strength but it didn’t really help the issue that much.  We tried scanning the airwaves for interference, but couldn’t decisively find anything troublesome with the channel frequencies.  We also checked the alignment of the antennas and saw that they appeared to be in the same position that they had been for quite some time.

I came across a wireless troubleshooting guide by Cisco that mentioned that the problem can be an indication of a bad RF. It suggested putting the command “packet retries 128 drop-packet” on both access points as a workaround for bad RF.  After this command was applied, we the wireless connection stopped disconnecting.

One of our customers has a point-to-point wireless connection, which started failing with an error that indicated problems with radio interference.  I ran the utility to check for busy radio channels, but it did not indicate any problems.  (Many channels came back as completely unused.)  I eventually reduced the transmit power of the root-bridge radio, which caused the connection to come back up. 

In retrospect, the issue was likely caused by a reflection that caused a second radio signal out of phase with the original signal.  This reduced or eliminated the signal at the antenna.

My iPhone connects in my office to wi-fi which also is able to connect through my VPN router.  For my laptop, I had set the DHCP settings on my wireless router to include the internal CoNetrix DNS server.  When I connected my phone which uses Exchange active-sync to connect, it would get an error about the certificate authority being untrusted and hit OK to continue. 

Later on I noticed that my phone kept getting synchronization errors and would get the pop up about the certificate authority being untrusted.  What I later noticed was that the server name would change from our internal to external back and forth.  [more]

I later realized that our DNS server had a host record that was the same as our external mail server address.  Each time the phone went on and off my wireless network, it would keep switching server names because the internal DNS would resolve to the actual internal server name. 

I removed the DNS server for the CoNetrix internal network from my wireless router and the phone has only connected to webmail externally.  It no longer tries internal access.

Symantec published a paper in conjunction with Indiana University describing how attackers could be using unsecured home wireless access points in pharming attacks. The vulnerability is related to easily guessed credentials on the wireless routers and default installations are definitely easily guessed.

The ploy described in this paper (http://www.symantec.com/avcenter/reference/Driveby_Pharming.pdf) involves the use of javascript on a malicious website that changes the DNS settings on the wireless router - provided the router credentials can be guessed by the application.

So, there is more to it than being sure your wireless transmissions are encrypted.