Debugging poor home wifi at the Snell-Pym residence (by alaric)
So, we have a fairly complicated network at home - the Snell-Pym Family Mainframe has a dedicated DSL link with a static IP for hosting various Internet-facing things, as well as providing internal services to the home LAN. The home LAN has the usual mix of desktop computers, the laser printer, and two wireless APs for mobile devices to connect to - one in the house and one in the workshop, because one can't get a good signal to both locations. And there's a separate infrastructure LAN for systems control and monitoring.
Now, we've often had on-and-off poor connectivity on the wifi in the house; this used to happen sporadically, usually for around a day, then just get better. The wifi signal strength would remain good, but packet loss was high (10-20%) so stuff just didn't work very well. TCP is poor at high packet loss; it's OK once a connection is open, but packet loss during the initial SYN/SYNACK/ACK handshake causes it to take a long time to retry on most implementations.
I went looking for interfering networks (we live in a pretty wifi-dense urban area) using an app called "Wifi Analyzer" on my Android phone, and it showed a strange network, always on the same channel as the house wifi (as in, if I changed the channel, it would move too). The network never had a name, and the signal strength was about the same as the house wifi; sometimes a bit stronger, sometimes a bit weaker.
I tried replacing the AP (I had an identical spare in storage), to no avail. But the problem would just go away before I ever got to the bottom of it, so it was just chalked down as a strange, frustrating, inconvenience. My only theory was that it was some device on our network that was trying to present itself as a wifi network in order to accept configuration - the Google Home Mini, when it can't connect to wifi, pops up an access point so that the Google Home app on an Android device can find and connect to it and tell it what wifi it should be using; and I'd noticed that it did that on the same channel it had been using to connect to the wifi normally, which would explain the channel-following behaviour. But what device could it be? It wasn't the Google Home Mini as it persisted even when that was turned off, and the Amazon Fire TV stick, laptops and mobile phones let you configure it via their own user interface; and that's all that connects to the wifi. I wondered if some device was buggy and emitting rogue AP advertisements.
However, recently, it started to get worse and the naff house wifi became continuous rather than sporadic. With lockdown and schooling the kids from home, house wifi also became more of a critical resource, with family members sometimes coming and sitting in the workshop with their devices just to get non-rubbish Internet connectivity.
So I had to do something about it, and what I did was to order a new access point - an Aruba AP-205, £55 second-hand from eBay. It's designed to be the kind of access point that goes up on the ceiling in an office, and the feature set emphasises central control of a fleet of them on the same network and lots of enterprisy features. But what made me choose it was the claim in the datasheet that it had some snazzy anti-interference capabilities. To save you viewing the PDF, in particular, it claims:
• RF management
- Adaptive Radio Management (ARM) technology automatically assigns channel and power settings, provides airtime fairness and ensures that APs stay clear of all sources of RF interference to deliver reliable, high-performance WLANs.
- The 200 Series APs can be configured to provide part-time or dedicated air monitoring for spectrum analysis and wireless intrusion protection, VPN tunnels to extend remote locations to corporate resources, and wireless mesh connections where Ethernet drops are not available.
• Spectrum analysis
- Capable of part-time or dedicated air monitoring, the spectrum analyzer remotely scans the 2.4-GHz and 5-GHz radio bands to identify sources of RF interference.
• Security
- Integrated wireless intrusion protection offers thread protection and mitigation, and eliminates the need for separate RF sensors and security appliances.
Anyway, the thing duly arrived, and I started to configure it. Reading the manual, I was a bit taken aback by its capabilities - I hadn't realised wifi AP technology had gotten this far.
Basically, it seems to monitor the entire wifi bands (but 2.4GHz and 5GHz), and identifies all the access points and client devices it can see. It then uses various heuristics to classify them - access points in its cluster are identified as friends, those that aren't are identified as neighbours... and APs that claim to provide the same network name or that are connected to the same wired network as it (eg, where somebody has plugged in their own AP to a corporate LAN, which might bypass network security restrictions), but aren't on the whitelist, are identified as "rogues". Clients that look like they're probing the network or attempting various wifi DoS or key-cracking/guessing attacks get classified as rogue, too.
Ok, cool, right? Detecting that another AP is on the same wired network as it is quite a technical feat in its own right. But what really surprised me was that it has a capability called "rogue containment".
If that's turned on, then when it detects a rogue AP or client, it will attempt to actually take it off the air. Here's how.
At the simplest level, it will spoof deauthorize frames from a rogue AP to all their clients, or from any APs a rogue client is talking to to that client. This forces them to reconnect to the network.
But if you turn the knobs up to eleven, this thing gets nasty. It will spoof frames from a rogue AP, or from any AP to a rogue client, telling the clients to connect to their AP on a channel that's not actually in use, meaning that the client will think it's connected to the network but then see no wifi signal strength. What a bastard! The manual warns that enabling that might be against FCC regulations so it's up to you to decide if it's legal where you live...
Well, for fear of wiping my neighbour's wireless networks out, I enabled only the lightest defensive measures ("Protect SSID" and "Protect against AP Impersonation"). I installed the access point and turned it on, and so far, the network connection has been perfect.
But this thing has a snazzy web UI with fine-grained monitoring, and I've been watching it carefully... because the strange name-less network is still there.
But unlike my phone, this device has managed to catch it transmitting a beacon frame with a network name in it.
"DIRECT-qC-FireTV_4c9b"
Ah-hah. Fire TV Stick, I'm onto you.
Looking in the devices list, the MAC address of the Fire TV stick is but one hex digit (somewhere in the middle) different from the MAC address of this peculiar access point. Smoking gun, I think.
Now, this doesn't mean that the Fire TV stick is the cause of our former Wifi problems; it's merely strange that it appeared when we have wifi problems - and it could have been it attempting to present some kind of configuration interface to configure its wifi, like the Google Home Mini (except that it doesn't need that, as it does have its own on-screen UI for wifi configuration). And it's still there now but failing to interfere with our connection any more.
So why's the Fire TV stick emitting a wifi network of its own, that my phone can't identify the name of? I need to see if I can convince my laptop to try to associate with it so I can see what it's doing, perhaps.
Disconcertingly, it's managed to spot the workshop access point, and it's worked out it's on the same wired network as it, and I've not put it on the whitelist so it's labelled it as "Rogue"... if I'd not turned down its offensive counter-measures it'd be trying to snipe it off the network right now!
But, most importantly, our home wifi now works, and I have a fascinating new toy that's busily categorising all the wifi access points and devices in my neighbourhood for me to nosily twitch my virtual net curtains at. It's even offering to help me locate them physically, although with only one access point in its cluster it's not able to triangulate much (but I'm kinda tempted to get a second one for the workshop, just to see them hunt in packs). £55 well spent, and an eye-opening view of just how intrusively you can monitor and police a wifi network with off-the-shelf equipment!
Alaric, Crypto / security, Domestic, Radio | alaric | 
Mon 4th May 2020 2:30 pm
Subscribe
By @ndy, Mon 4th May 2020 @ 3:35 pm
Nice writeup!
Last night I was turning my attention to the ENC28J60 so I can recall from its datasheet that it says "If the Least Significant bit in the first byte of the MAC address is set, the address is a Multicast destination."
Does that correlate with the digit (hexit?) that you see flipped in the MAC address?