Wifi on Insignificant Bits

Router redux

Thu, 07 Dec 2017 20:20:25 +0000

I had just a little bit of downtime over the last few weeks while Angeline and I reacquainted ourselves with how to take care of an infant. It’s like riding a bicycle: there are tons of things you forgot since last time.

One of the long-on-my-todo-list items finally got completed: I upgraded all of my wifi routers. I have 5: an old dual band 11n router and four TP-Link 11ac units, all of which were running some oldish build of OpenWRT.

Encrypted mesh PSA

Mon, 31 Oct 2016 13:32:19 +0000

I’m a bit late writing this up, as lately wifi stuff has taken a back seat to the day job. But, I’ve now seen the following issue reported more than once, so hopefully this post will save the other two mesh users some grief.

If you are running an encrypted mesh on wpa_supplicant or (ye gods) authsae, take note:

Encrypted mesh on kernel 4.8 will not interoperate with kernel < 4.8
wpa_supplicant 2.6 will not interoperate with 2.5
authsae as of commit 706a2cf will not interoperate with that of commit 813ec0e [1]
wpa_supplicant 2.6 and authsae commit 706a2cf require additional configuration to work with kernel < 4.8 (see below).

On Drawing Squares

Sun, 03 Apr 2016 21:24:05 +0000

I’ve been looking at the sample drawing in speccy to try and speed it up. For a given frame, it renders about 10000 points as 9-pixel anti-aliased squares using Cairo, in Python. On my desktop (Debian stable, Nouveau driver) it gets a pokey 1 FPS.

My graphics knowledge is about 20 years old at this point, and while I did once know various arcane tricks on the hardware of the day, none of that is relevant now. So I know basically nothing about modern graphics. It is still not clear to me to what extent the 2D primitives use acceleration, and it doesn’t help much that, in as many years that I’ve been asleep on this topic, there seems to have been as many new APIs introduced and retired: today there are at least XRender, XAA, EXA, UXA, SNA, and Glamor – did I miss any?

sae.py

Thu, 31 Dec 2015 23:57:47 +0000

For a while now, I’ve wanted an easy way to decrypt a mesh packet capture when I know the SAE passphrase. This would be quite handy for debugging.

I reasoned that, if I knew the shared secret, and had captured the over-the-air exchange, it should be possible to make such a tool, right? We know everything each station knows in that case, don’t we?

So I spent a bit of time last week reimplementing SAE in python to come to grips with its various steps. And I found my reasoning was flawed.

Fake SNRs

Mon, 21 Sep 2015 13:13:51 +0000

With the addition of per-link signal levels that I added over the weekend, my wmediumd fork leveled up from “mere curiosity” to “potentially useful someday.” For the case of mesh, this means you can use signal levels to inform how HWMP will create the mesh paths.

For example, as a test I was able to validate this fix, by setting up a virtual 4-node mesh with a bad path and a good path. With the patch reverted, the bad path was almost always selected due to its PREQs being received at the target first. [In actuality, this test will exhibit frequent path swapping because the order in which the PREQs are received is essentially random, a finding in “Experimental evaluation of two open source solutions for wireless mesh routing at layer two” by Garroppo et al. Wmediumd doesn’t show this yet because frames are mostly received and queued in-order. At the time of the patch, I validated it in an actual 15-node mesh.]

tmux + wmediumd

Sun, 13 Sep 2015 16:39:23 +0000

Wmediumd gained the ability to do a simple contention simulation a while ago. It turned out to be a small change to the existing code: just ensure that any new frames are scheduled after any other queued frames of equal or higher priority from any other station.

Assuming the simulation is accurate, we might use this to gather some information about different kinds of wireless network topologies. For example: what is the throughput and latency like for a mesh network, as a function of hops?

Weekend updates

Mon, 07 Sep 2015 00:20:50 +0000

More updates to speccy pushed to github this weekend. It gained the ability to toggle on-and-off line and scatter plots. Also, it now takes care of enabling spectral scan and then scanning channels (by exec()-ing iw, naughty me) so you can just tell it the device and it does the rest. Code is still ugly but gradually taking shape. There’s an animated gif for those that want to see what it currently looks like in operation.

time vs frequency

Wed, 02 Sep 2015 13:29:22 +0000

This is roughly what I had in mind for the time/frequency plot for my little spectrum visualizer. Time is on the y-axis and frequency on the x-axis. There are some interesting artifacts here, especially on the higher channels. Probably bugs in my implementation, but we’ll see as I develop it further.

Speccy with labels

Mon, 31 Aug 2015 01:49:56 +0000

I messed around with “speccy” a bit today to see what I could do with it to make it look slightly nicer. It really needed a grid so one can more easily see the frequencies and power levels. So now it looks like this:

(This is with iperf running on channel 6 to a nearby AP).

I have in mind a couple of other visualizations. An obvious one is to show the overall max or average power level rather than a scatter plot. This would be a cleaner display, although there could be co-channel interference sources you wouldn’t see that way. Here’s a first cut at that:

VHT mesh

Tue, 14 Jul 2015 04:43:30 +0000

…is a thing now.

# iw dev
phy#0
    Interface wlan0
		ifindex 4
		wdev 0x1
		addr 30:b5:c2:fb:34:d8
		type mesh point
		channel 149 (5745 MHz), width: 80 MHz, center1: 5775 MHz

# iperf -c 192.168.1.20
------------------------------------------------------------
Client connecting to 192.168.1.20, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.21 port 34175 connected with 192.168.1.20 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   148 MBytes   124 Mbits/sec

DWM-W034 UART

Fri, 15 May 2015 13:43:56 +0000

In response to my previous post about UART access on the Alfa AWUS036NHA, I got a nice email from Jim Ewing about the DWM-W034, an ath9k_htc device that apparently is embedded inside HDTVs and readily available for $10. He found the TX/RX pins on the board, and it looks like it would be a bit easier to put a socket on one of these compared to the Alfa since there are no pesky chips nearby.

Reserialized

Sun, 10 May 2015 04:17:32 +0000

I got a shiny new device today and the first thing I did was crack it open and heat it to 680 degrees. A good feeling.

The device in question is an ath9k_htc USB wifi dongle. A colleague suggested this one has an easy to access UART because they brought out the TX/RX pins out from the SoC to dedicated pads. He and I apparently have different definitions for “easy.” Unlike the TP-Link routers which give you through-holes to work with, these are simply SMT pads, and they are tiny in comparison. My soldering iron tip is at least double the size of the pad. Yes, it is somewhat better than trying to solder directly to the pins on the SoC, but not by a whole lot.

serialized

Fri, 20 Feb 2015 13:20:01 +0000

My ath10k-based router now has serial headers, after I managed to crash it a few times over the weekend while testing out some patches. Thank you, TP-Link, for making the pins so easily accessible, to the extent that it’s easier to whip out the soldering iron than remind oneself how to setup kexec/kdump.

I do need to get one of these nifty usb-serial cables so that the JTAG ribbon cable + FTDI-breakout-on-a-breadboard monstrosity can go back into the parts bin, but it is working fine otherwise. [The pictured 7-segment display and TTL chips are just misdirection, by the way.]

Spectrum

Mon, 01 Dec 2014 13:48:42 +0000

The ath9k and later chips support a spectral scan feature for measuring channel occupancy. I played with it for the first time last week over the Thanksgiving holiday. Simon Wunderlich’s FFT_eval is a great tool to look at the captured RF spectrum, but I found myself wanting something more real-time, and the various other things I found on github with that aim didn’t work for me. So, this too-ugly-to-live python hack happened.

wmediumd speed test

Mon, 29 Sep 2014 05:19:41 +0000

Thanks to some inquries on linux-wireless, I took a look at wmediumd recently. The code could use a bit of work, and there are some features I’ve been meaning to add since forever, so I started gutting it with an eye towards sprucing up the architecture and feature set (changes can be found here).

One of the questions from the mailing list was whether wmediumd adds a lot of overhead compared to mac80211_hwsim. It is of course doing more work, with additional memory copies, context switches, etc – but is it enough to make wmediumd unworkable?