Testing Wifi with netcat

Sat, Mar 4, 2017

I recently picked up a new 802.11ac wireless router because it was on sale. I’ve been on 802.11n for several years and really didn’t have any complaints, but it was a good deal and a chance to restructure my home network a bit.

Here’s a quick and dirty drawing of my network layout before and after done using GNU Dia (first time using this tool, so maybe not a great example):

network diagram before and after

Nothing special, but in the “after” config you can see that I have both wireless access points available, so I was curious to test throughput differences on AC vs. N. I went looking for a simple way to test throughput on a local network. I found this page that uses netcat and dd to push data across the network with some reporting on throughput.

While testing I tweaked the source of the data a bit and found some interesting results about the speed of 802.11AC vs N as well as AC vs /dev/urandom.

These tests were done by sending data from a linux PC that uses an Intel 7260 PCIe wireless adapter, over the air via the AC access point and subsequently the N router to a PC that’s connected via 1G ethernet to my N-wifi router/gateway.

On the receiving PC, setup netcat to listen on port 2112 (I kept this port from the link where I found this method… I dig Rush and 2112 holds a special place in this nerd’s heart).

 $ nc -lk 2112 > /dev/null

OK, that’s it for the receiving end.

Now, like in the tuxtweaks article, on the sending end we’ll use dd to copy the contents of /dev/zero (pro-tip: it’s a bunch of zeros) and pipe it through netcat using the magic of wireless to the PC that’s listening elsewhere on the network:

 $ dd if=/dev/zero bs=16000 count=35000 | nc -v 192.168.1.16 2112

 Connection to 192.168.1.16 2112 port [tcp/*] succeeded!
 35000+0 records in
 35000+0 records out
 560000000 bytes (560 MB, 534 MiB) copied, 16.7969 s, 33.3 MB/s

The above test used AC on my new router (running in Access Point mode). As you can see from the output of dd - 560MB were copied to the listening IP at the speed of 33.3 MB/s.

Now for 5GHz wireless N:

 $ dd if=/dev/zero bs=16000 count=35000 | nc -v 192.168.1.16 2112

 Connection to 192.168.1.16 2112 port [tcp/*] succeeded!
 35000+0 records in
 35000+0 records out
 560000000 bytes (560 MB, 534 MiB) copied, 71.3027 s, 7.9 MB/s

These results were roughly typical, if a little on the low side… I was consistently seeing AC running ~35 MB/s and 5Ghz N running around ~9 MB/s.

I did start to wonder if there was any effect to throughput from sending only a long stream of zeros, so I decided to use /dev/urandom as the source of my data and that led to something amusing. Piping /dev/urandom over the 5GHz N stayed about 9 MB/s. However, with AC my throughput dropped off to around 19 or 20 MB/s from ~35 MB/s.

 $ dd if=/dev/urandom bs=16000 count=35000 | nc -v 192.168.1.16 2112

 Connection to 192.168.1.16 2112 port [tcp/*] succeeded!
 35000+0 records in
 35000+0 records out
 560000000 bytes (560 MB, 534 MiB) copied, 30.0327 s, 18.6 MB/s

It looks suspiciously like /dev/urandom is now a bottleneck for this test. Just to confirm, I decided to copy about 1G worth of /dev/urandom out to a file on disk and then stream from there:

 $ dd bs=1024 count=1048576 < /dev/urandom > random.file

Now to try the test again, but with the file (on a 6 Gb/s SATA III SSD) as the source of the random bits:

 $ dd if=~/random.file | nc -v 192.168.1.16 2112

 Connection to 192.168.1.16 2112 port [tcp/*] succeeded!
 2097152+0 records in
 2097152+0 records out
 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 30.5995 s, 35.1 MB/s

Ahh, yes, back to normal. Thus proving that ~19 MB/s is the throughput of /dev/urandom on my system. Fun and unexpected.

Thanks to the tux tweaks article about using netcat to test network throughput.