Wi-Fi Tracing With Ubuntu and an Acer Aspire

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.

Wireshark-wpa-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!

2 Day LTE Services Course at the University of Oxford

Great News: On April 20 and 21st, Ajit Jaokar of Open Gardens and I will host a 2 day course on LTE Services at the University of Oxford's Department of Continuing Education!

Here’s the agenda:

  • New services based on enhanced capacity of the network
  • IP based business models
  • Rich voice applications
  • New role of devices to handle rich content and social networks
  • Social networks based on rich content like video
  • Services unique to LTE and the core network
  • Greater role for user generated content and for rich media
  • Unified communications and beyond 3G networks
  • Fixed mobile integration – leveraging enhanced networks and learning from past mistakes
  • Integrated networks and connecting back to home networks
  • Network elements: Femtocells vs Wi-Fi in the home gateway and services based on these elements
  • Wireless sensor networks at home and their role and opportunity in an overall beyond 3G network

I am very happy to be part of this and it will be great to look at these topics from our two different angles. We've also put together a questionnaire to see what your angle is on this topic. If you have a minute and are interested, we'd be happy to get your feedback. We'll share the result with those who leave their e-mail address and of course with all course participants. Needless to say that all responses are treated confidentially.

So, if I have caught your interest, head over to the course's web site for the details. During this week, there’s also the yearly Forum Oxford Future Telecommunication Conference. More about that in an extra post once the details are sorted out.

Lots of Wi-Fi in Smartphones These Days

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?

Old Centrinos Speak WPA2, too!

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.


These days I was wondering if in the mid-term, femtocells might replace public Wi-Fi hotspots!?

With the rise of 3G USB keys and notebooks with built in 3G connectivity, the popularity of Wi-Fi hotspots, especially paid ones, is likely to degrade over time. Once people have a 3G card anyway and have instantaneous connectivity anywhere, people just won't bother anymore to search for a public Wi-Fi hotspot and go through the manual login process. In addition, femtos remove another shortcoming of public Wi-Fi, the missing air interface encryption which today leaves the door wide open for all kinds of attacks.

With rising demand for Internet access in hotspot areas such as hotels, airports, train stations, etc., HSPA or LTE femtocells might be the ideal replacement for aging Wi-Fi access points which at some point have to be replaced by new equipment anyway. So mobile operators such as T-Mobile, Orange and others, who have a dual 3G / Wi-Fi strategy today could at some point just make such a move if they see that use of their Wi-Fi systems is decreasing and use of their 3G/4G macro base stations in the neighborhoods of their Wi-Fi installations is significantly increasing.

Some 'dual-mode' operators might even have a database with the geographical location of their base stations and their Wi-Fi installations. Together with traffic statistics of both systems an automated system could document changes over time and could be used to help predict when and if a replacement of the Wi-Fi access points for femto cells might make financial sense. After all, femto cells are just as easily connected to a DSL line than a Wi-Fi installation.

Maybe some femto manufacturers even come up with integrated Wi-Fi/Femto boxes for public installations with the Wi-Fi being used to create a wireless mesh between several nodes in locations with only a single backhaul line and for access for those people not yet having 3G connectivity. Agreed, femto vendors today mainly position themselves around the femto base station for home networks but public femtos might be an interesting opportunity as well.

WPA Insecurities

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. 

I Can Now Detect over 25 Wifi Networks At My Flat!

25 wifisA 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.

Breaking the Radio Silence with VoIP

In cellular networks, the primary rule for voice telephony is efficiency, efficiency, efficiency. Translated into practice, this means that the mobile device patiently waits till it receives a paging for an incoming call or until the user wants to establish an outgoing call. In the time between, there is complete radio silence, except for occasional short signaling exchanges once every few hours to confirm to the network that the device is still switched on. With always on mobile Internet devices, this is going to change significantly, as the following example shows:

In previous blog entries, I’ve described how well the SIP VoIP client works on the Nokia N95. It blends in very nicely with the rest of the phone’s functionality and I can’t tell the difference between a cellular call and a VoIP call over Wifi. On the radio layer, however, things could not be more different.

While the cellular telephony application remains silent while no call is ongoing, the VoIP part remains quite active on the IP layer. Per minute, there are at least 10 message exchanged between the mobile and the network for various reasons such as keeping communication ports open on NAT firewalls. While it doesn’t seem to be an issue for battery capacity, as there is still ample capacity left in the evening despite being logged into the SIP server over Wifi all day,  it does have implications for cellular networks once VoIP is used there, too. While not all messages exchanged over Wifi will appear in cellular networks, at least 6 of those 10 are relevant for that scenario as well.

Today, each cell serves about 2000 users. For the network, this is not a problem since most mobiles are dormant. In a world where most mobile devices are IP enabled and use a standard SIP VoIP client, 2000 x 6 (or even more) message exchanges per minute means 12,000 message exchanges per minute over a single cell for more or less nothing.

To stay with the SIP VoIP example, here’s an overview of what I traced with my Wifi Tracer during a typical 60 seconds time interval while the SIP client is running and the phone is connected to a Wifi network:

  • At 7 seconds into the minute, the N95 wakes up because it receives a notification from the access point that an IP packet has arrived. It sends ‘power save poll’ management frame and receives an IP packet from the STUN server or the SIP server. In total, the mobile transmits 4 frames and receives 4 frames during this message exchange (including acknowledgments at the MAC layer).
  • At 11 seconds into the minute, The N95 decides to return the polling gesture and sends 1 packet to the STUN server and 1 packet to the SIP server. The STUN server sends a confirmation. Afterwards, the mobile enters the Wifi sleep state and informs the network with a corresponding management frame. In total, the mobile transmits 4 frames and receives 3 frames.
  • At 12 seconds into the minute, the mobile has to turn on it’s transmitter again because there is some data waiting again. It sends a poll frame and receives an ARP broadcast as the access point queries all IP addresses in the subnet. The mobile answers the ARP request and goes back to sleep. In total, the mobile transmits 7 frames and receives 6 frames.
  • At 16 seconds into the minute, the mobile feels a sudden urge to check that the MAC address of the router is still valid. This is as unnecessary as the ARP request from the router at 12 seconds, but it’s happening at least once a minute. The mobile transmits 2 frames and receives 2 frames.
  • At 22 seconds into the minute, a keep alive frame is received from the SIP or STUN server. I stop counting frames at this point.
  • At 34 seconds into the minute, the router runs another ARP request for all IP addresses in the subnet.
  • At 35 seconds, the SIP/STUN server sends a keep-alive frame.
  • At 37 seconds, the mobile returns the favor.
  • At 46 seconds, the mobile returns to sleep state and signals this to the Wifi Access Point.
  • At 49 seconds, the SIP/STUN server sends a keep alive frame.
  • Silence until 4 seconds into the next minute.

And now imagine you have a push eMail client and Instant messenger running, which will create even more traffic and 2000 other mobiles in the cell doing the same.

Standards bodies seem to have become aware of this issue, at least to some degree and have started to specify radio interface enhancements to counter the challenge. In case of UMTS and HSPA, the following come to mind:

I am not sure how LTE and WiMAX handle such very low speed but persistent message exchanges on the MAC layer. If anyone can give me pointers to that, I’d really appreciate.

Sniffing Wifi Packets and Exploring Retransmission Behavoir

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 🙂

Intercepting VoIP Calls with Wireshark

In case you have an Nokia N95 or similar SIP capable 3G / Wifi / VoIP phone and wondered why the little icon during a VoIP call shows an ‘open lock’, the answer is simple: The encoded voice data is not end-to-end encrypted. That means that anyone on the network between you and the other party who can intercept the data packets can listen to your conversation.

Sounds difficult to do in practice? Well, not really. I recently discovered that Wireshark, a free network monitoring tool, can decode G.711 PCM encoded speech data of SIP VoIP calls as shown in the picture on the left.

Just to be clear, this is not the fault of Nokia as I haven’t seen any other SIP client in practice yet that encrypts the voice data stream. In a public Wifi hotspot, intercepting the call and listening to the conversation is very simple, as the data packets are not encrypted between the device and the Wifi access point. In home networks, things get more difficult because most people nowadays have encryption between their devices and the Wifi access point enabled. But do you know what happens on the other side of your DSL connection…?