Re: Switch issues and CI to GitHub
On Fri, Jan 7, 2022 at 1:38 AM Paul Spooren wrote: > > Hi all, > > Back at the Hamburg meeting in 2019 and a succeeding vote we decided to > migrate over to a self-hosted GitLab instance. Some years passed and nothing > really happened so I’d like to give this another go. > > None of the OpenWrt project members is willing to setup and maintain a GitLab > instance and there were multiple vetos again gitlab.com. > > Our current bug tracker at bugs.openwrt.org is used by a minority of users > (and devs), all community repositories (LuCI, packages, …) use GitHub for > issue tracking. Instead of maintaining flyspray and the server, I’d like to > export all flyspray issues, migrate them to GitHub and open GitHub issues for > openwrt/openwrt to the public. A static or read-only version of flyspray > could be hosted for the near future. > > Secondly I’d like to give the CI of the main repository another go. Our CI to > build Docker images is currently on gitlab.com, I’d migrate that over to > GitHub. Also I’d suggest to add similar CI checks as added to the packages > (and routing and video and LuCI) repository. We could compile targets and > tooling, check checksums etc, even build snapshots to lower the resource > usage of our Buildbot infrastructure. > > During a recent _poll_ in #openwrt-adm multiple members liked the idea, > however before doing or voting on anything, I’d like to ask for more comments. +1 for github. https://www.gnu.org/software/repo-criteria-evaluation.html seems to be complete garbage. Seems the higher the criteria, the less users. > > Thanks for all feedback, > Paul > ___ > 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: Switch issues and CI to GitHub
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Indeed, so +1 Paul > Op 7 jan. 2022, om 13:07 heeft Sam Kuper het > volgende geschreven: > > On Fri, Jan 07, 2022 at 10:34:34AM +0100, Paul Spooren wrote: >> Instead of maintaining flyspray and the server, I’d like to export all >> flyspray issues, migrate them to GitHub and open GitHub issues for >> openwrt/openwrt to the public. > > Please don't do this. GitHub has substantial accessibility and privacy > flaws, compared to other options - and fails ethical code/bug-hosting > criteria: https://www.gnu.org/software/repo-criteria-evaluation.html > > Please either stick with existing arrangements, or go with an ethical, > accessible code/bug-host (e.g. SourceHut https://sr.ht ). > > Thanks, > > Sam > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Indeed, so +1 Paul > Op 7 jan. 2022, om 13:07 heeft Sam Kuper het > volgende geschreven: > > On Fri, Jan 07, 2022 at 10:34:34AM +0100, Paul Spooren wrote: >> Instead of maintaining flyspray and the server, I’d like to export all >> flyspray issues, migrate them to GitHub and open GitHub issues for >> openwrt/openwrt to the public. > > Please don't do this. GitHub has substantial accessibility and privacy > flaws, compared to other options - and fails ethical code/bug-hosting > criteria: https://www.gnu.org/software/repo-criteria-evaluation.html > > Please either stick with existing arrangements, or go with an ethical, > accessible code/bug-host (e.g. SourceHut https://sr.ht ). > > Thanks, > > Sam > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] hostapd: fallback to psk when generating r0kh/r1kh
The 80211r r0kh and r1kh defaults are generated from the md5sum of
"$mobility_domain/$auth_secret". auth_secret is only set when using EAP
authentication, but the default key is used for SAE/PSK as well. In
this case, auth_secret is empty, and the default value of the key can
be computed from the SSID alone.
Fallback to using $key when auth_secret is empty. While at it, rename
the variable holding the generated key from 'key' to 'ft_key', to avoid
clobbering the PSK.
Signed-off-by: Eneas U de Queiroz
---
This should be cherry-picked to 21.02 as well.
package/network/services/hostapd/files/hostapd.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/package/network/services/hostapd/files/hostapd.sh
b/package/network/services/hostapd/files/hostapd.sh
index d9d5f34877..e00fc21cd9 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -876,10 +876,10 @@ hostapd_set_bss_options() {
set_default pmk_r1_push 0
[ -n "$r0kh" -a -n "$r1kh" ] || {
- key=`echo -n
"$mobility_domain/$auth_secret" | md5sum | awk '{print $1}'`
+ ft_key=`echo -n
"$mobility_domain/${auth_secret:-${key}}" | md5sum | awk '{print $1}'`
- set_default r0kh
"ff:ff:ff:ff:ff:ff,*,$key"
- set_default r1kh
"00:00:00:00:00:00,00:00:00:00:00:00,$key"
+ set_default r0kh
"ff:ff:ff:ff:ff:ff,*,$ft_key"
+ set_default r1kh
"00:00:00:00:00:00,00:00:00:00:00:00,$ft_key"
}
[ -n "$r1_key_holder" ] && append bss_conf
"r1_key_holder=$r1_key_holder" "$N"
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [firewall3 PATCH] firewall3: support async table init in 5.15+ kernel
Hi, Ansuel,
On Fri, 7 Jan 2022 at 17:26, Ansuel Smith wrote:
>
> With 5.15+ tables are init in an async way. Firewall3 use the proc entry
> ip_tables_names to check if a table exist. With this new implemenation,
> the proc entry can contain wrong data in the case where a table is
> present but never used/init and firewall3 would uncorrectly think that
> the table is not available. This cause some connection problem as from a
> normal boot the proc entry contains only the "filter" table and
> lacks "raw","mangle" and "nat".
>
> To fix this "poke" the tables to init them by simply open and closing
> them without doing any operation. This simple operation is sufficient to
> make the missing tables appear in the proc entry.
>
> Signed-off-by: Ansuel Smith
> ---
> main.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/main.c b/main.c
> index 7ad00b4..796ae80 100644
> --- a/main.c
> +++ b/main.c
> @@ -266,6 +266,21 @@ start(void)
> continue;
> }
>
> + /* From 5.15+ tables are created async as soon as the first
> rule
> +* is created or any operation is requested. This cause the
> +* *_tables_names to report wrong data / missing tables.
> +* Poke ipt to init the tables so fw3_has_table correctly
> detects
> +* them with the proc entires.
> +*/
> + for (table = FW3_TABLE_FILTER; table <= FW3_TABLE_RAW;
> table++)
> + {
> +
> + if (!(handle = fw3_ipt_open(family, table)))
> + continue;
> +
> + fw3_ipt_close(handle);
> + }
> +
> for (table = FW3_TABLE_FILTER; table <= FW3_TABLE_RAW;
> table++)
> {
> if (!fw3_has_table(family == FW3_FAMILY_V6,
> fw3_flag_names[table]))
> --
> 2.33.1
>
Groan. Still, it does seem the less insane solution, so…
Reviewed-by: Rui Salvaterra
Thanks,
Rui
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[firewall3 PATCH] firewall3: support async table init in 5.15+ kernel
With 5.15+ tables are init in an async way. Firewall3 use the proc entry
ip_tables_names to check if a table exist. With this new implemenation,
the proc entry can contain wrong data in the case where a table is
present but never used/init and firewall3 would uncorrectly think that
the table is not available. This cause some connection problem as from a
normal boot the proc entry contains only the "filter" table and
lacks "raw","mangle" and "nat".
To fix this "poke" the tables to init them by simply open and closing
them without doing any operation. This simple operation is sufficient to
make the missing tables appear in the proc entry.
Signed-off-by: Ansuel Smith
---
main.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/main.c b/main.c
index 7ad00b4..796ae80 100644
--- a/main.c
+++ b/main.c
@@ -266,6 +266,21 @@ start(void)
continue;
}
+ /* From 5.15+ tables are created async as soon as the first rule
+* is created or any operation is requested. This cause the
+* *_tables_names to report wrong data / missing tables.
+* Poke ipt to init the tables so fw3_has_table correctly
detects
+* them with the proc entires.
+*/
+ for (table = FW3_TABLE_FILTER; table <= FW3_TABLE_RAW; table++)
+ {
+
+ if (!(handle = fw3_ipt_open(family, table)))
+ continue;
+
+ fw3_ipt_close(handle);
+ }
+
for (table = FW3_TABLE_FILTER; table <= FW3_TABLE_RAW; table++)
{
if (!fw3_has_table(family == FW3_FAMILY_V6,
fw3_flag_names[table]))
--
2.33.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: IP-PBX users?
On Wed, 5 Jan 2022 17:09:19 -0700 Philip Prindeville wrote: > Anyone have documentation on getting started? > Or strong arguments to use Freeswitch over Asterisk or vice versa? My personal impression is that the mature Asterisk is good at combining POTS with VoIP, with very limited support for video, whereas the rather new FreeSwitch focuses on VoIP, has some ambitions towards video conferencing (Big Blue Button prefers it, FWIW), and seems to have limited support for POTS. Around 2019 I had to switch from Asterisk to FreeSwitch because Deutsche Telekom is rather picky about their DNS setup; you must use their SRV records, otherwise phone service will fail in an obscure way, occasionally. Only FreeSwitch was able to do the proper DNS SRV lookup. I also found that it handles the forced DSL disconnects very gracefully. FreeSwitch is being quite actively developed, and documentation (mostly the wiki) lags behind, more or less, so RTFS was inevitable back then. Torsten ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- On 07/01/2022 12:07, Sam Kuper wrote: On Fri, Jan 07, 2022 at 10:34:34AM +0100, Paul Spooren wrote: Instead of maintaining flyspray and the server, I’d like to export all flyspray issues, migrate them to GitHub and open GitHub issues for openwrt/openwrt to the public. Please don't do this. GitHub has substantial accessibility and privacy flaws, compared to other options - and fails ethical code/bug-hosting criteria: https://www.gnu.org/software/repo-criteria-evaluation.html Please either stick with existing arrangements, or go with an ethical, accessible code/bug-host (e.g. SourceHut https://sr.ht ). Thanks, Sam Hi Github is better for people using screen readers than flyspray. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
On Fri, Jan 07, 2022 at 12:07:38PM +, Sam Kuper wrote: > On Fri, Jan 07, 2022 at 10:34:34AM +0100, Paul Spooren wrote: > > Instead of maintaining flyspray and the server, I’d like to export all > > flyspray issues, migrate them to GitHub and open GitHub issues for > > openwrt/openwrt to the public. > > Please don't do this. GitHub has substantial accessibility and privacy > flaws, compared to other options - and fails ethical code/bug-hosting > criteria: https://www.gnu.org/software/repo-criteria-evaluation.html > > Please either stick with existing arrangements, or go with an ethical, > accessible code/bug-host (e.g. SourceHut https://sr.ht ). +1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Switch issues and CI to GitHub
On Fri, Jan 07, 2022 at 10:34:34AM +0100, Paul Spooren wrote: > Instead of maintaining flyspray and the server, I’d like to export all > flyspray issues, migrate them to GitHub and open GitHub issues for > openwrt/openwrt to the public. Please don't do this. GitHub has substantial accessibility and privacy flaws, compared to other options - and fails ethical code/bug-hosting criteria: https://www.gnu.org/software/repo-criteria-evaluation.html Please either stick with existing arrangements, or go with an ethical, accessible code/bug-host (e.g. SourceHut https://sr.ht ). Thanks, Sam ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Switch issues and CI to GitHub
Hi all, Back at the Hamburg meeting in 2019 and a succeeding vote we decided to migrate over to a self-hosted GitLab instance. Some years passed and nothing really happened so I’d like to give this another go. None of the OpenWrt project members is willing to setup and maintain a GitLab instance and there were multiple vetos again gitlab.com. Our current bug tracker at bugs.openwrt.org is used by a minority of users (and devs), all community repositories (LuCI, packages, …) use GitHub for issue tracking. Instead of maintaining flyspray and the server, I’d like to export all flyspray issues, migrate them to GitHub and open GitHub issues for openwrt/openwrt to the public. A static or read-only version of flyspray could be hosted for the near future. Secondly I’d like to give the CI of the main repository another go. Our CI to build Docker images is currently on gitlab.com, I’d migrate that over to GitHub. Also I’d suggest to add similar CI checks as added to the packages (and routing and video and LuCI) repository. We could compile targets and tooling, check checksums etc, even build snapshots to lower the resource usage of our Buildbot infrastructure. During a recent _poll_ in #openwrt-adm multiple members liked the idea, however before doing or voting on anything, I’d like to ask for more comments. Thanks for all feedback, Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
