Category: Wifi

If you are running Linux on a PC, notebook or netbook with a Wi-Fi card it's "relatively" easy to use the system together with Wireshark for WLAN tracing. Since Wireshark version 0.99.5, even WPA decryption is supported so Wireshark also decodes the packets from other devices in your network.

Relative is a relative term though as it seems that depending on the Wi-Fi hardware and the drivers used, there are different ways to set the network card and protocol stack into monitoring mode. This is necessary to send the full 802.11 Wi-Fi frames to Wireshark. On the Asus eeePC 701 running Xandros Linux it works as described in this post.

On my new Acer Aspire One D250 with an Atheros AR242x 802.11abg wireless chip running Ubuntu 9.04, things work a bit differently and it took some experimenting to figure things out:

The first step to install "iw" via the Synaptic package manager. Once installed, setting the Wi-Fi card into monitoring mode is quite straight forward with a couple of commands via a shell:

sudo ifconfig wlan0 down
sudo iw dev wlan0 interface add mon0 type monitor
sudo ifconfig mon0 up

At this point the Wi-Fi card stops working as a normal network interface and Wireshark gets a new network adapter "mon0" that can be used for tracing in promiscuous mode. Unlike with the original eeePC that required the Wi-Fi card to be configured for an unencrypted network before switching to monitor mode to prevent decryption of some packets before they reach Wireshark, this is not necessary on the Acer.

The picture on the left shows how Wireshark needs to be configured via the preferences menu for decoding encrypted packets. Different network cards might need different settings here. Changing the configuration and clicking on "apply" makes Wireshark go through all packets already traced and apply the changes. This way it's not necessary to generate a new trace which testing different settings.  For the WPA decoding to work, it's necessary to know the encryption key to capture the key exchange of the device to monitor. In other words, the Wireshark trace has to be started and only then should the device to be monitored enter the network.

Once done with tracing the network adapter can be set back to normal operation with the following commands:

sudo ifconfig mon0 down
sudo ifconfig wlan0 up

Happy tracing!

When Nokia started to put Wi-Fi into smartphones about three years ago they were pretty much the only company doing that and they were looked at suspiciously by both the competition and network carreirs. At the time a lot of people said they were not sure if Nokia would prevail with their strategy and that carriers would strongly oppose such phones.

If you look at the market these days I think it has prevailed quite well. All Nokia N-series phones have Wi-Fi built and virtually all competing mobile device vendors have followed their lead. Apple has it, HTC has it, RIM now has blackberries with Wi-fi and even Sony Ericsson has now started to put Wi-Fi into their camera feature phones (e.g. the new C905).

The way I see it, Nokia has made good use of their first mover advantage and currently offers the widest range of services over Wi-Fi. Here's how I use the built in Wi-Fi in my N95:

• Mobile web browsing (the number one application for every Wi-Fi enabled phone I guess), both the built in browser do a great job for surfing the web in general, using Google Reader for my RSS feeds, mobile banking, etc.

• My second killer application: VoIP telephony with the built in SIP client. I guess Nokia is the only company that has so far integrated a full VoIP client integrated in their software. It's fully automatic. When I get home, the N95 senses my home Wi-Fi and automatically connects. It's fully replaced my landline cordless phone by now.

• Automated podcast download: The podcasting application runs in the background and automatically downloads the latest podcasts when they appear. A very nice application and I've configured it in a way to only do it over Wi-Fi but not over cellular.

• Mobile Web Server: Very cool application to access my phones address book, calendar, camera etc. via my notebook's web browser. Here are some more details in case you never heard about it before.

• Picture upload to Flickr: When I travel to countries in which I only have an expensive mobile data subscription I rather wait to upload pictures to Flickr until I reach the cover of a Wi-Fi network. Shozu does a good job here with queuing pictures marked for upload and automatically sending them when a configured network becomes available.

• e-mail: When at home, my e-mail client (Profimail) uses the Wi-Fi instead of the cellular connection. Very convenient and cost saving.

• When I am traveling, I have my dongle dock with me and instead of communicating with the 3G network directly, most applications use Wi-Fi to the dongle dock which then sends out the data via 3G. Helps to save cost because in many country data over data only SIMs is much cheaper than a data add on to a SIM card with a decent voice tarrif.

• Some people us the 3G connectivity and the Wi-Fi as a Wi-Fi bridge for other devices. I prefer my dongle dock but I am sure such a solution appeals as well.

To see how the competition has reacted in the meantime here's a question to those with a non-Nokia smartphone: Which applications does your device offer today and which of those do you use?

After it has now been shown that WPA can be a bit broken, I decided to upgrade and reconfigure my devices to only use WPA2's CCMP together AES encryption. When I wanted to switch a notebook with the very first Centrino chipset to WPA2 (the 802.11b only Intel Pro Wireless LAN 2100) I noticed that I actually couldn't, the options for it are missing in the configuration dialog box. So I looked around on the Internet if a driver update from Intel would fix the problem. Unfortunately, not even Google seems to know. So after a while I decided to just give it a try and installed the Windows XP WPA2 hotfix from Microsoft. After a reboot, WPA2 is now supported even on the old chipset and WPA2 with AES works just fine. In case you want to upgrade as well and don't see WPA2 after the upgrade, you might want to update the driver for the 2100 chip itself, which I did the last time back in 2006 after the malformed Wi-Fi packet exploit showed up. With all my devices running with WPA2 now, I could finally switch the access point to WPA2 only mode.

Before Wired Equivalent Pricacy (WEP) encryption mechanism of Wi-Fi was fully broken, the industry acted quickly and pushed out a new Wi-Fi encryption scheme to the market called Wi-Fi Protected Access (WPA) Temporal Key Integrity Protocol (TKIP). WPA had a number of security improvements over WEP and so far was considered to be fully secure. Looks like this is no longer quite the case as Martin Beck and Eric Tews have recently published a paper on how they have partly cracked WPA encryption.

Partly in this case means that under a number of circumstances, all not unrealistic, it is possible to recover the encryption key for the data stream the key STREAM for ONE very short and specific type of packet from the access point to a client device within about 12 minutes plus the key used for generating the message integrity code (MIC). The attack can't recover the key for the reverse direction so the attack can not be used so far to gain full access to the network. The attack is limited to ARP (address resolution protocol) management packets for which most of the content is known in advance.

In practice this means that the attacker can then send up to 7 freely constructed packets (each in one QoS chain) to a client device. It is NOT possible, however, to decrypt other packets with the knowledge gained. Things that could be done with this, however, is to trigger intrusion detection systems or to trick a client into some sort of action and reporting the result to the destination IP address given in the packet, which could be in the Internet. For details see their paper here.

Two remedies are suggested in the paper: One of the requirements for a successful attack is that the timer responsible to force a re-negotiation of the ciphering key is set to a value higher than 12 minutes, which is usually the case. Many access points, however, allow to set the timer to a lower value. Beck and Tews therefore suggest a timer value of 2 to 3 minutes.

Another way to prevent the attack is to use WPA2, which uses CCMP/AES (Advanced Encryption Standard). Most access points and devices sold in the past 12-24 months are capable of this 802.11i compliant authentication and encryption scheme. In my case, I had to update my Windows XP Service Pack 2 with this Microsoft Patch before I could activate WPA2.

Fortunately, most access points allow WPA/TKIP/RC4 and WPA2/CCMP/AES to run simultaneously. Thus, WPA and WPA2 capable devices can be used in the same network and a WPA device, while itself being vulnerable, does not compromise the security of WPA2 devices.

Since only the data flow from an access point to a device can be broken this way, Since only single ARP packets can be decrypted and only short packets can be injected the usefulnes of the attack is quite limited for the moment, unless, of course, somebody figures out how to open up the reverse direction. another loophole like triggering an IDS system or to exploit an OS vulnerability with the few short packets that can be sent without knowing the key. 

A year ago, I reported that I could receive a stunning 13 Wifi networks at my flat. Since then, the number has risen even further! When I checked this time, I was able to detect over 25 access points, not counting secondary SSIDs of some access points and those networks that could be received but not decoded correctly due to their weak signal strength. Channel 11 is a hot place with over 10 access points sending out their signals in this area. A place in the spectrum definitely to be avoided as at least one access point sends a continuous high bitrate broadcast, probably a TV or video stream. The screenshot on the left, taken with WiSpy/Chanalyzer, shows the distribution of the networks on the different channels an how strong they can be received. My own network is the red curve on the left on channel 1, with at least three or four additional networks using the same channel. However, compared to what's going on at channel 11, this spot in the spectrum can be considered as being almost calm.

Since I figured out how to configure my eeePC for Wifi tracing with Wireshark, I’ve gained a number of interesting insights which go far beyond what you can read in literature on the topic. Standards are one thing, how they are implemented in devices are quite another sometimes. Here are some results I thought I’d share with you:

As a wireless medium is prone to transmission errors, each frame has to be acknowledged by the receiver. If the frame is not received it is automatically retransmitted. So how do devices do this in practice and how often does it happen? I’ve been able to do some pretty interesting traces with a Siemens Access point and a Nokia N95. The two devices are quite different in their radio characteristics as the antenna in the mobile device is far from ideal, especially if there is a wall separating the two devices as was the case in my test. Also, the behavior on the air interface is quite different, which has nothing to do with the antenna configuration.

The Siemens Access point is quite conservative concerning the use of modulation and coding schemes for a packet. The majority of packets are never sent with the maximum speed of 54 MBit/s, but instead with 36 MBit/s or even less. As a consequence, most packets are received correctly and are immediately acknowledged. In case there is no acknowledgement, the access point immediately reduces the modulation and coding by a step for the retransmission. As a result I haven’t seen many cases in which a frame has not been acknowledged after the second try.

The N95 on the other hand is pretty aggressive concerning modulation and coding scheme. It usually always starts with 54 MBit/s and even uses this setting for the first retry. If the first transmission has failed, the second usually does as well. Only for the third transmission is the modulation and coding scheme lowered to 48 MBit/s, then to 36 MBit/s and finally to 24 MBit/s. For subsequent frames, 36 MBit/s seems to be used for about 500 ms before the N95 Wifi chipset tries to go back to 54 MBit/s.

Also interesting is the repetition time in case no acknowledgment is received. On average, a packet is resent after around 0.5 ms. In case a packet is retransmitted 3 times, the resulting delay is about 2 ms. As a single frame usually carries 20 ms voice data, this time is negligible on the application layer and is far less than the jitter introduced on the way through the public Internet.

If you think three repetitions is a lot, you are right. However, I’ve seen cases in which the frame was transmitted 7 times before it was finally acknowledged. In this case, the backoff algorithm even allowed other stations to send their frame before the device could try all retransmissions. Pretty impressive.

The figure on the left shows how such a trace looks like in practice. Frame 6420 is sent but no acknowledgment is received. It is then resent as frame 6421 and then as 6422, after which an ack. is finally received. 6426, 6427 and 6430 are all the same frame, only acknowledged after the second retry. In between is 6428, a frame from another device together with its acknowledgment, 6429.

So that’s how it works in practice 🙂