Re: [OpenWrt-Devel] Ubus based service watchdog?
On Thu, May 14, 2020, 23:43 Philip Prindeville < philipp_s...@redfish-solutions.com> wrote: > > > On May 13, 2020, at 11:48 AM, Michael Jones > wrote: > > > > I have a critical service on my OpenWRT system that needs monitoring and > re-starting if it's failed. > > > > I've been looking for a mechanism in procd that would allow me to > request that my service be terminated if it did not periodically notify > some watchdog endpoint via ubus. > > > > It seems to me like this is not something that is currently supported by > procd, and I've written my own clumsy "watchdog" wrapper program that tries > to do the job. > > > > Are there any plans to support a feature like this in procd directly in > the future? > > > > If there are no plans, and I were to write code for this, would OpenWRT > be interested in reviewing, and then merging, patches? > > > > Are there other people on this list who would take advantage of this > feature if it were available? If so, what functionality would you like to > see? > > > > > So existing services that are launched by procd (like ISC dhcpd) would > need to be patched to support this? > > -Philip > Yes. That would be the case. It would need to be an opt-in feature. Its not possible for a service watchdog to be opt out because service watchdogs need to be tailored to the service being watched. > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ubus based service watchdog?
> On May 13, 2020, at 11:48 AM, Michael Jones wrote: > > I have a critical service on my OpenWRT system that needs monitoring and > re-starting if it's failed. > > I've been looking for a mechanism in procd that would allow me to request > that my service be terminated if it did not periodically notify some watchdog > endpoint via ubus. > > It seems to me like this is not something that is currently supported by > procd, and I've written my own clumsy "watchdog" wrapper program that tries > to do the job. > > Are there any plans to support a feature like this in procd directly in the > future? > > If there are no plans, and I were to write code for this, would OpenWRT be > interested in reviewing, and then merging, patches? > > Are there other people on this list who would take advantage of this feature > if it were available? If so, what functionality would you like to see? > So existing services that are launched by procd (like ISC dhcpd) would need to be patched to support this? -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Sysupgrade and Failed to kill all processes
Philip Prindeville wrote: >> In general, I think that this decision needs to up-leveled to as a >> build option. There are many cases where I would agree: you want the >> box to die rather than potentially come up insecurely. > A while ago I posted an option to “bake in” a default root password but > it was nixed. > https://github.com/openwrt/openwrt/pull/622 > Too bad. Such a thing would violate the California, UK and coming Australian and US laws. We are also going to have to deal with admin/admin; maybe there are already plans for that. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 1/1] firewall3: harden string functions that might overflow
What should I use instead of strlcpy or strcpy? Sent from my iPhone > On May 14, 2020, at 11:04 AM, Jo-Philipp Wich wrote: > > Hi, > > the sprintf() to snprintf() changes are fine to me. Please omit the > conversions to strlcpy() and please don't use fmemopen(). > > ~ Jo > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ubus based service watchdog?
FWIW, k8s has Liveness, Readiness and Startup Probes https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ :: > The kubelet uses startup probes to know when a container application has started. If such a probe is configured, it disables liveness and readiness checks until it succeeds, making sure those probes don’t interfere with the application startup. This can be used to adopt liveness checks on slow starting containers, avoiding them getting killed by the kubelet before they are up and running. On Thu, May 14, 2020, 1:01 PM Jo-Philipp Wich wrote: > Hi, > > I like the ubus watchdog ping/pong idea. > > ~ Jo > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Sysupgrade and Failed to kill all processes
> On May 14, 2020, at 8:23 AM, Michael Richardson wrote: > > [snip] > > It depends a lot on the relative cost of sending a service person there to > repair the device (push the button, reflash or replace the device), vs the > risk of the box not operating at all. > > In the NAT44 home router situation, the lack of an iptables to do MASQ or > port forwarding results in the "firewall" failing closed. > No packets traverse, but the box might be accessible by network for repairs > from one side or the other. > > In the IPv6 and routed IPv4 situation, if packet forwarding is enabled, then > the box might continue to provide critical functionality, and it might be > possible to repair it remotely. > > In the case where this isn't a router, but a NAS, or some other IoT device, > then the lack of a firewall, if the device has multiple layers of security > (no stupid default passwords, or no passwords at all) result in a lowered > level of security, but not zero security. > > In general, I think that this decision needs to up-leveled to as a build > option. There are many cases where I would agree: you want the box to die > rather than potentially come up insecurely. > A while ago I posted an option to “bake in” a default root password but it was nixed. https://github.com/openwrt/openwrt/pull/622 Too bad. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 1/1] firewall3: harden string functions that might overflow
Hi, the sprintf() to snprintf() changes are fine to me. Please omit the conversions to strlcpy() and please don't use fmemopen(). ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ubus based service watchdog?
Hi, I like the ubus watchdog ping/pong idea. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Sysupgrade and Failed to kill all processes
Philip Prindeville wrote: >> A reboot with some logging on disk would allow for remote sysupgrades >> to have some kind of recoverability. > What if the failure left the box in a partially compromised state? > Would you want your firewall to “fail open”? I wouldn’t. It depends a lot on the relative cost of sending a service person there to repair the device (push the button, reflash or replace the device), vs the risk of the box not operating at all. In the NAT44 home router situation, the lack of an iptables to do MASQ or port forwarding results in the "firewall" failing closed. No packets traverse, but the box might be accessible by network for repairs from one side or the other. In the IPv6 and routed IPv4 situation, if packet forwarding is enabled, then the box might continue to provide critical functionality, and it might be possible to repair it remotely. In the case where this isn't a router, but a NAS, or some other IoT device, then the lack of a firewall, if the device has multiple layers of security (no stupid default passwords, or no passwords at all) result in a lowered level of security, but not zero security. In general, I think that this decision needs to up-leveled to as a build option. There are many cases where I would agree: you want the box to die rather than potentially come up insecurely. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] ramips: mt7620: tidy up ethernet node in DTS files
This tidies up the ethernet node in mt7620 DTS files by: - removing unnecessary status as it is not disabled - reordering properties consistently - adding empty lines to enhance readability This should make comparison and reviewing new PRs based on C/P easier. Signed-off-by: Adrian Schmutzler --- target/linux/ramips/dts/mt7620a_aigale_ai-br100.dts | 1 + target/linux/ramips/dts/mt7620a_alfa-network_ac1200rm.dts | 6 -- target/linux/ramips/dts/mt7620a_bdcom_wap2100-sk.dts| 1 + target/linux/ramips/dts/mt7620a_buffalo_whr-300hp2.dts | 2 ++ target/linux/ramips/dts/mt7620a_buffalo_whr-600d.dts| 2 ++ target/linux/ramips/dts/mt7620a_dlink_dir-810l.dts | 1 + target/linux/ramips/dts/mt7620a_dlink_dwr-118-a1.dts| 1 - target/linux/ramips/dts/mt7620a_dlink_dwr-118-a2.dts| 4 ++-- target/linux/ramips/dts/mt7620a_dlink_dwr-960.dts | 3 +-- target/linux/ramips/dts/mt7620a_dovado_tiny-ac.dts | 2 +- target/linux/ramips/dts/mt7620a_edimax_br-6478ac-v2.dts | 5 +++-- target/linux/ramips/dts/mt7620a_edimax_ew-7478apc.dts | 5 +++-- target/linux/ramips/dts/mt7620a_edimax_ew-747x.dtsi | 6 ++ target/linux/ramips/dts/mt7620a_engenius_esr600.dts | 2 +- target/linux/ramips/dts/mt7620a_glinet_gl-mt300a.dts| 1 + target/linux/ramips/dts/mt7620a_glinet_gl-mt300n.dts| 1 + target/linux/ramips/dts/mt7620a_glinet_gl-mt750.dts | 1 + target/linux/ramips/dts/mt7620a_head-weblink_hdrm200.dts| 5 ++--- target/linux/ramips/dts/mt7620a_hiwifi_hc5861.dts | 5 +++-- target/linux/ramips/dts/mt7620a_hiwifi_hc5x61.dtsi | 2 ++ target/linux/ramips/dts/mt7620a_iodata_wn-ac1167gr.dts | 1 + target/linux/ramips/dts/mt7620a_iodata_wn-ac733gr3.dts | 1 + target/linux/ramips/dts/mt7620a_lava_lr-25g001.dts | 1 - target/linux/ramips/dts/mt7620a_lb-link_bl-w1200.dts| 6 +++--- target/linux/ramips/dts/mt7620a_lenovo_newifi-y1.dts| 2 ++ target/linux/ramips/dts/mt7620a_lenovo_newifi-y1s.dts | 5 +++-- target/linux/ramips/dts/mt7620a_linksys_e1700.dts | 4 ++-- target/linux/ramips/dts/mt7620a_microduino_microwrt.dts | 2 ++ target/linux/ramips/dts/mt7620a_ohyeah_oy-0001.dts | 2 ++ target/linux/ramips/dts/mt7620a_phicomm_k2g.dts | 2 ++ target/linux/ramips/dts/mt7620a_phicomm_psg1208.dts | 2 ++ target/linux/ramips/dts/mt7620a_phicomm_psg1218a.dts| 2 ++ target/linux/ramips/dts/mt7620a_phicomm_psg1218b.dts| 2 ++ target/linux/ramips/dts/mt7620a_planex_cs-qr10.dts | 2 ++ target/linux/ramips/dts/mt7620a_planex_db-wrt01.dts | 2 ++ target/linux/ramips/dts/mt7620a_planex_mzk-750dhp.dts | 2 ++ target/linux/ramips/dts/mt7620a_planex_mzk-ex300np.dts | 2 ++ target/linux/ramips/dts/mt7620a_planex_mzk-ex750np.dts | 2 ++ target/linux/ramips/dts/mt7620a_ralink_mt7620a-evb.dts | 2 +- .../linux/ramips/dts/mt7620a_ralink_mt7620a-mt7530-evb.dts | 2 +- .../linux/ramips/dts/mt7620a_ralink_mt7620a-mt7610e-evb.dts | 2 +- .../linux/ramips/dts/mt7620a_ralink_mt7620a-v22sg-evb.dts | 2 +- target/linux/ramips/dts/mt7620a_sanlinking_d240.dts | 1 + target/linux/ramips/dts/mt7620a_sercomm_na930.dts | 2 +- target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts | 4 ++-- target/linux/ramips/dts/mt7620a_tplink_archer.dtsi | 2 ++ target/linux/ramips/dts/mt7620a_xiaomi_miwifi-mini.dts | 2 ++ target/linux/ramips/dts/mt7620a_youku_yk1.dts | 2 ++ target/linux/ramips/dts/mt7620a_yukai_bocco.dts | 2 ++ target/linux/ramips/dts/mt7620a_zbtlink_zbt-ape522ii.dts| 2 ++ target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826.dtsi | 1 + target/linux/ramips/dts/mt7620a_zte_q7.dts | 1 + target/linux/ramips/dts/mt7620a_zyxel_keenetic-viva.dts | 2 +- target/linux/ramips/dts/mt7620n_asus_rt-n12p.dts| 1 + target/linux/ramips/dts/mt7620n_asus_rt-n14u.dts| 1 + target/linux/ramips/dts/mt7620n_buffalo_wmr-300.dts | 1 + target/linux/ramips/dts/mt7620n_dlink_dwr-116-a1.dts| 3 ++- target/linux/ramips/dts/mt7620n_elecom_wrh-300cr.dts| 1 + target/linux/ramips/dts/mt7620n_kingston_mlw221.dts | 1 + target/linux/ramips/dts/mt7620n_kingston_mlwg2.dts | 1 + target/linux/ramips/dts/mt7620n_nexx_wt3020.dtsi| 1 + target/linux/ramips/dts/mt7620n_vonets_var11n-300.dts | 1 + target/linux/ramips/dts/mt7620n_wrtnode_wrtnode.dts | 1 + target/linux/ramips/dts/mt7620n_zbtlink_zbt-cpe102.dts | 1 + target/linux/ramips/dts/mt7620n_zbtlink_zbt-wa05.dts| 1 + target/linux/ramips/dts/mt7620n_zbtlink_zbt-we2026.dts | 1 + target/linux/ramips/dts/mt7620n_zbtlink_zbt-wr8305rt.dts| 2 ++ target/linux/ramips/dts/mt7620n_zyxel_keenetic-omni-ii.dts | 1 + target/linux/ramips/dts/mt7620n_zyxel_keenetic-omni.dts |
[OpenWrt-Devel] [PATCH 2/2] ramips: drop non-existant ralink, port-map for Ravpower WD03
The property "ralink,port-map" never existed, and the device is a
one-port anyway. Just remove it.
Fixes: 5ef79af4f80f ("ramips: add support for Ravpower WD03")
Signed-off-by: Adrian Schmutzler
---
target/linux/ramips/dts/mt7620n_ravpower_wd03.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/target/linux/ramips/dts/mt7620n_ravpower_wd03.dts
b/target/linux/ramips/dts/mt7620n_ravpower_wd03.dts
index 6d734bb836..f67f186be1 100644
--- a/target/linux/ramips/dts/mt7620n_ravpower_wd03.dts
+++ b/target/linux/ramips/dts/mt7620n_ravpower_wd03.dts
@@ -100,7 +100,6 @@
{
mtd-mac-address = < 0x4000>;
- ralink,port-map = "w";
};
{
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add support for gl-e750
Hi adrian, However, if you need a separate factory for u-boot now, go for it. But then, I'd prefer it to have the .bin extension as well. --->In the uboot of gl-e750, the extension .bin is considered to be nor firmware and will be handled according to the upgrade process of nor firmware. --->The reason for this is that in the original ar71xx target, the bin extension was nor firmware and the .img extension was nand firmware. --->Although the E750 has not released nor firmware, we still have this feature in uboot. Best regards, Luochongjun ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add support for gl-e750
Hi,
> > + {
> > + status = "okay";
> > + mtd-cal-data = < 0x1000>;
> > + mtd-mac-address = < 0x1002>;
>
> mtd-mac-address can be dropped here, as it will be read from this offset by
> mtd-cal-data automatically.
> ---> Will the offset of 0x2 be automatically added?
If you read caldata with mtd-cal-data, it will automatically apply a MAC
address found with offset +2 compared to the start of the caldata.
So, cal-data at 0x1000 will use MAC address from 0x1002
caldata at 0x4000 will use MAC address from 0x4002
etc.
mtd-mac-address for wmac is only needed if that region does _not_ contain a
proper/valid address, so you need to overwrite it with a sensible value (e.g.
for many TP-Link devices, where there is only one valid MAC address in uboot
partition, and all others need to be calculated with increments).
Further reading (still WIP):
https://openwrt.org/docs/guide-developer/mac.address#mac_address_pulled_by_driver
> > + IMAGES += factory.img
>
> Typically, GL.inet devices can be installed with sysupgrade, so a factory
> image is not necessary? (And it's not set up anyway)
> I think this can be dropped.
> --->Many GL users like to use uboot to upgrade their firmware, so I think it
> is necessary to generate a factory image.
I'm only used to the old SPI-only devices from GL.inet, where you could just do
anything with the sysupgrade image.
However, if you need a separate factory for u-boot now, go for it. But then,
I'd prefer it to have the .bin extension as well.
And you still need to add a recipe for it ...
Best
Adrian
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add support for gl-e750
Hi,adrian
I added a reply below your question.
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Luochongjun
> Sent: Donnerstag, 7. Mai 2020 13:47
> To: openwrt-devel@lists.openwrt.org
> Cc: Luochongjun
> Subject: [OpenWrt-Devel] [PATCH] ath79: add support for gl-e750
>
> The gl-e750 is a portable travel router that gives you safe access to the
> internet while traveling.
>
> Specifications:
> - SoC: Qualcomm Atheros AR9531 (650MHz)
> - RAM: 128 MB DDR2
> - Flash: 16 MB SPI NOR (W25Q128FVSG) + 128 MB SPI NAND
> (GD5F1GQ4UFYIG)
> - Ethernet: 10/100: 1xLAN
> - Wireless: QCA9531 2.4GHz (bgn) + QCA9887 5GHz (ac)
> - USB: 1x USB 2.0 port
> - Switch: 1x switch
> - Button: 1x reset button
> - OLED Screen: 128*64 px
No LEDs?
--->Yes, No LEDs
Some other comments below.
>
> Flash instruction:
> Support for sysupgrade directive upgrades, as well as luci upgrades.
>
> OLED screen control:
> OLED controller is connected to QCA9531 through serial port, and can send
> instructions to OLED controller directly through serial port.
> Refer to the links below for a list of supported instructions:
> https://github.com/gl-inet/GL-E750-MCU-instruction
>
> Signed-off-by: Luochongjun
> ---
> target/linux/ath79/dts/qca9531_glinet_gl-e750.dts | 141
> +
> .../generic/base-files/etc/board.d/02_network | 1 +
> target/linux/ath79/image/nand.mk | 15 +++
> 3 files changed, 157 insertions(+)
> create mode 100644 target/linux/ath79/dts/qca9531_glinet_gl-e750.dts
>
> diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-e750.dts
> b/target/linux/ath79/dts/qca9531_glinet_gl-e750.dts
> new file mode 100644
> index 000..645c69a
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9531_glinet_gl-e750.dts
> @@ -0,0 +1,141 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT /dts-v1/;
> +
> +#include
> +#include
> +
> +#include "qca953x.dtsi"
> +
> +/ {
> + compatible = "glinet,gl-e750", "qca,qca9531";
> + model = "GL.iNet GL-E750";
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_disable_pins>;
> +
> + reset {
> + label = "reset";
> + linux,code = ;
> + gpios = < 3 GPIO_ACTIVE_LOW>;
> + };
> +
> + switch {
> + label = "switch";
> + linux,code = ;
> + gpios = < 1 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> +gpio-export {
> +compatible = "gpio-export";
> +#size-cells = <0>;
> +
> +gpio_lte_power {
> +gpio-export,name = "lte";
I'd consider lte-power or lte_power as name here.
--->I agree. It's easier to understand
> +gpio-export,output = <1>;
> +gpios = < 0 GPIO_ACTIVE_HIGH>;
> +};
> +};
> +
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + hub_port: port@1 {
> + reg = <1>;
> + #trigger-source-cells = <0>;
> + };
> +};
> +
> +_phy {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + num-cs = <2>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <2500>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x0 0x4>;
> + read-only;
> + };
> +
> + partition@4 {
> + label = "u-boot-env";
> + reg = <0x4 0x1>;
> + };
> +
> + art: partition@5 {
> + label = "art";
> + reg = <0x5 0x1>;
> + read-only;
> + };
> +
> + partition@6 {
> + label = "kernel";
> + reg = <0x6 0x40>;
> + };
> +
> + partition@46 {
> + label = "reserved";
> + reg = <0x46 0xba>;
> + };
> +
> + };
> + };
> +
> + flash@1 {
> + compatible = "spi-nand";
> + reg = <1>;
> + spi-max-frequency = <2500>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "ubi";
> + reg = <0x0 0x800>;
> + };
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + mtd-mac-address = < 0x0>;
> + phy-handle = <>;
> +};
> +
> + {
> + status = "okay";
> + mtd-cal-data = < 0x1000>;
> + mtd-mac-address = < 0x1002>;
mtd-mac-address can be dropped here, as it will be read from this offset by
mtd-cal-data automatically.
---> Will the offset of 0x2 be automatically added?
> +};
> diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
> b/target/linux/ath79/generic/base-files/etc/board.d/02_network
> index d7f7eed..a50dfec 100755
> --- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
> +++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
> @@ -23,6 +23,7 @@ ath79_setup_interfaces()
> dlink,dir-505|\
> engenius,ecb1750|\
> glinet,gl-ar300m-lite|\
> + glinet,gl-e750|\
> netgear,ex6400|\
> netgear,ex7300|\
>
Re: [OpenWrt-Devel] [PATCH] ath79: add support for gl-e750
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Luochongjun
> Sent: Donnerstag, 7. Mai 2020 13:47
> To: openwrt-devel@lists.openwrt.org
> Cc: Luochongjun
> Subject: [OpenWrt-Devel] [PATCH] ath79: add support for gl-e750
>
> The gl-e750 is a portable travel router that gives you safe access to the
> internet while traveling.
>
> Specifications:
> - SoC: Qualcomm Atheros AR9531 (650MHz)
> - RAM: 128 MB DDR2
> - Flash: 16 MB SPI NOR (W25Q128FVSG) + 128 MB SPI NAND
> (GD5F1GQ4UFYIG)
> - Ethernet: 10/100: 1xLAN
> - Wireless: QCA9531 2.4GHz (bgn) + QCA9887 5GHz (ac)
> - USB: 1x USB 2.0 port
> - Switch: 1x switch
> - Button: 1x reset button
> - OLED Screen: 128*64 px
No LEDs?
Some other comments below.
>
> Flash instruction:
> Support for sysupgrade directive upgrades, as well as luci upgrades.
>
> OLED screen control:
> OLED controller is connected to QCA9531 through serial port, and can send
> instructions to OLED controller directly through serial port.
> Refer to the links below for a list of supported instructions:
> https://github.com/gl-inet/GL-E750-MCU-instruction
>
> Signed-off-by: Luochongjun
> ---
> target/linux/ath79/dts/qca9531_glinet_gl-e750.dts | 141
> +
> .../generic/base-files/etc/board.d/02_network | 1 +
> target/linux/ath79/image/nand.mk | 15 +++
> 3 files changed, 157 insertions(+)
> create mode 100644 target/linux/ath79/dts/qca9531_glinet_gl-e750.dts
>
> diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-e750.dts
> b/target/linux/ath79/dts/qca9531_glinet_gl-e750.dts
> new file mode 100644
> index 000..645c69a
> --- /dev/null
> +++ b/target/linux/ath79/dts/qca9531_glinet_gl-e750.dts
> @@ -0,0 +1,141 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT /dts-v1/;
> +
> +#include
> +#include
> +
> +#include "qca953x.dtsi"
> +
> +/ {
> + compatible = "glinet,gl-e750", "qca,qca9531";
> + model = "GL.iNet GL-E750";
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_disable_pins>;
> +
> + reset {
> + label = "reset";
> + linux,code = ;
> + gpios = < 3 GPIO_ACTIVE_LOW>;
> + };
> +
> + switch {
> + label = "switch";
> + linux,code = ;
> + gpios = < 1 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> +gpio-export {
> +compatible = "gpio-export";
> +#size-cells = <0>;
> +
> +gpio_lte_power {
> +gpio-export,name = "lte";
I'd consider lte-power or lte_power as name here.
> +gpio-export,output = <1>;
> +gpios = < 0 GPIO_ACTIVE_HIGH>;
> +};
> +};
> +
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + hub_port: port@1 {
> + reg = <1>;
> + #trigger-source-cells = <0>;
> + };
> +};
> +
> +_phy {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + num-cs = <2>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <2500>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x0 0x4>;
> + read-only;
> + };
> +
> + partition@4 {
> + label = "u-boot-env";
> + reg = <0x4 0x1>;
> + };
> +
> + art: partition@5 {
> + label = "art";
> + reg = <0x5 0x1>;
> + read-only;
> + };
> +
> + partition@6 {
> + label = "kernel";
> + reg = <0x6 0x40>;
> + };
> +
> + partition@46 {
> + label = "reserved";
> + reg = <0x46 0xba>;
> + };
> +
> + };
> + };
> +
> + flash@1 {
> + compatible = "spi-nand";
> + reg = <1>;
> + spi-max-frequency = <2500>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> +
Re: [OpenWrt-Devel] [PATCH] ath79: add support for gl-e750
On 07.05.20 13:46, Luochongjun wrote: The gl-e750 is a portable travel router that gives you safe access to the internet while traveling. Specifications: - SoC: Qualcomm Atheros AR9531 (650MHz) - RAM: 128 MB DDR2 - Flash: 16 MB SPI NOR (W25Q128FVSG) + 128 MB SPI NAND (GD5F1GQ4UFYIG) - Ethernet: 10/100: 1xLAN - Wireless: QCA9531 2.4GHz (bgn) + QCA9887 5GHz (ac) - USB: 1x USB 2.0 port - Switch: 1x switch - Button: 1x reset button - OLED Screen: 128*64 px Flash instruction: Support for sysupgrade directive upgrades, as well as luci upgrades. Warning: Permanently added '192.168.8.1' (RSA) to the list of known hosts. BusyBox v1.28.3 () built-in shell (ash) ___ __ | |.-.-.-.| | | |..| |_ | - || _ | -__| || | | || _|| _| |___|| __|_|__|__||||__| || |__| W I R E L E S S F R E E D O M - OpenWrt 18.06.1, r7258-5eb055306f - === WARNING! = There is no root password defined on this device! Use the "passwd" command to set up a new password in order to prevent unauthorized SSH logins. -- root@GL-E750:~# cd /tmp/ root@GL-E750:/tmp# sysupgrade -n /tmp/openwrt-ath79-nand-glinet_gl-e750-squashfs -sysupgrade.bin Device gl-e750 not supported by this image Supported devices: glinet,gl-e750 Image check 'fwtool_check_image' failed. root@GL-E750:/tmp# ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add support for gl-e750
On 07.05.20 13:46, Luochongjun wrote: The gl-e750 is a portable travel router that gives you safe access to the internet while traveling. Specifications: - SoC: Qualcomm Atheros AR9531 (650MHz) - RAM: 128 MB DDR2 - Flash: 16 MB SPI NOR (W25Q128FVSG) + 128 MB SPI NAND (GD5F1GQ4UFYIG) - Ethernet: 10/100: 1xLAN - Wireless: QCA9531 2.4GHz (bgn) + QCA9887 5GHz (ac) - USB: 1x USB 2.0 port - Switch: 1x switch - Button: 1x reset button - OLED Screen: 128*64 px - Serial: TX pin marked as UART-SOUT, located near the switch (115200 8N1, 3V3 level) - Mobile: Quectel EP06-E in mini pci-e slot, USB 2.0 connected Correct? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ath9k on Archer C7 V5 can't see packets in monitor mode - paid contract available to help resolve
Hi all, We're using Openwrt 19.07.2 on the Archer C7 V5 for a client project, and have hit an issue that's blocking our development. Given our tight timelines on this project, we'd be very open to paying someone with ath9k experience to help us resolve this on a contract basis. We're based in London, but the work could be completed entirely remotely. In summary, when putting the 2.4Ghz WiFi interface on the Archer C7 V5 in monitor mode and monitoring an active channel, we see zero Data packets captured via tcpdump. We see a few Beacons, but no Data packets. We've reproduced the issue on multiple Archer C7 V5 devices. The issue is _not_ present on the Archer C7 V5 on its 5Ghz interface - 5Ghz capture in monitor mode works fine. The issue is also not present on the Archer C7 V2 (different QCA chip), both for 2.4Ghz and 5Ghz. We are using OpenWrt 19.07.2 downloaded from the OpenWrt website, but have also tried 18.06.x. The issue is described in more detail with reproduction steps at https://bugs.openwrt.org/index.php?do=details_id=3094 Thanks, Sam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
