[OpenWrt-Devel] [PATCH] ramips: fix port display for TRENDnet TEW-810DR
Was unable to communicate TEW-810DR port order was inverted similar to the D-Link DIR-810L. Tested - Patch corrects port order. Signed-off-by: J. Scott Heppler --- target/linux/ramips/mt7620/base-files/etc/board.d/02_network | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ramips/mt7620/base-files/etc/board.d/02_network b/target/linux/ramips/mt7620/base-files/etc/board.d/02_network index c70e4ff8e4..f85b7cfed1 100755 --- a/target/linux/ramips/mt7620/base-files/etc/board.d/02_network +++ b/target/linux/ramips/mt7620/base-files/etc/board.d/02_network @@ -25,7 +25,6 @@ ramips_setup_interfaces() ralink,mt7620a-mt7610e-evb|\ ralink,mt7620a-v22sg-evb|\ sanlinking,d240|\ - trendnet,tew-810dr|\ youku,yk1|\ zbtlink,zbt-ape522ii|\ zbtlink,zbt-we826-16m|\ @@ -109,6 +108,7 @@ ramips_setup_interfaces() "0:lan" "6@eth0" ;; dlink,dir-810l|\ + trendnet,tew-810dr|\ zbtlink,zbt-we2026) ucidef_add_switch "switch0" \ "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan" "6@eth0" -- 2.20.1 -- J. Scott Heppler ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ubiformat: bad UBI magic
I am having some trouble with installing an OpenWrt image I built onto a Mikrotik RB493AH. I have been using a RB493G for a long time, but I just bought a 493AH to serve as a backup. The following, when run on the router, produces the error as indicated: $ ubiformat /dev/mtd6 -f /tmp/openwrt-ar71xx-mikrotik-nand-64m-rootfs.ubi ubiformat: 1 eraseblocks have valid erase counter, mean value is 0 ubiformat: 3839 eraseblocks are supposedly empty ubiformat: erase counter 0 will be used for all eraseblocks ubiformat: note, arbitrary erase counter value may be specified using -e option ubiformat: continue? (y/N) y ubiformat: warning!: VID header and data offsets on flash are 2048 and 4096, which is different to requested offsets 512 and 1024 ubiformat: use erase counter 0 for all eraseblocks ubiformat: use new offsets 512 and 1024? ubiformat: continue? (y/N) ubiformat: use offsets 512 and 1024 ubiformat: flashing eraseblock 0 -- 0 % complete ubiformat: flashing eraseblock 1 -- 0 % complete ubiformat: error!: bad UBI magic , should be 0x55424923 ubiformat: error!: bad EC header at eraseblock 1 of "/tmp/openwrt-ar71xx-mikrotik-nand-64m-rootfs.ubi" I suspect this is either a hardware problem or an incorrect use of mkfs.ubifs, ubinize, or ubiformat. Does anyone have any experience with the RB493AH? -- Mike :wq ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] toolchain: remove gcc libssp and use libc variant
On Thu, 11 Jun 2020 18:15:04 +0200 Hauke Mehrtens wrote: > On 6/6/20 1:42 AM, Ian Cooper wrote: > > Removes the standalone implementation of stack smashing protection > > in gcc's libssp in favour of the native implementation in musl, > > glibc and uClibc and introduces a uniform configuration interface. > > > > This also makes kernel-level stack smashing protection available > > for builds using non-musl libc (subject to architecture support). > > > > Signed-off-by: Ian Cooper > > --- > > > > Update fixes an artefact with menuconfig which caused a toolchain > > menu option to move to the front page of menuconfig due to the > > removal of a prompt associated with a different CONFIG_ variable. > > > > NOTE: after applying this patch you must do a make dirclean as the > > entire toolchain and all packages will need to be rebuilt. > > > > This patch does not change the behaviour ot the musl toolchain. > > There are no changes to the uclibc toolchain since it's already > > being compiled with it's native ssp implementation enabled. > > If a toolchain recompilation is only needed for glibc this should be ok. > > > > > > config/Config-build.in| 4 > > toolchain/Config.in | 6 +- > > toolchain/gcc/Config.in | 8 > > toolchain/glibc/common.mk | 3 ++- > > 4 files changed, 7 insertions(+), 14 deletions(-) > > > > diff --git a/config/Config-build.in b/config/Config-build.in > > index 61a9265ad7..ac1e05d2ff 100644 > > --- a/config/Config-build.in > > +++ b/config/Config-build.in > > @@ -249,7 +249,6 @@ menu "Global build settings" > > > > choice > > prompt "User space Stack-Smashing Protection" > > - depends on USE_MUSL > > default PKG_CC_STACKPROTECTOR_REGULAR > > help > > Enable GCC Stack Smashing Protection (SSP) for userspace > > applications > > @@ -257,18 +256,15 @@ menu "Global build settings" > > bool "None" > > config PKG_CC_STACKPROTECTOR_REGULAR > > bool "Regular" > > - select GCC_LIBSSP if !USE_MUSL > > depends on KERNEL_CC_STACKPROTECTOR_REGULAR > > config PKG_CC_STACKPROTECTOR_STRONG > > bool "Strong" > > - select GCC_LIBSSP if !USE_MUSL > > depends on KERNEL_CC_STACKPROTECTOR_STRONG > > Do you know why the user space stack protector depends on the kernel > stack protector? I assumed this should be independent? You should not > fix it in this patch, I am just curious and if this is not needed we > should fix it in an other patch. No I don't know why this dependency was initially created. I agree that on the face of it there should not be a dependency. A lot of this code is 12 - 15 years old, so there was probably a good reason at one point in time. > > > endchoice > > > > choice > > prompt "Kernel space Stack-Smashing Protection" > > default KERNEL_CC_STACKPROTECTOR_REGULAR > > - depends on USE_MUSL || !(x86_64 || i386) > > help > > Enable GCC Stack-Smashing Protection (SSP) for the kernel > > config KERNEL_CC_STACKPROTECTOR_NONE > > diff --git a/toolchain/Config.in b/toolchain/Config.in > > index 762f4e10d7..e2af1c2c8e 100644 > > --- a/toolchain/Config.in > > +++ b/toolchain/Config.in > > @@ -283,8 +283,12 @@ config USE_MUSL > > default y if !TOOLCHAINOPTS && !EXTERNAL_TOOLCHAIN && !NATIVE_TOOLCHAIN > > && !(arc) > > bool > > > > +config GCC_LIBSSP > > +default n > > +bool > > + > > As nothing activates GCC_LIBSSP it is always false. I think we can > remove this, this is not used by any package in the Kconfig part as far > as I see it and only in some Makefiles and should be removed there > later, but should not harm. The approach I was taking was to try to eliminate libssp by making as few changes as possible. Removing it here is fine, but then also requires the removal of the libssp package in package/libs/toolchain/Makefile and the removal of the dependency from include/package-defaults.mk as you point out below. There are two additional removals that should be made: in the host build of binutils, where the configure flag --enable-libssp can be removed in the file toolchain/binutils/Makefile and in toolchain/gcc/common.mk to remove the configure option to build libssp if GCC_LIBSSP is enabled. I left these in based on the minimal change philosophy. If you think complete removal in this way is desirable I'll make the changes, do a bunch of test builds and send an updated patch. A git grep shows three references to GCC_LIBSSP in the packages feed. > > > config SSP_SUPPORT > > - default y if USE_MUSL || GCC_LIBSSP > > + default y if !PKG_CC_STACKPROTECTOR_NONE > > bool > > > > config USE_EXTERNAL_LIBC > > diff --git a/toolchain/gcc/Config.in b/toolchain/gcc/Config.in > > index
Re: [OpenWrt-Devel] [PATCH v2] toolchain: remove gcc libssp and use libc variant
On 6/6/20 1:42 AM, Ian Cooper wrote: > Removes the standalone implementation of stack smashing protection > in gcc's libssp in favour of the native implementation in musl, > glibc and uClibc and introduces a uniform configuration interface. > > This also makes kernel-level stack smashing protection available > for builds using non-musl libc (subject to architecture support). > > Signed-off-by: Ian Cooper > --- > > Update fixes an artefact with menuconfig which caused a toolchain > menu option to move to the front page of menuconfig due to the > removal of a prompt associated with a different CONFIG_ variable. > > NOTE: after applying this patch you must do a make dirclean as the > entire toolchain and all packages will need to be rebuilt. > > This patch does not change the behaviour ot the musl toolchain. > There are no changes to the uclibc toolchain since it's already > being compiled with it's native ssp implementation enabled. If a toolchain recompilation is only needed for glibc this should be ok. > > config/Config-build.in| 4 > toolchain/Config.in | 6 +- > toolchain/gcc/Config.in | 8 > toolchain/glibc/common.mk | 3 ++- > 4 files changed, 7 insertions(+), 14 deletions(-) > > diff --git a/config/Config-build.in b/config/Config-build.in > index 61a9265ad7..ac1e05d2ff 100644 > --- a/config/Config-build.in > +++ b/config/Config-build.in > @@ -249,7 +249,6 @@ menu "Global build settings" > > choice > prompt "User space Stack-Smashing Protection" > - depends on USE_MUSL > default PKG_CC_STACKPROTECTOR_REGULAR > help > Enable GCC Stack Smashing Protection (SSP) for userspace > applications > @@ -257,18 +256,15 @@ menu "Global build settings" > bool "None" > config PKG_CC_STACKPROTECTOR_REGULAR > bool "Regular" > - select GCC_LIBSSP if !USE_MUSL > depends on KERNEL_CC_STACKPROTECTOR_REGULAR > config PKG_CC_STACKPROTECTOR_STRONG > bool "Strong" > - select GCC_LIBSSP if !USE_MUSL > depends on KERNEL_CC_STACKPROTECTOR_STRONG Do you know why the user space stack protector depends on the kernel stack protector? I assumed this should be independent? You should not fix it in this patch, I am just curious and if this is not needed we should fix it in an other patch. > endchoice > > choice > prompt "Kernel space Stack-Smashing Protection" > default KERNEL_CC_STACKPROTECTOR_REGULAR > - depends on USE_MUSL || !(x86_64 || i386) > help > Enable GCC Stack-Smashing Protection (SSP) for the kernel > config KERNEL_CC_STACKPROTECTOR_NONE > diff --git a/toolchain/Config.in b/toolchain/Config.in > index 762f4e10d7..e2af1c2c8e 100644 > --- a/toolchain/Config.in > +++ b/toolchain/Config.in > @@ -283,8 +283,12 @@ config USE_MUSL > default y if !TOOLCHAINOPTS && !EXTERNAL_TOOLCHAIN && !NATIVE_TOOLCHAIN > && !(arc) > bool > > +config GCC_LIBSSP > +default n > +bool > + As nothing activates GCC_LIBSSP it is always false. I think we can remove this, this is not used by any package in the Kconfig part as far as I see it and only in some Makefiles and should be removed there later, but should not harm. > config SSP_SUPPORT > - default y if USE_MUSL || GCC_LIBSSP > + default y if !PKG_CC_STACKPROTECTOR_NONE > bool > > config USE_EXTERNAL_LIBC > diff --git a/toolchain/gcc/Config.in b/toolchain/gcc/Config.in > index 7d7f34210a..4b2ba7aaae 100644 > --- a/toolchain/gcc/Config.in > +++ b/toolchain/gcc/Config.in > @@ -47,14 +47,6 @@ config GCC_DEFAULT_SSP > help > Use gcc configure option --enable-default-ssp to turn on > -fstack-protector-strong by default. > > -config GCC_LIBSSP > - bool > - prompt "Build gcc libssp" if TOOLCHAINOPTS > - depends on !USE_MUSL > - default y if !USE_MUSL > - help > - Enable Stack-Smashing Protection support > - > config SJLJ_EXCEPTIONS > bool > prompt "Use setjump()/longjump() exceptions" if TOOLCHAINOPTS > diff --git a/toolchain/glibc/common.mk b/toolchain/glibc/common.mk > index db4f0fcc0e..f0b95d3cc7 100644 > --- a/toolchain/glibc/common.mk > +++ b/toolchain/glibc/common.mk > @@ -39,7 +39,6 @@ ifeq ($(ARCH),mips64) >endif > endif > > - > # -Os miscompiles w. 2.24 gcc5/gcc6 > # only -O2 tested by upstream changeset > # "Optimize i386 syscall inlining for GCC 5" > @@ -61,6 +60,8 @@ GLIBC_CONFIGURE:= \ > --without-cvs \ > --enable-add-ons \ > --$(if $(CONFIG_SOFT_FLOAT),without,with)-fp \ > + $(if > $(CONFIG_PKG_CC_STACKPROTECTOR_REGULAR),--enable-stack-protector=yes) \ > + $(if >
Re: [OpenWrt-Devel] iwinfo: DFS channels are not listed
Hi, since nobody really uses the `restricted` field (apart from LuCI itself I believe) and since I'd like to avoid changing the ABI, I would be fine with changing the condition to NO_IR || DFS or even just DFS. Initially the restricted flag was supposed to give a hint to the ui which channels are unavailable (in the sense that the radio won't come up when these are selected) - however most drivers seems to actually support DFS nowadays so maybe we can drop the DFS condition entirely and only mark NO_IR channels as restricted. Regards, Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] iwinfo: DFS channels are not listed
Hi, DFS channels are not marked as DFS, even though iw will detect that just fine. Getting frequencies list through ubus/iwinfo will result in this output # iwinfo wlan0 freqlist 2.412 GHz (Channel 1) 2.417 GHz (Channel 2) 2.422 GHz (Channel 3) 2.427 GHz (Channel 4) 2.432 GHz (Channel 5) 2.437 GHz (Channel 6) 2.442 GHz (Channel 7) 2.447 GHz (Channel 8) 2.452 GHz (Channel 9) 2.457 GHz (Channel 10) 2.462 GHz (Channel 11) 5.180 GHz (Channel 36) 5.200 GHz (Channel 40) 5.220 GHz (Channel 44) 5.240 GHz (Channel 48) 5.260 GHz (Channel 52) 5.280 GHz (Channel 56) 5.300 GHz (Channel 60) 5.320 GHz (Channel 64) 5.500 GHz (Channel 100) 5.520 GHz (Channel 104) 5.540 GHz (Channel 108) 5.560 GHz (Channel 112) 5.580 GHz (Channel 116) 5.600 GHz (Channel 120) 5.620 GHz (Channel 124) 5.640 GHz (Channel 128) 5.660 GHz (Channel 132) 5.680 GHz (Channel 136) 5.700 GHz (Channel 140) 5.720 GHz (Channel 144) 5.745 GHz (Channel 149) 5.765 GHz (Channel 153) 5.785 GHz (Channel 157) 5.805 GHz (Channel 161) 5.825 GHz (Channel 165) However iw will correctly return DFS flags # iw list Frequencies: * 5180 MHz [36] (23.0 dBm) * 5200 MHz [40] (23.0 dBm) * 5220 MHz [44] (23.0 dBm) * 5240 MHz [48] (23.0 dBm) * 5260 MHz [52] (23.0 dBm) (radar detection) * 5280 MHz [56] (23.0 dBm) (radar detection) * 5300 MHz [60] (23.0 dBm) (radar detection) * 5320 MHz [64] (23.0 dBm) (radar detection) * 5500 MHz [100] (23.0 dBm) (radar detection) * 5520 MHz [104] (23.0 dBm) (radar detection) * 5540 MHz [108] (23.0 dBm) (radar detection) * 5560 MHz [112] (23.0 dBm) (radar detection) * 5580 MHz [116] (23.0 dBm) (radar detection) * 5600 MHz [120] (23.0 dBm) (radar detection) * 5620 MHz [124] (23.0 dBm) (radar detection) * 5640 MHz [128] (23.0 dBm) (radar detection) * 5660 MHz [132] (23.0 dBm) (radar detection) * 5680 MHz [136] (23.0 dBm) (radar detection) * 5700 MHz [140] (23.0 dBm) (radar detection) * 5720 MHz [144] (23.0 dBm) (radar detection) * 5745 MHz [149] (30.0 dBm) * 5765 MHz [153] (30.0 dBm) * 5785 MHz [157] (30.0 dBm) * 5805 MHz [161] (30.0 dBm) * 5825 MHz [165] (30.0 dBm) * 5845 MHz [169] (disabled) * 5865 MHz [173] (disabled) This is probably due to certain condition in iwinfo/src/iwinfo_nl80211.c line 2757 e->restricted = ( freqs[NL80211_FREQUENCY_ATTR_NO_IR] && !freqs[NL80211_FREQUENCY_ATTR_RADAR] ) ? 1 : 0; I'm not entirely sure what restricted is supposed to mean in this context. Perhaps it could be handy to add radar boolean flag (or something similar) to struct iwinfo_freqlist_entry, that would be independent of NL80211_FREQUENCY_ATTR_NO_IR. That would of course mean breaking/extending ABI and I'm not sure if that won't break other code as well. I have already prepared such changes and I can send a patch, but I would like to know first if this is the correct way to address this. Regards Martin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Merged: odhcpd: remove bogus IPKG_INSTROOT reference
Merged into my staging tree. Thank you! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 2/2] octeontx: enable Cavium CPT and ZIP drivers
On 6/3/20 10:16 PM, Tim Harvey wrote: > On Tue, Jun 2, 2020 at 3:21 PM Hauke Mehrtens wrote: >> >> On 6/2/20 7:05 PM, Tim Harvey wrote: >>> The CPT module requires firmware which we add here as well. >>> >>> Signed-off-by: Tim Harvey >>> --- >>> v2: added license file for firmware >>> --- >>> target/linux/octeontx/config-5.4 | 11 +++ >>> target/linux/octeontx/files/firmware/cpt8x-mc-ae.out | Bin 0 -> 9760 bytes >>> target/linux/octeontx/files/firmware/cpt8x-mc-se.out | Bin 0 -> 35584 bytes >>> target/linux/octeontx/files/firmware/license.txt | 11 +++ >>> 4 files changed, 22 insertions(+) >>> create mode 100644 target/linux/octeontx/files/firmware/cpt8x-mc-ae.out >>> create mode 100644 target/linux/octeontx/files/firmware/cpt8x-mc-se.out >>> create mode 100644 target/linux/octeontx/files/firmware/license.txt >>> >>> diff --git a/target/linux/octeontx/config-5.4 >>> b/target/linux/octeontx/config-5.4 >>> index cfb8b19..9fcd12b 100644 >>> --- a/target/linux/octeontx/config-5.4 >>> +++ b/target/linux/octeontx/config-5.4 >> .. >>> @@ -233,6 +239,8 @@ CONFIG_EEPROM_AT24=y >>> CONFIG_EFI_EARLYCON=y >>> CONFIG_EXT4_FS=y >>> CONFIG_EXT4_FS_POSIX_ACL=y >>> +CONFIG_EXTRA_FIRMWARE="cpt8x-mc-ae.out cpt8x-mc-se.out" >>> +CONFIG_EXTRA_FIRMWARE_DIR="firmware" >>> CONFIG_F2FS_FS=y >>> CONFIG_F2FS_FS_XATTR=y >>> CONFIG_F2FS_STAT_FS=y >> >>> >>> diff --git a/target/linux/octeontx/files/firmware/license.txt >>> b/target/linux/octeontx/files/firmware/license.txt >>> new file mode 100644 >>> index 000..531eaba >>> --- /dev/null >>> +++ b/target/linux/octeontx/files/firmware/license.txt >> >> Hi, >> >> I think this is not compatible with the OpenWrt license or at least goes >> into a gray area. >> >>> @@ -0,0 +1,11 @@ >>> +Copyright (C) 2019 Marvell International Ltd. >>> + >>> +The software package is subject to the Marvell binary license that >>> prohibits the >>> +licensee to modify the software, in any manner and that prohibits to >>> distribute >>> +the software as a stand-alone product. >> >> Is the distribution in >> target/linux/octeontx/files/firmware/cpt8x-mc-se.out not a standalone >> product? > > Hauke, > > I agree that this is a gray area for sure. I don't like the wording at > all either. > >> You can create a link to https://git.openwrt.org where you can directly >> download it when we push it into openwrt master. >> > > I'm not sure what you mean by this. Are you saying we can still push > the firmware binaries 'somewhere' on https://git.openwrt.org but not > include the build process? I do not know if such a link would be a distribution as a standalone product: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob_plain;f=target/linux/lantiq/files/firmware/lantiq/xrx200_phy11g_a14.bin;hb=HEAD I would prefer if the user has to get the firmware files from somewhere else if we wants to use this feature as long as Marvell is not willing to change the license. >>> +Any use of the software, in all or in >>> +part, shall not be made subject to or otherwise contaminated by, a >>> copyleft open >>> +source license (as defined by the Open Source Initiative), such as without >>> +limitation, GNU GPL or LGPL licenses. >> >> Adding this file in CONFIG_EXTRA_FIRMWARE could be seen as bundeling it >> with GPL code. >> >> The CONFIG_EXTRA_FIRMWARE option says this: >> WARNING: If you include additional firmware files into your binary >> kernel image that are not available under the terms of the GPL, >> then it may be a violation of the GPL to distribute the resulting >> image since it combines both GPL and non-GPL work. You should >> consult a lawyer of your own before distributing such an image. >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/base/firmware_loader/Kconfig#n32 >> >>> +Any software which integrates this code or any part of it thereof, should >>> +include in its header the above license. >> >> We would have to extend the license information for all our octeontx >> binaries to add this information. >> > > I can replace this with a patch that enables the cpt driver as a > module to make it easier for people to use but they will have to go > get firmware and place it in their /lib/firmware on their rootfs this > way. > >> >> If this firmware contains cryptography we could also violate some export >> control regulation, but normally no one cares. >> > > agreed. Having this as a module and the user has to download the firmware on his own would be nice. If you add a script to make it easier to download it would be nice, but not necessary in my opineon. If the system still works without this firmware I am also find with building this into the kernel if this would be needed. Hauke signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org
Re: [OpenWrt-Devel] Problems with e-mail DMARC policy, and other usability issues
Hello, On Thu, Jun 11, 2020 at 6:56 PM wrote: > Sorry, but this is not us being mean, it's just the fact that this kind of > spam protection and mailing list are inherently incompatible. > I don't think OP was asking for spam protection to be disabled... I think the main issue is the DMARC warning is being picked up by Patchwork as part of the commit message. OP's suggestions (forwarding/wrapping the original message without adding the DMARC warning text, switching to another patch management system like Gerrit, having Patchwork pick up patches from attachments) are workarounds for this issue. Jeff ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Problems with e-mail DMARC policy, and other usability issues
Hi, > ... does it though? I know it does traditionally, but... is that really > the only way? IFF you keep this, then yeah, sure, all the other > justifications are fine, but it's clearly not working well. in the past we did rewrite the sender to the list mail address and (iirc) added the original sender as Reply-To. While this generally works, it also mangles patches in a sense that the patch author is set to the mailing list address, which is generally not wanted. Nowadays it is probably not that critical since we have a hooks and checks in place to reject pushes with commits where Author != S-o-b and scripts [1] to rewrite the author based on the first S-o-b. It will add a bit of work for the maintainer though. > If the purpose of the mailing list is for automated processes to handle > patches from specially formatted mails, then. is it really the best > tool? (hahah oh, I made myself sad) Inspired by the op's mail I took a look if patchwork could theoretically handle patches as attachments, but it appears not to be the case, at least judging from what I've seen in the configuration. Personally, I'm not married to patchwork, any system that grabs patches out of a mailing list and puts them in some kind of database is fine. I have no idea though how complex hosting a Gerrit instance (and keeping it operational and updated over a number of years) is. Regards, Jo 1: https://git.openwrt.org/?p=maintainer-tools.git;a=blob;f=sob2from.sh signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Problems with e-mail DMARC policy, and other usability issues
wrote: > > However, the basic concept of a mailing list requires it to > change the From header. ... does it though? I know it does traditionally, but... is that really the only way? IFF you keep this, then yeah, sure, all the other justifications are fine, but it's clearly not working well. If the purpose of the mailling list is for human interaction, then I'd argue it most certainly does _not_ need to be doing this. If the purpose of the mailing list is for automated processes to handle patches from specially formatted mails, then. is it really the best tool? (hahah oh, I made myself sad) Sincerely, Karl Palsson OpenPGP-digital-signature.html Description: OpenPGP Digital Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Problems with e-mail DMARC policy, and other usability issues
Hi, > -Original Message- > From: R. Diez [mailto:rdiezmail-open...@yahoo.com] > Sent: Donnerstag, 11. Juni 2020 12:09 > To: openwrt-devel@lists.openwrt.org > Subject: Problems with e-mail DMARC policy, and other usability issues > > Hi all: > > I am trying to contribute a few trivial changes to OpenWrt. So far it has been > frustrating. I recently jumped through all the hoops and managed to e-mail > the patches correctly (or so I believe): > > http://lists.infradead.org/pipermail/openwrt-devel/2020-June/023887.html > http://lists.infradead.org/pipermail/openwrt-devel/2020-June/023888.html > > However, when I look at Patchwork, it has picked up the following lines as > part of the commit message: > > 8<8< > 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. > 8<8< > > I am sure you have seen that often in this mailing list. > > The Patchwork links where you can see that effect are: > > https://patchwork.ozlabs.org/project/openwrt/patch/mailman.21997.15917 > 81638.2542.openwrt-de...@lists.openwrt.org/ > > https://patchwork.ozlabs.org/project/openwrt/patch/mailman.22006.15917 > 83382.2542.openwrt-de...@lists.openwrt.org/ > > > I am not mailing list expert, but I have seen this problem recently with > Microsoft Office 365 and with many other open-source-based mailing lists. It > has been talked about everywhere because many e-mail providers have > been tightening e-mail policies in an uphill battle against spam. > > I am using Yahoo, which I am not particular proud of, but this is a general > issue affecting other providers. Under Patchwork, I could quickly find a few > other people who got those lines in their commit messages too. > > Microsoft had to change the way their online system handles mailing list e- > mails, and many other people had to change their ways too. > > From what I gathered, I believe it is reasonable for providers to demand that > you shall not forge e-mails (send e-mails pretending to be the user). > And that is what many mailing lists actually tried to do until recently. > > Could you please stop your mailing list server from adding that "The sender > domain has a DMARC..." warning? The server should do whatever wrapping / > "reply to" header / forwarding it needs to do, or it has been decided it is > best > to do, and stop warning about it. Well, the problem is that mailing lists and SPF don't work well together. The domain of your e-mail has a domain that has DMARC configured in way that means "Throw away this e-mail if the From header doesn't match the sender's address". However, the basic concept of a mailing list requires it to change the From header. So there is no nice way out. If the wrapping was removed, all recipients would receive a mail where the From: header won't match the sender's address. Their mail provider would then either move it to Spam or delete it right away, as that's what _your_ DMARC setting tells them. Don't know how patchwork will treat those mails, but most people on the list just wouldn't receive your mails anymore. Therefore, the wrapping provides a way to still have your mails delivered. There is a few ways out of it, but none of them is really compelling: - Disable spam protection on the sender side: If you don't use SPF/DMARC, you won't have any problems. It's just normal mail then. Of course, then you won't help others to identify spam anymore. - Adjust your DMARC policy to p=none . This will tell the sender side that it should still accept your mails even if SPF fails. That's what I'm using right now, and it doesn't have messages wrapped. Of course, it doesn't really provide a substantial spamming protection for the receiver anymore either. - Don't use mailing list if you want to use sender-based spam protection. Haha ... However, since you use a @yahoo.com mail address, you won't have control over your domain, and therefore cannot adjust the SPF/DMARC settings yahoo puts there. So, the options just discussed are effectively unavailable to you, except for the third one, which doesn't help you either. So, your options are limited now to 1. ask yahoo to disable/adjust DMARC/SPF, which I don't think they will do 2. get yourself a different mail address 3. live with the mail wrapping Sorry, but this is not us being mean, it's just the fact that this kind of spam protection and mailing list are inherently incompatible. (Another theoretical option might be to set up DKIM, as IIRC DMARC will be okay if either DKIM _or_ SPF is okay. However, setting up DKIM is almost impossible with one of the standard mail providers, and I'm not sure whether DKIM will survive the list anyway.) If I was wrong somewhere, I would be glad if one of the
[OpenWrt-Devel] Problems with e-mail DMARC policy, and other usability issues
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 --- Hi all: I am trying to contribute a few trivial changes to OpenWrt. So far it has been frustrating. I recently jumped through all the hoops and managed to e-mail the patches correctly (or so I believe): http://lists.infradead.org/pipermail/openwrt-devel/2020-June/023887.html http://lists.infradead.org/pipermail/openwrt-devel/2020-June/023888.html However, when I look at Patchwork, it has picked up the following lines as part of the commit message: 8<8< 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. 8<8< I am sure you have seen that often in this mailing list. The Patchwork links where you can see that effect are: https://patchwork.ozlabs.org/project/openwrt/patch/mailman.21997.1591781638.2542.openwrt-de...@lists.openwrt.org/ https://patchwork.ozlabs.org/project/openwrt/patch/mailman.22006.1591783382.2542.openwrt-de...@lists.openwrt.org/ I am not mailing list expert, but I have seen this problem recently with Microsoft Office 365 and with many other open-source-based mailing lists. It has been talked about everywhere because many e-mail providers have been tightening e-mail policies in an uphill battle against spam. I am using Yahoo, which I am not particular proud of, but this is a general issue affecting other providers. Under Patchwork, I could quickly find a few other people who got those lines in their commit messages too. Microsoft had to change the way their online system handles mailing list e-mails, and many other people had to change their ways too. From what I gathered, I believe it is reasonable for providers to demand that you shall not forge e-mails (send e-mails pretending to be the user). And that is what many mailing lists actually tried to do until recently. Could you please stop your mailing list server from adding that "The sender domain has a DMARC..." warning? The server should do whatever wrapping / "reply to" header / forwarding it needs to do, or it has been decided it is best to do, and stop warning about it. Some mailing list systems, like the OpenWrt forum, have no such issues when forwarding e-mails. I will also take this opportunity to mention again that Gerrit, while also somewhat annoying, provides a better user experience than Patchwork (in my opinion). You can upload your patch directly from Git without facing e-mail formatting issues, and it tells you whether your patch compiles, and even whether it conflicts with another patch (and which one). You can also comment directly on a patch. You can see it in action here: http://openocd.zylin.com I do not particularly advocate for Gerrit, as it has annoying usability issues too, but it is a reminder that patch management can be better. Patchwork does not seem able to pick up a patch from an e-mail attachment aptly named xxx.patch, and with an e-mail title that starts with [PATCH]. Or maybe it is the mailing list server making it difficult. This is an example: http://lists.infradead.org/pipermail/openwrt-devel/2020-June/023772.html The attachment was dropped with the notice "A non-text attachment was scrubbed...", even though it is all plain text (all byte values are < 127). Maybe the mailing list server just needs to learn that ".patch" is a common file extension used in development mailing lists. You may of course insist on making people jump through your hoops in order to contribute. Such hoops are for example changing e-mail provider, having to use "git send-email" because it is the only practical way to get it to work. Or having to write the first character in the commit line in lowercase, and remembering to remove the period at the end. Those procedures probably makes the maintainer's lives easier. It is like filling long, difficult forms when dealing with government bureaucracy: it makes the lives of the public servants easier. But we all find that very annoying. But my guess is that keeping such policies will damage the project in the long run. I have already noticed many small issues in the build system that I have not bothered to send a patch for in the last years because of the high barrier of entry. Ease of use is extremely important for most humans, more than one would reasonably assume. I personally can understand why people buy Apple or use Visual Studio Code, which is a newcomer that has become very popular very fast. Such software is just easier to use than the alternatives. I can also understand that you may not have the
[OpenWrt-Devel] [PATCH] ramips: fix IPv4-only corner case in 01_enable_packet_steering
The uci config section network.globals set up in /bin/config_generate
will only be created if /proc/sys/net/ipv6 exists.
Correspondingly, lacking IPv6 support, the command
uci set network.globals.packet_steering=1
will fail with "uci: Invalid argument" as the network.globals config
has not been set up.
Fix that by adding the setup there as well.
Fixes: dfd62e575c6c ("ramips: enable packet steering by default on mt7621")
Signed-off-by: Adrian Schmutzler
---
.../mt7621/base-files/etc/uci-defaults/01_enable_packet_steering | 1 +
1 file changed, 1 insertion(+)
diff --git
a/target/linux/ramips/mt7621/base-files/etc/uci-defaults/01_enable_packet_steering
b/target/linux/ramips/mt7621/base-files/etc/uci-defaults/01_enable_packet_steering
index 6a77229f29..114c7e1a46 100644
---
a/target/linux/ramips/mt7621/base-files/etc/uci-defaults/01_enable_packet_steering
+++
b/target/linux/ramips/mt7621/base-files/etc/uci-defaults/01_enable_packet_steering
@@ -1,4 +1,5 @@
uci -q get network.globals.packet_steering > /dev/null || {
+ uci set network.globals='globals'
uci set network.globals.packet_steering=1
uci commit network
}
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
