Re: [LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]
On Wed, 16 Nov 2016, Simon Wunderlich wrote: Hi David, On Tuesday, November 15, 2016 4:49:40 PM CET David Lang wrote: 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. :) except that they don't need to be locked down to be sold in the US. The FCC posted a proposed rule that would require such a lockdown, but then have repeatedly made public statements that they do not intend to prevent different firmware from being loaded on the devices and the proposed rule that would have required lockdowns have basically been stopped. However, multiple vendors are imposing restriction and claiming that the FCC is requiring them, even after the FCC says that it's not. You are right, the FCC doesn't explicitly requires to prevent third-party firmware loading anymore. However, they still require to explain how a vendor makes sure that US RF limits are not violated [1]. Since a third-party firmware can be anything including a firmware with a patched ath9k where DFS is disabled etc, we (as Open-Mesh) can't really prevent that those RF limits are violated. Thus we can not give a convincing explanation there, and the situation stays the same. If you have any constructive idea, I would love to propose it internally. I'll point out that TP-Link got a slap on the risk for their actions in blocking all firmware updates. http://arstechnica.com/information-technology/2016/08/fcc-forces-tp-link-to-support-open-source-firmware-on-routers/ In that document, and in the post made at the same time ( https://www.fcc.gov/news-events/blog/2015/11/12/clearing-air-wi-fi-software-updates ) the FCC is explicitly saying that they don't want the vendors blocking DD-WRT and similar. I'll also point out that the FCC documents are not RFCs, the wording is not as precisely defined. When they ask what measures are being taken to block the devices working out of frequency, they are not asking you to make the devices impossible to operate improperly, no matter what (something that is impossible) I went through a similar set of issues back in the '90s with two-way radios. The FCC was requiring that the manufacturers block using the radios on inappropriate frequencies, and manufacturers were doing things to lock down the programming software that was used to reprogram the radios to other frequencies. But what has happened is that the manufacturers now have lock codes and/or jumpers (including 0-ohm resisters) that allow people to unlock the radios and program them (and the programming has largely been cloned with open-source software like chirp) The FCC, in practice, recognizes that people going to extrordinary lengths can bypass reasonable restrictions and don't hold the manufacturers liable for them doing so. The fact that OpenWRT, LEDE, DD-WRT, etc now all default to the least common denominator when a country code is not provided means that all the alturnative firmware is sane by default, you have to go to extrordinary lengths to be illegal. And someone going to such lengths could just buy the non-locked down version of the equipment on e-bay (or other websites) and have it shipped to them anywhere in the world. David Lang Thanks, Simon [1] From https://apps.fcc.gov/kdb/GetAttachment.html?id=zXtrctoj6zH7oNEOO6De6g %3D%3D&desc=594280%20D02%20U-NII%20Device%20Security %20v01r03&tracking_number=39498 "Describe, if the device permits third-party software or firmware installation, what mechanisms are provided by the manufacturer to permit integration of such functions while ensuring that the RF parameters of the device cannot be operated outside its authorization for operation in the U.S . In the description include what controls and/or agreements are in place with providers of third-party functionality to ensure the devices’ underlying RF parameters are unchanged and how the manufacturer verifies the functionality. "___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]
The linked document below is the same document we attacked, I thought successfully, last year, http://www.computerworld.com/article/2993112/security/vint-cerf-and-260-experts-give-fcc-a-plan-to-secure-wi-fi-routers.html with the ultimate response from the fcc being https://www.fcc.gov/news-events/blog/2015/11/12/clearing-air-wi-fi-software-updates Merely being asked to describe how the regdb works is all I see as the current FCC requirement. More than one manufacturer has got through this process since. Also, the context of that whole original debate was a dispute with tp-link, which only came out after the legal dust had settled. http://arstechnica.com/information-technology/2016/08/fcc-forces-tp-link-to-support-open-source-firmware-on-routers/ On Wed, Nov 16, 2016 at 2:15 PM, Simon Wunderlich wrote: > Hi David, > > On Tuesday, November 15, 2016 4:49:40 PM CET David Lang wrote: >> > 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. :) >> >> except that they don't need to be locked down to be sold in the US. >> >> The FCC posted a proposed rule that would require such a lockdown, but then >> have repeatedly made public statements that they do not intend to prevent >> different firmware from being loaded on the devices and the proposed rule >> that would have required lockdowns have basically been stopped. >> >> However, multiple vendors are imposing restriction and claiming that the FCC >> is requiring them, even after the FCC says that it's not. > > You are right, the FCC doesn't explicitly requires to prevent third-party > firmware loading anymore. However, they still require to explain how a vendor > makes sure that US RF limits are not violated [1]. Since a third-party > firmware > can be anything including a firmware with a patched ath9k where DFS is > disabled > etc, we (as Open-Mesh) can't really prevent that those RF limits are violated. > Thus we can not give a convincing explanation there, and the situation stays > the same. > > If you have any constructive idea, I would love to propose it internally. > > Thanks, > Simon > > [1] From https://apps.fcc.gov/kdb/GetAttachment.html?id=zXtrctoj6zH7oNEOO6De6g > %3D%3D&desc=594280%20D02%20U-NII%20Device%20Security > %20v01r03&tracking_number=39498 > > "Describe, if the device permits third-party software or firmware > installation, > what mechanisms are provided by the manufacturer to permit integration of > such functions while ensuring that the RF parameters of the device cannot be > operated outside its authorization for operation in the U.S . In the > description include what controls and/or agreements are in place with > providers of third-party functionality to ensure the devices’ underlying RF > parameters are unchanged and how the manufacturer verifies the functionality. > " > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev > -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]
Hi David, On Tuesday, November 15, 2016 4:49:40 PM CET David Lang wrote: > > 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. :) > > except that they don't need to be locked down to be sold in the US. > > The FCC posted a proposed rule that would require such a lockdown, but then > have repeatedly made public statements that they do not intend to prevent > different firmware from being loaded on the devices and the proposed rule > that would have required lockdowns have basically been stopped. > > However, multiple vendors are imposing restriction and claiming that the FCC > is requiring them, even after the FCC says that it's not. You are right, the FCC doesn't explicitly requires to prevent third-party firmware loading anymore. However, they still require to explain how a vendor makes sure that US RF limits are not violated [1]. Since a third-party firmware can be anything including a firmware with a patched ath9k where DFS is disabled etc, we (as Open-Mesh) can't really prevent that those RF limits are violated. Thus we can not give a convincing explanation there, and the situation stays the same. If you have any constructive idea, I would love to propose it internally. Thanks, Simon [1] From https://apps.fcc.gov/kdb/GetAttachment.html?id=zXtrctoj6zH7oNEOO6De6g %3D%3D&desc=594280%20D02%20U-NII%20Device%20Security %20v01r03&tracking_number=39498 "Describe, if the device permits third-party software or firmware installation, what mechanisms are provided by the manufacturer to permit integration of such functions while ensuring that the RF parameters of the device cannot be operated outside its authorization for operation in the U.S . In the description include what controls and/or agreements are in place with providers of third-party functionality to ensure the devices’ underlying RF parameters are unchanged and how the manufacturer verifies the functionality. " signature.asc Description: This is a digitally signed message part. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]
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. :) except that they don't need to be locked down to be sold in the US. The FCC posted a proposed rule that would require such a lockdown, but then have repeatedly made public statements that they do not intend to prevent different firmware from being loaded on the devices and the proposed rule that would have required lockdowns have basically been stopped. However, multiple vendors are imposing restriction and claiming that the FCC is requiring them, even after the FCC says that it's not. David Lang ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]
Simon Wunderlich [2016-11-15 11:51:54]: > Hey Petr, Hi! > We don't have any influence on the production decisions, though. sure, I'm not blaming any of you, I understand this, it's very hard :-) > But as Sven said, please contact customer support. I'm sure they will find a > solution for you. I'm not selfish, I've started wasting my time on this, so we've solution which works for everybody. But I'll try to ask customer support and share the outcome. > Well, we are. We can't change the fact that the devices need to be locked to > be sold in the US. You see, this is getting really crazy all this quick FCC workarounds... Imagine following situation. OpenMesh support will give me for example unlocked U-Boot bootloader for OM5P-AC or I'll pay someone to dissasemble it and patch it so U-Boot doesn't need any signed images at all, or we keep this security by obscurity in place and use it with just custom keys. Then anybody in the world, including US citizens can download it and unlock their devices. IANAL, it's still GPL licensed software, even in binary form, so I'm probably not going to break any law doing this. But law can be interpreted in many ways so just to be safe, I'm actually considering some help, probably via FSF. > 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) Sure, I know! Exactly opposite, you're doing great work, I recognize the work of you, Sven, Antonio and Marek for example even without your @openmesh.com addresses. So I know, that developers like you are strong opensource minded people. We probably just need to change thinking of management people, the almost impossible task. I'm not interested in sources of OpenMesh's proprietary Cloudtrax stuff, I don't care about it. I just want to have an option to be able to rebuild the opensource parts so I can find & fix any potential problems very quickly. Few years ago it was possible to rebuild the firmware minus the proprietary stuff from dev.cloudtrax.com sources. It's not possible for a long time anymore. > 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/ Great, thanks a lot everybody involved! > The other strings shouldn't be anything Open-Mesh specific, but maybe from a > different version (or patchset), as far as I can tell. Ok, so what's the problem with OpenMesh management people? :-) Why not just put all the sources online again? So I'm able to build firmware minus Cloudtrax proprietary bits without much hassle. Christmas is comming! :-) -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]
Hey Petr, On Tuesday, November 15, 2016 11:29:40 AM CET Petr Štetiar wrote: > Sven Eckelmann [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 signature.asc Description: This is a digitally signed message part. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]
Sven Eckelmann [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 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]
[this is a rather odd change of topic] On Montag, 14. November 2016 14:24:48 CET Petr Štetiar wrote: [...] > But on the other hand I'm wondering how should I upload my custom LEDE image > to my recently purchased OM5P-AC device as the U-Boot there is locked down and > accepts only signed OS images. I understand, that this is due to the recent > wonderful FCC project called "killing inovations in the wireless space". 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)". But I am not an OpenMesh employee and don't have access to all details of their current shipping policy. 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). > Puting aside the GPL license violation of U-boot and kernel code which > OpenMesh ships in the devices, we don't have much options left. 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. > The only sane > way of fixing this is to dump the private keys out of the U-Boot and patch the > ap51-flash so the LEDE users are able to sign their own LEDE or any other > custom OS images and use the HW as they wish. No private keys are shipped with the product or the firmware flash tools. The image itself only has signatures (cryptographically signed hashes). But this is what you most likely already knew when you saw "fwupgrade.cfg.sig" during the flash process. Kind regards, Sven signature.asc Description: This is a digitally signed message part. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]
Judging by how easy it was in the beggining to fool Android bootloaders into doing stupid stuff, I wouldn't be too worried - granted that we get the right people interested. This however is a substandard solution unfortunately.. > On 14 Nov 2016, at 16:59, Petr Štetiar wrote: > > Petr Štetiar [2016-11-14 14:24:48]: > >> The only sane way of fixing this is to dump the private keys out of the >> U-Boot and patch the ap51-flash so the LEDE users are able to sign their own >> LEDE or any other custom OS images and use the HW as they wish. > > I was corrected by someone who would like to remain anonymous off-list, that > I'm probably not going to find private keys in the U-boot at all, which is > probably correct, I don't know what I was thinking about while writting that > email :-) > > This is bummer, as this finding probably means, that some soldering would > always be needed to get unlocked device as I wasn't able to read out the > EEPROM content while using the Pomona SOIC clip when the IC was still soldered > on the board. But maybe I've done something wrong. > > So it's going to be a challenge to come up with some user friendly solution. > > -- ynezz > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]
Petr Štetiar [2016-11-14 14:24:48]: > The only sane way of fixing this is to dump the private keys out of the > U-Boot and patch the ap51-flash so the LEDE users are able to sign their own > LEDE or any other custom OS images and use the HW as they wish. I was corrected by someone who would like to remain anonymous off-list, that I'm probably not going to find private keys in the U-boot at all, which is probably correct, I don't know what I was thinking about while writting that email :-) This is bummer, as this finding probably means, that some soldering would always be needed to get unlocked device as I wasn't able to read out the EEPROM content while using the Pomona SOIC clip when the IC was still soldered on the board. But maybe I've done something wrong. So it's going to be a challenge to come up with some user friendly solution. -- ynezz ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] FCC killing open platforms and inovations [Was: Re: [PATCH] ar71xx: Add usable, inactive LEDs on OpenMesh devices]
Hi Sven, first of all I would like to thank you and your colleagues for your great work and upstreaming of the support for all OpenMesh devices, opensourcing the ap51-flash utils etc. But on the other hand I'm wondering how should I upload my custom LEDE image to my recently purchased OM5P-AC device as the U-Boot there is locked down and accepts only signed OS images. I understand, that this is due to the recent wonderful FCC project called "killing inovations in the wireless space". Puting aside the GPL license violation of U-boot and kernel code which OpenMesh ships in the devices, we don't have much options left. The only sane way of fixing this is to dump the private keys out of the U-Boot and patch the ap51-flash so the LEDE users are able to sign their own LEDE or any other custom OS images and use the HW as they wish. Then to please FCC again, you'll probably introduce new HW revision, where you'll use some kind of crypto IC as key storage and we're at the same position as now. Waiting for someone to find a way around it. Instead of improving stuff around us, we'll concetrate on this mouse&cat games. OpenMesh makes great hardware, you guys make it work very well for us small tinkerers which are not able to produce and sell like 10k units/year, so we can't afford our own more open hardware. We even don't mind to pay little bit higher price as the HW is rock solid and looks good on the desk. Just my Monday rant. I understand, that you can't do much about it. It's not personal, just wanted to start some conversation about this topic :-) Thanks anyway for any response, even off-list. -- ynezz Sven Eckelmann [2016-11-11 16:12:36]: > From: Jaylin Yu > > OpenMesh devices have often LEDs which are not yet used by OpenWrt. These > should still be available as disabled LEDs in the system configuration for > easier modification. > > Signed-off-by: Jaylin Yu > [sven.eckelm...@open-mesh.com: Remove LEDs already specified via diag.sh, > add wifi/status LEDs] > Signed-off-by: Sven Eckelmann ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
