WifiCopper — 802.11b Packet Injector

WifiCopper is a unique, PC-based product that aids in testing WiFi wireless networks. It is used to create wireless traffic on a particular channel and at a known level (i.e. packets / sec) and size (i.e. bytes / packet) without the need of the client adapter associating with an access point.  This makes it much easier to measure the quality of the transmission and reception performance on a particular 802.11 channel.

Whereas WifiCopper is used to inject wireless traffic, to complete the measurements it is also necessary to use packet capture software. We've had success using AirPcap/Wireshark, though other packet capture solutions are available — e.g. CommView for WiFi, and OptiView® Network Analyzer.

When troubleshooting a wireless network, being able to measure packet capture rates may be more informative than RF spectrum analysis — because now you are measuring the real thing. Though poor packet capture rates can't distinguish between interference or obstacles that create 'dead spots' or poor antenna location or positioning, because you are measuring packet rates then whatever changes you make to the system to improve packet rates should directly be reflected in improved performance. That is, if you reconfigure a wireless system (i.e. channel selection, antenna location and position) such that packet rate is doubled, then you should see a similar improvement in the overall performance of the wireless network. You can't make these sorts of measurements using an RF spectrum analyzer, since it doesn't measure performance.

WifiCopper Key Features

WifiCopper May Be Used For

---

Example: Measuring the Rate of 802.11 Packet Capture and Calculating the % Transmission Efficiency

When it comes to troubleshooting an 802.11 wireless network measuring the rate of packet capture may be a more valuable metric of the quality of 802.11 transmission / reception than RF spectrum analysis because you are measuring the real thing – i.e. performance throughput. Though this metric can not distinguish between interference versus obstacles or "dead spots" being the cause of poor performance, since packet rates are measured then whatever improvements you make to the system should directly translate to better performance. This is very useful – network discovery tools and spectrum analysis can not make the same claim.

Whereas WifiCopper is used to inject wireless traffic, to complete this type of measurement it is also necessary to employ packet capture software. We've had success using AirPcap/Wireshark, though other packet capture solutions are available — e.g. CommView for WiFi, and OptiView® Network Analyzer. In the example below we'll be using AirPcap/Wireshark – that is, on one machine we'll run WifiCopper (to inject 802.11 packets) and on a second machine we'll run AirPcap/Wireshark (to capture packets).

Figure 1 shows
WifiCopper running on the first machine where we've set transmission on channel 13, injection rate to 80 packets / sec, and packet size to approximately 1500 bytes / packet. We then press the 'Start' button and WifiCopper begins transmitting packets using these parameters.

On a second machine we run AirPcap/Wireshark, configure packet capture on channel 13, and capture packets for 60 seconds. This is shown in Figure 2. Referring to the arrows, we see that 4703 packets were captured over a 60 second interval (approximately 80 packets per second). Furthermore, when we begin examining the packet's fields we see the overall frame size of 1552 bytes is close to the 1500 bytes we specified in WifiCopper.

Next, in Figure 3, we learn more about the packets that were transmitted by WifiCopper. For example, we see the transmission rate used by WifiCopper's 802.11 adapter was set to 1 Mb / sec, which is roughly 125,000 bytes /sec. Furthermore, 80 packets per second, each 1552 bytes in size, works out to 124,160 bytes / sec. So, under these particular conditions where WifiCopper's transmitting device and AirPcap's receiving device were within a few feet of one another with no obstruction between them, we saw essentially no packet loss. However, when greater distances are tested or obstructions introduced, then the packet capture rate is significantly affected and declines accordingly.

Finally, refer to Figures 4 and 5. WifiCopper embeds a packet number near the beginning of the data field. The data bytes are all hexadecimal 0xA5 — however, data byte numbers 9,10 are the packet number as encoded by WifiCopper. Packets are numbered from [0,65535] and when 65536 is reached then it starts over at '0'. That is, the 9th and 10th data bytes are not 0xA5 but, rather, a two-byte counter. Figure 4 highlights packet number 4703, the last packet in the 60 second interval during which packets were captured. We see that WifiCopper embedded packet number hexadecimal 0x682F — or decimal 26671. Figure 5 highlights packet number 0, the first packet in our 60 second interval. And we see that WifiCopper embedded packet number hexadecimal 0x55CE — or decimal 21966. The difference between 26671 and 21966 is 4705 – that is, WifiCopper sent 4705 packets during the 60 second interval. Since AirPcap/Wireshark captured 4703 packets, then we have nearly 100% transmission efficiency. Turns out that due to the way AirPcap/Wireshark numbers the packets, the transmission efficiency is slightly over-stated. The 4703 packets reported by AirPcap/Wireshark not only include the ones injected by WifiCopper but also other packets transmitted on channel 13 by other access points in the area. This number is dwarfed by the number of packets transmitted by WifiCopper, but it could affect the overall, computed transmission efficiency by 1 or 2 percent.

Figure 1.	Figure 2.
Figure 3.	Figure 4.
Figure 5.