Re: [LEDE-DEV] [OpenWrt-Devel] Remerge logo ideas
Jamie- As, perhaps, the only (or at least one of the few) "marketing guys" on this list, I want to agree with Adrian - this is great. I think it conveys a very good, clean image. There was a suggestion of building a "standard, corporate" color scheme to go with it and make sure we have that available - it's a huge timesaver for a corporation trying to tie in with OpenWrt (which I think we would like to see happen - like Buffalo, but even more) and encourages a uniform "brand experience." It would be good to put all this (including "source," preferably as SVG) on the website in a "brand" section under an "About OpenWrt" section. Today on OpenWrt.org, there's a "Trademark policy" section, which is useful, but incomplete without an artistic usage guide and links to downloads. My 2 cents worth, Bill On 5/30/2017 6:08 AM, Adrian Panella wrote: Keeping the name after remerge but with a new logo, helps convey the notion that there has been a change. An modernizing the look is great +1 El 29/05/2017, a las 12:32, Jamie Stuart escribió: Tried that Moritz - it just wouldn’t work unfortunately. Neither does adding the antenna afterwards All - see another set of designs. I’ve opted for Roboto Condensed as the logo typeface. Personal favorite is the green as OpenWrt is targeted towards low-power devices. http://imgur.com/a/TfWxr What’s the next step here? John - could this be added to the remerge proposal v3? On 29 May 2017, at 19:12, Moritz Warning wrote: Looks nice. random idea, merge antenna with O of OpenWrt? On 05/29/2017 01:10 PM, Jamie Stuart wrote: See another iteration, with: - correct capitalisation - antenna to the side (will not work with lowercase ’n’) - open sans typeface (open source) - mockups of website header - accent colours http://i.imgur.com/ZKtcFXo.png On 29 May 2017, at 13:52, John Crispin wrote: On 29/05/17 12:11, Jamie Stuart wrote: Hi, First of all, I’m glad to hear the process of remerging LEDE with OpenWrt is moving forward. For what it’s worth, if prefer the LEDE name (it’s friendlier - ‘leddy’ - and not tied to the name of an old router!) However, it seems the consensus is that the OpenWrt name should remain. I thought that maybe we should take this opportunity to at least give the project an updated look? Maybe a new logo? I’m personally not one for mascots, so I had a quick go at a few simple text-based designs: http://i.imgur.com/9zyXSYR.png What are you thoughts? Jamie, onebillion Hi, the correct spelling is OpenWrt with a capital O and W. could you add that to the proposal aswell please ? ideally with and without the antenna feature John ___ 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 ___ 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 ___ 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] [OpenWrt-Devel] Remerge logo ideas
On 5/30/2017 12:15 PM, Mirko Vogt wrote: Huhu, looks great to me and it's definitely the right timing for a logo change :) Me who came to OpenWrt for porting it to a mobile phone and continued with pictures frames, mini-notebooks and landline phones, I never considered OpenWrt as a plain wifi router distribution/toolchain but one for every kind of embedded devices. Although I know it's coming from there and the name still reflects it, I'd appreciate more "embedded" than "wifi/antenna" in a logo, though having no idea how to do that :) Please don't consider that as complaint or even objection towards your drafts. It's just some input which might or might not be taken into account in the end. Thanks for your work! mirko Mirko- I just wanted to say that I had the same reaction (because I think LEDE is a good idea), and then I thought about it a while. The truth is that just about all the embedded devices coming up are going to have some sort of a wireless component, and in many cases the "wirelessness" of the device or application is just as important as the "embeddedness." The current popularity of the ESP8266 is proof of this (although it doesn't currently run OpenWRT) - there are lots of educational devices out there to connect sensors and measure things, but, when they have a wireless connection on them, suddenly they are a LOT more interesting for practical applications. I decided that I actually liked having the symbolic reference to radio/wireless/etc/ in the logo. I choose to view it not as a WiFi router, but just something that's wireless. Just my own 2 cents worth, Bill On 05/29/2017 12:11 PM, Jamie Stuart wrote: Hi, First of all, I’m glad to hear the process of remerging LEDE with OpenWrt is moving forward. For what it’s worth, if prefer the LEDE name (it’s friendlier - ‘leddy’ - and not tied to the name of an old router!) However, it seems the consensus is that the OpenWrt name should remain. I thought that maybe we should take this opportunity to at least give the project an updated look? Maybe a new logo? I’m personally not one for mascots, so I had a quick go at a few simple text-based designs: http://i.imgur.com/9zyXSYR.png What are you thoughts? Jamie, onebillion ___ 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 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Remerge logo ideas
Carlos- I don't think it matters what it's called to the OpenWrt/LEDE community - we have exhibited, shall we say, remarkable flexibility in the last few years, I think... ;-) And, in fairness, I don't disagree with you - I think OpenWrt is a terrible name, one we would never choose if we were starting from scratch. Just to ensure that I annoy EVERYONE equally, I dislike LEDE as a name just as much. That is not to suggest I have something better in mind... I'm just chipping in from the cheap seats. HOWEVER, OpenWRT is a name that has a fair bit of "equity" - it is known and recognized far beyond the OpenWrt community. I am confident that, if we did a name-recognition study among random geeky folks, a good percentage of them would recognize OpenWRT. Even though it harkens back to a long-since defunct Linksys router, and it does, therefore, carry that inaccurate "routers-only" baggage, that equity has some significant value in the "marketplace of ideas" and in the commercial market. Having a known brand helps us in many ways, from getting resources to attracting people to the community. It takes a long time and a lot of energy to build a recognized brand - it is expensive - so it is foolish to discard it without careful thought. It comes down to a simple calculation - the value of the brand as it exists, minus some amount for the fact that it is now somewhat inaccurate. My own analysis is that the net is still VERY positive, so renaming/rebranding is a bad idea. And a new logo will reinforce that value. So it's a bit like Churchill's famous quotation about democracy - I think OpenWrt is the worst possible name, except for any of the others. Hence, OpenWrt is the right name. -Bill On 6/2/2017 3:35 AM, Carlos Ferreira wrote: @Mirko and @Bill I had the same thoughts in the past. OpenWRt has evolved into a much more diverse and generic embedded development environment. It no longer serves only the Wireless community interests or used just in Wireless Routers. It goes much beyond that. Also, in my opinion, LEDE would be better and honestly, those who use OpenWRT already know what LEDE is. There's no branding issue here and LEDE, for me, is a much proper project name, which refers the current real use of OpenWRT. Also, I always believed it should be OpenWRt with capital WR. Why? Isn't suposed to be Open Wireless Router? :) Carlos. On 30 May 2017 at 20:34, Bill Moffitt wrote: On 5/30/2017 12:15 PM, Mirko Vogt wrote: Huhu, looks great to me and it's definitely the right timing for a logo change :) Me who came to OpenWrt for porting it to a mobile phone and continued with pictures frames, mini-notebooks and landline phones, I never considered OpenWrt as a plain wifi router distribution/toolchain but one for every kind of embedded devices. Although I know it's coming from there and the name still reflects it, I'd appreciate more "embedded" than "wifi/antenna" in a logo, though having no idea how to do that :) Please don't consider that as complaint or even objection towards your drafts. It's just some input which might or might not be taken into account in the end. Thanks for your work! mirko Mirko- I just wanted to say that I had the same reaction (because I think LEDE is a good idea), and then I thought about it a while. The truth is that just about all the embedded devices coming up are going to have some sort of a wireless component, and in many cases the "wirelessness" of the device or application is just as important as the "embeddedness." The current popularity of the ESP8266 is proof of this (although it doesn't currently run OpenWRT) - there are lots of educational devices out there to connect sensors and measure things, but, when they have a wireless connection on them, suddenly they are a LOT more interesting for practical applications. I decided that I actually liked having the symbolic reference to radio/wireless/etc/ in the logo. I choose to view it not as a WiFi router, but just something that's wireless. Just my own 2 cents worth, Bill On 05/29/2017 12:11 PM, Jamie Stuart wrote: Hi, First of all, I’m glad to hear the process of remerging LEDE with OpenWrt is moving forward. For what it’s worth, if prefer the LEDE name (it’s friendlier - ‘leddy’ - and not tied to the name of an old router!) However, it seems the consensus is that the OpenWrt name should remain. I thought that maybe we should take this opportunity to at least give the project an updated look? Maybe a new logo? I’m personally not one for mascots, so I had a quick go at a few simple text-based designs: http://i.imgur.com/9zyXSYR.png What are you thoughts? Jamie, onebillion ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev __
[LEDE-DEV] New UBNT Loco M2 XW units FYI
Folks- I just got a new batch of Loco M2 units, and they have changed to the XW architecture. I typically downgrade these to AirOS 5.5 (I also work with the Loco M5, which has been XW for a while, so I have the 5.5 XW firmware close at hand), but these units would not downgrade. I tried doing a tftp downgrade and I appear to have bricked the unit. (no matter what I flash onto it, the Ethernet port won't work except in "rescue" mode). The units I received are running AirOS 5.6.12, and I found I could use the WebUI to "upgrade" to LEDE. That was surprising... especially since using the tftp/"rescue mode" method did NOT work. I have not verified that LEDE is working properly, but I could log into the unit. I have bricked one so far and updated two to AirOS 6.0.6 (the only version available on the UBNT download site for the Loco M2). Updating to AirOS 6.0.6 initiates the "signed firmware only" capability in uboot, so nothing else can be loaded onto them. So I have, essentially, 3 of 4 units dead on my workbench (I checked the unit that was running LEDE to make see if it would still accept firmware via tftp; it only accepts the 6.0.6 firmware). I am certainly open to any ideas anyone has... I'll update this as I know more. -Bill Moffitt ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Problem trying to add support for Comfast E312A
I have been trying to put together a patch to support this device (5
GHz. directional - like UBNT NanoStation M5), but I have run into a bug
I can't seem to figure out.
Using the changes below, I have been able to get the system up and
running, the radio appears to be working properly and all but *one* of
the LEDs appear to be working. Note: I have not checked the reset button
and the power switch.
With this patch applied, the third signal strength light (GPIO 16) acts
strangely. It is on when it boots, and it stays on - forever. It cannot
be turned off. It appears to be controlled by something else - whatever
I send to /sys/class/cf-e312a:white:signal3/brightness the light never
changes:
[signal 3 light is on]
root@LEDE:/sys/class/leds# cat cf-e312a:white:signal3/brightness
0
[signal 3 light is on]
root@LEDE:/sys/class/leds# echo 1 >cf-e312a:white:signal3/brightness
[signal 3 light is on]
root@LEDE:/sys/class/leds# cat cf-e312a:white:signal3/brightness
1
root@LEDE:/sys/class/leds# echo 0 >cf-e312a:white:signal3/brightness
[signal 3 light is on]
root@LEDE:/sys/class/leds# cat cf-e312a:white:signal3/brightness
0
The other odd thing is that, despite the fact I am initializing all the
LEDs as " .active_low = 1," the other LEDs appear to be initializing
"hi" with only GPIO 16 initializing as "lo" -
root@LEDE:/sys/kernel/debug# cat gpio
gpiochip0: GPIOs 0-31, parent: platform/ath79-gpio, ath79-gpio:
gpio-0 ( |cf-e312a:white:wlan ) out hi
gpio-1 ( |cf-e312a:sda ) out lo
gpio-2 ( |cf-e312a:white:lan ) out hi
gpio-3 ( |cf-e312a:white:wan ) out lo
gpio-11 ( |suite button ) in hi
gpio-12 ( |cf-e312a:scl ) out lo
gpio-14 ( |cf-e312a:white:signa) out hi
gpio-15 ( |cf-e312a:white:signa) out hi
gpio-16 ( |cf-e312a:white:signa) out lo
gpio-17 ( |cf-e312a:white:signa) out hi
gpio-19 ( |PT7A7514 watchdog ) out hi
gpio-22 ( |reset ) in hi
gpiochip1: GPIOs 489-511, parent: platform/ar934x_wmac, ath9k-phy0:
gpio-490 ( |ath9k-phy0 ) in hi
I asked the folks at Comfast, and they assured me this is the right gpio
for that light. I also tried all the other GPIOs using the "blink"
script at https://wiki.openwrt.org/doc/hardware/port.gpio and verified
none of them caused the state of that LED to change.
It is ENTIRELY POSSIBLE I screwed something up... I just cannot find it.
Any assistance will be greatly appreciated.
Here's the patch as it exists now:
diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index e101d55..1c506d0 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -182,6 +182,11 @@ carambola2)
ucidef_set_led_netdev "wan" "WAN" "$board:orange:eth1" "eth1"
ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
;;
+cf-e312a)
+ ucidef_set_led_netdev "lan" "LAN" "$board:white:lan" "eth0"
+ ucidef_set_led_netdev "wan" "WAN" "$board:white:wan" "eth1"
+ ucidef_set_led_wlan "wlan" "WLAN" "$board:white:wlan" "phy0tpt"
+ ;;
cf-e316n-v2)
ucidef_set_led_netdev "lan" "LAN" "$board:blue:lan" "eth0"
ucidef_set_led_netdev "wan" "WAN" "$board:blue:wan" "eth1"
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 5ef620b..6274841 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -118,6 +118,7 @@ get_status_led() {
cap4200ag)
status_led="senao:green:pwr"
;;
+ cf-e312a|\
cf-e316n-v2|\
cf-e520n|\
cf-e530n)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 9903563..98ed277 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -504,6 +504,9 @@ ar71xx_board_detect() {
*"Carambola2"*)
name="carambola2"
;;
+ *"CF-E312A")
+ name="cf-e312a"
+ ;;
*"CF-E316N v2")
name="cf-e316n-v2"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 18e5e41..1b13230 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -215,6 +215,7 @@ platform_check_image() {
bullet-m|\
c-55|\
carambola2|\
+ cf-e312a|\
cf-e316n-v2|\
cf-e320n-v2|\
cf-e355ac|\
diff --git a/target/linux/ar71xx
[LEDE-DEV] Has anyone tried LEDE on the Mikrotik Groove 52HPn?
I have been trying to put LEDE 17.01.4 on this little outdoor radio with no success. I cannot get any initramfs image to boot. I have a LEDE router set up as my boot server, and I have tried all the initramfs images on it. In each case the router reports that it has sent the file to the Mikrotik, and the Mikrotik's ethernet light flashes showing the file is being received. The Mikrotik beeps, sits there for a while, and then beeps twice more, flashes its signal lights twice, and then reboots (to RouterOS). I don't know if this unit just won't boot LEDE or if I'm screwing it up somehow. Has anyone else tried this little unit? -Bill ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] add support for Comfast E314N
Comfast E314N is a 2.4 GHz. outdoor directional wireless radio with two
Ethernet ports and PoE pass-through (controlled by a slide switch).
diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index e5baa90..f1e29c7 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -182,6 +182,11 @@ carambola2)
ucidef_set_led_netdev "wan" "WAN" "$board:orange:eth1" "eth1"
ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
;;
+cf-e314n)
+ ucidef_set_led_netdev "lan" "LAN" "$board:white:lan" "eth0"
+ ucidef_set_led_netdev "wan" "WAN" "$board:white:wan" "eth1"
+ ucidef_set_led_wlan "wlan" "WLAN" "$board:white:wlan" "phy0tpt"
+ ;;
cf-e316n-v2)
ucidef_set_led_netdev "lan" "LAN" "$board:blue:lan" "eth0"
ucidef_set_led_netdev "wan" "WAN" "$board:blue:wan" "eth1"
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 6cbb357..93b9e76 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -119,6 +119,7 @@ get_status_led() {
cap4200ag)
status_led="senao:green:pwr"
;;
+ cf-e314n|\
cf-e316n-v2|\
cf-e520n|\
cf-e530n)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 285fa68..ee7b93a 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -504,6 +504,9 @@ ar71xx_board_detect() {
*"Carambola2"*)
name="carambola2"
;;
+ *"CF-E314N")
+ name="cf-e314n"
+ ;;
*"CF-E316N v2")
name="cf-e316n-v2"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 172a58b..159bd49 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -215,6 +215,7 @@ platform_check_image() {
bullet-m|\
c-55|\
carambola2|\
+ cf-e314n|\
cf-e316n-v2|\
cf-e320n-v2|\
cf-e355ac|\
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index 3ba3853..134352b 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -67,6 +67,7 @@ CONFIG_ATH79_MACH_C55=y
CONFIG_ATH79_MACH_CAP324=y
CONFIG_ATH79_MACH_CAP4200AG=y
CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E314N=y
CONFIG_ATH79_MACH_CF_E316N_V2=y
CONFIG_ATH79_MACH_CF_E320N_V2=y
CONFIG_ATH79_MACH_CF_E355AC=y
diff --git a/target/linux/ar71xx/config-4.9 b/target/linux/ar71xx/config-4.9
index 1d47246..7047aa4 100644
--- a/target/linux/ar71xx/config-4.9
+++ b/target/linux/ar71xx/config-4.9
@@ -65,6 +65,7 @@ CONFIG_ATH79_MACH_C55=y
CONFIG_ATH79_MACH_CAP324=y
CONFIG_ATH79_MACH_CAP4200AG=y
CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E314N=y
CONFIG_ATH79_MACH_CF_E316N_V2=y
CONFIG_ATH79_MACH_CF_E320N_V2=y
CONFIG_ATH79_MACH_CF_E355AC=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
index 1198fcb..bd21f40 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
@@ -2051,6 +2051,16 @@ config ATH79_MACH_RAMBUTAN
select ATH79_DEV_USB
select ATH79_DEV_WMAC
+config ATH79_MACH_CF_E314N
+ bool "COMFAST CF-E314N support"
+ select SOC_QCA953X
+ select ATH79_DEV_ETH
+ select ATH79_DEV_GPIO_BUTTONS
+ select ATH79_DEV_LEDS_GPIO
+ select ATH79_DEV_M25P80
+ select ATH79_DEV_USB
+ select ATH79_DEV_WMAC
+
config ATH79_MACH_CF_E316N_V2
bool "COMFAST CF-E316N v2 support"
select SOC_AR934X
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Makefile
b/target/linux/ar71xx/files/arch/mips/ath79/Makefile
index 455af76..148c3a3 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Makefile
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_ATH79_MACH_C60) += mach-c60.o
obj-$(CONFIG_ATH79_MACH_CAP324) += mach-cap324.o
obj-$(CONFIG_ATH79_MACH_CAP4200AG) += mach-cap4200ag.o
obj-$(CONFIG_ATH79_MACH_CARAMBOLA2) += mach-carambola2.o
+obj-$(CONFIG_ATH79_MACH_CF_E314N) += mach-cf-e316n-v2.o
obj-$(CONFIG_ATH79_MACH_CF_E316N_V2) += mach-cf-e316n-v2.o
obj-$(CONFIG_ATH79_MACH_CF_E320N_V2) += mach-cf-e316n-v2.o
obj-$(CONFIG_ATH79_MACH_CF_E355AC) += mach-cf-e316n-v2.o
diff --git
a/target/linux/ar71xx/files/arch/mips/ath79/mach-cf-e316n-v2.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-cf-e316n-v2.c
index 82fe83f..d340440 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-cf-e316n-v2.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-cf-e316n-v2.c
@@ -1,5 +1,6 @@
/*
* S
[LEDE-DEV] Add support for Comfast E312A
This unit is the 5 GHz cousin to the E314N - a 5 GHz. 2x2 radio with
built-in directional antenna. Very similar to a Ubiquiti NanoStation M5.
This version of the patch seems to have everything working.
I need some help generating a pull request (I'm a git newbie) - I have
followed the directions here:
https://lede-project.org/submitting-patches, but, when I get to the step
"git push --all" I get the response, "fatal: unable to access
'https://git.lede-project.org/source.git/': The requested URL returned
error: 403" and I can't seem to get past that.
Thanks!
diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index e101d55..1c506d0 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -182,6 +182,11 @@ carambola2)
ucidef_set_led_netdev "wan" "WAN" "$board:orange:eth1" "eth1"
ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
;;
+cf-e312a)
+ ucidef_set_led_netdev "lan" "LAN" "$board:white:lan" "eth0"
+ ucidef_set_led_netdev "wan" "WAN" "$board:white:wan" "eth1"
+ ucidef_set_led_wlan "wlan" "WLAN" "$board:white:wlan" "phy0tpt"
+ ;;
cf-e316n-v2)
ucidef_set_led_netdev "lan" "LAN" "$board:blue:lan" "eth0"
ucidef_set_led_netdev "wan" "WAN" "$board:blue:wan" "eth1"
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 5ef620b..6274841 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -118,6 +118,7 @@ get_status_led() {
cap4200ag)
status_led="senao:green:pwr"
;;
+ cf-e312a|\
cf-e316n-v2|\
cf-e520n|\
cf-e530n)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 9903563..98ed277 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -504,6 +504,9 @@ ar71xx_board_detect() {
*"Carambola2"*)
name="carambola2"
;;
+ *"CF-E312A")
+ name="cf-e312a"
+ ;;
*"CF-E316N v2")
name="cf-e316n-v2"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 18e5e41..1b13230 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -215,6 +215,7 @@ platform_check_image() {
bullet-m|\
c-55|\
carambola2|\
+ cf-e312a|\
cf-e316n-v2|\
cf-e320n-v2|\
cf-e355ac|\
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index 4793bf4..e86837f 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -67,6 +67,7 @@ CONFIG_ATH79_MACH_C55=y
CONFIG_ATH79_MACH_CAP324=y
CONFIG_ATH79_MACH_CAP4200AG=y
CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E312A=y
CONFIG_ATH79_MACH_CF_E316N_V2=y
CONFIG_ATH79_MACH_CF_E320N_V2=y
CONFIG_ATH79_MACH_CF_E355AC=y
diff --git a/target/linux/ar71xx/config-4.9 b/target/linux/ar71xx/config-4.9
index 84b2a0b..231e78e 100644
--- a/target/linux/ar71xx/config-4.9
+++ b/target/linux/ar71xx/config-4.9
@@ -65,6 +65,7 @@ CONFIG_ATH79_MACH_C55=y
CONFIG_ATH79_MACH_CAP324=y
CONFIG_ATH79_MACH_CAP4200AG=y
CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E312A=y
CONFIG_ATH79_MACH_CF_E316N_V2=y
CONFIG_ATH79_MACH_CF_E320N_V2=y
CONFIG_ATH79_MACH_CF_E355AC=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
index 5cb4f7e..e0484f2 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
@@ -2021,6 +2021,16 @@ config ATH79_MACH_RAMBUTAN
select ATH79_DEV_USB
select ATH79_DEV_WMAC
+config ATH79_MACH_CF_E312A
+ bool "COMFAST CF-E312A support"
+ select SOC_AR934X
+ select ATH79_DEV_ETH
+ select ATH79_DEV_GPIO_BUTTONS
+ select ATH79_DEV_LEDS_GPIO
+ select ATH79_DEV_M25P80
+ select ATH79_DEV_USB
+ select ATH79_DEV_WMAC
+
config ATH79_MACH_CF_E316N_V2
bool "COMFAST CF-E316N v2 support"
select SOC_AR934X
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Makefile
b/target/linux/ar71xx/files/arch/mips/ath79/Makefile
index 7d12282..3cf8e69 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Makefile
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_ATH79_MACH_C60) += mach-c60.o
obj-$(CONFIG_ATH79_MACH_CAP324) += mach-cap324.o
obj-$(CONFIG_ATH79_MACH_CAP4200AG) += mach-cap4200ag.o
obj-$(CONFIG_ATH79_MACH_CARAMBOLA2) += mach-carambola2.o
+obj-$(CONFIG_ATH79_MACH_CF_E312A) += mach-cf-e316n-v2.o
obj-$(CONFIG_ATH79_MACH_CF_E316N_V2) += mach-cf-e316n-v2.o
obj-$(CONFIG_ATH79_MACH_CF_E
Re: [LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6
Hello Piotr and Karol, On 11/29/2017 11:03 AM, Piotr Dymacz wrote: Hello Karol, Sorry for a late reply. On 06.11.2017 18:58, Bizon wrote: Hi Piotr, Thank You for comments. Before sending v2 patch lets clarify all doubts. 2017-11-05 23:22 GMT+01:00 Piotr Dymacz : Hello Karol, Thank you for your patch but it seems that it got whitespace mangled and tabs were replaced with spaces. Please, send v2 using git send-email. Also, please see my comments inline, below. On 30.10.2017 20:32, Bizon wrote: Add support for TP-Link TL-WDR7500 V6. Specifications: - WiSoC: QCA9563 - 3x3 2.4GHz - Radio2: QCA9880 - 3x3 5GHz - RAM: 64MB DDR2 - Storage: 8MB NOR SPI flash, can be replaced with 16M - Switch: RTL8367S, now unmanaged - Ethernet: 5x1G - Misc: 2x button, 2x LED Please, include in commit message how to install LEDE on this device as described under "commit description" section on [1]. Ok, will prepare manual how to change bootloader to non-RSA one, move art and install LEDE. I'm sorry but I'm against accepting support for devices which requires such invasive modifications. We always try to make it possible for users to get back to the stock firmware which wouldn't be easy (or possible at all) with your changes in mtd layout and after bootloader swap. In general, of course, I agree. However, we are seeing an increasing number of vendors (TP-Link and Ubiquiti, to name 2) using some form of locking in the bootloader to prevent loading of third-party firmware. The only option for loading OpenWRT (permanently - not using initramfs) on these devices will be replacing the bootloader, as Karol does in this patch. If the only objection is that it involves invasive modifications that may not (probably won't) allow the device to be re-flashed to stock, I would prefer we accept the patch and make a very strongly-worded note in the ToH and the device's wiki page explaining the situation. FWIW, Bill ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6
Piotr- Good points all... On 11/29/2017 12:03 PM, Piotr Dymacz wrote: Hello Bill, On 29.11.2017 20:17, Bill Moffitt wrote: Hello Piotr and Karol, [snip] Please, include in commit message how to install LEDE on this device as described under "commit description" section on [1]. Ok, will prepare manual how to change bootloader to non-RSA one, move art and install LEDE. I'm sorry but I'm against accepting support for devices which requires such invasive modifications. We always try to make it possible for users to get back to the stock firmware which wouldn't be easy (or possible at all) with your changes in mtd layout and after bootloader swap. In general, of course, I agree. However, we are seeing an increasing number of vendors (TP-Link and Ubiquiti, to name 2) using some form of locking in the bootloader to prevent loading of third-party firmware. Then buy and use hardware from vendors who are open source friendly and allow users to actually fully own the hardware they paid for! :) Hey, THERE'S a good idea!!! Suggestions??? :-D (especially for outdoors - that's why I'm working with the Comfast devices...) The only option for loading OpenWRT (permanently - not using initramfs) on these devices will be replacing the bootloader, as Karol does in this patch. Swapping bootloader isn't the only issue I see here. Moving ART which is essential and unique per device might end up in a data loss which cannot be recovered in any way. Yes, that's true. But the only other option is not use the hardware. If the only objection is that it involves invasive modifications that may not (probably won't) allow the device to be re-flashed to stock, I would prefer we accept the patch and make a very strongly-worded note in the ToH and the device's wiki page explaining the situation. This is not the only one objection. Personally I don't have problems with swapping bootloader and for ar71xx target we already have a dedicated package with old U-Boot sources: [1] The problem here is that the bootloader the user has to use for this device comes from some random GitHub repository which exist today but may disappear tomorrow. Who will make sure that the bootloader image the author of the support mentions in his patch will be still available in next years and is correct and won't break users device? If the bootloader code was in our repository or in upstream, I would be first one accepting support for this device. Good point. What's also important to notice here, devices with QCA WiSoCs and SPI NOR flash chips aren't easy to recover from a failed bootloader flash. If there is no JTAG on the board the only way to bring device back to life is to use flash chip programmer. Very good point. [1] https://github.com/lede-project/source/tree/master/package/boot/uboot-ar71xx But I'd still rather endorse a notation in the ToH and the wiki than just prevent the patch from being accepted. Everything in OpenWRT is pretty much "use at your own risk." Could we make a distinction between "Use at your own risk - might cause problems that will be hard to get around" and "Use at your own risk - you have a pretty good chance of bricking this thing?" Or, put another way, instead of just saying "supported" could we have platforms that are "Supported and easy" to "Supported, but, hey, this thing is ugly and will hurt you if you're not careful?" We should do everything we can to reduce the risk of a repo going away, etc., but I'd endorse using some sketchy sources if necessary to gain support of a particular device. It is good and necessary to look out for the naive beginner (as we all were at one time). But, at the same time, there is value in supporting the wisened and experienced user who can go to some extra effort and undertake some risk for a particular purpose. That's how I feel about it. As always, FWIW. -Bill -- Bill Moffitt Ayrstone Productivity http://ayrstone.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6
Mathias- Good points all. I don't think I have anything to add. On 12/01/2017 12:13 AM, Mathias Kresin wrote: 30.11.2017 22:06, Bill Moffitt: On 11/29/2017 12:03 PM, Piotr Dymacz wrote: On 29.11.2017 20:17, Bill Moffitt wrote: Swapping bootloader isn't the only issue I see here. Moving ART which is essential and unique per device might end up in a data loss which cannot be recovered in any way. Yes, that's true. But the only other option is not use the hardware. Not using the hardware is a valid option and so far no veto from any other dev. But I'd still rather endorse a notation in the ToH and the wiki than just prevent the patch from being accepted. Forget about it! People don't read. Instead we will be flooded on all public and private (!) channels with request for help similar to: - how to install LEDE on the board - where to get the custom bootloader - i bricked my board help! help! It is good and necessary to look out for the naive beginner (as we all were at one time). But, at the same time, there is value in supporting the wisened and experienced user who can go to some extra effort and undertake some risk for a particular purpose. Well, your patch can be now found by $searchengine and anyone how is brave enough, can add support for this board to a local clone. I'm perfect fine with the decision made by Piotr. If it is to hard to get LEDE installed on a board/to error prone, we do not necessarily need to add support for this board to a target with > 100 already supported boards of all kinds. Mathias ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev Thanks, Bill ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6
Piotr- Thank you for your time and energy in helping me understand the issues. First, I strongly agree with your comment about "I think it's always up to the person who takes care" of the PRs, etc - it is, and should be, entirely your call! I cannot do and do not want the job!!! :-D Second, Mathias's point "any [experienced] user can take it and make use of it" is also very well-taken. Together, I think these more than adequately answer my concerns - I certainly have no objections. Thank you again, Bill On 12/12/2017 11:49 AM, Piotr Dymacz wrote: Hello Bill, On 30.11.2017 22:06, Bill Moffitt wrote: Piotr- Good points all... [snip] In general, of course, I agree. However, we are seeing an increasing number of vendors (TP-Link and Ubiquiti, to name 2) using some form of locking in the bootloader to prevent loading of third-party firmware. Then buy and use hardware from vendors who are open source friendly and allow users to actually fully own the hardware they paid for! :) Hey, THERE'S a good idea!!! Suggestions??? :-D (especially for outdoors - that's why I'm working with the Comfast devices...) There are great people working on the Wiki and table of hardware [1]. The ToH is now mostly driven by information included in commits which add support for new devices. You can also ask on the forum [2] for hardware suggestions. The only option for loading OpenWRT (permanently - not using initramfs) on these devices will be replacing the bootloader, as Karol does in this patch. Swapping bootloader isn't the only issue I see here. Moving ART which is essential and unique per device might end up in a data loss which cannot be recovered in any way. Yes, that's true. But the only other option is not use the hardware. I wouldn't be surprised if there is some other way but people usually prefer "make it working and forget" approach (I follow it very often, too). [snip] But I'd still rather endorse a notation in the ToH and the wiki than just prevent the patch from being accepted. I think it's always up to the person who takes care (and spends time reviewing, merging and then maintaining related code in future) about the patch/PR as we don't have any strictly defined rule/s about what device/platform can be accepted. If someone else feels that this patch should be included, I won't argue - I have already pointed out what's in my opinion wrong with it. Everything in OpenWRT is pretty much "use at your own risk." Could we make a distinction between "Use at your own risk - might cause problems that will be hard to get around" and "Use at your own risk - you have a pretty good chance of bricking this thing?" Or, put another way, instead of just saying "supported" could we have platforms that are "Supported and easy" to "Supported, but, hey, this thing is ugly and will hurt you if you're not careful?" I hope some day in future OpenWrt/LEDE will have all the code required to support every platform from top to bottom, including bootloader/s, radio firmware, JTAG configs, etc. But we are not there yet. FWIW, there is an ongoing work on making Barebox bootloader support MIPS based QCA WiSoCs [3] and a PR with packaging it is under review: [4]. We should do everything we can to reduce the risk of a repo going away, etc., but I'd endorse using some sketchy sources if necessary to gain support of a particular device. I think it's always a trade off and every single person would have different opinion here. It is good and necessary to look out for the naive beginner (as we all were at one time). But, at the same time, there is value in supporting the wisened and experienced user who can go to some extra effort and undertake some risk for a particular purpose. As Mathias wrote, the patch was sent to a public mailing list and now any [experienced] user can take it and make use of it... assuming that (s)he would magically find out where to get, compile and write the custom bootloader. The patch doesn't include any clue about that. That's how I feel about it. As always, FWIW. Thanks, I appreciate every valuable comment! [1] https://lede-project.org/toh/start [2] https://forum.lede-project.org/ [3] https://git.pengutronix.de/cgit/barebox/log/?qt=grep&q=ath79 [4] https://github.com/lede-project/source/pull/1556 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] AuthSAE for mesh authentication
I have downloaded a few recent nightly builds, and AuthSAE seems to be missing from the packages. What happened? How can we get it back? Thanks, Bill ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] Add support for Comfast E314N
The Comfast E314N-V2 is a 2.4 GHz 2x2 radio with a built-in directional
antenna and a second Ethernet port - very similar to the Ubiquiti
NanoStation M2. The Ethernet port features a pass-through PoE
capability, enabled or disabled with a slide switch. The radio is built
using a Qualcomm/Atheros QCA9531 chipset.
The majority of the changes are in the
target/linux/ar71xx/files/arch/mips/ath79/mach-cf-e316n-v2.c file.
One significant change is that the function cf_exxxn_qca953x_eth_setup
had to be moved before the CF-314N section in that file.
Firmware can be flashed on these units by the following method:
1.) Apply power to the unit
2.) Immediately AFTER applying power, hold down the reset button
3.) The WAN, LAN, and wireless lights will flash - wait three seconds
(three flashes) and then release the button.
4.) After a second, the lights will "flutter" quickly and the unit will
be visible at 192.168.1.1. A web page will be available to enable quick
and simple uploading and flashing of firmware.
During the boot process, these units also look for a tftp server at
192.168.1.10. If one is present, the firmware can be uploaded as a file
called "firmware-auto.bin"
---
target/linux/ar71xx/base-files/etc/board.d/01_leds | 5 +
target/linux/ar71xx/base-files/etc/diag.sh | 1 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
.../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ar71xx/config-4.4 | 1 +
.../ar71xx/files/arch/mips/ath79/Kconfig.openwrt | 10 ++
target/linux/ar71xx/files/arch/mips/ath79/Makefile | 1 +
.../files/arch/mips/ath79/mach-cf-e316n-v2.c | 148 +
.../linux/ar71xx/files/arch/mips/ath79/machtypes.h | 1 +
target/linux/ar71xx/image/generic.mk | 9 ++
10 files changed, 153 insertions(+), 27 deletions(-)
diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index 833522f..dae3481 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -143,6 +143,11 @@ carambola2)
ucidef_set_led_netdev "wan" "WAN" "$board:orange:eth1" "eth1"
ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
;;
+cf-e314n-v2)
+ucidef_set_led_netdev "wan" "WAN" "$board:white:wan" "eth0"
+ ucidef_set_led_netdev "lan" "lAN" "$board:white:lan" "eth1"
+ ucidef_set_led_wlan "wlan" "WLAN" "$board:white:wlan" "phy0tpt"
+;;
cf-e316n-v2)
ucidef_set_led_netdev "lan" "LAN" "$board:blue:lan" "eth0"
ucidef_set_led_netdev "wan" "WAN" "$board:blue:wan" "eth1"
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index bc2fc2f..e2f26eb 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -101,6 +101,7 @@ get_status_led() {
cap4200ag)
status_led="senao:green:pwr"
;;
+cf-e314n-v2|\
cf-e316n-v2|\
cf-e520n|\
cf-e530n)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index bf36598..b01f4af 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -487,6 +487,9 @@ ar71xx_board_detect() {
*CAP4200AG)
name="cap4200ag"
;;
+ *"CF-E314N v2")
+ name="cf-e314n-v2"
+ ;;
*"CF-E316N v2")
name="cf-e316n-v2"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 21ad2a6..f7d03e5 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -209,6 +209,7 @@ platform_check_image() {
bullet-m|\
c-55|\
carambola2|\
+cf-e314n-v2|\
cf-e316n-v2|\
cf-e320n-v2|\
cf-e380ac-v1|\
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index a862245..7ba7e2f 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -62,6 +62,7 @@ CONFIG_ATH79_MACH_C60=y
CONFIG_ATH79_MACH_CAP324=y
CONFIG_ATH79_MACH_CAP4200AG=y
CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E314N_V2=y
CONFIG_ATH79_MACH_CF_E316N_V2=y
CONFIG_ATH79_MACH_CF_E320N_V2=y
CONFIG_ATH79_MACH_CF_E380AC_V1=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
index 58d7e43..d85ae2c 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
@@ -1765,6 +1765,16 @@ config ATH79_MACH_CARAMBOLA2
select ATH79_DEV_USB
select ATH79_DEV_WMAC
+config ATH79_MACH_CF_E314N_V2
+ bool "COMFAST CF-E314
Re: [LEDE-DEV] [OpenWrt] [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things
On 12/5/2016 4:54 AM, Hauke Mehrtens wrote:
On 2016-12-05 11:57, Daniel Golle wrote:
Hi Felix,
On Thu, Dec 01, 2016 at 04:51:30PM +0100, Felix Fietkau wrote:
On 2016-12-01 16:38, Daniel Golle wrote:
> Hi Felix,
>
> On Thu, Dec 01, 2016 at 04:12:38PM +0100, Felix Fietkau wrote:
>> On 2016-12-01 16:05, Daniel Golle wrote:
>> > I was following your posts and do believe there is quite some
overlap.
>> > It would thus be feasible to generalize the common parts (ubus
call
>> > proxy, ubus service proxy, ubus remote monitor) by agreeing on
a shared
>> > interface the actual implementations shall use. In that way,
people
>> > can choose whether they want WebSockets, TR-069 or a suitable P2P
>> > framework depending on their specific needs.
>> > Has anything of your current approach at IOPSYS been made
available
>> > publicly (eg. on github?)
>> >
>> > From what I can tell there is also some overlap with Felix'
proposed
>> > System Configuration Abstraction Layer, just that my envisioned
use
>> > exceeds system configuration as it includes sensors, events and
actors
>> > rather than just access to a configuration model.
>> If it makes sense, I'd be open to extending my abstraction layer
to make
>> it suitable for your use case as well.
>> Feel free to propose changes to it if you like.
>
> Having a first deeper look at scal I believe that access to sensors
> and actors could be implemented inside scal similar to the existing
> shell and system backends. That would be nice, as then scal would
> make things available on ubus and provide the ACL mechanics.
Nice. Maybe we can reinterpret the acronym as "System Communication
Abstraction Layer". I'd be fine with renaming it to something else as
well, I just didn't find a better name for it yet.
I think a good approach would be to add a dlopen plugin API to the json
plugin itself, so you can use json files to parameterize access to
sensors and other devices.
To me the question remains whether access to devices should happen
directly inside those scal-json-plugins or if it'd be better to
expose a service on ubus ("urthings") handling them (which was my
original plan) and then have scal access them via ubus. The latter
would come with the advantage that other local services (think:
collectd) could also access them via that urthings service instead of
having to go through scal.
I would like to have an API which can be used locally easily not just
from remote, I haven't found the time to look into scal .
Like a Luci web UI to switch on and off your lamps and also some API
so that others can easily integrate own application running on the
device which are managing and controlling the things. Probably people
will also run applications to connect the devices to existing clouds
with existing interfaces.
I'd be glad to here more opinions, because this obviously has to be
decided early in the design of the IoT integration approach. Find
me on IRC (dangole@freenode) in the next couple of hours, maybe we
can collect some ideas about the edges to be cut before the meeting
at 3pm CET.
Event handling could also be scripted through .json files using
json_script.
I thought of it like that, similar to how procd's hotplug json_scripts
look like. In addition I thought about adding ubus input and output
support to collectd (so events can be triggered depending on conditions
defined over polled sensors), but maybe something much simpler and more
thightly designed for that specific job -- polling sensors, (maybe)
caching & monitoring/triggering events -- could also be sufficient.
However, I reckon this can be decided at a later stage, and as I'm
already quite familiar with collectd, I'd just go ahead and create
a ubus plugin there and who ever is unhappy with that may suggest
what ever else could be better.
I think we should focus on Phase 1 first to get these stuff properly
into a generic API in LEDE and then use some generic interfaces to
expose it to remote hosts.
I want to agree with this approach. There are some interesting issues in
polling sensors that I'm not sure collectd would cover well (my
experience here is in weather: you can sample temperature any time, but
you have to "watch" a rain bucket continuously and make note of every
time it tips), and it would be good to include the possibility of
control outputs, as well (gpio or pwm). But it's good to start
somewhere, IMHO.
Cheers
Daniel
> I'll have a deeper look and play with it to see whether that can
> work.
>
> Ideally, data collection (think: interface counters and such things
> which need to be polled) and triggering events (think: link status
> updates) should also be made accessible.
>
> A local database which exceeds UCI state as suggested by Luka could
> also be very useful, eg. for renewable energy or other applications
> where loss of connectivity should never imply loss of collected data.
Makes sense.
- Felix
___
Lede
Re: [LEDE-DEV] [PATCH] ar71xx: change image version for ubiquiti devices
I don't know if it makes any difference, but insofar as there is an AirOS 6.0 now (https://community.ubnt.com/t5/airMAX-Updates-Blog/airOS-6-0-Has-Been-Released/ba-p/1769476) should we change the strong to something like "v7.0.0-" etc.? On 3/3/2017 7:51 AM, txt.file wrote: changes the image version from hardcoded OpenWrt to $VERSION_DIST. AirOS shows a notification with the image version during a firmware upgrade. fixes #582 Signed-off-by: Matthias Fritzsche --- target/linux/ar71xx/image/ubnt.mk | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/target/linux/ar71xx/image/ubnt.mk b/target/linux/ar71xx/image/ubnt.mk index 7a1fc80..c633ca1 100644 --- a/target/linux/ar71xx/image/ubnt.mk +++ b/target/linux/ar71xx/image/ubnt.mk @@ -6,7 +6,7 @@ # routerboard creates partitions out of the ubnt header define Build/mkubntimage -$(STAGING_DIR_HOST)/bin/mkfwimage \ - -B $(UBNT_BOARD) -v $(UBNT_TYPE).$(UBNT_CHIP).v6.0.0-OpenWrt-$(REVISION) \ + -B $(UBNT_BOARD) -v $(UBNT_TYPE).$(UBNT_CHIP).v6.0.0-$(VERSION_DIST)-$(REVISION) \ -k $(IMAGE_KERNEL) \ -r $@ \ -o $@ @@ -19,7 +19,7 @@ define Build/mkubntimage-split dd if=$@ of=$@.old1 bs=1024k count=1; \ dd if=$@ of=$@.old2 bs=1024k skip=1; \ $(STAGING_DIR_HOST)/bin/mkfwimage \ - -B $(UBNT_BOARD) -v $(UBNT_TYPE).$(UBNT_CHIP).v6.0.0-OpenWrt-$(REVISION) \ + -B $(UBNT_BOARD) -v $(UBNT_TYPE).$(UBNT_CHIP).v6.0.0-$(VERSION_DIST)-$(REVISION) \ -k $@.old1 \ -r $@.old2 \ -o $@; \ @@ -28,7 +28,7 @@ endef define Build/mkubntimage2 -$(STAGING_DIR_HOST)/bin/mkfwimage2 -f 0x9f00 \ - -v $(UBNT_TYPE).$(UBNT_CHIP).v6.0.0-OpenWrt-$(REVISION) \ + -v $(UBNT_TYPE).$(UBNT_CHIP).v6.0.0-$(VERSION_DIST)-$(REVISION) \ -p jffs2:0x5:0xf6:0:0:$@ \ -o $@.new @mv $@.new $@ ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] portal wifi router
On 6/22/2016 10:41 AM, Dave Taht wrote: eero shipped something debian based (using batman-adv to mesh, I believe) google onhub shipped some sort of hybrid of chromeos (so far as I know) https://www.plumewifi.com/ is making all sorts of promises, can't tell what they are using. A new one just cropped up - portal - where their kickstarter claims they are using openwrt. Anyone know anything more about it? Not clear what chipset they are using but since they are based in taiwan I'd guess it's mediatek, but it could be qualcomm? https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi?ref=email http://getportal.io/ has more "details" and early backers should be seeing routers soon. They are all claiming massive improvements in wifi performance mostly based on whatever 802.11ac based technology they are using, I keep hoping at least some of the above were also paying attention to bql, fq_codel, per station queuing, etc. Dave- Thanks for pointing those out (I'll volunteer that Ayrstone AyrMesh is also, of course, based on OpenWRT and Open80211s, for those on U.S. and Canadian farms. I don't claim that we're improving on anything but getting moderate-bandwidth LAN connectivity over very large rural areas). I love the idea of meshing WiFi systems adapting their channel settings around local interference... so the Plume in my house detects that my next door neighbor's Portal is interfering, so it changes its channel. However, the Plume in my garage is much closer to the neighbor behind me than the Plume in my house, and changes the channel to avoid them. This then interferes with the neighbor's Portal, which changes its channel to avoid my interference, which then interferes with the neighbor behind me, who changes channel to avoid that interference... And, of course, as you point out, this is a situation ripe for bufferbloat (we know that mesh networks are potentially, ah, troublesome). On the other hand, you, Jim, and others have been banging the drum for 6 years or so, if memory serves. So there's no excuse for new products coming out to NOT use bql, etc. If the word has gotten down to the least capable wireless networking developers (i.e. me), everyone should be up to speed by now. So, on balance, I'm not too worried about these things increasing congestion - in a typical apartment building I'm not sure they'll be actually be working long enough to congest anything. ;-) Humorously, Bill P.S. for the mathematically inclined, note the discrepancy between the 3 distinct channels in the 2.4 GHz. band and the application of the 4-color theorem to channel selection. Sucks... ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] A Wiki for LEDE Documentation
I'll throw out another candidate: Twiki (twiki.org). I have used it, I wasn't crazy about it, but it had some nice features. And I cannot say with certainty how it would map into our use for LEDE. I haven't used DokuWiki, so I can't say how it stacks up. An admittedly weak endorsement, and I will be interested in hearing differing views. Thanks, Bill ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Ubnt Bullet M2 flashing ?
I have not been able to figure out a way to do it. On 04/18/2018 02:14 PM, Etienne Champetier wrote: Hi All, Is it still possible to flash latest ubnt bullet m2 with OpenWRT? (AirOS 6.X) Is it possible to downgrade to 5.5.10 from the 6.X versions ? is it still required ? The wiki is not really up to date: https://openwrt.org/toh/ubiquiti/bullet And I've tried to ask on the forum but no luck :( https://forum.lede-project.org/t/bullet-m2-flashing-replacement/10849 Thanks in advance Etienne ___ 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
