Ubiquiti still refuses to release images for complete system recovery for EdgeRouter devices. So when your EdgeOS firmware gets corrupted beyond repair and your out of warranty then the only course of action is to install LEDE. No official restoration procedure for EdgeOS is available.
That is not understandable for me since most TP-Link devices and Netgear units too have a way to restore the entire firmware using TFTP.
Fellow developers-
I wanted to follow up on this topic, as it pertains to anyone
considering using OpenWRT/LEDE on Ubiquiti wireless gear (I can't speak
to the EdgeRouter, etc. devices).
I have been speaking with one of the executives at Ubiquiti, and he
disclosed that they have been feeling pressured by the FCC to deal with
the perceived issue of firmware being able to alter the RF
characteristics of the hardware, particularly in the 5 GHz. band. He
pointed to this note from the FCC as evidence:
This is an interesting document - I really don't understand what legal
standing it has - wasn't this the proposal that set us all to the web
last year to try to make the FCC be sensible? In its First Review and
Order of July 13
(https://apps.fcc.gov/edocs_public/attachmatch/FCC-17-93A1.pdf) the FCC
specifically mention in the footnotes that they are NOT addressing
"...provisions to prevent the unauthorized modification of the software
and firmware that ensure that and RF device complies with FCC rules that
prevent harmful interference..."
So it appears, at this point, that the FCC's position is that the
replacement of firmware on devices is perfectly legal, but, to have a
U-NII (5 GHz) device authorized in the U.S., it must have its firmware
locked so it cannot be modified.
Whatever the legality is, the folks at Ubiquiti have made the decision
to lock the bootloader on all their models so that firmware that is not
specifically "signed" by Ubiquiti cannot be flashed on to their
products. Models with locked bootloaders are just being introduced now -
my last batch of Loco M2 units (note that these are 2.4 GHz. radios)
were very odd: on units running AirOS 5.6.12 (as they shipped) I could
load LEDE via the Web UI, but I could not load it using tftp. I updated
some units to AirOS 6.0.6 and could not load LEDE at all via any method.
Even connecting to the serial port did not help - the console stops when
the firmware starts booting.
The bottom line is this: effective in the very near future, we will not
be able to load OpenWRT/LEDE on to Ubiquiti wireless gear, unless I'm
missing something here.
And we should expect every vendor to follow suit.
This represents an interesting problem for getting commercial vendors to
adopt and support OpenWRT/LEDE - if Ubiquiti is interpreting the FCC's
notes correctly, any company that wants to use OpenWRT/LEDE will have to
sign the images so they cannot be modified. This seems to contradict the
real value of OpenWRT/LEDE - and how would that even work with opkg, etc?).
I wanted to report what I have found to this group and see if anyone has
any brilliant ideas. I haven't any at the moment.
Thanks,
Bill
Bill Moffitt bmoffitt@ayrstone.com writes:
I have been speaking with one of the executives at Ubiquiti, and he
disclosed that they have been feeling pressured by the FCC to deal
with the perceived issue of firmware being able to alter the RF
characteristics of the hardware, particularly in the 5 GHz. band. He
pointed to this note from the FCC as evidence:
https://assets.documentcloud.org/documents/2339685/fcc-software-security-requirements.pdf
The executive lied. That's the Ubiquiti market strategy. They tell lies
until they are pushed into a corner. Then they become silent. Until
the next person starts asking. Then the same lies are repeated. This
story can obviously be repeated again and again.
You should google before repeating such nonsense in public. Notice the
date of that document? The FCC has clarified their position multiple
times since then, and even published updated revisions of those
requirements. See for example:.
Feel free to forward this back to your executive contact. But please be
aware that he already knew all this. And he probably has a followup lie
for you. Please google it this time...
Bjørn
Hey Bill,
My next words are not directed towards you or a specific person or any company.
These come to clear very known things which some try to just ignore.
I want to clear up couple things since your words can be misleading.
First I want to let anyone that reads this post that I am not a RF or embedded or electronics certified expert but,
I'm in the field for a very long time(since 199x) and I have couple good mentors which are experts in these fields.
I have asked them more than once about this matter and others.
They answered and cleared for me many practical doubts which led me to respond this post.
We can split the issue with RF transmission devices into couple:
The first is a natural physical phenomenon which is hard to overcome which is induction of waves.
This issue is the first to concern of the FCC and many other organizations around the world.
Many hardware components can form a wave in a certain frequency and in a specific length but,
it will always overlap a certain nearby frequency and also will 100% create a parallel wave then the desired.
It's possible to cancel some of the parallel and nearby "noises" that the transmission creates but.. it costs money.
Also when you go upper in the wave length and\or power it becomes much harder technically\physically to control the "noises".
There are many companies and home made and low quality and cheap transmitters which will be fine for usage in the
middle of a place where humans and communications gears are not operated like in the depth of a jungle or a desert.
But these devices can harm delicate electrical systems operations which are critical for human lives.
And also as upper you go into the frequency this task becomes much harder.
Many 2.4 devices already proved that there is a need to enforce a policy regarding the basic quality gears which creates RF.
Another issue is that the world of electrical parts such as communication gear chips became so advanced that the same gear
can be programmed to create either a specific desired frequency and also in a specific amplification\strength.
The most common device which can demonstrate this concept is the size and power of welding gears.
The simple and "old" welding power supply was a simple a transformer to either AC or DC.
These transformers are monsters in their size compared to the new electrical version which is lighter and smaller.
And yes, these devices are super dangerous for touch!!!(let alone the danger of usage without the proper eyes shielding)
These issues:
Are the main concern of the FCC and many organizations around the globe.
And just to illustrate how many crazy things humans can do intentionally for the sake of Internet or money you can try to dig into youtube.
You can see documented installations of Microwave gears was on towers in a height of above 50 Meters without any safety gear.
These gears can save\spare or cost human lives!!(both the safety and the RF)
Once consumers (network engineers and integrators) will understand this and consider the risks and they will not be blinded by money or fame or other things which
are based only on lust and\or greed and\or the need to survive the next day in a crazy world, they will fold their tail between their legs and
will act much carefully and will not pull their joker winning card "GPL and Open Source compatibility".
All The Bests,
Eliezer
Hi elico,
I can not follow you. The RadioLockDown came from the ETSI, the "european FCC". So FCC was just following the ETSI in that concern.
It's not the device violates the regulatory, people violates the regulatory. In the first drafts SDR (software defined radios) are mentioned as the "reason" to create the RadioLockDown: No idea what routers have to do with it.
We're talking about 5 Ghz and 2.4 Ghz. Both frequencies doesn't have a well-good propergation. Second the usual transmission power is about 100 mW. Yes 5 Ghz is allowed to use 1 Watt in certain country.
So even if the firmware signature is working, I still can get hardware which operates with wrong country settings. And locking the country wouldn't work either, because we buy and sell device globally. So again the people violates the regulatory.
I think more interference comes from in-proper shielded power supplies than from this. This is also the reason why many notebook power supplies in Europe have a ground connection in difference to the ones from the US.
The RadioLockDown is not about interferance or frequency issues.
No. No one should die because the wifi is not reliable at a certain moment.. Hopefully there is pacemaker which relies on the connection to your smartphone to work.
The RadioLockDown move the trust of the whole firmware to the vendors. But can we actually trust those vendors?
A lot of the vendors doesn't care about security updates (e.g. Ubiquity doesn't seem to care either). Of if a vendors supports security updates, but for how long? Should I through away the 1 year old device?
The result would be a mass of outdated devices which results into botnets like the Mirai Botnet.
In Germany it's also forbidden to use such "Kill ForeignAPs" or "Deauth all Clients on ForeignAps" in commercial enterprise wifi appliances. But those company still shipping this feature to customer in germany, do you think signing the firmware would solve this problem?
But back to the original post. Ubiquity has shown in the past they doesn't like OpenWrt/LEDE community at all [0]. So far Ubiquity doesn't release the source code of their U-Boot modifcations.
Why not buying hardware from vendors which supports the OpenSource community?
[0] https://lists.openwrt.org/pipermail/openwrt-devel/2015-November/037572.html
PS. 2.4 Ghz devices shouldn't be locked by the RadioLockDown, only 5 Ghz devices.
That's true.
Hi bmoffitt,
thanks for the explanation. We have a couple of these newer loco M2 XW, shipped with AirOS 5.6.12.
We tried to upgrade one with lede using the Web UI => it doesn't work anymore. I think we have broken it.
Could you please let me know which lede image have you succesfully loaded on your device?
Thanks for your help.
Cant you downgrade to 5.5 and then flash LEDE?
Unfortunately, the downgrading procedure doesn't work anymore.
Well downgrade over TFTP should still work
There is no way to downgrade it. Have you ever tried it on a XW model?
Cant you just flash a new u-boot version without firmware checking to it based on the gpl archive ?
Yeah I tried it couple of months on Loco M2 XW,could be that they changed it.
Giuseppe-
I was able to flash the 17.01.2 images. There was a change in MTD
layout, so earlier builds may not work. The trunk images work, as well.
However, note that nothing (except AirOS) works via tftp, which is...
weird. It seems as if uboot is locked, but, somehow, the WebUI in 5.6.12
overcomes the lock. Or something like that... I tried using a serial
cable to discover what was happening, but they have turned off the
serial console in AirOS.
PLEASE NOTE: they will soon be shipping everything with AirOS 6, and
there will be no way to overcome the lock (unless you somehow hack the
signature). If you are (like me) depending on Ubiquiti products running
OpenWRT/LEDE, it's time to find an alternative - Senao/Engenius,
Comfast, etc. That's what I'm doing - if anyone is interested, I'll can
update the list on what I find out there. So far I have taken a hard
look at Engenius,/Senao. They provide a "GPL dump" of their firmware
source if you ask multiple times, but I don't have the
knowledge/experience to turn that into a working OpenWRT/LEDE image
(It's probably fairly easy, I haven't put in the time to figure it out).
For instance, the files for the ENS620EXT (a very nice outdoor AP) are
here:
https://files.mycloud.com/home.php?brand=webfiles&seuuid=1bf3b5078722a94c8c5b1ec9a16b3e89&name=GPL_ENS620EXT.tar_2
-Bill
Hi Bill,
thanks for your reply.
We tried to flash with Lede 17.01.2 stable (Factory) via WebUI (AirOS 5.6.12) without success => we bricked the unit.
Did you load the stable release or the trunk image?
By the way, yes, we have hundreds of nanostations and, if we cannot use OpenWRT/Lede anymore, then we need to find an alternative.
Hmmmmmmmm... it was actually a custom build of LEDE based on 17.01.2,
but I only added shell scripts and other stuff, no patches to
executables, extra drivers, or anything like that. I bricked several of
them trying to flash OpenWRT CC onto them, and I'm waiting for some new
ones, as I am out again.
I tested the units we flashed myself, and they seemed to be working fine.
-Bill
I dont think you hard bricked them.
You should be able to TFTP recover to AirOS
Well, it's effectively a hard brick, because the only version of AirOS available is 6.0.6, and that enacts the firmware lock.
So, yes, you can still tftp AirOS 6, but then there is absolutely nothing else you can do with it.
Well,according to XW 6.0.6 release notes: Signed firmware support (Users are not able to downgrade below v6.0.6 unless using TFTP)
So TFTP downgrade to older version should work.
Also downgrading to 6.0.6 beta using Web UI and then to other versions should also work
Hi guys,
finally I recovered the unit via TFTP with AirOS 5.6.15 XW (earlier versions don't work), then I uploaded Lede 17.01.2 via WebUI .
It works 
It seems that you don't need to downgrade to AirOS 5.5.10 anymore, at least with the latest version of Lede.