see:
http://bbhn.org/index.php?option=com_ccboard&view=postlist&forum=6&topic=1885&Itemid=67
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 point.in range...
You are here
AREDN as a weapon of mass disruption
Mon, 07/18/2016 - 12:29
#1
KE2N
AREDN as a weapon of mass disruption
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
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.
(I'm not aware of any such team address available for BBHN sorry)
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
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?
Joe AE6XE
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.
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.