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

Tue Nov 15 02:51:54 PST 2016

Hey Petr,

On Tuesday, November 15, 2016 11:29:40 AM CET Petr Štetiar wrote:
> 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.
> 

Oh, mhm, that's unfortunate. :(

We don't have any influence on the production decisions, though.

But as Sven said, please contact customer support. I'm sure they will find a 
solution for you.

> > 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..."

Well, we are. We can't change the fact that the devices need to be locked to 
be sold in the US. But if you google a little, you will find a lot of patches 
for various Open Source projects signed by @open-mesh.com mail addresses 
(LEDE, Linux, hostapd, etc) ... Feel free to compare that with other WiFi 
vendors. I don't think we are doing that bad. :)

> 
> > 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/pat
>  > ches/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:

It seems there was a misunderstanding somewhere and not all patches were 
provided. In that case, I would suggest to insist until you get everything.

> 
>  /srv/autobuild/firmware-ng-ng5xx/openwrt-build/build_dir/target-mips_r2_uCl
> ibc-0.9.33.2/linux-ar71xx_generic/compat-wireless-2014-11-04/drivers/net/wir
> eless/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.

FYI, the decryption stuff has been released now. It was considered too dirty 
for upstream for a long time, but it was decided to at least provide the patch 
in public now for others to clean it up:

https://patchwork.kernel.org/patch/9381651/

The other strings shouldn't be anything Open-Mesh specific, but maybe from a 
different version (or patchset), as far as I can tell.

Cheers,
     Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20161115/a1c72664/attachment-0001.sig>