[LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]

[Petr Štetiar]

Sven Eckelmann <sven.eckelmann at open-mesh.com> [2016-11-15 09:32:18]:

Hi,

> I was told that OpenMesh is also shipping an already unlocked version of it in
> regions which don't requires closed down versions. They called it
> "(International Version)".

quoting from Cloudtrax help portal[1]:

"For international customers, please order part MR1750-INTL. Once current stock
is depleted, the FCC version will be available globally."

FYI, there is no -INTL version for OM5P-AC. FCC version means no unsigned
images over ap51-flash.

> But you can also try to get in contact with the customer support to get this
> resolved. They should be able to find a solution for your problem when you
> are in a region which doesn't require the FCC lockdown (but you still got
> devices which were locked down).

It's quite interesting article[1], reading it again now, quoting:

  "1. Custom firmware versions can no longer be loaded onto the device."

and few lines down:

  "We're strong believers in open source software..."

> If you found a GPL violation then please get in contact with OpenMesh support
> to get it resolved. They were quite willingly in the past to provide the source
> code of the GPL portions of the firmware . Maybe your are just talking
> about some formal problem - at least I cannot know about them because I never
> received a retail/boxed version of their products.

Ok, thanks for the hint. I'll try to ask for U-Boot and Linux kernel sources
again. I hope, that this time they're not only "strong believers in open
source", but that they actually know what that does it mean :-)

For example here is my year old experience with with OpenMesh and GPL
compliance. One of my clients had some issues with their mesh network and
wanted me to fix it.

I've looked at it and found some errors like this in the logs:

  ath: 21 decryption error for ac:86:74:xx:xx:xx - refreshing cache

I wanted to know the cause of the error, so I've tried to find this error in
the ath9k driver sources. I couldn't find it, so I've asked OpenMesh for
sources of ath9k driver in firmware r585 and I got following reply:

 > This is the driver we're using:
 > https://dev.openwrt.org/changeset/43239/trunk/package/kernel/mac80211/patches/410-ath9k_allow_adhoc_and_ap.patch

Which was nonsense, because just with simple strings method you can find
following strings not available in the linked source code of the ath9k driver:

 /srv/autobuild/firmware-ng-ng5xx/openwrt-build/build_dir/target-mips_r2_uClibc-0.9.33.2/linux-ar71xx_generic/compat-wireless-2014-11-04/drivers/net/wireless/ath/ath9k/recv.c

 unsupported hw bitrate detected 0x%02x using 1 Mbit
 ath: %d decryption error for %pM - refreshing cache
 Reconfigure beacon timers based on synchronized timestamp
 Received DTIM beacon indicating buffered broadcast/multicast frame(s)
 PS wait for CAB frames timed out
 All PS CAB frames received, back to sleep
 Going back to sleep after having received PS-Poll data (0x%lx)

As you can see, there's 'ath: %d decryption error for %pM - refreshing cache'
error message which is not available in OpenWRT source code or anywhere else.


1. https://help.cloudtrax.com/hc/en-us/articles/210206213-Dual-band-changes-due-to-FCC-requirements


Anyway, thanks a lot for your input and amazing work!

-- ynezz