Re: When should gpio-restart be used/avoided?
Hi,
Yes, I can confirm, this is used to reset the modem on rebooting the device.
At least when used in conjunction with uqmi, the modem would misbehave
otherwise,
and connection attempts would fail after rebooting the device. The same
is true for its ath79-based predecessors.
I think this issue deserves investigation on its own.
Issue with this pin is that if we'd just like to reset the modem, it's
not possible without resetting the device,
as this is basically a "suicide switch" rather than just USB power cutoff.
Kind regards,
Lech
W dniu 2022-08-13 o 22:48, Robert Marko pisze:
I had just that question today when reviewing a similar ZTE modem.
It appears that its to reset the modem as well:
https://github.com/openwrt/openwrt/pull/10418/files#r945125301
Regards,
Robert
On Sat, 13 Aug 2022 at 19:13, Bjørn Mork wrote:
I just got myself a ZTE286D. But after installing OpenWrt I had an
unexpected problem on reboot. The Openwrt DTS includes a gpio-restart
device:
gpio-restart {
compatible = "gpio-restart";
gpios = < 8 GPIO_ACTIVE_HIGH>;
};
The gpio-restart driver is therefore used to reboot the system due to
default priorities.
I have two concerns about this:
1) it's different from OEM, and
2) it cuts power to the 3.3V VCC console line on reboot
A quick test indicates that reboot works just fine without using
gpio-restart in OpenWrt too. And a similar node seems to be rare in
this target. AFAICS, this is the only device having one.
So I wonder if we could/should remove that gpio-restart device. What do
you think?
The reason I ask is because the VCC toggling causes unnecessary problems
for me. I realize that I have an unusual setup, but I have connected a
bluetooth module to the console port. Toggling the console VCC on
reboot makes it hard/imposible to enter the bootloader, or to capture
the whole boot log. It takes some time before the console server
notices that the bluetooth device disappeared and tries to reconnect. I
believe this is an unwanted side effect. And it wasn't like that with
OEM.
This is of course only a minor problem. In addition to just pathcing the
DTS myself, I could also put something like
test -w /sys/bus/platform/drivers/restart-gpio/unbind && echo gpio-restart
>/sys/bus/platform/drivers/restart-gpio/unbind
into /etc/rc.local. That's a perfectly fine workaround. But I wanted
to ask becasuse of the different behaviour in OEM.
Bjørn
___
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
--
Pozdrawiam,
Lech Perczak
lech.perc...@gmail.com
Mobile: +48 694 309 185
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: When should gpio-restart be used/avoided?
I had just that question today when reviewing a similar ZTE modem.
It appears that its to reset the modem as well:
https://github.com/openwrt/openwrt/pull/10418/files#r945125301
Regards,
Robert
On Sat, 13 Aug 2022 at 19:13, Bjørn Mork wrote:
>
> I just got myself a ZTE286D. But after installing OpenWrt I had an
> unexpected problem on reboot. The Openwrt DTS includes a gpio-restart
> device:
> gpio-restart {
> compatible = "gpio-restart";
> gpios = < 8 GPIO_ACTIVE_HIGH>;
> };
>
>
> The gpio-restart driver is therefore used to reboot the system due to
> default priorities.
>
> I have two concerns about this:
>
> 1) it's different from OEM, and
> 2) it cuts power to the 3.3V VCC console line on reboot
>
> A quick test indicates that reboot works just fine without using
> gpio-restart in OpenWrt too. And a similar node seems to be rare in
> this target. AFAICS, this is the only device having one.
>
> So I wonder if we could/should remove that gpio-restart device. What do
> you think?
>
> The reason I ask is because the VCC toggling causes unnecessary problems
> for me. I realize that I have an unusual setup, but I have connected a
> bluetooth module to the console port. Toggling the console VCC on
> reboot makes it hard/imposible to enter the bootloader, or to capture
> the whole boot log. It takes some time before the console server
> notices that the bluetooth device disappeared and tries to reconnect. I
> believe this is an unwanted side effect. And it wasn't like that with
> OEM.
>
> This is of course only a minor problem. In addition to just pathcing the
> DTS myself, I could also put something like
>
> test -w /sys/bus/platform/drivers/restart-gpio/unbind && echo gpio-restart
> >/sys/bus/platform/drivers/restart-gpio/unbind
>
> into /etc/rc.local. That's a perfectly fine workaround. But I wanted
> to ask becasuse of the different behaviour in OEM.
>
>
> Bjørn
>
>
> ___
> 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
[PATCH] tplink-safeloader: add TP-Link Deco S4 v2 support
Support creating images for TP-Link Deco S4R v2.
Original partition layout from OEM image:
partition fs-uboot base 0x0 size 0x8
partition product-info base 0x8 size 0x05000
partition default-mac base 0x85000 size 0x01000
partition device-id base 0x86000 size 0x01000
partition support-list base 0x87000 size 0x1
partition user-config base 0xa7000 size 0x1
partition device-config base 0xb7000 size 0x1
partition group-info base 0xc7000 size 0x1
partition partition-table base 0xd7000 size 0x02000
partition soft-version base 0xd9000 size 0x1
partition profile base 0xe9000 size 0x1
partition default-config base 0xf9000 size 0x1
partition url-sig base 0x1e size 0x1
partition radio base 0x1f size 0x1
partition os-image base 0x20 size 0x20
partition file-system base 0x40 size 0xc0
The 'os-image' and 'file-system' partitions were merged into 'firmware'
to make use of the automatic mtd split.
Signed-off-by: Nick French
---
src/tplink-safeloader.c | 43 +
1 file changed, 43 insertions(+)
diff --git a/src/tplink-safeloader.c b/src/tplink-safeloader.c
index 7a31ac2..7f9081d 100644
--- a/src/tplink-safeloader.c
+++ b/src/tplink-safeloader.c
@@ -1577,6 +1577,49 @@ static struct device_info boards[] = {
.last_sysupgrade_partition = "file-system",
},
+ /** Firmware layout for the Deco S4 v2 */
+ {
+ .id = "DECO-S4-V2",
+ .vendor = "",
+ .support_list =
+ "SupportList:\n"
+
"{product_name:S4,product_ver:1.0.0,special_id:5553}\n"
+
"{product_name:S4,product_ver:1.0.0,special_id:4555}\n"
+
"{product_name:S4,product_ver:1.0.0,special_id:4341}\n"
+
"{product_name:S4,product_ver:1.0.0,special_id:4A50}\n"
+
"{product_name:S4,product_ver:1.0.0,special_id:4155}\n"
+
"{product_name:S4,product_ver:1.0.0,special_id:4B52}\n"
+
"{product_name:S4,product_ver:2.0.0,special_id:5553}\n"
+
"{product_name:S4,product_ver:2.0.0,special_id:4555}\n"
+
"{product_name:S4,product_ver:2.0.0,special_id:4341}\n"
+
"{product_name:S4,product_ver:2.0.0,special_id:4A50}\n"
+
"{product_name:S4,product_ver:2.0.0,special_id:4155}\n"
+
"{product_name:S4,product_ver:2.0.0,special_id:4B52}\n",
+ .part_trail = 0x00,
+ .soft_ver = SOFT_VER_DEFAULT,
+
+ .partitions = {
+ {"fs-uboot", 0x0, 0x8},
+ {"product-info", 0x8, 0x05000},
+ {"default-mac", 0x85000, 0x01000},
+ {"device-id", 0x86000, 0x01000},
+ {"support-list", 0x87000, 0x1},
+ {"user-config", 0xa7000, 0x1},
+ {"device-config", 0xb7000, 0x1},
+ {"group-info", 0xc7000, 0x1},
+ {"partition-table", 0xd7000, 0x02000},
+ {"soft-version", 0xd9000, 0x1},
+ {"profile", 0xe9000, 0x1},
+ {"default-config", 0xf9000, 0x1},
+ {"url-sig", 0x1e, 0x1},
+ {"radio", 0x1f, 0x1},
+ {"firmware", 0x20, 0xe0},
+ {NULL, 0, 0}
+ },
+ .first_sysupgrade_partition = "os-image",
+ .last_sysupgrade_partition = "file-system",
+ },
+
/** Firmware layout for the EAP120 */
{
.id = "EAP120",
--
2.37.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
When should gpio-restart be used/avoided?
I just got myself a ZTE286D. But after installing OpenWrt I had an
unexpected problem on reboot. The Openwrt DTS includes a gpio-restart
device:
gpio-restart {
compatible = "gpio-restart";
gpios = < 8 GPIO_ACTIVE_HIGH>;
};
The gpio-restart driver is therefore used to reboot the system due to
default priorities.
I have two concerns about this:
1) it's different from OEM, and
2) it cuts power to the 3.3V VCC console line on reboot
A quick test indicates that reboot works just fine without using
gpio-restart in OpenWrt too. And a similar node seems to be rare in
this target. AFAICS, this is the only device having one.
So I wonder if we could/should remove that gpio-restart device. What do
you think?
The reason I ask is because the VCC toggling causes unnecessary problems
for me. I realize that I have an unusual setup, but I have connected a
bluetooth module to the console port. Toggling the console VCC on
reboot makes it hard/imposible to enter the bootloader, or to capture
the whole boot log. It takes some time before the console server
notices that the bluetooth device disappeared and tries to reconnect. I
believe this is an unwanted side effect. And it wasn't like that with
OEM.
This is of course only a minor problem. In addition to just pathcing the
DTS myself, I could also put something like
test -w /sys/bus/platform/drivers/restart-gpio/unbind && echo gpio-restart
>/sys/bus/platform/drivers/restart-gpio/unbind
into /etc/rc.local. That's a perfectly fine workaround. But I wanted
to ask becasuse of the different behaviour in OEM.
Bjørn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Various grant programs that could help
I wanted to point out that various governments are making big internet investments and establishing grant programs. I'm not aware in any detail what is going on in europe (?), but recognition of the long term maintenance and security problems our internet has today is now at high levels, and putting a floor under the best orgs and people doing the best work (such as openwrt) has to be on at least some minds. Not only is there the huge NTIA broadband program in the USA, but for the first time the NSF has actually created a program that is oriented more to how open source engineering works, called POSE. There's a 1.5m phase two grant process closing in october, and if anyone here would like to collaborate on a proposal for POSE, doing something worthwhile, please let me know offlist. Details here: https://www.nsf.gov/pubs/2022/nsf22062/nsf22062.jsp Less arduous than the NSF... ARDC is doing a great job of finding things worth doing in the wireless world. Recently they funded some of the LibreRouter project. see https://grants.ardc.net And read more about it here: https://www.ampr.org/new-grants-management-system-to-make-applying-for-and-tracking-grants-easier/ nlnet has always been a great source of small grants: https://nlnet.nl/project/current.html - they funded, in small part, my efforts on this openwrt release (although I was supposed to be working on something else!) https://nlnet.nl/project/current.html the comcast innovation fund is out of money for the year... :( On Sat, Aug 13, 2022 at 6:13 AM Robert Marko wrote: > > On Fri, 12 Aug 2022 at 23:12, Florian Fainelli wrote: > > > > On 8/12/22 13:28, Robert Marko wrote: > > > On Fri, 12 Aug 2022 at 21:45, Florian Fainelli > > > wrote: > > >> > > >> On 8/12/22 11:09, Robert Marko wrote: > > >>> On Fri, 12 Aug 2022 at 19:54, Florian Fainelli > > >>> wrote: > > > > On 8/10/22 13:32, Robert Marko wrote: > > > On Wed, 10 Aug 2022 at 22:30, Philip Prindeville > > > wrote: > > >> > > >> Not to play the devil's advocate but... do we want old kernels > > >> hanging out that long? > > >> > > >> Besides not encouraging people to update to new releases that > > >> mitigate discovered CVE's, we'd also not pick up David Taht's > > >> excellent improvements in Buffer Bloat. > > > > > > I have to agree with this. > > > What would be the benefit for OpenWrt with having LTS kernels > > > supported for 6 years? > > > > One aspect I could see is take for instance a device that is widely > > popular amongst our user base as was TI's ar7 for instance a while > > back, > > and for which we might have done a Linux 5.4, or 5.10 version at the > > time but we do not wish to continue to maintain. > > >>> > > >>> I dont see how this is related to LTS kernel support. > > >> > > >> OK maybe I need to spell out my example more clearly. Let us say that we > > >> have a release in 2019 of OpenWrt that supported TI AR7 based upon the > > >> Linux 5.4 kernel. > > >> > > >> Fast forward to 2022, we decide to abandon TI AR7 in master and we stop > > >> supporting it entirely for future releases. A very bad Linux security > > >> problem show up, and because we care about our users, we keep updating > > >> the LTS kernel that was used in the 2019.x release up until, say the > > >> said kernel stops being supported. If that support time frame was 6 > > >> years, then we would really be helping our users. > > >> > > >> Maybe the wider discussion to be had, is: > > >> > > >> - when and how do we decide to deprecate a given Linux port, I assume it > > >> is when no more users show up or maybe more realistically when OpenWrt > > >> developers just cannot keep up with updating those devices because they > > >> no longer use those themselves > > >> > > >> - how long do we want to keep supporting past OpenWrt releases with > > >> kernel updates, 2 years, 3/4 years, 6 years to match the kernel > > >> lifecycle they are based upon? > > > > > > As an idea, I understand this, it would basically be an "LTS" OpenWrt > > > release that > > > would receive security-only updates. > > > > > > However, we had a long discussion on the IRC today and the resources are > > > spread > > > rather thin even currently with 2 or 3 releases being supported. > > > > > > If its gonna be a volunteer kind of no guarantees release, then maybe > > > but I dont see > > > how we can manage that as well. > > > > That is fair, if we are spread too thin, and clearly we are, then yes, I > > agree we should focus on the latest releases and people who cannot > > update for whatever reason, be it now unsupported hardware, or high > > availability or whatever should find out a solution. It's open source > > after all :) > > > > > > >> > > >> > > >>> > > > > Being able to continue to deliver stable kernel updates in a stable > > OpenWrt branch could be a good way for users to pick up their next xDSL > >
Re: [PATCH] netifd: fix WPA3 enterprise ciphers
On 6/26/22 17:21, Joerg Werner wrote:
WPA3 enterprise requires wpa_cipher to be GCMP-256, so if the user set
encryption to wpa3 or wpa3-mixed, then add GCMP-256. Also allow explicit
selection of GCMP-256 by adding gcmp256 at the end of the encryption
value.
This code from hostapd looks like the driver has to support CCMP_256 or
GCMP_256 to allow operation with SUITE_B_192:
if (drv->capa.enc & (WPA_DRIVER_CAPA_ENC_CCMP_256 |
WPA_DRIVER_CAPA_ENC_GCMP_256))
drv->capa.key_mgmt |=
WPA_DRIVER_CAPA_KEY_MGMT_SUITE_B_192;
https://w1.fi/cgit/hostap/tree/src/drivers/driver_nl80211_capa.c#n1361
Signed-off-by: Joerg Werner
---
scripts/netifd-wireless.sh | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/scripts/netifd-wireless.sh b/scripts/netifd-wireless.sh
index 0e3293c..435a707 100644
--- a/scripts/netifd-wireless.sh
+++ b/scripts/netifd-wireless.sh
@@ -221,6 +221,7 @@ wireless_vif_parse_encryption() {
*aes|*ccmp) wpa_cipher="CCMP";;
*tkip) wpa_cipher="TKIP";;
*gcmp) wpa_cipher="GCMP";;
+ *gcmp256) wpa_cipher="GCMP-256";;
esac
# 802.11n requires CCMP for WPA
@@ -246,7 +247,6 @@ wireless_vif_parse_encryption() {
wpa_cipher=
;;
esac
- wpa_pairwise="$wpa_cipher"
case "$encryption" in
owe*)
@@ -254,9 +254,11 @@ wireless_vif_parse_encryption() {
;;
wpa3-mixed*)
auth_type=eap-eap192
+ wpa_cipher="${wpa_cipher} GCMP-256"
;;
wpa3*)
auth_type=eap192
+ wpa_cipher="GCMP-256"
Instead of setting it here I would prefer if wpa_cipher gets set to the
wpa3 default earlier and can be overwritten if really wanted.
I would prefer if you set it close to here the initial value is set
depending on hwmode and someone could overwrite it with encryption setting.
;;
psk3-mixed*|sae-mixed*)
auth_type=psk-sae
@@ -283,6 +285,7 @@ wireless_vif_parse_encryption() {
esac
;;
esac
+ wpa_pairwise="$wpa_cipher"
case "$encryption" in
*osen*)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCHv2] ramips: add support for Notion R281
On 7/27/22 05:17, Ian Pangilinan wrote: From: Ian Pangilinan Date: Sun, 27 July 2022 10:55:00 +0800 Subject: [PATCHv2] ramips: add support for Notion R281 Notion R281 is a Cat.6 LTE CPE. It is known as Boosteven R281 in some markets. Product link: https://www.notioni.com/productinfo/759146.html Hardware highlights: - CPU: MT7621A 2C4T @ 880MHz - RAM: DDR3 128MB @ 1066MHz - FLASH: S34ML01G2 128MB SPI NAND - WLAN0: MT7603E 2.4GHz 802.11bgn 2x2:2 @ 300Mbps - WLAN1: MT7613BE 5GHz 802.11nac 2x2:2 @ 867Mbps - SWITCH: MT7530 4-port GbE - WWAN: Marvell PXA1826 (Nezha3) Profile M26H Board Cat.6 LTE - SIM: 1x Mini-SIM 2FF - USB: 1x USB 2.0 Micro Type-B - BUTTONS: WPS, Reset - LEDS: Power, Data, Wi-Fi, LAN, Signal1-3 - POWER: 12VDc 2A The device comes in two configurations. In one configuration the bootloader loads the kernel at 0xbc14 (mtd4) and another at 0xbe80 (mtd5). This patch is for the former. To check, gain root shell and run 'cat /proc/cmdline', look for 'root='. If 'root=/dev/mtdblock5' then it is already configured as intended. If not, then run fw_setenv bootargs console=ttyS1,57600n8 root=/dev/mtdblock5 in the terminal, or run setenv bootargs console=ttyS1,57600n8 root=/dev/mtdblock5 in U-boot. Reboot then follow the installation instructions below. This is the flash layout for the mtd4 configuration: 0x-0x07f8 : "ALL" 0x-0x0008 : "Bootloader" 0x0008-0x0010 : "Config" 0x0010-0x0014 : "Factory" 0x0014-0x0280 : "firmware1" 0x002d6867-0x0280 : "rootfs" 0x00b0-0x0280 : "rootfs_data" 0x0280-0x04ec : "firmware2" 0x04ec-0x07f0 : "ota" 0x07f0-0x07f8 : "Configbak" This is the flash layout for the mtd5 configuration: 0x-0x07f8 : "ALL" 0x-0x0008 : "Bootloader" 0x0008-0x0010 : "Config" 0x0010-0x0014 : "Factory" 0x0014-0x0280 : "firmware1" 0x0280-0x04ec : "firmware2" 0x02996dfc-0x04ec : "rootfs" 0x0318-0x04ec : "rootfs_data" 0x04ec-0x07f0 : "ota" 0x07f0-0x07f8 : "Configbak" This is how it looks when flashed to OpenWrt with this patch: 0x-0x0008 : "u-boot" 0x0008-0x000a : "u-boot-env" 0x0010-0x0014 : "factory" 0x0014-0x0054 : "kernel" 0x0054-0x07f0 : "ubi" 0x07f0-0x07f8 : "configbak" Installation Instructions: Stock firmware runs an old OpenWrt Chaos Calmer release. Unfortunately, because of the changes in the flash layout, this cannot be sysupgrade-d readily from stock. Installation will be via tftpboot in the bootloader. Connect the USB-TTL serial converter as follows, indicated on the board by the APTX marking near three round PCB pads: (GND) (RX) (TX) APTX Baud rate is 57600. 1. Connect the computer to the device via ethernet cable. Set a static adddress of 10.10.10.3/24 to the wired interface. 2. Start the TFTP server, point it to where the initramfs image is located. Rename the image to 'test.bin'. 3. Turn on the device. There will be a three-second delay before the default 'Boot system code via flash' is selected. 4. Interrupt the boot process by pressing 1 to 'System Load Linux to SDRAM via TFTP'. 5. Press enter to accept the default 'Input device IP (10.10.10.123)'. 6. Press enter to accept the default 'Input server IP (10.10.10.3)'. 7. Press enter to accept the default 'Input Linux Kernel filename ()', or enter 'test.bin'. 8. Wait for the initramfs image to finish loading. 9. Reconnect the wired interface to any LAN ports of the device via DHCP. 9. Flash the sysupgrade image at http://192.168.1.1/cgi-bin/luci/admin/system/flash What Works? - LEDs - Buttons - Wired LAN and WAN - Wireless LAN What Doesn't? - Wireless WAN The only configurable LEDs are the red and white data, and white Wi-Fi LEDs. I use the red data LED as status indicator for OpenWrt. The white LAN LED is controlled by the switch and functions as expected, as well as the three green signal LED indicators controlled by the WWAN. I setup the WPS button to work as a Wi-Fi/rfkill button. There is also an exported GPIO to reset the WWAN. These are the same LEDs and GPIO found on the stock firmware. Support for WWAN could come at a later date. I have setup LAN1 of the device as WAN. Signed-off-by: Ian Pangilinan --- package/boot/uboot-envtools/files/ramips | 1 + .../linux/ramips/dts/mt7621_notion_r281.dts (new) | 203 + target/linux/ramips/image/mt7621.mk| 15 +++ .../mt7621/base-files/etc/board.d/02_network | 3 ++ .../mt7621/base-files/lib/upgrade/platform.sh | 1 + 5 files changed, 223 insertions(+), 0 deletion(-) create mode 100644
Re: Reaching out to Greg KH for 6 year LTS kernel versions
On Fri, 12 Aug 2022 at 23:12, Florian Fainelli wrote: > > On 8/12/22 13:28, Robert Marko wrote: > > On Fri, 12 Aug 2022 at 21:45, Florian Fainelli wrote: > >> > >> On 8/12/22 11:09, Robert Marko wrote: > >>> On Fri, 12 Aug 2022 at 19:54, Florian Fainelli > >>> wrote: > > On 8/10/22 13:32, Robert Marko wrote: > > On Wed, 10 Aug 2022 at 22:30, Philip Prindeville > > wrote: > >> > >> Not to play the devil's advocate but... do we want old kernels hanging > >> out that long? > >> > >> Besides not encouraging people to update to new releases that mitigate > >> discovered CVE's, we'd also not pick up David Taht's excellent > >> improvements in Buffer Bloat. > > > > I have to agree with this. > > What would be the benefit for OpenWrt with having LTS kernels > > supported for 6 years? > > One aspect I could see is take for instance a device that is widely > popular amongst our user base as was TI's ar7 for instance a while back, > and for which we might have done a Linux 5.4, or 5.10 version at the > time but we do not wish to continue to maintain. > >>> > >>> I dont see how this is related to LTS kernel support. > >> > >> OK maybe I need to spell out my example more clearly. Let us say that we > >> have a release in 2019 of OpenWrt that supported TI AR7 based upon the > >> Linux 5.4 kernel. > >> > >> Fast forward to 2022, we decide to abandon TI AR7 in master and we stop > >> supporting it entirely for future releases. A very bad Linux security > >> problem show up, and because we care about our users, we keep updating > >> the LTS kernel that was used in the 2019.x release up until, say the > >> said kernel stops being supported. If that support time frame was 6 > >> years, then we would really be helping our users. > >> > >> Maybe the wider discussion to be had, is: > >> > >> - when and how do we decide to deprecate a given Linux port, I assume it > >> is when no more users show up or maybe more realistically when OpenWrt > >> developers just cannot keep up with updating those devices because they > >> no longer use those themselves > >> > >> - how long do we want to keep supporting past OpenWrt releases with > >> kernel updates, 2 years, 3/4 years, 6 years to match the kernel > >> lifecycle they are based upon? > > > > As an idea, I understand this, it would basically be an "LTS" OpenWrt > > release that > > would receive security-only updates. > > > > However, we had a long discussion on the IRC today and the resources are > > spread > > rather thin even currently with 2 or 3 releases being supported. > > > > If its gonna be a volunteer kind of no guarantees release, then maybe > > but I dont see > > how we can manage that as well. > > That is fair, if we are spread too thin, and clearly we are, then yes, I > agree we should focus on the latest releases and people who cannot > update for whatever reason, be it now unsupported hardware, or high > availability or whatever should find out a solution. It's open source > after all :) > > > >> > >> > >>> > > Being able to continue to deliver stable kernel updates in a stable > OpenWrt branch could be a good way for users to pick up their next xDSL > router since there are not so many out there that can actually run > OpenWrt compared to pure Wired/Wi-Fi for instance. > >>> > >>> I can agree with this. > >>> > > > Backporting stuff is already hard with only 2 LTS versions supported in > > OpenWrt. > > That argument I am sympathetic with, and the sheer amount of out of tree > patches we have in OpenWrt is not helping, in fact it definitively makes > it harder to regularly test, but still somehow we managed to do it. > > Since we will merge stable updates eventually, the point would be that > instead of testing those that are already released, we could try to test > the release candidates and report back anything we find? > >>> > >>> This is a good idea, not sure how we can do it within OpenWrt though with > >>> the amount of patches we have that make it a pain to bump kernels. > >> > >> Maybe we should give it a spin and see how painful that actually is and > >> then if we can sustain doing that over time it just becomes a thing a > >> group of volunteers can do? > >> > >> After all, we do go through that exercise fairly frequently. > > > > This looks similar to what we discussed to today on IRC, maybe having a more > > up-to-date development OpenWrt along longer lasting stable releases. > > > > As currently, OpenWrt is way out of date for kernel development but is > > moving > > too quickly for keeping the stable releases from regressing. > > Which is an interesting paradox. Agreed, however that is the conclusion we reached on the IRC after a long discussion. Its a compromise that makes both sides equally unhappy. Regards, Robert > -- > Florian
Re: Reaching out to Greg KH for 6 year LTS kernel versions
> On Aug 12, 2022, at 5:12 PM, Florian Fainelli wrote: > >> As an idea, I understand this, it would basically be an "LTS" OpenWrt >> release that >> would receive security-only updates. >> However, we had a long discussion on the IRC today and the resources are >> spread >> rather thin even currently with 2 or 3 releases being supported. >> If its gonna be a volunteer kind of no guarantees release, then maybe >> but I dont see >> how we can manage that as well. > > That is fair, if we are spread too thin, and clearly we are, then yes, I > agree we should focus on the latest releases and people who cannot update for > whatever reason, be it now unsupported hardware, or high availability or > whatever should find out a solution. It's open source after all :) I've been lurking in this discussion, but thought I would throw in this perspective: Who is asking for this? Could we ask them to quantify the benefit (to them) of a six-year LTS? Would they be willing to fund the effort required? (Some companies decide that Red Hat or Ubuntu are critical to their business, and hire people/assign developers to work to support those distributions...) Thanks for listening. Rich (Sorry for any duplicates - original message was in Rich Text...) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
