Re: OpenWrt 21.02 status
On 9/1/21 4:15 AM, Andy Botting wrote: On Wed, 1 Sept 2021 at 11:56, Alexander E. Patrakov wrote: Hauke Mehrtens : On 8/31/21 1:52 PM, Alexander E. Patrakov wrote: Hauke Mehrtens wrote: We did the 21.02-rc4, but there is still a problem with flow offloading as this was not fixed. The other problems should be fixed now. ... Some more information can be found here: https://forum.openwrt.org/t/software-flow-offloading-and-conntrack-timeouts/74588 https://bugs.openwrt.org/index.php?do=details_id=3373 https://bugs.openwrt.org/index.php?do=details_id=3759 It could be that this change causes the problems: https://patchwork.ozlabs.org/project/netdev/patch/20180720130906.27687-3-pa...@netfilter.org/ I do not know how much time and interest I have in debugging and fixing this problem. If someone wants to have a closer look into this problem it would be really nice. even when you can make it easier to reproduce it in a test environment it would be nice. There is no need to debug this problem. Just revert the patch, because the upstream kernel history looks like this: Jun 15, 2018, e97d940: flow offload pickup timeouts were changed to hard-coded values, 120 seconds for TCP and 30 seconds for UDP, because the author had a concern with the "established" timeout to be too huge for this purpose. Jun 3, 2021, 1d91d2e: sysctls are introduced so that the timeouts for picking up offloaded flows are configurable, because they were too low for some use cases. Aug 4, 2021, 4592ee7: the timeouts were bumped again to their old "established" values, sysctls are removed, the motivation is, essentially, that the pickup timeouts were effectively acting like the new version of established timeouts. I.e., the patch was effectively reverted upstream. I'd be happy to try it soon if you could point me to the specific commit. I can reproduce the issue quite easily here. Thanks! Hi, The commits are in the mail. You could try to revert this one: https://git.kernel.org/linus/e97d9404d5e8aea1f91f4c00dbe7854008f3a1e1 in Linux 5.15 it will be more or less reverted again. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
Hey Hauke. On 31/08/2021 00:51, Hauke Mehrtens wrote: All people who answered agreed to do the release soon and keep this as a known bug. I plan to tag 21.02.0 on Wednesday, 1. September if no one objects. I have a detailed mail to send about the situation with DSA. It's about documentation and inaccurate definitions on UCI. It could appear at later 21.02 releases so I don't object. Good luck! Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
On Wed, 1 Sept 2021 at 11:56, Alexander E. Patrakov wrote: > > Hauke Mehrtens : > > > > > On 8/31/21 1:52 PM, Alexander E. Patrakov wrote: > > > Hauke Mehrtens wrote: > > > > > >> We did the 21.02-rc4, but there is still a problem with flow offloading > > >> as this was not fixed. The other problems should be fixed now. > > > > > >> ... > > > > > >> Some more information can be found here: > > >> https://forum.openwrt.org/t/software-flow-offloading-and-conntrack-timeouts/74588 > > >> https://bugs.openwrt.org/index.php?do=details_id=3373 > > >> https://bugs.openwrt.org/index.php?do=details_id=3759 > > > > > >> It could be that this change causes the problems: > > >> https://patchwork.ozlabs.org/project/netdev/patch/20180720130906.27687-3-pa...@netfilter.org/ > > > > > >> I do not know how much time and interest I have in debugging and fixing > > >> this problem. If someone wants to have a closer look into this problem > > >> it would be really nice. even when you can make it easier to reproduce > > >> it in a test environment it would be nice. > > > > > > There is no need to debug this problem. Just revert the patch, because > > > the upstream kernel history looks like this: > > > > > > Jun 15, 2018, e97d940: flow offload pickup timeouts were changed to > > > hard-coded values, 120 seconds for TCP and 30 seconds for UDP, because > > > the author had a concern with the "established" timeout to be too huge > > > for this purpose. > > > Jun 3, 2021, 1d91d2e: sysctls are introduced so that the timeouts for > > > picking up offloaded flows are configurable, because they were too low > > > for some use cases. > > > Aug 4, 2021, 4592ee7: the timeouts were bumped again to their old > > > "established" values, sysctls are removed, the motivation is, > > > essentially, that the pickup timeouts were effectively acting like the > > > new version of established timeouts. > > > > > > I.e., the patch was effectively reverted upstream. > > > I'd be happy to try it soon if you could point me to the specific commit. I can reproduce the issue quite easily here. Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
Hauke Mehrtens : > > On 8/31/21 1:52 PM, Alexander E. Patrakov wrote: > > Hauke Mehrtens wrote: > > > >> We did the 21.02-rc4, but there is still a problem with flow offloading > >> as this was not fixed. The other problems should be fixed now. > > > >> ... > > > >> Some more information can be found here: > >> https://forum.openwrt.org/t/software-flow-offloading-and-conntrack-timeouts/74588 > >> https://bugs.openwrt.org/index.php?do=details_id=3373 > >> https://bugs.openwrt.org/index.php?do=details_id=3759 > > > >> It could be that this change causes the problems: > >> https://patchwork.ozlabs.org/project/netdev/patch/20180720130906.27687-3-pa...@netfilter.org/ > > > >> I do not know how much time and interest I have in debugging and fixing > >> this problem. If someone wants to have a closer look into this problem > >> it would be really nice. even when you can make it easier to reproduce > >> it in a test environment it would be nice. > > > > There is no need to debug this problem. Just revert the patch, because > > the upstream kernel history looks like this: > > > > Jun 15, 2018, e97d940: flow offload pickup timeouts were changed to > > hard-coded values, 120 seconds for TCP and 30 seconds for UDP, because > > the author had a concern with the "established" timeout to be too huge > > for this purpose. > > Jun 3, 2021, 1d91d2e: sysctls are introduced so that the timeouts for > > picking up offloaded flows are configurable, because they were too low > > for some use cases. > > Aug 4, 2021, 4592ee7: the timeouts were bumped again to their old > > "established" values, sysctls are removed, the motivation is, > > essentially, that the pickup timeouts were effectively acting like the > > new version of established timeouts. > > > > I.e., the patch was effectively reverted upstream. > > > > Thanks for looking into this problem. > > I would prefer to not delay the release any further and will take care > of this after the release. Did you test this and see improvements in > your scenarios? > > Hauke Not yet, and can't until I return home. No objections to making this a .1 material. -- Alexander E. Patrakov CV: http://u.pc.cd/wT8otalK ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
On 8/31/21 1:52 PM, Alexander E. Patrakov wrote: Hauke Mehrtens wrote: We did the 21.02-rc4, but there is still a problem with flow offloading as this was not fixed. The other problems should be fixed now. ... Some more information can be found here: https://forum.openwrt.org/t/software-flow-offloading-and-conntrack-timeouts/74588 https://bugs.openwrt.org/index.php?do=details_id=3373 https://bugs.openwrt.org/index.php?do=details_id=3759 It could be that this change causes the problems: https://patchwork.ozlabs.org/project/netdev/patch/20180720130906.27687-3-pa...@netfilter.org/ I do not know how much time and interest I have in debugging and fixing this problem. If someone wants to have a closer look into this problem it would be really nice. even when you can make it easier to reproduce it in a test environment it would be nice. There is no need to debug this problem. Just revert the patch, because the upstream kernel history looks like this: Jun 15, 2018, e97d940: flow offload pickup timeouts were changed to hard-coded values, 120 seconds for TCP and 30 seconds for UDP, because the author had a concern with the "established" timeout to be too huge for this purpose. Jun 3, 2021, 1d91d2e: sysctls are introduced so that the timeouts for picking up offloaded flows are configurable, because they were too low for some use cases. Aug 4, 2021, 4592ee7: the timeouts were bumped again to their old "established" values, sysctls are removed, the motivation is, essentially, that the pickup timeouts were effectively acting like the new version of established timeouts. I.e., the patch was effectively reverted upstream. Thanks for looking into this problem. I would prefer to not delay the release any further and will take care of this after the release. Did you test this and see improvements in your scenarios? Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
Hauke Mehrtens wrote: > We did the 21.02-rc4, but there is still a problem with flow offloading > as this was not fixed. The other problems should be fixed now. > ... > Some more information can be found here: > https://forum.openwrt.org/t/software-flow-offloading-and-conntrack-timeouts/74588 > https://bugs.openwrt.org/index.php?do=details_id=3373 > https://bugs.openwrt.org/index.php?do=details_id=3759 > It could be that this change causes the problems: > https://patchwork.ozlabs.org/project/netdev/patch/20180720130906.27687-3-pa...@netfilter.org/ > I do not know how much time and interest I have in debugging and fixing > this problem. If someone wants to have a closer look into this problem > it would be really nice. even when you can make it easier to reproduce > it in a test environment it would be nice. There is no need to debug this problem. Just revert the patch, because the upstream kernel history looks like this: Jun 15, 2018, e97d940: flow offload pickup timeouts were changed to hard-coded values, 120 seconds for TCP and 30 seconds for UDP, because the author had a concern with the "established" timeout to be too huge for this purpose. Jun 3, 2021, 1d91d2e: sysctls are introduced so that the timeouts for picking up offloaded flows are configurable, because they were too low for some use cases. Aug 4, 2021, 4592ee7: the timeouts were bumped again to their old "established" values, sysctls are removed, the motivation is, essentially, that the pickup timeouts were effectively acting like the new version of established timeouts. I.e., the patch was effectively reverted upstream. -- Alexander E. Patrakov CV: http://u.pc.cd/wT8otalK ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
On 8/29/21 11:53 AM, Hauke Mehrtens wrote: Hi, We did the 21.02-rc4, but there is still a problem with flow offloading as this was not fixed. The other problems should be fixed now. On 7/17/21 5:45 PM, Hauke Mehrtens wrote: Currently we still have these problem: - IPv6 broken with flow offloading (according to reports, potentially related to hw flow offloading) - PPPoE allegedly broken (according to reports, not fully reproducible, likely related to hw flow offloading too) - https://bugs.openwrt.org/index.php?do=details_id=3909 - https://bugs.openwrt.org/index.php?do=details_id=3835 Some more information can be found here: https://forum.openwrt.org/t/software-flow-offloading-and-conntrack-timeouts/74588 https://bugs.openwrt.org/index.php?do=details_id=3373 https://bugs.openwrt.org/index.php?do=details_id=3759 It could be that this change causes the problems: https://patchwork.ozlabs.org/project/netdev/patch/20180720130906.27687-3-pa...@netfilter.org/ I do not know how much time and interest I have in debugging and fixing this problem. If someone wants to have a closer look into this problem it would be really nice. even when you can make it easier to reproduce it in a test environment it would be nice. Should we just release with this as a known problem? Other than this problem I am not aware of any other critical problem. Hauke Hi all, All people who answered agreed to do the release soon and keep this as a known bug. I plan to tag 21.02.0 on Wednesday, 1. September if no one objects. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
+1 for release. It's just been too long since the last one. The idea of time-based releases is getting lost and this is a process issue we definitely should address. On Sun, 29 Aug 2021 at 11:44, Hannu Nyman wrote: > > Hauke Mehrtens wrote at Sun Aug 29 02:53:47 PDT 2021: > > > Should we just release with this as a known problem? > > > > Other than this problem I am not aware of any other critical problem. > > We should. > > It is annoying that 21.02 was branched more than 6 months ago, but no final > release has happened by now. Due to the prolonged release process lots of > "new" stuff has already been backported (unlike originally intended) causing > potential new problems, and that will accumulate more the further we wait for > the final release. > > As we depend to a large part also on upstream developments (on kernel and > packages), we will never get perfect releases. > > The 21.02 release is also keeping the kernel 5.10 bump for many targets > hostage (which is then preventing DSA bump, e.g. ipq806x), so that we can > keep testing 5.4 in master for the benefit of 21.02. > (reference to the kernel list at > https://lists.openwrt.org/pipermail/openwrt-devel/2021-August/036159.html > > Looking back at the history, this 21.02 starts to be the longest period > between major releases (especially if we calculate 15.05.1 as a major > release). > > Lets get this 20.01, 20.07, 20.12, 21.02 finally out before it turns to be > 22.xx in practice... > > I think that the original (LEDE) release process goal was relatively > frequently branched releases and then doing the final releases quickly after > branching. We have now reverted back to the old "let's wait long for > branching and then wait even longer for the actual release". > > The reality is the same than earlier: almost all devs and enthusiasts are > already with master where interesting new stuff happens, so 21.02 rots > quietly waiting for the release. The prolonged wait serves nobody :-( > > > > ___ > 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 21.02 status
On Aug 29, 2021, at 6:31 AM, Hannu Nyman wrote: > > Hauke Mehrtens wrote at Sun Aug 29 02:53:47 PDT 2021: > > We have now reverted back to the old "let's wait long for branching and then > wait even longer for the actual release". > > The reality is the same than earlier: almost all devs and enthusiasts are > already with master where interesting new stuff happens, so 21.02 rots > quietly waiting for the release. The prolonged wait serves nobody :-( I agree that we should release 21.02.0 in its current state. We can then plan for a (relatively quick) 21.02.1 that addresses known issues and/or recently-discovered problems. Do we need a formal Call for Vote on this? If so, I offer this wording: --- We should release OpenWrt 21.02.0 in the current state (I need help specifying the exact commit to use). It has one known problem: hardware flow offloading may not work in certain cases. Disabling flow offloading provides a working device, possibly with decreased performance. --- Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
Hi Hauke Op zondag 29 augustus 2021 om 11u53 schreef Hauke Mehrtens : Hi, We did the 21.02-rc4, but there is still a problem with flow offloading as this was not fixed. The other problems should be fixed now. On 7/17/21 5:45 PM, Hauke Mehrtens wrote: Currently we still have these problem: - IPv6 broken with flow offloading (according to reports, potentially related to hw flow offloading) - PPPoE allegedly broken (according to reports, not fully reproducible, likely related to hw flow offloading too) - https://bugs.openwrt.org/index.php?do=details_id=3909 - https://bugs.openwrt.org/index.php?do=details_id=3835 I'd like to add that disabling IPv6 with PPP on 21.02 will not fully disable IPv6 as per jow's tip here [1], would be neat if that could be fixed (and backported to a .1, this is not a showstopper for 21.02 final in any way). Just wanted to put it on the radar. An unintentional side effect with a local ISP here is that it breaks IPv4 a well. Cheers Stijn [1] https://forum.openwrt.org/t/21-02-snapshot-ipv4-pppoe-session-keeps-terminating/90552/4 Some more information can be found here: https://forum.openwrt.org/t/software-flow-offloading-and-conntrack-timeouts/74588 https://bugs.openwrt.org/index.php?do=details_id=3373 https://bugs.openwrt.org/index.php?do=details_id=3759 It could be that this change causes the problems: https://patchwork.ozlabs.org/project/netdev/patch/20180720130906.27687-3-pa...@netfilter.org/ I do not know how much time and interest I have in debugging and fixing this problem. If someone wants to have a closer look into this problem it would be really nice. even when you can make it easier to reproduce it in a test environment it would be nice. Should we just release with this as a known problem? Other than this problem I am not aware of any other critical problem. Hauke ___ 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 21.02 status
+1 for finally releasing. Our wireless mesh community is testing OpenWrt 21.02-snapshot now for months. Only some trouble with ipq40xx soc, but we have workarounds for it. On 8/29/21 12:53 PM, Adrian Schmutzler wrote: Hi, -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Hauke Mehrtens Sent: Sonntag, 29. August 2021 11:54 To: OpenWrt Development List Cc: John Crispin; Jo-Philipp Wich; Kevin 'ldir' Darbyshire-Bryant Subject: Re: OpenWrt 21.02 status Hi, We did the 21.02-rc4, but there is still a problem with flow offloading as this was not fixed. The other problems should be fixed now. On 7/17/21 5:45 PM, Hauke Mehrtens wrote: Currently we still have these problem: - IPv6 broken with flow offloading (according to reports, potentially related to hw flow offloading) - PPPoE allegedly broken (according to reports, not fully reproducible, likely related to hw flow offloading too) - https://bugs.openwrt.org/index.php?do=details_id=3909 - https://bugs.openwrt.org/index.php?do=details_id=3835 Some more information can be found here: https://forum.openwrt.org/t/software-flow-offloading-and-conntrack- timeouts/74588 https://bugs.openwrt.org/index.php?do=details_id=3373 https://bugs.openwrt.org/index.php?do=details_id=3759 It could be that this change causes the problems: https://patchwork.ozlabs.org/project/netdev/patch/20180720130906.27687- 3-pa...@netfilter.org/ I do not know how much time and interest I have in debugging and fixing this problem. If someone wants to have a closer look into this problem it would be really nice. even when you can make it easier to reproduce it in a test environment it would be nice. Should we just release with this as a known problem? Although my opinion should not be given much weight in this context, I'd also prefer a "quick" release, for about the same reasons as Hannu has given in his e-mail. As I understand it, disabling offloading will give you a working device, so it's fair enough. Best Adrian Other than this problem I am not aware of any other critical problem. Hauke ___ 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 21.02 status
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Hauke Mehrtens > Sent: Sonntag, 29. August 2021 11:54 > To: OpenWrt Development List > Cc: John Crispin; Jo-Philipp Wich; Kevin 'ldir' Darbyshire-Bryant > Subject: Re: OpenWrt 21.02 status > > Hi, > > We did the 21.02-rc4, but there is still a problem with flow offloading as > this > was not fixed. The other problems should be fixed now. > > On 7/17/21 5:45 PM, Hauke Mehrtens wrote: > > Currently we still have these problem: > > > > - IPv6 broken with flow offloading (according to reports, potentially > > related to hw flow offloading) > > - PPPoE allegedly broken (according to reports, not fully > > reproducible, likely related to hw flow offloading too) > >- https://bugs.openwrt.org/index.php?do=details_id=3909 > >- https://bugs.openwrt.org/index.php?do=details_id=3835 > > > Some more information can be found here: > https://forum.openwrt.org/t/software-flow-offloading-and-conntrack- > timeouts/74588 > https://bugs.openwrt.org/index.php?do=details_id=3373 > https://bugs.openwrt.org/index.php?do=details_id=3759 > > It could be that this change causes the problems: > https://patchwork.ozlabs.org/project/netdev/patch/20180720130906.27687- > 3-pa...@netfilter.org/ > > I do not know how much time and interest I have in debugging and fixing this > problem. If someone wants to have a closer look into this problem it would > be really nice. even when you can make it easier to reproduce it in a test > environment it would be nice. > > Should we just release with this as a known problem? Although my opinion should not be given much weight in this context, I'd also prefer a "quick" release, for about the same reasons as Hannu has given in his e-mail. As I understand it, disabling offloading will give you a working device, so it's fair enough. Best Adrian > > Other than this problem I am not aware of any other critical problem. > > Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
Hauke Mehrtens wrote at Sun Aug 29 02:53:47 PDT 2021: > Should we just release with this as a known problem? > > Other than this problem I am not aware of any other critical problem. We should. It is annoying that 21.02 was branched more than 6 months ago, but no final release has happened by now. Due to the prolonged release process lots of "new" stuff has already been backported (unlike originally intended) causing potential new problems, and that will accumulate more the further we wait for the final release. As we depend to a large part also on upstream developments (on kernel and packages), we will never get perfect releases. The 21.02 release is also keeping the kernel 5.10 bump for many targets hostage (which is then preventing DSA bump, e.g. ipq806x), so that we can keep testing 5.4 in master for the benefit of 21.02. (reference to the kernel list at https://lists.openwrt.org/pipermail/openwrt-devel/2021-August/036159.html Looking back at the history, this 21.02 starts to be the longest period between major releases (especially if we calculate 15.05.1 as a major release). Lets get this 20.01, 20.07, 20.12, 21.02 finally out before it turns to be 22.xx in practice... I think that the original (LEDE) release process goal was relatively frequently branched releases and then doing the final releases quickly after branching. We have now reverted back to the old "let's wait long for branching and then wait even longer for the actual release". The reality is the same than earlier: almost all devs and enthusiasts are already with master where interesting new stuff happens, so 21.02 rots quietly waiting for the release. The prolonged wait serves nobody :-( ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
Hi, We did the 21.02-rc4, but there is still a problem with flow offloading as this was not fixed. The other problems should be fixed now. On 7/17/21 5:45 PM, Hauke Mehrtens wrote: Currently we still have these problem: - IPv6 broken with flow offloading (according to reports, potentially related to hw flow offloading) - PPPoE allegedly broken (according to reports, not fully reproducible, likely related to hw flow offloading too) - https://bugs.openwrt.org/index.php?do=details_id=3909 - https://bugs.openwrt.org/index.php?do=details_id=3835 Some more information can be found here: https://forum.openwrt.org/t/software-flow-offloading-and-conntrack-timeouts/74588 https://bugs.openwrt.org/index.php?do=details_id=3373 https://bugs.openwrt.org/index.php?do=details_id=3759 It could be that this change causes the problems: https://patchwork.ozlabs.org/project/netdev/patch/20180720130906.27687-3-pa...@netfilter.org/ I do not know how much time and interest I have in debugging and fixing this problem. If someone wants to have a closer look into this problem it would be really nice. even when you can make it easier to reproduce it in a test environment it would be nice. Should we just release with this as a known problem? Other than this problem I am not aware of any other critical problem. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
Hi Hauke, > Could you please try this patch: > https://patchwork.ozlabs.org/project/openwrt/patch/20210531195732.522580-1-dqf...@gmail.com/ > I do not see this problem with this patch any more, I am not sure which > change exactly fixed it or if I am unable to reproduce it any more. > > I have some wireshark dumps of the problem with unmodified OpenWrt 21.02. > Before the flow handling: offload-ipv6-problem2-wifi.pcapng > On the PC receiving the stream: offload-ipv6-problem2-pc.pcapng > Some packets of this TCP stream are not forward. I've just tested a build of 21.02-rc3 with that patch, and I'm still seeing the same problem unfortunately. If I get a minute, I'll have a look at your traces and see if I can capture them too. cheers, Andy ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
On 7/31/21 9:05 AM, Andy Botting wrote:
Thank you for the link and the description on how to reproduce this:
while [ 1 ]; do curl -k -s -o /dev/null -L -I -w "%{http_code}
'%{time_total}'\n" -H 'Host: www.6connect.com'
https://[2607:fae0:a000::9]; sleep 1; done
I see this problem once every 250 tries, but I got a wireshak capture.
A TCP package is lost and we get the next one after 6 seconds. I would
have expected a retransmission much earlier.
I have to check that I do not see this without the offloading and then
also capture before the device.
Thanks for looking into it. I've just had a look on my setup, and I
can easily reproduce it, so if there are some specific scenarios you'd
like me to capture, let me know.
cheers,
Andy
Hi Andy,
Could you please try this patch:
https://patchwork.ozlabs.org/project/openwrt/patch/20210531195732.522580-1-dqf...@gmail.com/
I do not see this problem with this patch any more, I am not sure which
change exactly fixed it or if I am unable to reproduce it any more.
I have some wireshark dumps of the problem with unmodified OpenWrt 21.02.
Before the flow handling: offload-ipv6-problem2-wifi.pcapng
On the PC receiving the stream: offload-ipv6-problem2-pc.pcapng
Some packets of this TCP stream are not forward.
Hauke
offload-ipv6-problem2-pc.pcapng
Description: application/pcapng
offload-ipv6-problem2-wifi.pcapng
Description: application/pcapng
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
> Thank you for the link and the description on how to reproduce this:
> while [ 1 ]; do curl -k -s -o /dev/null -L -I -w "%{http_code}
> '%{time_total}'\n" -H 'Host: www.6connect.com'
> https://[2607:fae0:a000::9]; sleep 1; done
>
> I see this problem once every 250 tries, but I got a wireshak capture.
>
> A TCP package is lost and we get the next one after 6 seconds. I would
> have expected a retransmission much earlier.
>
> I have to check that I do not see this without the offloading and then
> also capture before the device.
Thanks for looking into it. I've just had a look on my setup, and I
can easily reproduce it, so if there are some specific scenarios you'd
like me to capture, let me know.
cheers,
Andy
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status - DSA documentation status
Folks, I made a start at documentation for the DSA networking in 21.02. I now realize that I have neither the knowledge necessary to write good docs, nor will I have the time to organize this work. Consequently, I have to step back from the following pages: Upgrading to OpenWrt 21.02.0: https://openwrt.org/playground/richb/to2102 DSA Mini-Tutorial: https://openwrt.org/playground/richb/dsa-mini-tutorial Converting to DSA: https://openwrt.org/playground/richb/converting-to-dsa I've already had some help from Arınç ÜNAL (and from Rafał Miłecki's early draft), but I would hope a small team could come together to get this information together before we release 21.02. Thanks. Rich > On Jul 17, 2021, at 5:04 PM, Rich Brown wrote: > > Hauke and all, > > Thanks for the hard work to corral all those outstanding bug reports. > > As we move forward, I want to be sure the documentation side is as good as > the software... I have these comments/questions: > > 1) I created a new "Upgrading to OpenWrt 21.02.0" page at: > https://openwrt.org/playground/richb/to2102 I distilled the announcement page > (https://openwrt.org/releases/21.02/notes-21.02.0) to make this checklist for > people that won't read that entire page. > > Did I get the new page right? Please feel free to edit and make it correct. > > 2) I was pretty fuzzy about what people should do if their target did migrate > to DSA. Do we have a guide to help those people through the transition? > > 3) Is there any OpenWrt document that describes how DSA affects the files in > /etc/config and how it affects LuCI? Do we need to worry that a bunch of > people will glibly upgrade, then be knocked off the air? > > As always, I really appreciate all the effort that goes into OpenWrt. > > Best, > > Rich > >> On Jul 17, 2021, at 11:45 AM, Hauke Mehrtens wrote: >> >> Hi, >> >> In general the 21.02-rc3 looks good, but we still have some problems. >> >> Currently we still have these problem: >> >> - IPv6 broken with flow offloading (according to reports, potentially >> related to hw flow offloading) >> - PPPoE allegedly broken (according to reports, not fully reproducible, >> likely related to hw flow offloading too) >> - https://bugs.openwrt.org/index.php?do=details_id=3909 >> - https://bugs.openwrt.org/index.php?do=details_id=3835 >> - >> https://forum.openwrt.org/t/21-02-snapshot-ipv4-pppoe-session-keeps-terminating/90552 >> - DHCPv6 broken if lease times < 12h chosen >> - >> https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/137 >> - >> https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/162 >> - WDS with bridge-vlan broken (missing backport from master) >> - cron jobs are triggered in UTC even when the system uses a different time >> zone: >> - >> https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/184 >> >> Thank you Jo for collecting most of them. >> These problems should at least get some investigation and better should get >> fixed before the final release. >> >> In addition there are multiple problems with specific device, if they get >> fixed it would be nice otherwise we just leave it like it is now. >> >> The problem fixed here was also reported in 21.02: >> https://git.openwrt.org/ba5bd8e556b2e7573d27b16e005ba287e066f795 >> @Kevin: Any objections to backport this change to 21.02? Are there any other >> changes needed? >> >> @John: Did you look into the IPv6 Flow offloading problem? >> >> I would like to get some of them fixed or at least investigated and then do >> the final or a rc4, depending of the number of changes. >> I will try to find some time in the next days to investigate some of these >> problems. >> >> Hauke >> ___ >> 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 21.02 status
On 7/20/21 9:40 AM, Andy Botting wrote:
- IPv6 broken with flow offloading (according to reports, potentially
related to hw flow offloading)
There is a bug report about this at:
- https://bugs.openwrt.org/index.php?do=details_id=3373
I've reproduced it with and without hw flow offloading on mt7621.
I think it's very important to do something about this issue before
the release, as it took me nearly a week to track down. I found it
quite hard to isolate as it's like some packets just disappear, so
makes for a very bad user experience.
Hi,
Thank you for the link and the description on how to reproduce this:
while [ 1 ]; do curl -k -s -o /dev/null -L -I -w "%{http_code}
'%{time_total}'\n" -H 'Host: www.6connect.com'
https://[2607:fae0:a000::9]; sleep 1; done
I see this problem once every 250 tries, but I got a wireshak capture.
A TCP package is lost and we get the next one after 6 seconds. I would
have expected a retransmission much earlier.
I have to check that I do not see this without the offloading and then
also capture before the device.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
Or we could drop support for it and let the user do it by themselves. At least for the release of OpenWrt 21.02. The warning pop-up when the user heads to Network -> Interfaces after upgrade, could let the user know that, if they have set up packet mirroring with swconfig, they will have to do it themselves for DSA. Arınç On Wed, Jul 21, 2021 at 9:44 AM Arınç ÜNAL wrote: > > If the user enabled packet mirroring on swconfig, we need to migrate that too. > > I don't think UCI supports packet mirroring via the DSA framework, > yet. Anyone with UCI knowledge want to help out? > tc-full package is needed. > > Refer to: > https://biot.com/switches/testing/mirroring > > > On Wed, Jul 21, 2021 at 8:31 AM Arınç ÜNAL wrote: > > > > Hi Rich > > > > On Wed, Jul 21, 2021 at 2:06 AM Rich Brown wrote: > > > > > > Hi Arınç > > > > > > On Jul 20, 2021, at 3:09 PM, Arınç ÜNAL wrote: > > > > > > Let's say we wrote a script that takes 19.07 network config and > > > outputs one with DSA configuration instead, how do we implement it in > > > the image that, after upgrade, it will ask the user to convert the > > > swconfig configuration to DSA? > > > > > > > > > I'm at the edge of my knowledge here - scripting ash/bash is not a strong > > > suit. But one random neuron fires: I do wonder whether it's worth > > > including a comment at the head of /etc/config/network something like > > > this: > > > > > > # Converted with swconfig2dsa on 22Jul2021 > > > > > > That could serve to indicate that you shouldn't run the script again. > > That's an idea. Although, I was thinking the script would only run > > once, i.e. after the upgrade, when the user heads to Network -> > > Interfaces, a warning pops up and forces the user to migrate to DSA. > > We wouldn't have to put any comment on the configuration file, keep > > things clean. > > > > Cheers. > > Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
If the user enabled packet mirroring on swconfig, we need to migrate that too. I don't think UCI supports packet mirroring via the DSA framework, yet. Anyone with UCI knowledge want to help out? tc-full package is needed. Refer to: https://biot.com/switches/testing/mirroring On Wed, Jul 21, 2021 at 8:31 AM Arınç ÜNAL wrote: > > Hi Rich > > On Wed, Jul 21, 2021 at 2:06 AM Rich Brown wrote: > > > > Hi Arınç > > > > On Jul 20, 2021, at 3:09 PM, Arınç ÜNAL wrote: > > > > Let's say we wrote a script that takes 19.07 network config and > > outputs one with DSA configuration instead, how do we implement it in > > the image that, after upgrade, it will ask the user to convert the > > swconfig configuration to DSA? > > > > > > I'm at the edge of my knowledge here - scripting ash/bash is not a strong > > suit. But one random neuron fires: I do wonder whether it's worth including > > a comment at the head of /etc/config/network something like this: > > > > # Converted with swconfig2dsa on 22Jul2021 > > > > That could serve to indicate that you shouldn't run the script again. > That's an idea. Although, I was thinking the script would only run > once, i.e. after the upgrade, when the user heads to Network -> > Interfaces, a warning pops up and forces the user to migrate to DSA. > We wouldn't have to put any comment on the configuration file, keep > things clean. > > Cheers. > Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
Hi Rich On Wed, Jul 21, 2021 at 2:06 AM Rich Brown wrote: > > Hi Arınç > > On Jul 20, 2021, at 3:09 PM, Arınç ÜNAL wrote: > > Let's say we wrote a script that takes 19.07 network config and > outputs one with DSA configuration instead, how do we implement it in > the image that, after upgrade, it will ask the user to convert the > swconfig configuration to DSA? > > > I'm at the edge of my knowledge here - scripting ash/bash is not a strong > suit. But one random neuron fires: I do wonder whether it's worth including a > comment at the head of /etc/config/network something like this: > > # Converted with swconfig2dsa on 22Jul2021 > > That could serve to indicate that you shouldn't run the script again. That's an idea. Although, I was thinking the script would only run once, i.e. after the upgrade, when the user heads to Network -> Interfaces, a warning pops up and forces the user to migrate to DSA. We wouldn't have to put any comment on the configuration file, keep things clean. Cheers. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
Hey Rich I'd love to help write an explanation and the steps required to convert a swconfig setup to DSA. I will start working on the draft. It should encourage people to upgrade to 21.02 without worrying about losing their current VLAN setup. I have a good understanding of swconfig and DSA switch configuration, so I want to make a migration script to convert swconfig configuration to DSA. If anyone knows scripting and would like to help, please let me know. Let's make it happen as a team effort. I suspect the script will be supposed to read the contents of /etc/config/network on OpenWrt 19.07 or older and convert the switch configuration to DSA. Let's say we wrote a script that takes 19.07 network config and outputs one with DSA configuration instead, how do we implement it in the image that, after upgrade, it will ask the user to convert the swconfig configuration to DSA? Cheers. Arınç On Tue, Jul 20, 2021 at 3:59 PM Rich Brown wrote: > > Hi Arınç > > > On Jul 20, 2021, at 12:23 AM, Arınç ÜNAL wrote: > > > > I believe I could try to make one, I have a pretty good understanding > > of swconfig and DSA configuration. If someone can help me out with > > writing the script, I believe we can pull it off as a team effort. > > I am in need of expertise in DSA & swconfig. Specifically, the draft DSA > Mini-Tutorial (at https://openwrt.org/playground/richb/dsa-mini-tutorial) has > a sentence that begins: > > > If you are upgrading your OpenWrt device to 21.02 or later, you should read > > … > > but there's only a placeholder article now. > > Would you be able to start an outline for the "converting to DSA" page? We > can all collaborate on it to flesh it out. Thanks. > > Rich ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
Hi Arınç > On Jul 20, 2021, at 12:23 AM, Arınç ÜNAL wrote: > > I believe I could try to make one, I have a pretty good understanding > of swconfig and DSA configuration. If someone can help me out with > writing the script, I believe we can pull it off as a team effort. I am in need of expertise in DSA & swconfig. Specifically, the draft DSA Mini-Tutorial (at https://openwrt.org/playground/richb/dsa-mini-tutorial) has a sentence that begins: > If you are upgrading your OpenWrt device to 21.02 or later, you should read … but there's only a placeholder article now. Would you be able to start an outline for the "converting to DSA" page? We can all collaborate on it to flesh it out. Thanks. Rich ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
> - IPv6 broken with flow offloading (according to reports, potentially > related to hw flow offloading) There is a bug report about this at: - https://bugs.openwrt.org/index.php?do=details_id=3373 I've reproduced it with and without hw flow offloading on mt7621. I think it's very important to do something about this issue before the release, as it took me nearly a week to track down. I found it quite hard to isolate as it's like some packets just disappear, so makes for a very bad user experience. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
On 19/07/21 21:11, Luiz Angelo Daros de Luca wrote: This is not a migration script but a mitigation. A 21.02 image should detect during boot if the current network config was for swconfig in a system using DSA. It could happen during early boot stages, after FS are mounted, before services are started, something similar to uci-defaults, but not in a "run once" way. It would cover both upgrades with confs and restores. We are asking the user to upgrade without saving confs but nothing will prevent them from keeping settings while using "sysupgrade -F" nor restoring an 19.07 backup "manually" into a 21.02. I think an expert dev could solve this one with a 5 line script ;-) It's a 5 line script if you are migrating default switch config to new default switch config and assuming the user did not touch much. With smart switch you could do some pretty elaborate setups and making a script that can actually migrate more than very basic configs is not easy at all. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: OpenWrt 21.02 status
> It could happen during early boot stages, after FS are mounted, before > services are started, something similar to uci-defaults, but not in a "run > once" > way. > It would cover both upgrades with confs and restores. We are asking the > user to upgrade without saving confs but nothing will prevent them from > keeping settings while using "sysupgrade -F" nor restoring an 19.07 backup > "manually" into a 21.02. I think an expert dev could solve this one with a 5 > line > script That's what everybody believes until he tries. The problem is how to detect whether the config is old or new. This might be hacked somehow for specific cases, but it's impossible to do in an acceptable way for a generic case. Note that compat 1.0->1.1 does not necessarily mean swconfig->DSA, so we have no general variable that will define which state we are in. There is a reason why nobody provided a DSA migration script (or even tried AFAIK). This horse is dead. (Doing -f without -n is a real world problem. They might pseudo-brick their devices. However, we have no better solution about that at the moment.) Best Adrian > ;-) > > Regards, 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 21.02 status
Hi Hauke, On Mon, Jul 19, 2021 at 8:05 PM Hauke Mehrtens wrote: > > Hi Hans, > > On 7/17/21 5:45 PM, Hauke Mehrtens wrote: > > Hi, > > > > In general the 21.02-rc3 looks good, but we still have some problems. > > > > Currently we still have these problem: > > > > > - DHCPv6 broken if lease times < 12h chosen > >- > > https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/137 > >- > > https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/162 > > > Should this commit fix the "DHCPv6 broken if lease times < 12h chosen" > problem? > https://git.openwrt.org/4633471d74589c761a3849bd63935b42ac3cea73 Correct this fixes the issue if the leasetime is smaller than the preferred lifetime of an address Hans > > Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: OpenWrt 21.02 status
> -Original Message- > From: Daniel Golle [mailto:dan...@makrotopia.org] > Sent: Montag, 19. Juli 2021 10:13 > To: Adrian Schmutzler > Cc: 'Luiz Angelo Daros de Luca'; 'Hauke Mehrtens'; 'Rich Brown'; 'OpenWrt > Development List'; 'Jo-Philipp Wich'; 'Kevin 'ldir' Darbyshire-Bryant'; 'John > Crispin'; 'Rafał Miłecki' > Subject: Re: OpenWrt 21.02 status > > On Sun, Jul 18, 2021 at 10:30:20PM +0200, Adrian Schmutzler wrote: > > > The last time I tried it was very confusing. When I first read about > > > "new fresh installation", I thought: "install without keeping settings". > > > However, OpenWrt returned an image check failure, even when I did > > > not keep the settings (sysupgrade -n). It was the same type of error > > > (image validation failed) that would happen if I selected the wrong > > > firmware (but maybe with a different content). The only way to > > > install it was forcing the operation, which might also allow an > > > incompatible image to be installed (bricking the device). Please > > > reconsider some form of upgrade path that validates the image and > > > allows the user to upgrade without a force or going back to factory > > > before reinstalling OpenWrt with DSA. Something like "update package > > > foo to version n.m.z or upgrade to 19.07.9 before installing > > > 21.02 for proper image validation". Most users will not be confident to > apply > > > a forced installation. > > > > That would be nice, but unfortunately it's not so easy. The problem is that > the upgrade mechanism is baked into the _old_ image. > > Any upgrade can only do what the old firmware supported. Thus, I was > really glad that I was able to hack this message into the device detection > mechanism at all. Otherwise, we would not have any message at all for old > installations. > > I believe what he meant to say was to make another 19.07.x point release > with an updated sysupgrade mechanism which would improve the situation > when upgrading to 21.02.x and, for example, allow flashing with non- > matching DEVICE_COMPAT_VERSION already when specifying the '-n' flag to > not keep configuration, but not require the '-F' flag which is scary for > regular > users (for good reasons). I see the point of this approach, and I also considered it already when I started this thing. It should work like that if done properly. However, I really do not like to backport fundamental features/feature changes like that. It probably wouldn't even be much work as the code changes itself are few; but changing the sysupgrade mechanism in a .8 point release that might be the last one really does not feel right to me. I will give it a few days of thought... Best Adrian > > > > > > > > > From wiki upgrading to 21.02 page: > > > > > > "Don't worry - If you try to upgrade with the wrong target, > > > sysupgrade will refuse to proceed with an error message like this: > > > Image version mismatch. image 1.1 device 1.0 Please wipe config > > > during upgrade (force required) or reinstall. Config cannot be > > > migrated from swconfig to DSA Image check failed" > > > > > > My experience and the message content indicates that it will show > > > for all migrations from "swconfig" to "DSA" and not only for "wrong > target". > > > > Yes. For the old sysupgrade, we simply match two strings (the board name > from the device against SUPPORTED_DEVICES from the image). Either it's > successful, or it's not. If it's not, the message displays the name of the > SUPPORTED_DEVICES. That's what we got. So I have to hack all of the > message into the SUPPORTED_DEVICES string. > > > > > > > > I tried to start a discussion about it in an email "Usability issues > > > for DSA upgrade" (jun/28) but I got no answer. > > > > We can discuss this for the future, i.e. for updates starting at 21.xx, and > > we > can discuss the exact wording of the message. > > Not saying that I'm fond of it, neither that I'm volunteering to do it, but we > **could** also update 19.07.x > > > > > > > > > It would also be great if we could detect a config from a pre-dsa > > > system and restore everything but skipping or renaming DSA relevant > > > files (nework, > > > wifi?) DSA) with a suffix like '.pre-dsa'. > > > > We had a very long delay due to DSA and nobody was even slightly > interested in creating a migration script. > > For partial migration, I suspect that implementing something here that is >
Re: OpenWrt 21.02 status
> I believe what he meant to say was to make another 19.07.x point > release with an updated sysupgrade mechanism which would improve the > situation when upgrading to 21.02.x and, for example, allow > flashing with non-matching DEVICE_COMPAT_VERSION already when > specifying the '-n' flag to not keep configuration, but not require > the '-F' flag which is scary for regular users (for good reasons). That is exactly what I propose. We should somehow make sysupgrade in 19.07 be able to understand a DSA image and allow an upgrade '-n' without warning and forces. I think a package upgrade or a new package installation might be able to do that. It touches the image validation, which I guess happens before switch_root. It does not invalidate the use of -F for older images but it allows a safer path. We could have a new 19.07 point release with that update, but it is just another way to install the new/updated package. I think all involved files in image validation are in base-files. I think they should be in an individual package to help upgrade them without touching the rest of the system. This will not be the last time OpenWrt will need to prepare an old version to deal with a new release image. > > We can discuss this for the future, i.e. for updates starting at 21.xx, and > > we can discuss the exact wording of the message. First we need a solution to offer the user. > > > It would also be great if we could detect a config from a pre-dsa system > > > and > > > restore everything but skipping or renaming DSA relevant files (nework, > > > wifi?) DSA) with a suffix like '.pre-dsa'. > > > > We had a very long delay due to DSA and nobody was even slightly interested > > in creating a migration script. > > For partial migration, I suspect that implementing something here that is > > general will be much more complicated than just having the user select what > > he wants/needs. This is not a migration script but a mitigation. A 21.02 image should detect during boot if the current network config was for swconfig in a system using DSA. It could happen during early boot stages, after FS are mounted, before services are started, something similar to uci-defaults, but not in a "run once" way. It would cover both upgrades with confs and restores. We are asking the user to upgrade without saving confs but nothing will prevent them from keeping settings while using "sysupgrade -F" nor restoring an 19.07 backup "manually" into a 21.02. I think an expert dev could solve this one with a 5 line script ;-) Regards, ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
Hi Hans, On 7/17/21 5:45 PM, Hauke Mehrtens wrote: Hi, In general the 21.02-rc3 looks good, but we still have some problems. Currently we still have these problem: - DHCPv6 broken if lease times < 12h chosen - https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/137 - https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/162 Should this commit fix the "DHCPv6 broken if lease times < 12h chosen" problem? https://git.openwrt.org/4633471d74589c761a3849bd63935b42ac3cea73 Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
On Sun, Jul 18, 2021 at 10:30:20PM +0200, Adrian Schmutzler wrote: > > The last time I tried it was very confusing. When I first read about "new > > fresh > > installation", I thought: "install without keeping settings". > > However, OpenWrt returned an image check failure, even when I did not > > keep the settings (sysupgrade -n). It was the same type of error (image > > validation failed) that would happen if I selected the wrong firmware (but > > maybe with a different content). The only way to install it was forcing the > > operation, which might also allow an incompatible image to be installed > > (bricking the device). Please reconsider some form of upgrade path that > > validates the image and allows the user to upgrade without a force or going > > back to factory before reinstalling OpenWrt with DSA. Something like > > "update package foo to version n.m.z or upgrade to 19.07.9 before installing > > 21.02 for proper image validation". Most users will not be confident to > > apply > > a forced installation. > > That would be nice, but unfortunately it's not so easy. The problem is that > the upgrade mechanism is baked into the _old_ image. > Any upgrade can only do what the old firmware supported. Thus, I was really > glad that I was able to hack this message into the device detection mechanism > at all. Otherwise, we would not have any message at all for old installations. I believe what he meant to say was to make another 19.07.x point release with an updated sysupgrade mechanism which would improve the situation when upgrading to 21.02.x and, for example, allow flashing with non-matching DEVICE_COMPAT_VERSION already when specifying the '-n' flag to not keep configuration, but not require the '-F' flag which is scary for regular users (for good reasons). > > > > > From wiki upgrading to 21.02 page: > > > > "Don't worry - If you try to upgrade with the wrong target, sysupgrade will > > refuse to proceed with an error message like this: > > Image version mismatch. image 1.1 device 1.0 Please wipe config during > > upgrade (force required) or reinstall. Config cannot be migrated from > > swconfig to DSA Image check failed" > > > > My experience and the message content indicates that it will show for all > > migrations from "swconfig" to "DSA" and not only for "wrong target". > > Yes. For the old sysupgrade, we simply match two strings (the board name from > the device against SUPPORTED_DEVICES from the image). Either it's successful, > or it's not. If it's not, the message displays the name of the > SUPPORTED_DEVICES. That's what we got. So I have to hack all of the message > into the SUPPORTED_DEVICES string. > > > > > I tried to start a discussion about it in an email "Usability issues for DSA > > upgrade" (jun/28) but I got no answer. > > We can discuss this for the future, i.e. for updates starting at 21.xx, and > we can discuss the exact wording of the message. Not saying that I'm fond of it, neither that I'm volunteering to do it, but we **could** also update 19.07.x > > > > > It would also be great if we could detect a config from a pre-dsa system and > > restore everything but skipping or renaming DSA relevant files (nework, > > wifi?) DSA) with a suffix like '.pre-dsa'. > > We had a very long delay due to DSA and nobody was even slightly interested > in creating a migration script. > For partial migration, I suspect that implementing something here that is > general will be much more complicated than just having the user select what > he wants/needs. > > Best > > Adrian > > > > > DSA is missing a lot of docs. For example: is there a simple, secure way to > > detect a system is using DSA for a specific switch (or device)? > > Is it possible to exist a device with two switches and only one of them uses > > DSA? > > > > Regards, > > > > ___ > > 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: OpenWrt 21.02 status
> The last time I tried it was very confusing. When I first read about "new > fresh > installation", I thought: "install without keeping settings". > However, OpenWrt returned an image check failure, even when I did not > keep the settings (sysupgrade -n). It was the same type of error (image > validation failed) that would happen if I selected the wrong firmware (but > maybe with a different content). The only way to install it was forcing the > operation, which might also allow an incompatible image to be installed > (bricking the device). Please reconsider some form of upgrade path that > validates the image and allows the user to upgrade without a force or going > back to factory before reinstalling OpenWrt with DSA. Something like > "update package foo to version n.m.z or upgrade to 19.07.9 before installing > 21.02 for proper image validation". Most users will not be confident to apply > a forced installation. That would be nice, but unfortunately it's not so easy. The problem is that the upgrade mechanism is baked into the _old_ image. Any upgrade can only do what the old firmware supported. Thus, I was really glad that I was able to hack this message into the device detection mechanism at all. Otherwise, we would not have any message at all for old installations. > > From wiki upgrading to 21.02 page: > > "Don't worry - If you try to upgrade with the wrong target, sysupgrade will > refuse to proceed with an error message like this: > Image version mismatch. image 1.1 device 1.0 Please wipe config during > upgrade (force required) or reinstall. Config cannot be migrated from > swconfig to DSA Image check failed" > > My experience and the message content indicates that it will show for all > migrations from "swconfig" to "DSA" and not only for "wrong target". Yes. For the old sysupgrade, we simply match two strings (the board name from the device against SUPPORTED_DEVICES from the image). Either it's successful, or it's not. If it's not, the message displays the name of the SUPPORTED_DEVICES. That's what we got. So I have to hack all of the message into the SUPPORTED_DEVICES string. > > I tried to start a discussion about it in an email "Usability issues for DSA > upgrade" (jun/28) but I got no answer. We can discuss this for the future, i.e. for updates starting at 21.xx, and we can discuss the exact wording of the message. > > It would also be great if we could detect a config from a pre-dsa system and > restore everything but skipping or renaming DSA relevant files (nework, > wifi?) DSA) with a suffix like '.pre-dsa'. We had a very long delay due to DSA and nobody was even slightly interested in creating a migration script. For partial migration, I suspect that implementing something here that is general will be much more complicated than just having the user select what he wants/needs. Best Adrian > > DSA is missing a lot of docs. For example: is there a simple, secure way to > detect a system is using DSA for a specific switch (or device)? > Is it possible to exist a device with two switches and only one of them uses > DSA? > > Regards, > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel 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 21.02 status
>> 1) I created a new "Upgrading to OpenWrt 21.02.0" page at: >> https://openwrt.org/playground/richb/to2102 I distilled the announcement >> page (https://openwrt.org/releases/21.02/notes-21.02.0) to make this >> checklist for people that won't read that entire page. >> Did I get the new page right? Please feel free to edit and make it correct. > > Yes looks good, we should probably integrate this somehow in the release > notes, so that people do not have to read everything. Thanks. I hasten to point out that I was just guessing / making stuff up in places. Please check every word, VERY CAREFULLY. (Remember, some readers will study it line by line. If it's not totally correct, they're going to do the wrong thing...) https://openwrt.org/playground/richb/to2102 >> 2) I was pretty fuzzy about what people should do if their target did >> migrate to DSA. Do we have a guide to help those people through the >> transition? > > We do not support a migration and people have to start with a new fresh > installation. Doing a backup and restoring some settings manually works. Then I think this is a big deal for people with interesting network configurations (maybe for everyone except those with a vanilla bridged LAN?) If they just install, I suspect they're going to be off the air, and we'll receive continuing "21.02 broke my router" complaints. Is this something we can detect automatically? In any event, we need to have good documentation about: - Whether or not you need to worry - either by examining LuCi or by examining /etc/config/network - How you make the transition from swconfig to DSA - How you recover if you made the switch and now want to get back to the same configuration >> 3) Is there any OpenWrt document that describes how DSA affects the files in >> /etc/config and how it affects LuCI? Do we need to worry that a bunch of >> people will glibly upgrade, then be knocked off the air? > > Rafał created this forum post: > https://forum.openwrt.org/t/mini-tutorial-for-dsa-network-config/96998 > > It would be nice if someone could create a wiki page based on this. Maybe something like this? https://openwrt.org/playground/richb/dsa-mini-tutorial It would be really great if Rafał (and others) could review the words on this page ASAP to make sure that a) I copy/pasted it correctly, and b) that the text is still correct. Thanks. Rich ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
On Sat, Jul 17, 2021 at 9:48 AM Hauke Mehrtens wrote: > > In addition there are multiple problems with specific device, if they > get fixed it would be nice otherwise we just leave it like it is now. Configuration of 60 GHz radios via LuCI is still broken (my proposed patch [1] was not accepted in its entirety [2][3]). I would love to donate a TP-Link AD7200 to anyone willing to work on the problem. -Alex [1] http://lists.openwrt.org/pipermail/openwrt-devel/2021-July/035810.html [2] http://lists.openwrt.org/pipermail/openwrt-devel/2021-July/035811.html [3] http://lists.openwrt.org/pipermail/openwrt-devel/2021-July/035815.html ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
> > 2) I was pretty fuzzy about what people should do if their target did > > migrate to DSA. Do we have a guide to help those people through the > > transition? > > We do not support a migration and people have to start with a new fresh > installation. Doing a backup and restoring some settings manually works. The last time I tried it was very confusing. When I first read about "new fresh installation", I thought: "install without keeping settings". However, OpenWrt returned an image check failure, even when I did not keep the settings (sysupgrade -n). It was the same type of error (image validation failed) that would happen if I selected the wrong firmware (but maybe with a different content). The only way to install it was forcing the operation, which might also allow an incompatible image to be installed (bricking the device). Please reconsider some form of upgrade path that validates the image and allows the user to upgrade without a force or going back to factory before reinstalling OpenWrt with DSA. Something like "update package foo to version n.m.z or upgrade to 19.07.9 before installing 21.02 for proper image validation". Most users will not be confident to apply a forced installation. >From wiki upgrading to 21.02 page: "Don't worry - If you try to upgrade with the wrong target, sysupgrade will refuse to proceed with an error message like this: Image version mismatch. image 1.1 device 1.0 Please wipe config during upgrade (force required) or reinstall. Config cannot be migrated from swconfig to DSA Image check failed" My experience and the message content indicates that it will show for all migrations from "swconfig" to "DSA" and not only for "wrong target". I tried to start a discussion about it in an email "Usability issues for DSA upgrade" (jun/28) but I got no answer. It would also be great if we could detect a config from a pre-dsa system and restore everything but skipping or renaming DSA relevant files (nework, wifi?) DSA) with a suffix like '.pre-dsa'. DSA is missing a lot of docs. For example: is there a simple, secure way to detect a system is using DSA for a specific switch (or device)? Is it possible to exist a device with two switches and only one of them uses DSA? Regards, ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
Hi Rich, On 7/17/21 11:04 PM, Rich Brown wrote: Hauke and all, Thanks for the hard work to corral all those outstanding bug reports. As we move forward, I want to be sure the documentation side is as good as the software... I have these comments/questions: 1) I created a new "Upgrading to OpenWrt 21.02.0" page at: https://openwrt.org/playground/richb/to2102 I distilled the announcement page (https://openwrt.org/releases/21.02/notes-21.02.0) to make this checklist for people that won't read that entire page. Did I get the new page right? Please feel free to edit and make it correct. Yes looks good, we should probably integrate this somehow in the release notes, so that people do not have to read everything. 2) I was pretty fuzzy about what people should do if their target did migrate to DSA. Do we have a guide to help those people through the transition? We do not support a migration and people have to start with a new fresh installation. Doing a backup and restoring some settings manually works. 3) Is there any OpenWrt document that describes how DSA affects the files in /etc/config and how it affects LuCI? Do we need to worry that a bunch of people will glibly upgrade, then be knocked off the air? Rafał created this forum post: https://forum.openwrt.org/t/mini-tutorial-for-dsa-network-config/96998 It would be nice if someone could create a wiki page based on this. As always, I really appreciate all the effort that goes into OpenWrt. Best, Rich Hauke On Jul 17, 2021, at 11:45 AM, Hauke Mehrtens wrote: Hi, In general the 21.02-rc3 looks good, but we still have some problems. Currently we still have these problem: - IPv6 broken with flow offloading (according to reports, potentially related to hw flow offloading) - PPPoE allegedly broken (according to reports, not fully reproducible, likely related to hw flow offloading too) - https://bugs.openwrt.org/index.php?do=details_id=3909 - https://bugs.openwrt.org/index.php?do=details_id=3835 - https://forum.openwrt.org/t/21-02-snapshot-ipv4-pppoe-session-keeps-terminating/90552 - DHCPv6 broken if lease times < 12h chosen - https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/137 - https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/162 - WDS with bridge-vlan broken (missing backport from master) - cron jobs are triggered in UTC even when the system uses a different time zone: - https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/184 Thank you Jo for collecting most of them. These problems should at least get some investigation and better should get fixed before the final release. In addition there are multiple problems with specific device, if they get fixed it would be nice otherwise we just leave it like it is now. The problem fixed here was also reported in 21.02: https://git.openwrt.org/ba5bd8e556b2e7573d27b16e005ba287e066f795 @Kevin: Any objections to backport this change to 21.02? Are there any other changes needed? @John: Did you look into the IPv6 Flow offloading problem? I would like to get some of them fixed or at least investigated and then do the final or a rc4, depending of the number of changes. I will try to find some time in the next days to investigate some of these problems. Hauke ___ 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 21.02 status
Hauke and all, Thanks for the hard work to corral all those outstanding bug reports. As we move forward, I want to be sure the documentation side is as good as the software... I have these comments/questions: 1) I created a new "Upgrading to OpenWrt 21.02.0" page at: https://openwrt.org/playground/richb/to2102 I distilled the announcement page (https://openwrt.org/releases/21.02/notes-21.02.0) to make this checklist for people that won't read that entire page. Did I get the new page right? Please feel free to edit and make it correct. 2) I was pretty fuzzy about what people should do if their target did migrate to DSA. Do we have a guide to help those people through the transition? 3) Is there any OpenWrt document that describes how DSA affects the files in /etc/config and how it affects LuCI? Do we need to worry that a bunch of people will glibly upgrade, then be knocked off the air? As always, I really appreciate all the effort that goes into OpenWrt. Best, Rich > On Jul 17, 2021, at 11:45 AM, Hauke Mehrtens wrote: > > Hi, > > In general the 21.02-rc3 looks good, but we still have some problems. > > Currently we still have these problem: > > - IPv6 broken with flow offloading (according to reports, potentially related > to hw flow offloading) > - PPPoE allegedly broken (according to reports, not fully reproducible, > likely related to hw flow offloading too) > - https://bugs.openwrt.org/index.php?do=details_id=3909 > - https://bugs.openwrt.org/index.php?do=details_id=3835 > - > https://forum.openwrt.org/t/21-02-snapshot-ipv4-pppoe-session-keeps-terminating/90552 > - DHCPv6 broken if lease times < 12h chosen > - > https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/137 > - > https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/162 > - WDS with bridge-vlan broken (missing backport from master) > - cron jobs are triggered in UTC even when the system uses a different time > zone: > - > https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/184 > > Thank you Jo for collecting most of them. > These problems should at least get some investigation and better should get > fixed before the final release. > > In addition there are multiple problems with specific device, if they get > fixed it would be nice otherwise we just leave it like it is now. > > The problem fixed here was also reported in 21.02: > https://git.openwrt.org/ba5bd8e556b2e7573d27b16e005ba287e066f795 > @Kevin: Any objections to backport this change to 21.02? Are there any other > changes needed? > > @John: Did you look into the IPv6 Flow offloading problem? > > I would like to get some of them fixed or at least investigated and then do > the final or a rc4, depending of the number of changes. > I will try to find some time in the next days to investigate some of these > problems. > > Hauke > ___ > 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 21.02 status
I would like to bring this to everyone's attention for the final release of 21.02. There must be a fundamental change of handling interfaces & VLANs on a switch on DSA-enabled architectures on OpenWrt. Please refer to this post: http://lists.openwrt.org/pipermail/openwrt-devel/2021-July/035787.html On Sat, Jul 17, 2021 at 6:51 PM Hauke Mehrtens wrote: > > Hi, > > In general the 21.02-rc3 looks good, but we still have some problems. > > Currently we still have these problem: > > - IPv6 broken with flow offloading (according to reports, potentially > related to hw flow offloading) > - PPPoE allegedly broken (according to reports, not fully reproducible, > likely related to hw flow offloading too) >- https://bugs.openwrt.org/index.php?do=details_id=3909 >- https://bugs.openwrt.org/index.php?do=details_id=3835 >- > https://forum.openwrt.org/t/21-02-snapshot-ipv4-pppoe-session-keeps-terminating/90552 > - DHCPv6 broken if lease times < 12h chosen >- > https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/137 >- > https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/162 > - WDS with bridge-vlan broken (missing backport from master) > - cron jobs are triggered in UTC even when the system uses a different > time zone: >- > https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/184 > > Thank you Jo for collecting most of them. > These problems should at least get some investigation and better should > get fixed before the final release. > > In addition there are multiple problems with specific device, if they > get fixed it would be nice otherwise we just leave it like it is now. > > The problem fixed here was also reported in 21.02: > https://git.openwrt.org/ba5bd8e556b2e7573d27b16e005ba287e066f795 > @Kevin: Any objections to backport this change to 21.02? Are there any > other changes needed? > > @John: Did you look into the IPv6 Flow offloading problem? > > I would like to get some of them fixed or at least investigated and then > do the final or a rc4, depending of the number of changes. > I will try to find some time in the next days to investigate some of > these problems. > > Hauke > ___ > 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 21.02 status
On 2021-07-17 17:45, Hauke Mehrtens wrote: > Hi, > > In general the 21.02-rc3 looks good, but we still have some problems. > > Currently we still have these problem: > > - IPv6 broken with flow offloading (according to reports, potentially > related to hw flow offloading) > - PPPoE allegedly broken (according to reports, not fully reproducible, > likely related to hw flow offloading too) >- https://bugs.openwrt.org/index.php?do=details_id=3909 >- https://bugs.openwrt.org/index.php?do=details_id=3835 >- > https://forum.openwrt.org/t/21-02-snapshot-ipv4-pppoe-session-keeps-terminating/90552 > - DHCPv6 broken if lease times < 12h chosen >- > https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/137 >- > https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/162 > - WDS with bridge-vlan broken (missing backport from master) I added a netifd backport in fe498dd3f108 (with a fix in f3f70fb9567d) - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 21.02 status
Hi, In general the 21.02-rc3 looks good, but we still have some problems. Currently we still have these problem: - IPv6 broken with flow offloading (according to reports, potentially related to hw flow offloading) - PPPoE allegedly broken (according to reports, not fully reproducible, likely related to hw flow offloading too) - https://bugs.openwrt.org/index.php?do=details_id=3909 - https://bugs.openwrt.org/index.php?do=details_id=3835 - https://forum.openwrt.org/t/21-02-snapshot-ipv4-pppoe-session-keeps-terminating/90552 - DHCPv6 broken if lease times < 12h chosen - https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/137 - https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/162 - WDS with bridge-vlan broken (missing backport from master) - cron jobs are triggered in UTC even when the system uses a different time zone: - https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/184 Thank you Jo for collecting most of them. These problems should at least get some investigation and better should get fixed before the final release. In addition there are multiple problems with specific device, if they get fixed it would be nice otherwise we just leave it like it is now. The problem fixed here was also reported in 21.02: https://git.openwrt.org/ba5bd8e556b2e7573d27b16e005ba287e066f795 @Kevin: Any objections to backport this change to 21.02? Are there any other changes needed? @John: Did you look into the IPv6 Flow offloading problem? I would like to get some of them fixed or at least investigated and then do the final or a rc4, depending of the number of changes. I will try to find some time in the next days to investigate some of these problems. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
