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:
- Noises and interference reduction ie wave accuracy
- Software based frequency and amplification control(converting a 1000 mW 
device into a 5000 mW** by just adding the proper cooling or 5.xGhz to 20Ghz++ )

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

* Again I just wanted to clear things which are known but sometimes are 
forgotten.

----
http://ngtech.co.il/lmgtfy/
Linux System Administrator
Mobile: +972-5-28704261
Email: [email protected]


From: openwrt-devel [mailto:[email protected]] On Behalf 
Of Bill Moffitt
Sent: Friday, August 25, 2017 07:56
To: LEDE Project Forum 
<[email protected]>; 
[email protected]
Subject: Re: [OpenWrt-Devel] [LEDE Project Forum] [Installing and Using LEDE] 
New Ubiquiti LOCO M2 XW

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: 
https://assets.documentcloud.org/documents/2339685/fcc-software-security-requirements.pdf
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


On 08/14/2017 10:46 AM, Adrian Draus wrote:

http://forum.lede-project.org/users/r43k3n 
http://forum.lede-project.org/users/r43k3n 
August 14 

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.
________________________________________
http://forum.lede-project.org/t/new-ubiquiti-loco-m2-xw/5760/5 or reply to this 
email to respond.
________________________________________
In Reply To

http://forum.lede-project.org/users/bmoffitt 
http://forum.lede-project.org/users/bmoffitt 
August 14 

Yes, they are not being very friendly towards us...
________________________________________
http://forum.lede-project.org/t/new-ubiquiti-loco-m2-xw/5760/5 or reply to this 
email to respond.
To unsubscribe from these emails, 
http://forum.lede-project.org/email/unsubscribe/d77905e615393f4ac90fda533896470e252bc1a7f50554875dac5763ab8e4293.
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Reply via email to