You are here

AREDN as a weapon of mass disruption

8 posts / 0 new
Last post
KE2N's picture
AREDN as a weapon of mass disruption

Back in the day when WRT54 ruled the roost, all you would need to do is fly an AREDN -1/20 system over a city and shut down every wifi access range...

Well that is pretty darn

Well that is pretty darn interesting.

And here we (a few other devs and myself) questioning if LInksys boxes were able to handle the load of a mesh network that is on the "global" tunnel (the adhoc mesh of meshes that seems to have been created accidently by a few dozen or so sites tunneling to anyone and everyone who requests access) channel -1 problems didn't ever come up as issues.

I no longer have any WRT54g's floating around to test with to see this myself, but rather interesting you can make this occur.

I'm likely to think its the Driver or Chipset but it could be OpenWRT  as well.

For those who don't know the BBHN Linksys devices run a version of OpenWRT known as 7.09 Kamikaze, released in 2007. (AREDN is running BB on production released in 2014, and Chaos Calmer 15.05.1 released in Feb 2016 has been merged into the Development branch and should be in the next Major Release)  this means that the kernel and everything else around it is much older, its possible flaws exist in the code from that age that have been upgraded since then.

Beyond that the RF driver for a Linksys device is closed source, created by Broadcom.  It already has one known flaw (where the device will randomly change channels from the programmed channel to another channel, possibly outside of the HAM bands causing a license issue) that can't be fixed (While I wasn't the first to discover the flaw I made sure it got looked into while I was doing dev for BBHN)  Its internally possible this is a flaw in the closed source portions.

--- What follows below includes speculative statements based on knowledge of the device, however the majority of the internal workings are 'black box' and 'closed source' and as such I am not able to provide a guarantee one way or the other on these statements and they should be taken as opinion/speculation only---

I'll admit channel -1 is a bit unique in how it works, it actually registers as Chanel 255 in the RF protocol (the "channel id" field of RF is an 8bit unsigned binary field so 0-255 and the drivers consider 0 as invalid) so its possible that the hardware is trying to "Jump" to 255 which is WAY outside of its capability (depending how the math was done in the chip) and in addition should only happen if the SSID of the two networks matched.

Though I'm not sure if decoding makes any since as on a 20MHz wide channel its 10 mhz down on -1 which means it shouldn't decode.  This would more likely be that the hardware is just not handling a half channel of RF, but that would mean I would expect it to happen on many more channels as well.

Perhaps BBHN will throw more technical input from their thread.

Oh and a subnote, if anyone

Oh and a subnote, if anyone finds something this critical in AREDN, we have a security team ( ) that should be consulted with to give a chance to patch a flaw like this before it can be exploited by the general public.

(I'm not aware of any such team address available for BBHN sorry)

WL7COO's picture
Thank you for an excellent explanation and posing a clearly

defined theory as such wrt to the 'closed' Broadcom source code..

This is the first good explanation re: why channel "0" is off limits that I've stumbled across<g>.

73, ...dan wl7coo

AE6XE's picture
General use case concern?

General use case concern?

Ken, the general use case for folks integrating their established BBHN-linksys devices with AREDN devices is ch -2 at typically 5Mhz or 10Mhz channel width.  While the ch -1 @ 20Mhz issue is of concern to avoid and for those with intent to misuse, this may impact more individuals if the issue occurred on ch -2 usage.     It would not enable a smooth transition for linksys groups to incorporate newer hardware when they are ready to do so. 

Has anyone observed similar symptoms when integrating with ch -2 in use?    Can we declare this a non-issue for anyone that is running a NSM2 ch -2 on the roof and also has BBHN-linksys ch 1 in the shack?


I'm not sure we have the

I'm not sure we have the power to ever call it a 'non issue', as we can only observe it, I would be inclined to say that it would be up to BBHN to say "Yes there is a fault when around -1@20MHz but it doesn't (or does maybe) exist at <insert condition>".

In the mean time until BBHN comes back with an official status from their side on this and a resolution the best suggestion may be to "Use an AREDN supported device like an AirRouter or other device at sites that are performing band/channel bridiing operations" (I normally recommend this already for people trying to bridge to an AREDN negative channel and a BBHN channel 1, use an AREDN firmware image on a device, this allows you to roll the device over to a negative channel if ever needed without reflashing the firmware)

Either way we remain fully compatible with BBHN and it just becomes an issue of BBHN creating a fault resolution.

KE2N's picture
problem identified

Some experimentation shows that the problem was caused by the fact the same SSID's were in use on both AREDN and BBHN. Even though they were on different channels, apparently the LinkSys tries to go over the -1 to join the AREDN mesh and something inside really does not like finding itself on ch -1.

One problem was that we could not get into the LinkSys router to change it, until we shut down all the AREDN nodes in range. The LinkSys would not boot up and the flashing lights looked exactly like a bad firmware load.

Case closed I think.

AE6XE's picture
This is the known "possessed

This is the known "possessed linksys channel jump" issue.  Same thing happens with another (linksys or other hardware ) same SSID on another channel.   It will jump on it's own over to it, but this is a jump off the edge of the cliff :) .  Linksys was trying to be too smart in the design.  Curious if it can detect a (not part 97 compliant) ch -2 @ 20Mhz in the lab and same thing happens?  Are the receive filters that wide?  Since it can't do 10Mhz and 5Mhz channels, it wouldn't detect these signals and would not an issue. 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer