Re: [PATCH v2 03/10] base-files: upgrade: add get_image_dd()
Comments…
> On Nov 9, 2020, at 7:22 PM, Yousong Zhou wrote:
>
> This is mainly to handle stderr message "Broken pipe", "F+P records
> in/out" by common pattern "xcat | dd .."
>
> Ref: https://bugs.openwrt.org/index.php?do=details&task_id=3140
> Reported-by: Philip Prindeville
> Signed-off-by: Yousong Zhou
> ---
> package/base-files/files/lib/upgrade/common.sh | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/package/base-files/files/lib/upgrade/common.sh
> b/package/base-files/files/lib/upgrade/common.sh
> index e12dfc9678..6c09908ee3 100644
> --- a/package/base-files/files/lib/upgrade/common.sh
> +++ b/package/base-files/files/lib/upgrade/common.sh
> @@ -94,6 +94,12 @@ get_image() { # [ ]
> $cmd <"$from"
> }
>
> +get_image_dd() {
> + local from="$1"; shift
> +
> + ( get_image "$from" | dd "$@" ) 2>&1 | grep -v -E ': Broken pipe|
> records (in|out)'
Can you through stdout onto another descriptor first, like 3, then move 2 to 1,
run the grep, and then after the grep put 3 back onto 1?
I don’t like the idea of co-mingling stdout and stderr…
Thanks
> +}
> +
> get_magic_word() {
> (get_image "$@" | dd bs=2 count=1 | hexdump -v -n 2 -e '1/1 "%02x"')
> 2>/dev/null
> }
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 06/11] base-files: upgrade: fwtool.sh: rewording logs
Reviewed-By: Philip Prindeville
> On Nov 10, 2020, at 6:45 AM, Yousong Zhou wrote:
>
> The intent is to make it sound more like info level message, not some
> error like "404 not found". x86 target at the moment makes image with
> only signature but no metadata (ref commit f8141216 "x86: append
> metadata to combined images").
>
> Signed-off-by: Yousong Zhou
> ---
> package/base-files/files/lib/upgrade/fwtool.sh | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/package/base-files/files/lib/upgrade/fwtool.sh
> b/package/base-files/files/lib/upgrade/fwtool.sh
> index bf3059dbce..3826bf5c30 100644
> --- a/package/base-files/files/lib/upgrade/fwtool.sh
> +++ b/package/base-files/files/lib/upgrade/fwtool.sh
> @@ -10,7 +10,7 @@ fwtool_check_signature() {
> }
>
> if ! fwtool -q -s /tmp/sysupgrade.ucert "$1"; then
> - v "Image signature not found"
> + v "Image signature not present"
> [ "$REQUIRE_IMAGE_SIGNATURE" = 1 -a "$FORCE" != 1 ] && {
> v "Use sysupgrade -F to override this check when
> downgrading or flashing to vendor firmware"
> }
> @@ -30,7 +30,7 @@ fwtool_check_image() {
> . /usr/share/libubox/jshn.sh
>
> if ! fwtool -q -i /tmp/sysupgrade.meta "$1"; then
> - v "Image metadata not found"
> + v "Image metadata not present"
> [ "$REQUIRE_IMAGE_METADATA" = 1 -a "$FORCE" != 1 ] && {
> v "Use sysupgrade -F to override this check when
> downgrading or flashing to vendor firmware"
> }
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 04/11] base-files: upgrade: add get_image_dd()
Reviewed-By: Philip Prindeville
> On Nov 10, 2020, at 6:45 AM, Yousong Zhou wrote:
>
> This is mainly to handle stderr message "Broken pipe", "F+P records
> in/out" by common pattern "xcat | dd .."
>
> Ref: https://bugs.openwrt.org/index.php?do=details&task_id=3140
> Reported-by: Philip Prindeville
> Signed-off-by: Yousong Zhou
> ---
> package/base-files/files/lib/upgrade/common.sh | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/package/base-files/files/lib/upgrade/common.sh
> b/package/base-files/files/lib/upgrade/common.sh
> index 5eb7b23a83..a5c27dc2fb 100644
> --- a/package/base-files/files/lib/upgrade/common.sh
> +++ b/package/base-files/files/lib/upgrade/common.sh
> @@ -106,6 +106,17 @@ get_image() { # [ ]
> $cmd <"$from"
> }
>
> +get_image_dd() {
> + local from="$1"; shift
> +
> + (
> + exec 3>&2
> + ( exec 3>&2; get_image "$from" 2>&1 1>&3 | grep -v -F ' Broken
> pipe' ) 2>&1 1>&3 \
> + | ( exec 3>&2; dd "$@" 2>&1 1>&3 | grep -v -E ' records
> (in|out)') 2>&1 1>&3
> + exec 3>&-
> + )
> +}
> +
> get_magic_word() {
> (get_image "$@" | dd bs=2 count=1 | hexdump -v -n 2 -e '1/1 "%02x"')
> 2>/dev/null
> }
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 10/11] x86: upgrade: use get_image_dd
Reviewed-By: Philip Prindeville
> On Nov 10, 2020, at 6:45 AM, Yousong Zhou wrote:
>
> Ref: https://bugs.openwrt.org/index.php?do=details&task_id=3140
> Reported-by: Philip Prindeville
> Signed-off-by: Yousong Zhou
> ---
> target/linux/x86/base-files/lib/upgrade/platform.sh | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/target/linux/x86/base-files/lib/upgrade/platform.sh
> b/target/linux/x86/base-files/lib/upgrade/platform.sh
> index 617b267e68..0b54caea29 100644
> --- a/target/linux/x86/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/x86/base-files/lib/upgrade/platform.sh
> @@ -20,7 +20,7 @@ platform_check_image() {
> get_partitions "/dev/$diskdev" bootdisk
>
> #extract the boot sector from the image
> - get_image "$@" | dd of=/tmp/image.bs count=63 bs=512b 2>/dev/null
> + get_image_dd "$1" of=/tmp/image.bs count=63 bs=512b
>
> get_partitions /tmp/image.bs image
>
> @@ -83,7 +83,7 @@ platform_do_upgrade() {
> get_partitions "/dev/$diskdev" bootdisk
>
> #extract the boot sector from the image
> - get_image "$@" | dd of=/tmp/image.bs count=63 bs=512b >/dev/null
> + get_image_dd "$1" of=/tmp/image.bs count=63 bs=512b
>
> get_partitions /tmp/image.bs image
>
> @@ -94,7 +94,7 @@ platform_do_upgrade() {
> fi
>
> if [ -n "$diff" ]; then
> - get_image "$@" | dd of="/dev/$diskdev" bs=4096 conv=fsync
> + get_image_dd "$1" of="/dev/$diskdev" bs=4096 conv=fsync
>
> # Separate removal and addtion is necessary; otherwise,
> partition 1
> # will be missing if it overlaps with the old partition 2
> @@ -108,7 +108,7 @@ platform_do_upgrade() {
> while read part start size; do
> if export_partdevice partdev $part; then
> v "Writing image to /dev/$partdev..."
> - get_image "$@" | dd of="/dev/$partdev" ibs=512 obs=1M
> skip="$start" count="$size" conv=fsync
> + get_image_dd "$1" of="/dev/$partdev" ibs=512 obs=1M
> skip="$start" count="$size" conv=fsync
> else
> v "Unable to find partition $part device, skipped."
> fi
> @@ -116,7 +116,7 @@ platform_do_upgrade() {
>
> #copy partition uuid
> v "Writing new UUID to /dev/$diskdev..."
> - get_image "$@" | dd of="/dev/$diskdev" bs=1 skip=440 count=4 seek=440
> conv=fsync
> + get_image_dd "$1" of="/dev/$diskdev" bs=1 skip=440 count=4 seek=440
> conv=fsync
>
> platform_do_bootloader_upgrade "$diskdev"
> local parttype=ext4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] busybox: enable whois by default
I liked the idea of including whois. I think it should be one of those things that gets enabled if we’re not doing a super-skinny-build. And if I’m at a remote location and OpenWRT isn’t coming up enough for me to run “whois” on a laptop behind it, then having it on OpenWRT itself makes it that much more self-contained. > On Nov 18, 2020, at 12:22 AM, Josef Schlehofer > wrote: > > Hi guys, > > Thank you for your feedback. > I was surprised how fast this was rejected and I thought that there is > going to be some vote or discussion about it. My bad. > > I noticed that on OpenWrt forum, there are some requests like this [1] > to have whois present on their routers. We can be thinking about which > tools are essentials to you and which are you using. On the other hand, > why we should be using whois on a mobile phone or on websites. Because > in my opinion, It's all just a matter of taste. > > For now, I am satisfied with enabled whois in busybox and as I was doing > compile and run tests. I thought that it was a nice idea to share it > with you. > > Anyway, there isn't anything wrong with that! At least we have it > documented on the mailing list, so we can refer to it in the future. > > [1] > https://forum.openwrt.org/t/whois-binary-cannot-find-providing-package/31274 > > Regards, > > Josef > > > On 17. 11. 20 21:18, Paul Spooren wrote: >> On Mon Nov 16, 2020 at 9:14 PM HST, Petr Štetiar wrote: >>> Josef Schlehofer [2020-11-17 02:07:09]: >>> >>> Hi, >>> Whois can identify who owns a domain and how to get reach owner. Providing this tool in OpenWrt someone does not need to use websites for everything. >>> I don't think, that this tool is essential enough to be shipped by >>> default. >> I agree. >> >>> One can use whois on desktop or mobile phone for example. I think, that >>> packaging whois[1] shouldn't be that hard, then you've it one `opkg >>> install` >>> away. >>> >>> 1. https://github.com/rfc1036/whois >>> >>> Cheers, >>> >>> Petr >>> >>> ___ >>> 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: perl/host/compile: fails on macOS 11 Big Sur, workaround
> On Nov 23, 2020, at 2:52 PM, Rosen Penev wrote:
>
> On Mon, Nov 23, 2020 at 10:39 AM Georgi Valkov wrote:
>>
>> Dear Rosen,
>>
>> Thanks to your help I discovered the feeds/packages repository, however I
>> was not able to resolve the race condition during build and discover why
>> Errno.pm is not built when multiple workers are used e.g.: make
>> package/feeds/packages/perl/host/{clean,compile} -j 12
>>
>> The good news is that if we move to perl 5.30.0 or newer, the race condition
>> is resolved.
> That's very good.
>
>> We also need to add a few flags to files/base.config:
>> d_attribute_always_inline=‘define'
>> d_setlocale_accepts_any_locale_name=‘undef'
>> d_sockaddr_storage=‘undef’
>> d_towlower=‘undef'
>> d_towupper=‘undef'
>> d_wcrtomb=‘undef'
>> i_wctype=‘define’
>>
>> Then we can compile perl/host 5.30.0 up to 5.32.0. However building perl for
>> the target fails the install phase:
>>
>> error:
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
>> input file:
>> /Volumes/test/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/perl/perl-5.30.0/ipkg-install/usr/bin/perl5.30.0
>> is not a Mach-O file
>> Cannot update
>> /Volumes/test/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/perl/perl-5.30.0/ipkg-install/usr/bin/perl5.30.0
>> dependency paths
>> make[3]: *** [makefile:445: install-all] Error 1
>> make[3]: Leaving directory
>> '/Volumes/test/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/perl/perl-5.30.0'
>> make[2]: *** [Makefile:152:
>> /Volumes/test/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/perl/perl-5.30.0/.built]
>> Error 2
>>
>> Another symptom I see, is that with 5.30.0
>> build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/perl/perl-5.30.0/ipkg-install/usr/bin
>> contains only perl5.30.0, while with the original 5.28.1 it contains many
>> executables.
>>
>> Can you please update perl to 5.30.0 or 5.32.0? Just make sure it compiles
>> correctly on Linux or whatever environment you are using, and I will test it
>> on macOS 11. I seem to be missing something, and it might take me a very
>> long time to learn my way through, because I lack experience.
> I don't maintain perl. That's https://github.com/pprindeville . CC'ed
If you have a patch to update to 5.30, I’ll look at it.
-Philip
>>
>>
>> Thank you again for any help!
>> Georgi Valkov
>>
>>
>>> On 2020-11-18, at 10:32 AM, Georgi Valkov wrote:
>>>
>>>
>>>
On 2020-11-18, at 4:24 AM, Rosen Penev wrote:
On Tue, Nov 17, 2020 at 3:16 PM Georgi Valkov wrote:
>
> Dear OpenWRT team,
>
> I just updated my laptop to macOS 11 Big Sur. Presently only the perl
> hostpkg package fails during the build. Once I get past perl, everything
> else compiles correctly. Below is a patch, workaround, and details from
> my research. My target is Marvell EBU Armada, Linksys WRT3200ACM.
>
> Before applying the patch, make package/feeds/packages/perl/host/compile
> V=sc fails with the following error:
> Which of these apply, if any? [darwin]
>
> *** Unexpected product version 11.0.
> ***
> *** Try running sw_vers and see what its ProductVersion says.
>
> After the patch, make package/feeds/packages/perl/host/compile succeeds,
> however when multiple workers are used: make
> package/feeds/packages/perl/host/compile -j 12 V=sc, the build fails:
> Writing Makefile for CPAN
> make[4]: Entering directory
> '/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/Archive-Tar'
> make[4]: Entering directory
> '/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/CPAN'
> Generating a Unix-style Makefile
> Writing Makefile for Errno
> make[4]: Entering directory
> '/Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/ext/Errno'
> "../../miniperl" "-I../../lib" Errno_pm.PL Errno.pm
> Can't locate Errno.pm in @INC (you may need to install the Errno module)
> (@INC contains:
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/AutoLoader/lib
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/Carp/lib
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/PathTools
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/PathTools/lib
>
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/ExtUtils-Install/lib
>
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/ExtUtils-MakeMaker/lib
>
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/ExtUtils-Manifest/lib
>
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/cpan/File-Path/lib
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/ext/re
> /Volumes/test/openwrt/build_dir/hostpkg/perl/perl-5.28.1/dist/Term-ReadLine/lib
>
> /Volumes/test/o
IPsec (Strongswan) testing... help needed urgently
Hi, I’m working on a PR to add X.509 certificates to Strongswan for authentication and that all seems to be working fine: https://github.com/openwrt/packages/pull/14028 But I can’t figure out why my traffic isn’t being passed, even though the tunnel comes up: root@OpenWrt2:~# ip xfrm state src 174.27.7.72 dst 45.33.216.244 proto esp spi 0xc2390651 reqid 1 mode tunnel replay-window 0 flag af-unspec aead rfc4106(gcm(aes)) ... 128 anti-replay context: seq 0x0, oseq 0x0, bitmap 0x src 45.33.216.244 dst 174.27.7.72 proto esp spi 0xc6a9b1c6 reqid 1 mode tunnel replay-window 32 flag af-unspec aead rfc4106(gcm(aes)) ... 128 anti-replay context: seq 0x0, oseq 0x0, bitmap 0x root@OpenWrt2:~# ip xfrm policy src 192.168.3.0/24 dst 192.168.2.0/24 dir out priority 375423 tmpl src 174.27.7.72 dst 45.33.216.244 proto esp spi 0xc2390651 reqid 1 mode tunnel src 192.168.2.0/24 dst 192.168.3.0/24 dir fwd priority 375423 tmpl src 45.33.216.244 dst 174.27.7.72 proto esp reqid 1 mode tunnel src 192.168.2.0/24 dst 192.168.3.0/24 dir in priority 375423 tmpl src 45.33.216.244 dst 174.27.7.72 proto esp reqid 1 mode tunnel src 192.168.3.0/24 dst 192.168.1.0/24 dir out priority 375423 tmpl src 174.27.7.72 dst 45.33.216.244 proto esp spi 0xc2390651 reqid 1 mode tunnel src 192.168.1.0/24 dst 192.168.3.0/24 dir fwd priority 375423 tmpl src 45.33.216.244 dst 174.27.7.72 proto esp reqid 1 mode tunnel src 192.168.1.0/24 dst 192.168.3.0/24 dir in priority 375423 tmpl src 45.33.216.244 dst 174.27.7.72 proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 src ::/0 dst ::/0 socket in priority 0 src ::/0 dst ::/0 socket out priority 0 src ::/0 dst ::/0 socket in priority 0 src ::/0 dst ::/0 socket out priority 0 root@OpenWrt2:~# root@OpenWrt2:~# ip -4 addr show 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 9: eth3: mtu 1500 qdisc mq state UP group default qlen 1000 inet 174.27.7.72/19 brd 174.27.31.255 scope global eth3 valid_lft forever preferred_lft forever 17: br-lan: mtu 1500 qdisc noqueue state UP group default qlen 1000 inet 192.168.3.1/24 brd 192.168.3.255 scope global br-lan valid_lft forever preferred_lft forever root@OpenWrt2:~# root@OpenWrt2:~# ip -4 route show default via 174.27.0.1 dev eth3 proto static src 174.27.7.72 174.27.0.0/19 dev eth3 proto kernel scope link src 174.27.7.72 192.168.3.0/24 dev br-lan proto kernel scope link src 192.168.3.1 root@OpenWrt2:~# But if I do a “ping 192.168.1.252” then I see unencapsulated packets leaking out my “wan” (eth3) interface with my public (masqueraded) address: 10:33:06.093236 IP (tos 0x0, ttl 64, id 59993, offset 0, flags [DF], proto ICMP (1), length 84) 174.27.7.72 > 192.168.1.252: ICMP echo request, id 9506, seq 5, length 64 And doing “ping -I 192.168.3.1 192.168.1.252” doesn’t seem to make any difference. What would stop the XFRM’s from matching the traffic and causing it to be encapsulated? Only thing I can think of is that NATting is happening before the XFRM can happen, but that doesn’t make sense because the masquerading happens very late: -A zone_wan_postrouting -m comment --comment "!fw3" -j MASQUERADE The relevant parts (from what I can tell) of my /etc/config/firewall look like: config defaults option syn_flood1 option inputACCEPT option output ACCEPT option forward REJECT # Uncomment this line to disable ipv6 rules option disable_ipv6 1 option tcp_ecn 1 config zone option name vpn option inputACCEPT option output ACCEPT option forward ACCEPT option subnet '192.168.1.0/24' option extra_src'-m policy --dir in --pol ipsec --proto esp' option extra_dest '-m policy --dir out --pol ipsec --proto esp' option mtu_fix 1 ... config zone option name wan list network 'wan' list network 'wan6' option inputDROP option output ACCEPT option forward DROP option masq 1 option mtu_fix 0 option log 1 config forwarding option src lan option dest wan ... config
Lightweight policy-based routing
Hi.
I’m currently manually doing the following in a script but was wondering if
there was an easy way to do this in UCI, such as in /etc/config/network:
#!/bin/sh
INTF=xfrm0
STB=192.168.3.6/24
TABLE=stb
GW2=192.168.1.252
NETS="151.101.0.0/16"
eval `ipcalc -n -p $STB`
if ! grep -q "^200 $TABLE" /etc/iproute2/rt_tables; then
echo "200 $TABLE" >> /etc/iproute2/rt_tables
fi
for NET in $NETS; do
ip route add $NET via $GW2 dev $INTF table $TABLE
done
ip route add $NETWORK/$PREFIX dev br-lan table $TABLE
ip route flush cache
ip rule add from ${STB%%/*} table $TABLE
Basically, I have an STB that I travel with that mostly works on the road, but
one of the services is anchored to my home IP so I have to backhaul that with
VPN to get it to work, and that service is hosted on fastly.
Is there any easy way to integrate this into my OpenWRT config? (Yes, I also
have a RPi4 that I use as a portable pocket firewall/hotspot…)
Thanks,
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Lightweight policy-based routing
But I’m trying: config rule option src '192.168.3.6' option lookup 200 Per the cheatsheet and it’s resulting in: root@OpenWrt2:~# ip rule ls 0: from all lookup local 1: from all lookup 200 32766: from all lookup main 32767: from all lookup default i.e. the ’src’ is being ignored. Also trying: config route option target '151.101.0.0/16' option interface ‘xfrm0' option gateway '192.168.1.252' option table 200 option proto ‘static' But that works great. > On Dec 4, 2020, at 1:00 PM, Jo-Philipp Wich wrote: > > Hi Philip, > > ip rules are possible in uci, but not sure if all the bits you require are > covered: > > https://openwrt.org/docs/guide-user/network/ucicheatsheet#ip_rules_for_both_rule_and_rule6 > > `config route` sections allow specifying `option table` as well to stage the > routes in the non-main rttable. > > Since the device options for uci rules and routes require logical networks and > not Linux network device names, you might need to declare a dummy interface > for xfrm0, like this: > > config interface vpn > option proto static > option ifname xfrm0 > > It might be that netifd will clear out any IP addresses on the xfrm0 > interface, so you would need to encode those in uci as well: > > config interface vpn > option proto static > option ifname xfrm0 > option ipaddr 192.168.1.0/24 > option table 200 # will instruct netifd to put any related routes into > table 200 > > > Netifd understands aliases set up in /etc/iproute2/rt_tables but there is no > uci way to declare new symbolic aliases. So either you need to manage that > file externally or you stick to numeric table IDs. > > ~ Jo > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] remove x86 qemu images
> On Dec 7, 2020, at 1:28 AM, Florian Eckert wrote: > > Hi, > >> openwrt.git includes an old version of QEMU (0.14 vs 5.1.0 in >> packages.git) only to convert x86 images to vdi and vmdk. Is there >> anyone actively using the vanilla x86 QEMU images from the upstream >> servers or can can we remove that "feature"? > > I am building my own openwrt. > So I do not use the upstream vmdk image. > But I use the generated vmdk image by the image builder for a few tests. > > If we remove a feature, then we should offer an alternative. > Even if it is only a command. > > Regards > > Florian I have a few cheap (Xeon-D) KVM servers lying around that I wouldn’t mind putting into a CI/CD pipeline for testing x86 (and x86_64) builds, but don’t have the time. If someone else wanted to do the integration I would host it (hint, hint). So potentially, Qemu integration is still useful. That said, though, I’d probably test .img’s and not .vmdk files… -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Bind + ISC dhcpd integration (for intranet split-horizon, etc)
Hi, I’m the maintainer of ISC-DHCP. I’m trying to do the integration “glue” to allow one to operate a DNS private zone inside your intranet (aka “split horizon”) and prime it with both static data as well as DHCP lease information. Ideally this could be done with a minimum of UCI configuration and canned configurations. I tried to follow a couple of examples of this online: https://www.talk-about-it.ca/setup-bind9-with-isc-dhcp-server-dynamic-host-registration/ https://docs.oracle.com/cd/E19469-01/820-6410-12/app_example_dns.html But couldn’t get either to work demonstrably. Has anyone else managed to get this working, and if so, would they share the details of how they did it? I’ve followed the steps and I’m not seeing any errors, but I’m not able to resolve the dynamic host names, either. Some of the details of what I’ve tried are here: https://lists.isc.org/pipermail/bind-workers/2020-December/003530.html It’s probably something trivial but I can’t put my finger on it. Any help is appreciated. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Bind + ISC dhcpd integration (for intranet split-horizon, etc)
> On Dec 15, 2020, at 1:22 AM, Bjørn Mork wrote: > > Philip Prindeville writes: > >> I’m trying to do the integration “glue” to allow one to operate a DNS >> private zone inside your intranet (aka “split horizon”) and prime it >> with both static data as well as DHCP lease information. > > “split horizon” is a very bad idea, and should not be encouraged. Can you say more about that? I don’t see why the converse would be any better, i.e. publishing RFC-1918 addresses of NATted hosts behind a firewall, and disclosing more information than is necessary anyway… > >> Ideally this could be done with a minimum of UCI configuration and canned >> configurations. >> >> I tried to follow a couple of examples of this online: >> >> https://www.talk-about-it.ca/setup-bind9-with-isc-dhcp-server-dynamic-host-registration/ >> >> https://docs.oracle.com/cd/E19469-01/820-6410-12/app_example_dns.html >> >> But couldn’t get either to work demonstrably. Has anyone else managed >> to get this working, and if so, would they share the details of how >> they did it? >> >> I’ve followed the steps and I’m not seeing any errors, but I’m not >> able to resolve the dynamic host names, either. Some of the details >> of what I’ve tried are here: >> >> https://lists.isc.org/pipermail/bind-workers/2020-December/003530.html >> >> It’s probably something trivial but I can’t put my finger on it. > > You need to post your configs. See here: https://github.com/openwrt/packages/pull/14233 Looking for testers, if anyone is interested. I don’t have an easy way to do 172.16.0.0/12 or 10.0.0.0/8 testing… but I might add support for those if someone can test it. I think the problem was that neither example that I was going by included "ddns-updates on;” which obvious was the “secret sauce” missing. Seems kind of obvious in retrospect. > > Missing those, I tried to look at the examples you point to. The first > one doesn't resolve due to serious errors in the DNS configuration, so I > will assume that ANY advice you found there is plain wrong (I guess > someone here is unable to spell DNS): > > > bjorn@miraculix:~$ dig www.talk-about-it.ca +trace > > ; <<>> DiG 9.16.8-Debian <<>> www.talk-about-it.ca +trace > ;; global options: +cmd > . 516931 IN NS f.root-servers.net. > . 516931 IN NS g.root-servers.net. > . 516931 IN NS h.root-servers.net. > . 516931 IN NS i.root-servers.net. > . 516931 IN NS j.root-servers.net. > . 516931 IN NS k.root-servers.net. > . 516931 IN NS l.root-servers.net. > . 516931 IN NS m.root-servers.net. > . 516931 IN NS a.root-servers.net. > . 516931 IN NS b.root-servers.net. > . 516931 IN NS c.root-servers.net. > . 516931 IN NS d.root-servers.net. > . 516931 IN NS e.root-servers.net. > . 516931 IN RRSIG NS 8 0 518400 2020122805 > 2020121504 26116 . > FhG5WBLPhzoCY01sZlB76cBR5OyhyjACLV1V3QrwUISVBRhucfjtm+0K > rfw857zJ39mEX/oV7uTat3WjavPIjDqL+6YIRq18FqE9BX+vaYzUUDgU > fZgLF/4MM9kQjsYIIiX+HUZGxT2IdYfP8YLO5q+2I5B53PS4iw9lK1aT > 66FIx+OEKGVdEwVAFTOgH3GQB2R0A52VByfbMYotj0YxbdnQ6g+OVfwD > Xzud5Cf3imyqb4PY7P4mBvgZszLET/uUbfHje4eyesjK0cFwoW8txAEA > 7Pu/Bs13/s79r76pk5jFtbKwDgXAWPj+60jdk7bZPEoxU9x+6P+jtfAq BK4ZQQ== > ;; Received 1125 bytes from 148.122.16.253#53(148.122.16.253) in 248 ms > > ca. 172800 IN NS c.ca-servers.ca. > ca. 172800 IN NS j.ca-servers.ca. > ca. 172800 IN NS x.ca-servers.ca. > ca. 172800 IN NS any.ca-servers.ca. > ca. 86400 IN DS 2134 8 2 > 4B8475C0C0FE2AFDFEE1A71A237C91059098D12FC18265B290EDB238 A5F63582 > ca. 86400 IN RRSIG DS 8 1 86400 2020122805 > 2020121504 26116 . > bNnIysh6MYhpbK6KBAuQt24vxB+wU838f07IxOCAjbnru4IHyLrcjCF+ > 3zz2ctSrUJ/5EQOHdi+rbDdOiCsQg3eOhLO/xqFDjy8M+yapBZxolhNJ > pvcIKcfOVfuIgPTq8ZcvxYV+/M7i5dD89yDaJ2X7DcHauMryaNjO+xb5 > +LchwPmUsGtWKH/gABBSPy7U+W3OM5fgDEVVTh1SjHqU5CH1+Mpf6W0Y > y6JIsXQheb1feNdPZT1H+LkJEyeXsuKe9eUFFqHwlSGezlPQkkbHCObT > k+S+RoN6XrH8qn9ysU3FDCdSPiVPhC6WOM2fFNJTT6nZLmtZf/KYujRb H8sxQw== > ;; Received 637 bytes from 2001:503:ba3e::2:30#5
Re: Bind + ISC dhcpd integration (for intranet split-horizon, etc)
> On Dec 16, 2020, at 12:59 AM, Bjørn Mork wrote:
>
> Philip Prindeville writes:
>>> On Dec 15, 2020, at 1:22 AM, Bjørn Mork wrote:
>>>
>>> Philip Prindeville writes:
>>>
>>>> I’m trying to do the integration “glue” to allow one to operate a DNS
>>>> private zone inside your intranet (aka “split horizon”) and prime it
>>>> with both static data as well as DHCP lease information.
>>>
>>> “split horizon” is a very bad idea, and should not be encouraged.
>>
>>
>> Can you say more about that?
>
> It breaks the basic DNS premise: There is one distributed database.
I don’t know how concrete that premise is: why would Bind have ‘views’ if there
was a single, global version of the database?
> The fallout is broken DNSSEC, lame delegations, failing services, broken
> caches etc. Most of these are results of the added operational
> complexity. Feeble attempts to simplify split DNS also often involve
> breaking best practices, like having authoritative servers in more than
> one AS.
This is for the SoHo scenario where the firewall provides both DNS, DNS
forwarding, DHCP, and connectivity. If that device fails, everything does
anyway.
> All this might have been acceptable if it solved a real problem. It
> doesn't.
>
>> I don’t see why the converse would be any better, i.e. publishing
>> RFC-1918 addresses of NATted hosts behind a firewall,
>
> This is not a problem. There is nothing special about RFC 1918, or any
> other, addresses in DNS. DNS replies comes without any guarantee about
> firewalls, routing or provided public services. Software which assumes
> otherwise is buggy, with very few exceptions.
That’s not my concern. I don’t want to admit the existence of devices which
aren’t reachable to begin with, if (a) they have unroutable addresses and (b)
there is no port-forwarding to reach them.
Disclosing information about internal resources… possibly critical or sensitive
resources… without any need to do so is a mistake. Why give potential
attackers additional information with which to prepare an attack?
> The classic example of such bugs is the claimed "rebind protection" in
> dnsmasq. Which
> a) breaks valid configurations
> b) doesn't do rebind protection
>
>> and disclosing more information than is necessary anyway…
>
> I realize this is important to some. But split DNS will not protect
> this information. You should not put anything you don't want to
> disclose in DNS.
Sure it protects it. The name server that contains this information about my
hosts also serves that information to the only hosts that need it. It’s
configured as:
options {
...
allow-query {
localhost;
192.168.1.0/24;
192.168.2.0/24;
192.168.3.0/24;
};
...
};
>
>> See here:
>>
>> https://github.com/openwrt/packages/pull/14233
>
> Huh? Can't find anything related to dynamic DNS in either BIND or ISC
> dhcp there?
Doh. Wrong PR:
https://github.com/openwrt/packages/pull/14240
The previous one is a precursor for getting Bind to start before DHCPD.
>
>> Well, doing an RTFM I see:
>>
>> The ddns-update-style parameter
>>
>> ddns-update-style style;
>>
>>The style parameter must be one of ad-hoc, interim or none. The
>>ddns-update-style statement is only meaningful in the outer scope
>>- it is evaluated once after reading the dhcpd.conf file, rather
>>than each time a client is assigned an IP address, so there is no
>>way to use different DNS update styles for different clients. The
>>default is none.
>
> My manual says
>
>ddns-update-style style;
>
>The style parameter must be one of standard, interim or
>none. The ddns-update-style statement is only meaningful in
>the outer scope - it is evaluated once after reading the
>dhcpd.conf file, rather than each time a client is assigned
>an IP address, so there is no way to use different DNS
>update styles for different clients. The default is none.
Serves me right for looking at the Ubuntu 18.04 LTS man page…
Okay, fixed to use “standard”.
Thanks for that.
-Philip
>
> The "standard" style was introduced in commit d7d9c0c7c36d ("-n [master]
> Add code to support the standards version of DDNS") in 2013. It was
> released with version 4.3 in 2014.
>
>
>
> Bjørn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Bind + ISC dhcpd integration (for intranet split-horizon, etc)
Responses… > On Dec 17, 2020, at 1:56 AM, Bjørn Mork wrote: > > Philip Prindeville writes: > >> https://github.com/openwrt/packages/pull/14240 >> >> The previous one is a precursor for getting Bind to start before DHCPD. > > > That makes more sense yes. > > I looked at it briefly. A couple of notes without testing: > > I would not have used a key named "rdnc"-anything for zone updates. > rndc is the remote management tool for BIND, and most users will > probably assume that a key with such a name is dedicated to restricting > rndc access. Okay, I’ll rename the key. So it should be a separate key from the one that rndc uses for reloads, etc? > And I would have defined a limited "update-policy" for each key/identity > instead of using "allow-update". You probably only want the DHCP server > to modify A records in the forward zone and PTR records in the reverse > zone. Can you walk us through that? > Alternatively, you might want to consider "update-policy local" since > BIND and the DHCP server runs on the same host. Well… maybe not necessarily. I’m thinking about how to support distributed DHCP servers, and getting keys out to the DHCP servers so they can be authoritative for subnets that they’re responsible for, but still push updates to a single intranet DNS server. > This has the advantage > that only local clients are allowed to do updates. BIND will > automatically generate a HMAC-SHA256 session key named “local-ddns” and > store it in /var/run/named/session.key (These defaults can be adjusted > using session-keyfile, session-keyname, and session-keyalg options). > Just point the DHCP server to that file and key name. Hmmm… That seems both handy and risky at the same time. And… https://kb.isc.org/docs/aa-01599 Turns out it was risky. But fixed now, so… here goes. Please see the updated PR. -Philip > Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Bind + ISC dhcpd integration (for intranet split-horizon, etc)
Heads up that there’s a major change to the PR: https://github.com/openwrt/packages/pull/14240 It adds support for “cname”, “domain”, “mxhost”, and “srvhost” config sections. Thanks to Bjorn for pointing me at how to use nsupdate to do this. Calling out run-time requirements on “named” and “nsupdate” in the dependencies. Still trying to work through a start/boot problem where Bind doesn’t seem to listen on all interfaces (what’s surprising is that these aren’t even DHCP’d interfaces… even “wan” has a static address assigned). If anyone has any suggestions on how to troubleshoot this, please speak up. Looking at lib/ns/interfacemgr.c, it seems that Bind detects RTM_NEWADDR and RTM_DELADDR messages from Netlink so no external prodding should be required to handle interface changes. (Though I don’t see RTM_NEWLINK in the source code… but maybe just catching addresses is enough; I’ve not dug very deep there.) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH 1/2] base-files: sysupgrade: add function for conffiles retrieval
Reviewed-by: Philip Prindeville
> On Jul 10, 2020, at 4:47 AM, Adrian Schmutzler
> wrote:
>
> The find command to retrieve files from /etc/sysupgrade.conf and
> /lib/upgrade/keep.d/* is used twice in almost similar way.
>
> Move it into a function to consolidate, enhance readability and make
> future adjustments easier.
>
> Signed-off-by: Adrian Schmutzler
> ---
> package/base-files/files/sbin/sysupgrade | 18 +++---
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/package/base-files/files/sbin/sysupgrade
> b/package/base-files/files/sbin/sysupgrade
> index ca2eb298dc..4ecea5a303 100755
> --- a/package/base-files/files/sbin/sysupgrade
> +++ b/package/base-files/files/sbin/sysupgrade
> @@ -131,12 +131,18 @@ list_changed_conffiles() {
> done
> }
>
> +list_static_conffiles() {
> + local filter=$1
> +
> + find $(sed -ne '/^[[:space:]]*$/d; /^#/d; p' \
> + /etc/sysupgrade.conf /lib/upgrade/keep.d/* 2>/dev/null) \
> + \( -type f -o -type l \) $filter 2>/dev/null
> +}
> +
> add_conffiles() {
> local file="$1"
> - ( find $(sed -ne '/^[[:space:]]*$/d; /^#/d; p' \
> - /etc/sysupgrade.conf /lib/upgrade/keep.d/* 2>/dev/null) \
> - \( -type f -o -type l \) $find_filter 2>/dev/null;
> - list_changed_conffiles ) | sort -u > "$file"
> +
> + ( list_static_conffiles "$find_filter"; list_changed_conffiles ) | sort
> -u > "$file"
> return 0
> }
>
> @@ -154,9 +160,7 @@ add_overlayfiles() {
>
> # backup files from /etc/sysupgrade.conf and
> /lib/upgrade/keep.d, but
> # ignore those aready controlled by opkg conffiles
> - find $(sed -ne '/^[[:space:]]*$/d; /^#/d; p' \
> - /etc/sysupgrade.conf /lib/upgrade/keep.d/* 2>/dev/null)
> \
> - \( -type f -o -type l \) 2>/dev/null | sort -u |
> + list_static_conffiles | sort -u |
> grep -h -v -x -F -f $conffiles > "$keepfiles"
>
> # backup conffiles, but only those changed if '-u'
> --
> 2.20.1
>
>
> ___
> 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: [PATCH] scripts/qemustart: use squashfs instead of ext4
Reviewed-by: Philip Prindeville
> On Dec 29, 2020, at 4:13 PM, Paul Spooren wrote:
>
> The qemustart script currently picks the ext4 filesystem rather than
> squashfs, while the latter is default for nearly all OpenWrt targets.
>
> Change the default behaviour of qemustart to be in line with the rest.
>
> Signed-off-by: Paul Spooren
> ---
> scripts/qemustart | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/qemustart b/scripts/qemustart
> index 7a2878ea70..f0ddefb839 100755
> --- a/scripts/qemustart
> +++ b/scripts/qemustart
> @@ -257,7 +257,7 @@ start_qemu_x86() {
> local mach="${o_mach:-pc}"
>
> [ -n "$rootfs" ] || {
> -
> rootfs="$o_bindir/openwrt-$o_target-${o_subtarget%-*}-generic-ext4-combined.img"
> +
> rootfs="$o_bindir/openwrt-$o_target-${o_subtarget%-*}-generic-squashfs-combined.img"
> if [ ! -f "$rootfs" -a -s "$rootfs.gz" ]; then
> gunzip "$rootfs.gz"
> fi
> --
> 2.29.2
>
>
> ___
> 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: [PATCH] scripts/qemustart: use squashfs instead of ext4
Reviewed-by: Philip Prindeville
> On Dec 29, 2020, at 4:13 PM, Paul Spooren wrote:
>
> The qemustart script currently picks the ext4 filesystem rather than
> squashfs, while the latter is default for nearly all OpenWrt targets.
>
> Change the default behaviour of qemustart to be in line with the rest.
>
> Signed-off-by: Paul Spooren
> ---
> scripts/qemustart | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/qemustart b/scripts/qemustart
> index 7a2878ea70..f0ddefb839 100755
> --- a/scripts/qemustart
> +++ b/scripts/qemustart
> @@ -257,7 +257,7 @@ start_qemu_x86() {
> local mach="${o_mach:-pc}"
>
> [ -n "$rootfs" ] || {
> -
> rootfs="$o_bindir/openwrt-$o_target-${o_subtarget%-*}-generic-ext4-combined.img"
> +
> rootfs="$o_bindir/openwrt-$o_target-${o_subtarget%-*}-generic-squashfs-combined.img"
> if [ ! -f "$rootfs" -a -s "$rootfs.gz" ]; then
> gunzip "$rootfs.gz"
> fi
> --
> 2.29.2
>
>
> ___
> 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: [PATCH] kexec-tools: update to 2.0.21
Just because GDB can be used as an alternative, it’s not clear that we should force people into that. > On Dec 29, 2020, at 5:05 PM, Rosen Penev wrote: > > kdump was removed in 7acd257ae67b4ca94f8c23cb8bda0ee0709b9216 > > gdb can be used as an alternative. > > Remove autoreconf. It's not needed as the configure files are already > generated. > > Remove upstreamed patch. > > Signed-off-by: Rosen Penev > --- > package/boot/kexec-tools/Makefile | 42 ++- > ...rela-relocation-R_X86_64_PLT32-error.patch | 14 --- > 2 files changed, 3 insertions(+), 53 deletions(-) > delete mode 100644 > package/boot/kexec-tools/patches/100-kexec-tools-fix-for-Unhandled-rela-relocation-R_X86_64_PLT32-error.patch > > diff --git a/package/boot/kexec-tools/Makefile > b/package/boot/kexec-tools/Makefile > index 269345aa9d..36fe53671a 100644 > --- a/package/boot/kexec-tools/Makefile > +++ b/package/boot/kexec-tools/Makefile > @@ -8,14 +8,12 @@ > include $(TOPDIR)/rules.mk > > PKG_NAME:=kexec-tools > -PKG_VERSION:=2.0.16 > -PKG_RELEASE:=2 > +PKG_VERSION:=2.0.21 > +PKG_RELEASE:=1 > > PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz > PKG_SOURCE_URL:=@KERNEL/linux/utils/kernel/kexec > -PKG_HASH:=5b103351ad752c9badd1d65b00eb6de4bce579f944f4df4e3ef3a755ba567010 > - > -PKG_FIXUP:=autoreconf > +PKG_HASH:=e113142dee891638ad96e0f72cf9277b244477619470b30c41999d312e8e8702 > > PKG_CONFIG_DEPENDS := CONFIG_KEXEC_ZLIB CONFIG_KEXEC_LZMA > > @@ -51,17 +49,6 @@ define Package/kexec/description > The kexec utility allows to load and boot another kernel. > endef > > -define Package/kdump > - $(call Package/kexec-tools/Default) > - TITLE:=Kernel crash analysis > - DEPENDS:=+kexec @(i386||x86_64||arm) @KERNEL_CRASH_DUMP > -endef > - > -define Package/kdump/description > - The kdump package allows to automatically boot into a > - special kernel for analyzing kernel crashes using kdump. > -endef > - > define Package/kexec/config > source "$(SOURCE)/Config.in" > endef > @@ -108,28 +95,5 @@ define Package/kexec/install > $(LN) ../usr/sbin/kexec $(1)/sbin/kexec > endef > > -define Package/kdump/install > - $(INSTALL_DIR) $(1)/usr/sbin $(1)/etc/init.d $(1)/etc/config > $(1)/etc/uci-defaults > - $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/sbin/kdump > $(PKG_INSTALL_DIR)/usr/sbin/vmcore-dmesg $(1)/usr/sbin > - $(INSTALL_BIN) ./files/kdump.init $(1)/etc/init.d/kdump > - $(INSTALL_BIN) ./files/kdump.defaults $(1)/etc/uci-defaults/kdump > - $(INSTALL_CONF) ./files/kdump.config $(1)/etc/config/kdump > -endef > - > -define Package/kdump/prerm > -#!/bin/sh > - > -case $$(uname -m) in > - i?86|x86_64) > - if grep -q " crashkernel=" /boot/grub/grub.cfg; then > - mount /boot -o remount,rw > - sed -i 's/ crashkernel=[^ ]*//' /boot/grub/grub.cfg > - mount /boot -o remount,ro > - fi > - ;; > -esac > -endef > - > $(eval $(call BuildPackage,kexec-tools)) > $(eval $(call BuildPackage,kexec)) > -$(eval $(call BuildPackage,kdump)) > diff --git > a/package/boot/kexec-tools/patches/100-kexec-tools-fix-for-Unhandled-rela-relocation-R_X86_64_PLT32-error.patch > > b/package/boot/kexec-tools/patches/100-kexec-tools-fix-for-Unhandled-rela-relocation-R_X86_64_PLT32-error.patch > deleted file mode 100644 > index dfad21992b..00 > --- > a/package/boot/kexec-tools/patches/100-kexec-tools-fix-for-Unhandled-rela-relocation-R_X86_64_PLT32-error.patch > +++ /dev/null > @@ -1,14 +0,0 @@ > -diff --git a/kexec/arch/x86_64/kexec-elf-rel-x86_64.c > b/kexec/arch/x86_64/kexec-elf-rel-x86_64.c > -index 7fdde73..af33689 100644 > a/kexec/arch/x86_64/kexec-elf-rel-x86_64.c > -+++ b/kexec/arch/x86_64/kexec-elf-rel-x86_64.c > -@@ -78,7 +78,8 @@ void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr), > - if ((int64_t)value != *(int32_t *)location) > - goto overflow; > - break; > --case R_X86_64_PC32: > -+case R_X86_64_PC32: > -+case R_X86_64_PLT32: > - *(uint32_t *)location = value - address; > - break; > - default: > -- > 2.29.2 > > > ___ > 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
Job board support on openwrt.org?
Hi, Is anyone interested in adding a page to the openwrt.org site about developers willing to do commercial work? It could be as simple as: * name * email address * mobile (if wanted) * packages/platforms/architectures you maintain or have competence in * whether you're available full-time, part-time, or currently unavailable Might be useful for matching up devs with work. Just an idea to help our community prosper. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Need review of adding X.509 certs to Strongswan
Hi, I posted the following PR some time ago (late November) and it's languishing: https://github.com/openwrt/packages/pull/14028 Can I get some reviews of it? X.509 authentication is a more attractive alternative to simple PSK authentication (more entropy, less susceptible to dictionary attacks, etc). It's a short series of commits that do: * suppress multiple logging in /var/log/messages for authentication messages; * adds the /etc/swanctl/conf.d/ which is read from /etc/swanctl/swanctl.conf but doesn't exist; * cleans up some of the UCI and corrects the handling of the "updown" and "firewall" scripts (there is no "left" or "right" version, since it's always local by definition); * adds new parameters "reauth", "fragmentation", "closeaction", "mobile" for greater completeness; * the X.509 support, which is the most important part of this PR, but is actually a fairly trivial change; * add support for a global "setup" config section, which contains the "cachecrls", "charondebug", "strictcrlpolicy", and "uniqueids" parameters; It's all Shell and UCI changes, and the relevant .conf generation. Pretty straightforward. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 19.07.6 service release
As an alternative to dnsmasq, master now has isc-dhcp (v4 only) and Bind integration, so that's getting close to the essential functionality that dnsmasq provides. I stopped using dnsmasq about 8 years ago because it has several minor violations of the RFC's (which the Kelly's claim are convenient and therefore justified) but I believe create potential incompatibilities for specious reasons (yes, I'm a strict-interpretation-of-the-standards nazi). If anyone is interested in having v6 support to DHCP+Bind integration, I can look at doing that as well. Thanks, -Philip > On Jan 19, 2021, at 3:56 PM, Hauke Mehrtens wrote: > > Hi, > > The OpenWrt community is proud to announce the sixth service release of > OpenWrt 19.07. It focuses on fixing several security issues. > > Main changes from OpenWrt 19.07.5 > > Security fixes > * Security Advisory 2021-01-19-1 - dnsmasq multiple vulnerabilities > (CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, CVE-2020-25687, > CVE-2020-25684, CVE-2020-25685 and CVE-2020-25686) > * openssl: NULL pointer deref in GENERAL_NAME_cmp function can lead to > a DOS attack. (CVE-2020-1971) > > Note: security fixes for most packages can also be applied by upgrading only > the affected packages on running devices, without the need for a full > firmware upgrade. This can be done with opkg update; opkg upgrade > the_package_name or through the LuCI web interface. > > Nevertheless, we encourage all users to upgrade their devices to OpenWrt > 19.07.6 or later versions whenever possible. > > Major bug fixes > * Fix iOS 14 tethering problem > > Device support > * Enable LED VCC for Asus RT-AC51U > > LuCI web interface > * luci-mod-system: properly handle SSH pubkeys with options (GH#4684) > * luci-mod-network: properly handle wireless netdevs when creating > interfaces > * Update translations from weblate > > Core components > * Update Linux kernel from 4.14.209 to 4.14.215 > * Update mac80211 and wifi drivers from 4.19.137-1 to 4.19.161-1 > * Update wireless-regdb from 2019.06.03 to 2020.11.20 > * Update mbedtls from 2.16.8 to 2.16.9 > * Update openssl from 1.1.1h to 1.1.1i > > Full release notes and upgrade instructions are available at > https://openwrt.org/releases/19.07/notes-19.07.6 > > In particular, make sure to read the regressions and known issues before > upgrading: > https://openwrt.org/releases/19.07/notes-19.07.6#regressions > > For a very detailed list of all changes since 19.07.5, refer to > https://openwrt.org/releases/19.07/changelog-19.07.6 > > - --- > > To stay informed of new OpenWrt releases and security advisories, there > are new channels available: > > * a low-volume mailing list for important announcements: > https://lists.openwrt.org/mailman/listinfo/openwrt-announce > > * a dedicated "announcements" section in the forum: > https://forum.openwrt.org/c/announcements/14 > > * other announcement channels (such as RSS feeds) might be added in the > future, they will be listed at https://openwrt.org/contact > > - --- > > For latest information about the 19.07 series, refer to the wiki at: > https://openwrt.org/releases/19.07/ > > To download a OpenWrt 19.07.6 firmware image for your device, head to the > Table of Hardware: > https://openwrt.org/toh/start > > Or navigate directly in the list of firmware images: > https://downloads.openwrt.org/releases/19.07.6/targets/ > > As always, a big thank you goes to all our active package maintainers, > testers, documenters, and supporters. > > Have fun! > > The OpenWrt Community > > ___ > 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: Job board support on openwrt.org?
> On Jan 22, 2021, at 12:03 PM, Daniel Golle wrote: > > Hi Philip, > > On Fri, Jan 22, 2021 at 11:23:42AM -0700, Philip Prindeville wrote: >> Hi, >> >> Is anyone interested in adding a page to the openwrt.org site about >> developers willing to do commercial work? >> >> It could be as simple as: >> >> * name >> * email address >> * mobile (if wanted) >> * packages/platforms/architectures you maintain or have competence in >> * whether you're available full-time, part-time, or currently unavailable >> >> Might be useful for matching up devs with work. > > While I like the idea and would probably benefit from it myself, I'm > a bit sceptical when it comes to making OpenWrt.org an institution > certifying developers. Too much trouble was caused over having > '@openwrt.org' addresses and I doubt we are able to handle the > moderation needs (think: classic fraud, fishing, ...) of such a thing > if it is even a wiki, ie. free to edit for all. > Things like a wiki with only volunteer moderation somehow work because > there is little to no commercial interest in manipulation and it is > usually easy to recognize (ie. classic spam). In the moment that we > change that, we have to be prepared to also face a different quality > of manipulation attempts. > > Just my 2 cents... In thought about this. I guess the page would have a caveat that it wasn't an official endorsement or anything like that. Still, the price of admission might be being known in the community for at least one year (that can be submitting PR's, reviewing PR's, editing the Wiki, for example), and do have submitted and had approved at least 5 PR's or to be the maintainer of at least one package. Does that seem like enough of a bar to prevent fraud? -Philip > >> >> Just an idea to help our community prosper. >> >> Thanks, >> >> -Philip >> >> >> ___ >> 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: Job board support on openwrt.org?
> On Jan 22, 2021, at 11:57 AM, Alberto Bursi wrote: > > > > On 22/01/21 19:23, Philip Prindeville wrote: >> Hi, >> Is anyone interested in adding a page to the openwrt.org site about >> developers willing to do commercial work? >> It could be as simple as: >> * name >> * email address >> * mobile (if wanted) >> * packages/platforms/architectures you maintain or have competence in >> * whether you're available full-time, part-time, or currently unavailable >> Might be useful for matching up devs with work. >> Just an idea to help our community prosper. >> Thanks, >> -Philip > > I'm fine with adding that (imho it is a good idea), but of course the main > question is if the freelance developers in the community would like to use it. > > -Alberto > If there's a show of hands, I definitely would, and Daniel said (below) he would too... so that's 2... -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 19.07.6 service release
> On Jan 22, 2021, at 12:00 PM, Alberto Bursi wrote: > > > > On 22/01/21 19:53, Philip Prindeville wrote: >> As an alternative to dnsmasq, master now has isc-dhcp (v4 only) and Bind >> integration, so that's getting close to the essential functionality that >> dnsmasq provides. >> I stopped using dnsmasq about 8 years ago because it has several minor >> violations of the RFC's (which the Kelly's claim are convenient and >> therefore justified) but I believe create potential incompatibilities for >> specious reasons (yes, I'm a strict-interpretation-of-the-standards nazi). > > How do I enable/use the "isc-dhcp (v4 only) and Bind integration" and > replace/disable dnsmasq? > > -Alberto > You'll need to remove the dnsmasq package and select CONFIG_PACKAGE_isc-dhcp-server-ipv4 (or -ipv6 which actually supports both IPv4 and IPv6, but the UCI scripting for dynDNS for IPv6 as I said is missing). That will bring in Bind and the related tools. To the top of your /etc/config/dhcp you'll need to add: config isc_dhcpd 'isc_dhcpd' option authoritative '1' option default_lease_time '3600' option max_lease_time '86400' option always_broadcast 0 option boot_unknown_clients 1 option log_facility 'daemon' option domain 'example.com' option dynamicdns 1 Which are the ISC specific global options. The last line is the one that enables dynamic DNS internally. To the subnet sections like: config dhcp 'lan' option interface 'lan' option leasetime '12h' option start '128' option limit '32' list dhcp_option 'option:ntp-servers,192.168.1.40,192.168.1.252' You can call out specific DHCP options (per dhcp-options(5)) with something like the last line. For statically configured hosts that you want DNS records for, use: config domain option ip '192.168.1.2' option name 'myserver' Other record types: config cname option cname 'mail' option target 'www' config cname option cname 'ftp' option target 'www' config srvhost option srv '_sip._udp' option target 'pbx' option port '5060' option priority '0' option weight '10' config mxhost option domain '@' option relay 'mail' option pref '10' etc. Hope that helps. Send an email if you have more questions. -Philip >> If anyone is interested in having v6 support to DHCP+Bind integration, I can >> look at doing that as well. >> Thanks, >> -Philip >>> On Jan 19, 2021, at 3:56 PM, Hauke Mehrtens wrote: >>> >>> Hi, >>> >>> The OpenWrt community is proud to announce the sixth service release of >>> OpenWrt 19.07. It focuses on fixing several security issues. >>> >>> Main changes from OpenWrt 19.07.5 >>> >>> Security fixes >>> * Security Advisory 2021-01-19-1 - dnsmasq multiple vulnerabilities >>> (CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, CVE-2020-25687, >>> CVE-2020-25684, CVE-2020-25685 and CVE-2020-25686) >>> * openssl: NULL pointer deref in GENERAL_NAME_cmp function can lead to >>> a DOS attack. (CVE-2020-1971) >>> >>> Note: security fixes for most packages can also be applied by upgrading >>> only the affected packages on running devices, without the need for a full >>> firmware upgrade. This can be done with opkg update; opkg upgrade >>> the_package_name or through the LuCI web interface. >>> >>> Nevertheless, we encourage all users to upgrade their devices to OpenWrt >>> 19.07.6 or later versions whenever possible. >>> >>> Major bug fixes >>> * Fix iOS 14 tethering problem >>> >>> Device support >>> * Enable LED VCC for Asus RT-AC51U >>> >>> LuCI web interface >>> * luci-mod-system: properly handle SSH pubkeys with options (GH#4684) >>> * luci-mod-network: properly handle wireless netdevs when creating >>> interfaces >>> * Update translations from weblate >>> >>> Core components >>> * Update Linux kernel from 4.14.209 to 4.14.215 >>> * Update mac80211 and wifi drivers from 4.19.137-1 to 4.19.161-1 >>> * Update wireless-regdb from 2019.06.03 to 2020.11.20 >>> * Update mbedtls from 2.16.8 to 2.16.9 >>> * Update openssl from 1.1.1h to 1.1.1i >>
Re: Need review of adding X.509 certs to Strongswan
I'll try splitting it into smaller pieces as well. https://github.com/openwrt/packages/pull/14535 > On Jan 22, 2021, at 11:47 AM, Philip Prindeville > wrote: > > Hi, > > I posted the following PR some time ago (late November) and it's languishing: > > https://github.com/openwrt/packages/pull/14028 > > Can I get some reviews of it? > > X.509 authentication is a more attractive alternative to simple PSK > authentication (more entropy, less susceptible to dictionary attacks, etc). > > It's a short series of commits that do: > > * suppress multiple logging in /var/log/messages for authentication messages; > * adds the /etc/swanctl/conf.d/ which is read from /etc/swanctl/swanctl.conf > but doesn't exist; > * cleans up some of the UCI and corrects the handling of the "updown" and > "firewall" scripts (there is no "left" or "right" version, since it's always > local by definition); > * adds new parameters "reauth", "fragmentation", "closeaction", "mobile" for > greater completeness; > * the X.509 support, which is the most important part of this PR, but is > actually a fairly trivial change; > * add support for a global "setup" config section, which contains the > "cachecrls", "charondebug", "strictcrlpolicy", and "uniqueids" parameters; > > It's all Shell and UCI changes, and the relevant .conf generation. Pretty > straightforward. > > Thanks, > > -Philip > > > ___ > 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: Job board support on openwrt.org?
> On Jan 24, 2021, at 12:56 PM, Paul Spooren wrote: > > > > On Sun, Jan 24, 2021 at 00:16, Sam Kuper wrote: >> On Sat, Jan 23, 2021 at 06:57:53PM -0500, Etienne Champetier wrote: >>> Le sam. 23 janv. 2021 à 18:09, Sam Kuper a écrit : I suggest that if a vote is held, it should be a three-way vote between the following outcomes (which should probably be mutually exclusive): - OpenWRT Jobs wiki page; - openwrt-jobs mailing list; >>> - OpenWrt Jobs forum section, with a "non endorsement" disclaimer at >>> the top - Do nothing. >> Thanks, fair point. I forgot the forum. (I mostly avoid Discourse.) >> So, a vote between four possible outcomes. > > I "revert" my agreement with a curated wiki entry and much prefer an open > "jobs" list where everyone can subscribe and whoever post job offers. > > The list could be moderated in a way that only job-offers are allowed while > sending resumes is blocked to limit noise. I still have a preference for the developers' page, but an openwrt-jobs ML works too... Can we proceed with that? Thanks, -Philip > >> -- >> A: When it messes up the order in which people normally read text. >> Q: When is top-posting a bad thing? >> () ASCII ribbon campaign. Please avoid HTML emails & proprietary >> /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you. >> ___ >> 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: [PATCH 2/2] base-files: remove execute bit and shebang from functions.sh
Reviewed-by: Philip Prindeville
> On Jan 25, 2021, at 4:48 AM, Adrian Schmutzler
> wrote:
>
> /lib/functions.sh was executable for no obvious reason and its
> execute property was even checked in package-ipkg.mk just to
> source it afterwards.
>
> Remove the execute bit and shebang as this is clearly a library.
>
> Signed-off-by: Adrian Schmutzler
> ---
> include/package-ipkg.mk | 4 ++--
> package/base-files/files/lib/functions.sh | 1 -
> 2 files changed, 2 insertions(+), 3 deletions(-)
> mode change 100755 => 100644 package/base-files/files/lib/functions.sh
>
> diff --git a/include/package-ipkg.mk b/include/package-ipkg.mk
> index a92d692121..32de3cc93e 100644
> --- a/include/package-ipkg.mk
> +++ b/include/package-ipkg.mk
> @@ -232,13 +232,13 @@ $(_endef)
> ( \
> echo "#!/bin/sh"; \
> echo "[ \"\{IPKG_NO_SCRIPT}\" = \"1\" ] && exit 0";
> \
> - echo "[ -x "\{IPKG_INSTROOT}/lib/functions.sh" ] ||
> exit 0"; \
> + echo "[ -s "\{IPKG_INSTROOT}/lib/functions.sh" ] ||
> exit 0"; \
> echo ". \{IPKG_INSTROOT}/lib/functions.sh"; \
> echo "default_postinst \0 \@"; \
> ) > postinst; \
> ( \
> echo "#!/bin/sh"; \
> - echo "[ -x "\{IPKG_INSTROOT}/lib/functions.sh" ] ||
> exit 0"; \
> + echo "[ -s "\{IPKG_INSTROOT}/lib/functions.sh" ] ||
> exit 0"; \
> echo ". \{IPKG_INSTROOT}/lib/functions.sh"; \
> echo "default_prerm \0 \@"; \
> ) > prerm; \
> diff --git a/package/base-files/files/lib/functions.sh
> b/package/base-files/files/lib/functions.sh
> old mode 100755
> new mode 100644
> index 272e230db2..2bad45324f
> --- a/package/base-files/files/lib/functions.sh
> +++ b/package/base-files/files/lib/functions.sh
> @@ -1,4 +1,3 @@
> -#!/bin/sh
> # Copyright (C) 2006-2014 OpenWrt.org
> # Copyright (C) 2006 Fokus Fraunhofer
> # Copyright (C) 2010 Vertical Communications
> --
> 2.20.1
>
>
> ___
> 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 19.07.6 service release
Getting some numbers, on x86_64, for dnsmasq-dhcpv6 (for apples to apples comparison) I get: -rw-r--r-- 1 philipp philipp 157156 Jan 25 20:20 dnsmasq-dhcpv6_2.82-10_x86_64.ipk The Bind packages are: -rw-r--r-- 1 philipp philipp 1140535 Jan 23 13:13 bind-libs_9.16.8-2_x86_64.ipk -rw-r--r-- 1 philipp philipp 161266 Jan 23 13:13 bind-server_9.16.8-2_x86_64.ipk -rw-r--r-- 1 philipp philipp 21592 Jan 23 13:13 bind-client_9.16.8-2_x86_64.ipk -rw-r--r-- 1 philipp philipp 16813 Jan 23 13:13 bind-rndc_9.16.8-2_x86_64.ipk And for ISC-dhcp: -rw-r--r-- 1 philipp philipp 1108571 Jan 23 13:15 isc-dhcp-server-ipv6_4.4.1-13_x86_64.ipk So... about 2.3MB bigger. But you do get a full-fledged DNS server, which you can run two instances of, and provide split-horizon and authoritative external DNS service for your domain to the Internet as well. > On Jan 22, 2021, at 3:51 PM, Paul Spooren wrote: > > What's the size difference here. I'd be curious to replace dnsmasq for the > default setup, but only if it brings an advantage in size and security. > > Just a personal interest. > > Best, > Paul > -- > > > > Jan 22, 2021 11:44:50 AM Philip Prindeville > : > >> >> >>> On Jan 22, 2021, at 12:00 PM, Alberto Bursi > wrote: >>> >>> >>> >>> On 22/01/21 19:53, Philip Prindeville wrote: >>>> As an alternative to dnsmasq, master now has isc-dhcp (v4 only) and > Bind integration, so that's getting close to the essential functionality that > dnsmasq provides. >>>> I stopped using dnsmasq about 8 years ago because it has several > minor violations of the RFC's (which the Kelly's claim are convenient and > therefore justified) but I believe create potential incompatibilities for > specious reasons (yes, I'm a strict-interpretation-of-the-standards nazi). >>> >>> How do I enable/use the "isc-dhcp (v4 only) and Bind integration" and > replace/disable dnsmasq? >>> >>> -Alberto >>> >> >> >> You'll need to remove the dnsmasq package and select > CONFIG_PACKAGE_isc-dhcp-server-ipv4 (or -ipv6 which actually supports both > IPv4 and IPv6, but the UCI scripting for dynDNS for IPv6 as I said is > missing). That will bring in Bind and the related tools. >> >> To the top of your /etc/config/dhcp you'll need to add: >> >> config isc_dhcpd 'isc_dhcpd' >> option authoritative '1' >> option default_lease_time '3600' >> option max_lease_time '86400' >> option always_broadcast 0 >> option boot_unknown_clients 1 >> option log_facility 'daemon' >> option domain 'example.com' >> option dynamicdns 1 >> >> Which are the ISC specific global options. The last line is the one > that enables dynamic DNS internally. >> >> To the subnet sections like: >> >> config dhcp 'lan' >> option interface 'lan' >> option leasetime '12h' >> option start '128' >> option limit '32' >> list dhcp_option > 'option:ntp-servers,192.168.1.40,192.168.1.252' >> >> You can call out specific DHCP options (per dhcp-options(5)) with > something like the last line. >> >> >> For statically configured hosts that you want DNS records for, use: >> >> config domain >> option ip '192.168.1.2' >> option name 'myserver' >> >> Other record types: >> >> config cname >> option cname 'mail' >> option target 'www' >> >> config cname >> option cname 'ftp' >> option target 'www' >> >> config srvhost >> option srv '_sip._udp' >> option target 'pbx' >> option port '5060' >> option priority '0' >> option weight '10' >> >> config mxhost >> option domain '@' >> option relay 'mail' >> option pref '10' >> >> etc. >> >> Hope that helps. Send an email if you have more questions. >> >> -Philip >> >> >> >>>> If anyone is interested in having v6 support to DHCP+Bind > integration, I can look at doing that as well. >>>> Thanks, >>>> -Philip >>>>> On Jan 19, 2021, at 3:56 PM, Hauke Mehrtens > wrote: >
Re: Job board support on openwrt.org?
> On Jan 26, 2021, at 2:09 PM, Paul Oranje wrote: > > > >> Op 22 jan. 2021, om 20:03 heeft Daniel Golle het >> volgende geschreven: >> >> Hi Philip, >> >> On Fri, Jan 22, 2021 at 11:23:42AM -0700, Philip Prindeville wrote: >>> Hi, >>> >>> Is anyone interested in adding a page to the openwrt.org site about >>> developers willing to do commercial work? >>> >>> It could be as simple as: >>> >>> * name >>> * email address >>> * mobile (if wanted) >>> * packages/platforms/architectures you maintain or have competence in >>> * whether you're available full-time, part-time, or currently unavailable >>> >>> Might be useful for matching up devs with work. >> >> While I like the idea and would probably benefit from it myself, I'm >> a bit sceptical when it comes to making OpenWrt.org an institution >> certifying developers. Too much trouble was caused over having >> '@openwrt.org' addresses and I doubt we are able to handle the >> moderation needs (think: classic fraud, fishing, ...) of such a thing >> if it is even a wiki, ie. free to edit for all. >> Things like a wiki with only volunteer moderation somehow work because >> there is little to no commercial interest in manipulation and it is >> usually easy to recognize (ie. classic spam). In the moment that we >> change that, we have to be prepared to also face a different quality >> of manipulation attempts. >> >> Just my 2 cents... > Indeed, having a job board would be like opening a can of worms. Don't do it. > Paul And an open mailing list? -Philip > >> >>> >>> Just an idea to help our community prosper. >>> >>> Thanks, >>> >>> -Philip >>> >>> >>> ___ >>> 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 19.07.6 service release
> On Jan 22, 2021, at 9:28 PM, Nishant Sharma wrote: > > On 23/01/21 3:13 am, Philip Prindeville wrote: > >> You'll need to remove the dnsmasq package and select >> CONFIG_PACKAGE_isc-dhcp-server-ipv4 (or -ipv6 which actually supports both >> IPv4 and IPv6, but the UCI scripting for dynDNS for IPv6 as I said is >> missing). That will bring in Bind and the related tools. > > Thanks for the detailed how-to. > > I would like to understand how to populate ipsets dynamically using > bind, the way dnsmasq does with simple config like: > > list ipset '/domain.one/ipset1,ipset2' > list ipset '/domain.two/ipset3,ipset1' > > If I can get it working with bind, I will be able to move to ISC DHCPD > and BIND. Not something I've looked at up to now. Jo-Philipp: is there anything in ipset-dns that's proprietary to Dnsmasq? -Philip > > Thanks in advance. > Regards, > Nishant ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] fakeroot: fix to work with glibc 2.33
Comments...
> On Feb 11, 2021, at 10:42 PM, Ilya Lipnitskiy
> wrote:
>
> The following commit removed _STAT_VER definitions from glibc:
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8ed005daf0ab03e142500324a34087ce179ae78e
>
> That subsequently broke fakeroot:
> https://bugs.archlinux.org/task/69572
> https://bugzilla.redhat.com/show_bug.cgi?id=1889862#c13
> https://forum.openwrt.org/t/unable-to-build-toolchain-fakeroot-fails-perhaps-others-after-it/87966
>
> Make the patch based on Jan Pazdziora's suggestion from here:
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/SMQ3RYXEYTVZH6PLQMKNB3NM4XLPMNZO/
>
> Additionally, add wrappers for newly exported symbols in glibc.
>
> Tested on my x86_64 Arch Linux machine, fakeroot unit tests pass.
> Also tested by building various .ipks and examining the tar contents, to
> ensure that the owner uid/gid was 0/0.
>
> Signed-off-by: Ilya Lipnitskiy
> ---
> .../300-glibc-2.33-compatibility.patch| 74 +++
> 1 file changed, 74 insertions(+)
> create mode 100644 tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
>
> diff --git a/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
> b/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
> new file mode 100644
> index 00..2e6beab095
> --- /dev/null
> +++ b/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
> @@ -0,0 +1,74 @@
> +--- a/libfakeroot.c
> b/libfakeroot.c
> +@@ -90,6 +90,16 @@
> + #define SEND_GET_XATTR64(a,b,c) send_get_xattr64(a,b)
> + #endif
> +
> ++#ifndef _STAT_VER
> ++ #if defined (__aarch64__)
> ++ #define _STAT_VER 0
> ++ #elif defined (__x86_64__)
> ++ #define _STAT_VER 1
> ++ #else
> ++ #define _STAT_VER 3
> ++ #endif
> ++#endif
> ++
> + /*
> +These INT_* (which stands for internal) macros should always be used when
> +the fakeroot library owns the storage of the stat variable.
> +@@ -1358,6 +1368,54 @@ int renameat(int olddir_fd, const char *
> + #endif /* HAVE_FSTATAT */
> +
> +
> ++#ifdef __GLIBC__
> ++#if __GLIBC_PREREQ(2,33)
Minor nit, but please combine these into a single line:
#if defined(__GLIBC__) && __GLIBC_PREREQ(2,33)
As that's easier to grep.
> ++/* Glibc 2.33 exports symbols for these functions in the shared lib */
> ++int lstat(const char *file_name, struct stat *statbuf) {
> ++ return WRAP_LSTAT LSTAT_ARG(_STAT_VER, file_name, statbuf);
> ++}
> ++int stat(const char *file_name, struct stat *st) {
> ++ return WRAP_STAT STAT_ARG(_STAT_VER, file_name, st);
> ++}
> ++int fstat(int fd, struct stat *st) {
> ++ return WRAP_FSTAT FSTAT_ARG(_STAT_VER, fd, st);
> ++}
> ++#ifdef HAVE_FSTATAT
Please indent nested #if or #ifdef's.
> ++int fstatat(int dir_fd, const char *path, struct stat *st, int flags) {
> ++ return WRAP_FSTATAT FSTATAT_ARG(_STAT_VER, dir_fd, path, st, flags);
> ++}
> ++#endif
> ++#ifdef STAT64_SUPPORT
> ++int lstat64(const char *file_name, struct stat64 *st) {
> ++ return WRAP_LSTAT64 LSTAT64_ARG(_STAT_VER, file_name, st);
> ++}
> ++int stat64(const char *file_name, struct stat64 *st) {
> ++ return WRAP_STAT64 STAT64_ARG(_STAT_VER, file_name, st);
> ++}
> ++int fstat64(int fd, struct stat64 *st) {
> ++ return WRAP_FSTAT64 FSTAT64_ARG(_STAT_VER, fd, st);
> ++}
> ++#ifdef HAVE_FSTATAT
Ditto.
> ++int fstatat64(int dir_fd, const char *path, struct stat64 *st, int flags) {
> ++ return WRAP_FSTATAT64 FSTATAT64_ARG(_STAT_VER, dir_fd, path, st, flags);
> ++}
> ++#endif
> ++#endif
> ++int mknod(const char *pathname, mode_t mode, dev_t dev) {
> ++ return WRAP_MKNOD MKNOD_ARG(_STAT_VER, pathname, mode, &dev);
> ++}
> ++#ifdef HAVE_FSTATAT
> ++#ifdef HAVE_MKNODAT
Combine as:
#if defined(HAVE_FSTATAT) && defined(HAVE_MKNODAT)
> ++int mknodat(int dir_fd, const char *pathname, mode_t mode, dev_t dev) {
> ++ return WRAP_MKNODAT MKNODAT_ARG(_STAT_VER, dir_fd, pathname, mode, &dev);
> ++}
> ++#endif
> ++#endif
Combined...
> ++
> ++#endif /* __GLIBC_PREPREQ */
> ++#endif /* __GLIBC__ */
Combined...
> ++
> ++
> + #ifdef FAKEROOT_FAKENET
> + pid_t fork(void)
> + {
> --
> 2.30.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] fakeroot: fix to work with glibc 2.33
> On Feb 12, 2021, at 10:52 AM, Ilya Lipnitskiy > wrote: > > Hi Philip, > > On Thu, Feb 11, 2021 at 11:23 PM Philip Prindeville > wrote: >> >> Minor nit, but please combine these into a single line: >> >> >> Please indent nested #if or #ifdef's. >> >> > I can make the style changes, but a couple of points to consider: > 1. These changes have already been submitted upstream[0]; > 2. If you look elsewhere within libfakeroot.c it is peppered with > #ifdefs that are not indented or combined, so I mostly followed the > existing code style (or the absence thereof) > > Ilya > > [0]: https://salsa.debian.org/clint/fakeroot/-/merge_requests/8 If it's already been submitted and accepted, then leave it. If they ask you to resubmit with changes, add that too please. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3] fakeroot: fix to work with glibc 2.33
Inline
> On Feb 13, 2021, at 9:41 PM, Ilya Lipnitskiy
> wrote:
>
> The following commit removed _STAT_VER definitions from glibc:
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8ed005daf0ab03e142500324a34087ce179ae78e
>
> That subsequently broke fakeroot:
> https://bugs.archlinux.org/task/69572
> https://bugzilla.redhat.com/show_bug.cgi?id=1889862#c13
> https://forum.openwrt.org/t/unable-to-build-toolchain-fakeroot-fails-perhaps-others-after-it/87966
>
> Make the patch based on Jan Pazdziora's suggestion from here:
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/SMQ3RYXEYTVZH6PLQMKNB3NM4XLPMNZO/
>
> Add wrappers for newly exported symbols in glibc.
>
> Apply patch from Debian to fix warnings in fts_read and fts_children:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676428
> https://sources.debian.org/patches/fakeroot/1.25.3-1.1/eglibc-fts-without-LFS/
>
> Fix __xmknod{,at} dev pointer argument. Switch default to assume * and
> not the absence of *. On glibc 2.33+, there is no definition for these
> functions in header files, so the compile test doesn't work. But, we
> can default to using the pointer (as is the case with newer glibc), and
> use the header file on older platforms to fail the test and use no pointer.
>
> Tested on my x86_64 Arch Linux machine, fakeroot unit tests pass.
> Also tested by building various .ipks and examining the tar contents, to
> ensure that the owner uid/gid was 0/0.
>
> Signed-off-by: Ilya Lipnitskiy
> ---
> .../300-glibc-2.33-compatibility.patch| 145 ++
> 1 file changed, 145 insertions(+)
> create mode 100644 tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
>
> diff --git a/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
> b/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
> new file mode 100644
> index 00..a460cace0c
> --- /dev/null
> +++ b/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
> @@ -0,0 +1,145 @@
> +--- a/libfakeroot.c
> b/libfakeroot.c
> +@@ -90,6 +90,16 @@
> + #define SEND_GET_XATTR64(a,b,c) send_get_xattr64(a,b)
> + #endif
> +
> ++#ifndef _STAT_VER
> ++ #if defined (__aarch64__)
> ++ #define _STAT_VER 0
> ++ #elif defined (__x86_64__)
> ++ #define _STAT_VER 1
> ++ #else
> ++ #define _STAT_VER 3
> ++ #endif
> ++#endif
> ++
> + /*
> +These INT_* (which stands for internal) macros should always be used when
> +the fakeroot library owns the storage of the stat variable.
> +@@ -1358,6 +1368,54 @@ int renameat(int olddir_fd, const char *
> + #endif /* HAVE_FSTATAT */
> +
> +
> ++#if defined(__GLIBC__) && __GLIBC_PREREQ(2,33)
> ++/* Glibc 2.33 exports symbols for these functions in the shared lib */
> ++ int lstat(const char *file_name, struct stat *statbuf) {
> ++ return WRAP_LSTAT LSTAT_ARG(_STAT_VER, file_name, statbuf);
> ++ }
Sorry, was suggesting that the # lines be indented, not necessary function
definitions.
Thanks
> ++ int stat(const char *file_name, struct stat *st) {
> ++ return WRAP_STAT STAT_ARG(_STAT_VER, file_name, st);
> ++ }
> ++ int fstat(int fd, struct stat *st) {
> ++ return WRAP_FSTAT FSTAT_ARG(_STAT_VER, fd, st);
> ++ }
> ++
> ++ #ifdef HAVE_FSTATAT
> ++int fstatat(int dir_fd, const char *path, struct stat *st, int flags) {
> ++ return WRAP_FSTATAT FSTATAT_ARG(_STAT_VER, dir_fd, path, st, flags);
> ++}
> ++ #endif
> ++
> ++ #ifdef STAT64_SUPPORT
> ++int lstat64(const char *file_name, struct stat64 *st) {
> ++ return WRAP_LSTAT64 LSTAT64_ARG(_STAT_VER, file_name, st);
> ++}
> ++int stat64(const char *file_name, struct stat64 *st) {
> ++ return WRAP_STAT64 STAT64_ARG(_STAT_VER, file_name, st);
> ++}
> ++int fstat64(int fd, struct stat64 *st) {
> ++ return WRAP_FSTAT64 FSTAT64_ARG(_STAT_VER, fd, st);
> ++}
> ++
> ++#ifdef HAVE_FSTATAT
> ++ int fstatat64(int dir_fd, const char *path, struct stat64 *st, int
> flags) {
> ++ return WRAP_FSTATAT64 FSTATAT64_ARG(_STAT_VER, dir_fd, path, st,
> flags);
> ++ }
> ++#endif
> ++ #endif
> ++
> ++ int mknod(const char *pathname, mode_t mode, dev_t dev) {
> ++ return WRAP_MKNOD MKNOD_ARG(_STAT_VER, pathname, mode, &dev);
> ++ }
> ++
> ++ #if defined(HAVE_FSTATAT) && defined(HAVE_MKNODAT)
> ++int mknodat(int dir_fd, const char *pathname, mode_t mode, dev_t dev) {
> ++ return WRAP_MKNODAT MKNODAT_ARG(_STAT_VER, dir_fd, pathname, mode,
> &dev);
> ++}
> ++ #endif
> ++#endif /* GLIBC_PREREQ */
> ++
> ++
> + #ifdef FAKEROOT_FAKENET
> + pid_t fork(void)
> + {
> +@@ -2024,11 +2082,7 @@ FTSENT *fts_read(FTS *ftsp) {
> + || r->fts_info == FTS_NS || r->fts_info == FTS_NSOK))
> + r->fts_statp = NULL; /* Otherwise fts_statp may be a random pointer */
> + if(r && r->fts_statp) { /* Should we bother checking fts_info here? */
> +-# if defined(STAT64_SUPPORT) && !defined(__APPLE__)
> +-SEND_GET_STAT64(r->fts_statp,
Re: [PATCH v3] fakeroot: fix to work with glibc 2.33
Surprised (after what you said) that it was accepted that quickly. Had the
impression that things were slow.
Go ahead for now, unless you think the upstream release is imminent.
> On Feb 14, 2021, at 3:26 PM, Ilya Lipnitskiy
> wrote:
>
> Oh well, it is too late now - it's been merged upstream:
> https://salsa.debian.org/clint/fakeroot/-/commits/upstream/
>
> No release yet, though. Do you want me to do another patch, getting
> rid of the upstreamed patches and using PKG_SOURCE_VERSION?
>
> Ilya
>
>
> Ilya
>
> On Sun, Feb 14, 2021 at 12:25 PM Philip Prindeville
> wrote:
>>
>> Inline
>>
>>
>>> On Feb 13, 2021, at 9:41 PM, Ilya Lipnitskiy
>>> wrote:
>>>
>>> The following commit removed _STAT_VER definitions from glibc:
>>> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8ed005daf0ab03e142500324a34087ce179ae78e
>>>
>>> That subsequently broke fakeroot:
>>> https://bugs.archlinux.org/task/69572
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1889862#c13
>>> https://forum.openwrt.org/t/unable-to-build-toolchain-fakeroot-fails-perhaps-others-after-it/87966
>>>
>>> Make the patch based on Jan Pazdziora's suggestion from here:
>>> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/SMQ3RYXEYTVZH6PLQMKNB3NM4XLPMNZO/
>>>
>>> Add wrappers for newly exported symbols in glibc.
>>>
>>> Apply patch from Debian to fix warnings in fts_read and fts_children:
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676428
>>> https://sources.debian.org/patches/fakeroot/1.25.3-1.1/eglibc-fts-without-LFS/
>>>
>>> Fix __xmknod{,at} dev pointer argument. Switch default to assume * and
>>> not the absence of *. On glibc 2.33+, there is no definition for these
>>> functions in header files, so the compile test doesn't work. But, we
>>> can default to using the pointer (as is the case with newer glibc), and
>>> use the header file on older platforms to fail the test and use no pointer.
>>>
>>> Tested on my x86_64 Arch Linux machine, fakeroot unit tests pass.
>>> Also tested by building various .ipks and examining the tar contents, to
>>> ensure that the owner uid/gid was 0/0.
>>>
>>> Signed-off-by: Ilya Lipnitskiy
>>> ---
>>> .../300-glibc-2.33-compatibility.patch| 145 ++
>>> 1 file changed, 145 insertions(+)
>>> create mode 100644 tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
>>>
>>> diff --git a/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
>>> b/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
>>> new file mode 100644
>>> index 00..a460cace0c
>>> --- /dev/null
>>> +++ b/tools/fakeroot/patches/300-glibc-2.33-compatibility.patch
>>> @@ -0,0 +1,145 @@
>>> +--- a/libfakeroot.c
>>> b/libfakeroot.c
>>> +@@ -90,6 +90,16 @@
>>> + #define SEND_GET_XATTR64(a,b,c) send_get_xattr64(a,b)
>>> + #endif
>>> +
>>> ++#ifndef _STAT_VER
>>> ++ #if defined (__aarch64__)
>>> ++ #define _STAT_VER 0
>>> ++ #elif defined (__x86_64__)
>>> ++ #define _STAT_VER 1
>>> ++ #else
>>> ++ #define _STAT_VER 3
>>> ++ #endif
>>> ++#endif
>>> ++
>>> + /*
>>> +These INT_* (which stands for internal) macros should always be used
>>> when
>>> +the fakeroot library owns the storage of the stat variable.
>>> +@@ -1358,6 +1368,54 @@ int renameat(int olddir_fd, const char *
>>> + #endif /* HAVE_FSTATAT */
>>> +
>>> +
>>> ++#if defined(__GLIBC__) && __GLIBC_PREREQ(2,33)
>>> ++/* Glibc 2.33 exports symbols for these functions in the shared lib */
>>> ++ int lstat(const char *file_name, struct stat *statbuf) {
>>> ++ return WRAP_LSTAT LSTAT_ARG(_STAT_VER, file_name, statbuf);
>>> ++ }
>>
>>
>> Sorry, was suggesting that the # lines be indented, not necessary function
>> definitions.
>>
>> Thanks
>>
>>
>>> ++ int stat(const char *file_name, struct stat *st) {
>>> ++ return WRAP_STAT STAT_ARG(_STAT_VER, file_name, st);
>>> ++ }
>>> ++ int fstat(int fd, struct stat *st) {
>>> ++ return WRAP_FSTAT FSTAT_ARG(_STAT_VER, fd, st);
>>> ++ }
>>> ++
>>> ++ #ifdef HAVE_FSTATAT
>>> ++int fstatat(int dir_fd, const char *path, struct stat *st, int flags)
Re: [PATCH 4/4] mac80211: add AX support
AX support. Cool.
Is there any UCI defaults stuff that needs to be touched for first boot and
discovery?
Comments:
> On Feb 15, 2021, at 3:19 AM, John Crispin wrote:
>
> Signed-off-by: John Crispin
> ---
> .../files/lib/netifd/wireless/mac80211.sh | 193 +-
> .../mac80211/files/lib/wifi/mac80211.sh | 19 +-
> 2 files changed, 195 insertions(+), 17 deletions(-)
>
> diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> index 92c56afd24..b717770d5e 100644
> --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> @@ -56,6 +56,13 @@ drv_mac80211_init_device_config() {
> short_gi_40 \
> max_amsdu \
> dsss_cck_40
> + config_add_int \
> + he_su_beamformer \
> + he_su_beamformee \
> + he_mu_beamformer \
> + he_bss_color \
> + he_spr_sr_control \
> + he_spr_non_srg_obss_pd_max_offset
> }
>
> drv_mac80211_init_iface_config() {
> @@ -69,6 +76,7 @@ drv_mac80211_init_iface_config() {
> config_add_int max_listen_int
> config_add_int dtim_period
> config_add_int start_disabled
> + config_add_int he_twt_required he_spr_sr_control
>
> # mesh
> config_add_string mesh_id
> @@ -96,6 +104,77 @@ mac80211_add_capabilities() {
> export -n -- "$__var=$__out"
> }
>
> +mac80211_add_he_capabilities() {
> + local __out= oifs
> +
> + oifs="$IFS"
> + IFS=:
Can't we just do:
local IFS=:
and get rid of oifs, etc.
% cat /tmp/foo
#!/bin/sh
func() {
local IFS="b"
echo "IFS=$IFS"
}
IFS="a"
echo "IFS=$IFS"
func
echo "IFS=$IFS"
% /tmp/foo
IFS=a
IFS=b
IFS=a
%
> + for capab in "$@"; do
> + set -- $capab
> + [ "$(($4))" -gt 0 ] || continue
> + [ "$(((0x$2) & $3))" -gt 0 ] || continue
> + append base_cfg "$1=1" "$N"
> + done
> + IFS="$oifs"
> +}
> +
> +mac80211_get_seg0() {
> + local ht_mode="$1"
> + local seg0=0
> +
> + case "$ht_mode" in
> + 40)
> + if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; then
> + case "$(( ($channel / 4) % 2 ))" in
> + 1) seg0=$(($channel - 2));;
> + 0) seg0=$(($channel + 2));;
> + esac
> + elif [ $freq != 5935 ]; then
> + case "$(( ($channel / 4) % 2 ))" in
> + 1) seg0=$(($channel + 2));;
> + 0) seg0=$(($channel - 2));;
> + esac
> + fi
> + ;;
> + 80)
> + if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; then
> + case "$(( ($channel / 4) % 4 ))" in
> + 0) seg0=$(($channel + 6));;
> + 1) seg0=$(($channel + 2));;
> + 2) seg0=$(($channel - 2));;
> + 3) seg0=$(($channel - 6));;
> + esac
> + elif [ $freq != 5935 ]; then
> + case "$(( ($channel / 4) % 4 ))" in
> + 1) seg0=$(($channel + 6));;
> + 2) seg0=$(($channel + 2));;
> + 3) seg0=$(($channel - 2));;
> + 0) seg0=$(($channel - 6));;
> + esac
> + fi
> + ;;
> + 160)
> + if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; then
> + case "$channel" in
> + 1|5|9|13|17|21|25|29) seg0=15;;
> + 33|37|41|45|49|53|57|61) seg0=47;;
> + 65|69|73|77|81|85|89|93) seg0=79;;
> + 97|101|105|109|113|117|121|125)
> seg0=111;;
> + 129|133|137|141|145|149|153|157)
> seg0=143;;
> + 161|165|169|173|177|181|185|189)
> seg0=175;;
> + 193|197|201|205|209|213|217|221)
> seg0=207;;
> + esac
> + elif [ $freq != 5935 ]; then
> + case "$channel" in
> + 36|40|44|48|52|56|60|64) seg0=50;;
> + 100|104|108|112|116|120|124|128)
> seg0=114;;
> + esac
> + fi
> + ;;
> + esac
> + printf "$seg0"
> +}
> +
> mac80
Strongswan testers wanted
Hi, I have some patches to Strongswan (mostly in packaging and UCI generation, not the Strongswan binaries themselves) that I'd like independent testing and verification. The maintainers have limited bandwidth to test, so others testing and finding bugs and me fixing them first might be more expedient. For instance: https://github.com/openwrt/packages/pull/14028 https://github.com/openwrt/packages/pull/14711 https://github.com/openwrt/packages/pull/14708 At this time. Please reach out to me via email or IRC to coordinate. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/1] firewall3: remove last remaining sprintf()
From: Philip Prindeville
Signed-off-by: Philip Prindeville
---
iptables.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/iptables.c b/iptables.c
index
9e8fa743c99f84222307128047d40d657916aa75..49b34394dfec4df361ec1cf6778cade831454c7c
100644
--- a/iptables.c
+++ b/iptables.c
@@ -1022,7 +1022,7 @@ fw3_ipt_rule_icmptype(struct fw3_ipt_rule *r, struct
fw3_icmptype *icmp)
#endif
{
if (icmp->code_min == 0 && icmp->code_max == 0xFF)
- sprintf(buf, "%u", icmp->type);
+ snprintf(buf, sizeof(buf), "%u", icmp->type);
else
snprintf(buf, sizeof(buf), "%u/%u", icmp->type,
icmp->code_min);
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
CI/CD sanity and failed x86_64 builds
I'm seeing repeated failures when rebuilding strongswan for x86_64. From what I can tell from the CI/CD logs, everything *is* being built with -fPIC, so I'm not sure why we're still seeing: 2021-02-24T20:02:59.8624672Z OpenWrt-libtool: compile: x86_64-openwrt-linux-musl-gcc -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../src/libstrongswan -I/home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/usr/include -I/home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/include/fortify -I/home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/include -I/home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib/libiconv-stub/include -I/home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib/libintl-stub/include -rdynamic -Os -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -ffile-prefix-map=/home/build/openwrt/build_dir/target-x86_64_musl/strongswan-5.9.1=strongswan-5.9.1 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -I/home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib/libiconv-stub/include -I/home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib/libintl-stub/include -include /home/build/openwrt/build_dir/target-x86_64_musl/strongswan-5.9.1/config.h -MT ../gmp/gmp_diffie_hellman.lo -MD -MP -MF ../gmp/.deps/gmp_diffie_hellman.Tpo -c ../gmp/gmp_diffie_hellman.c -fPIC -DPIC -o ../gmp/.libs/gmp_diffie_hellman.o 2021-02-24T20:02:59.9724902Z /bin/bash ../../../../libtool --tag=CC --mode=link x86_64-openwrt-linux-musl-gcc -rdynamic -Os -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -ffile-prefix-map=/home/build/openwrt/build_dir/target-x86_64_musl/strongswan-5.9.1=strongswan-5.9.1 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -I/home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib/libiconv-stub/include -I/home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib/libintl-stub/include -include /home/build/openwrt/build_dir/target-x86_64_musl/strongswan-5.9.1/config.h -module -avoid-version -Wl,-Bstatic -Wl,-lgmp -Wl,-Bdynamic -Wl,--as-needed -L/home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/usr/lib -L/home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/lib -znow -zrelro -L/home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib/libiconv-stub/lib -Wl,-rpath-link=/home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib/libiconv-stub/lib -L/home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib/libintl-stub/lib -Wl,-rpath-link=/home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib/libintl-stub/lib -Wl,-rpath-link,/home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib -o libstrongswan-gmpdh.la -rpath /usr/lib/ipsec/plugins gmpdh_plugin.lo ../gmp/gmp_diffie_hellman.lo 2021-02-24T20:03:00.0467739Z OpenWrt-libtool: link: x86_64-openwrt-linux-musl-gcc -shared -fPIC -DPIC .libs/gmpdh_plugin.o ../gmp/.libs/gmp_diffie_hellman.o -L/home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/usr/lib -L/home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/lib -L/home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib/libiconv-stub/lib -L/home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib/libintl-stub/lib -Os -fstack-protector -Wl,-z -Wl,now -Wl,-z -Wl,relro -Wl,-Bstatic -Wl,-lgmp -Wl,-Bdynamic -Wl,--as-needed -Wl,-rpath-link=/home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib/libiconv-stub/lib -Wl,-rpath-link=/home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib/libintl-stub/lib -Wl,-rpath-link -Wl,/home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib -Wl,-soname -Wl,libstrongswan-gmpdh.so -o .libs/libstrongswan-gmpdh.so 2021-02-24T20:03:00.0787467Z /home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/bin/../lib/gcc/x86_64-openwrt-linux-musl/8.4.0/../../../../x86_64-openwrt-linux-musl/bin/ld: /home/build/openwrt/staging_dir/target-x86_64_musl/usr/lib/libgmp.a(bdiv_q_1.o): relocation R_X86_64_PC32 against symbol `__gmp_binvert_limb_table' can not be used when making a shared object; recompile with -fPIC 2021-02-24T20:03:00.0790070Z /home/build/openwrt/staging_dir/toolchain-x86_64_gcc-8.4.0_musl/bin/../lib/gcc/x86_64-openwrt-linux-musl/8.4.0/../../../../x86_64-openwrt-linux-musl/bin/ld: final link failed: bad value 2021-02-24T20:03:00.0791131Z collect2: error: ld returned 1 exit status 2021-02-24T20:03:00.0803715Z make[8]: *** [Makefile:564: libstrongswan-gmpdh.la] Error 1 Anyone else want to venture a guess as to what is impeding CI/CD? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: CI/CD sanity and failed x86_64 builds
> On Feb 25, 2021, at 12:12 AM, Ilya Lipnitskiy > wrote: > > Hi Philip, > > On Wed, Feb 24, 2021 at 10:30 PM Philip Prindeville > wrote: > >> -Wl,-Bstatic -Wl,-lgmp > Does that tell ld to link against libgmp.a instead of libgmp.so? I > didn't try to reproduce this, just reading the log, so take it with a > grain of salt ;) > > Ilya Presumably all targets are linked this way. So why is it only a problem for x86_64? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Installation error for libncursesw6
> On Feb 15, 2021, at 11:52 PM, Brian Norris > wrote: > > On Sun, Feb 14, 2021 at 4:07 PM Ansuel Smith wrote: >> >>> Collected errors: >>> * pkg_hash_fetch_best_installation_candidate: Packages for >>> libreadline8 found, but incompatible with the architectures configured >>> * opkg_install_cmd: Cannot install package libreadline8. >>> * satisfy_dependencies_for: Cannot satisfy the following dependencies >>> for softethervpn5-libs: >>> * libncursesw6 >>> * opkg_install_cmd: Cannot install package softethervpn5-libs. >>> make[2]: *** [package/Makefile:69: package/install] Error 255 >>> >>> Multiple packages complain about this... This is from a clean custom build. >>> Think this is caused by the abi changes to buildroot >> >> reverting c92165038217e49075098479704da58a2a3a89bd fix the problem > > Thanks for tracking down the regression! This has been bugging me too. > > FWIW, I found that the problem seems to be in badly-generated > libncurses ipk files. The 'control' file seems to have lines like > this: > > Provides: libncursesw, libncurses, libncursesw > > when it should have: > > Provides: libncursesw, libncurses, libncursesw6 > > Brian Is there a workaround to force an install? -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Installation error for libncursesw6
Inline... > On Mar 1, 2021, at 7:00 AM, Hannu Nyman wrote: > > Philip Prindeville philipp_subx at redfish-solutions.com wrote at Mon Mar 1 > 02:11:20 EST 2021: > > Is there a workaround to force an install? > > * Build a new up-to-date version with the current packages data. Update opkg > lists. > * Download a .ipk manually and install it with opkg. > > To my knowledge the bug has been already fixed in master, but you may still > have the broken old firmware. When you say "update opkg lists", are you talking about the /usr/lib/opkg/status file or something else? Because it seems to me that that's what's lingering that might be damaged. Is there a way to update "opkg" itself and resynthesize this file? Or a script I can run to recreate it from scratch? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] iproute2: fix build with a newer toolchain
Reviewed-by: Philip Prindeville > On Mar 3, 2021, at 1:48 PM, Rui Salvaterra wrote: > > GCC 10.2.0 complains loudly of missing limits.h. Add a patch to fix this. > > Signed-off-by: Rui Salvaterra > --- > .../050-fix-build-include-limits.patch| 23 +++ > 1 file changed, 23 insertions(+) > create mode 100644 > package/network/utils/iproute2/patches/050-fix-build-include-limits.patch > > diff --git > a/package/network/utils/iproute2/patches/050-fix-build-include-limits.patch > b/package/network/utils/iproute2/patches/050-fix-build-include-limits.patch > new file mode 100644 > index 00..df7d9a0fb7 > --- /dev/null > +++ > b/package/network/utils/iproute2/patches/050-fix-build-include-limits.patch > @@ -0,0 +1,23 @@ > +--- a/lib/bpf_glue.c > b/lib/bpf_glue.c > +@@ -4,6 +4,9 @@ > + * Authors: Hangbin Liu > + * > + */ > ++ > ++#include > ++ > + #include "bpf_util.h" > + #ifdef HAVE_LIBBPF > + #include > +--- a/lib/bpf_libbpf.c > b/lib/bpf_libbpf.c > +@@ -5,6 +5,8 @@ > + * > + */ > + > ++#include > ++ > + #include > + #include > + #include > -- > 2.30.1 > > > ___ > 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
Bumping firewall3 to latest
David, Yousong: Can we get a bump of firewall3 to HEAD again please? Thanks ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] gmp: compile with -DPIC to use correct asm code
> On Mar 12, 2021, at 6:25 AM, Felix Fietkau wrote: > > > On 2021-03-12 11:34, Stijn Tintel wrote: >> On 11/03/2021 23:46, Eneas U de Queiroz wrote: >>> The library is always compiled with $(FPIC) (-fPIC or -fpic), even for >>> the static library. >>> >>> There are some assembly sources that decide whether or not to enable >>> PIC code by checking if PIC is defined. It counts on libtool to define >>> it, but libtool does it only when producing code for the dynamic >>> library, while we need it for both. >>> >>> Ensure it is defined by adding it to CFLAGS next to $(FPIC). >>> >>> It avoids linking errors with strongswan on x86_64: >>> >>> ld: libgmp.a(bdiv_q_1.o): relocation R_X86_64_PC32 against symbol >>> `__gmp_binvert_limb_table' can not be used when making a shared object; >>> recompile with -fPIC >>> >>> Cc: Stijn Tintel >>> Signed-off-by: Eneas U de Queiroz >>> --- >>> >>> There's an error on one architecture, and all others work fine without >>> this, so I'm uneasy changing this and then breaking stuff that was >>> working fine otherwise. However, it feels wrong to me to generate PIC >>> code from C files, but not use it in asm sources, which is essentially >>> what I am changing here. >>> >>> I've looked at asm sources for different chitectures, and there are >>> checks for PIC in: arm64, arm, x86_64, x86, and ppc asm sources, but the >>> error only appears on x86_64. >>> >>> For most CPUs, ifdef(`PIC'), is just used to do different definitions of >>> LEA (Load Effective Address). However, both x86 and x86_64 have many >>> other checks. >>> >>> I've looked at bdiv_q_1.asm for different CPUs, and they all do some >>> form of LEA(binvert_limb_table), except for x86, where it will do it >>> only when PIC is defined. That may explain why x86_64 is affected, and >>> x86 is not. >>> >>> I have not investigated further details. >>> >>> Alternatively, we can define it only for x86_64, which is where we know >>> there's a build failure with the linker asking to recompile with -fPIC. >>> >> I'm sorry, but I lack the knowledge to review this. > > I think the patch makes sense and -DPIC should be used along with -fPIC. > I don't see any reason to make it x86_64 specific. > > - Felix Maybe I'm missing something, but why not just fix rules.mk: ifneq (,$(findstring $(ARCH) , aarch64 aarch64_be powerpc )) FPIC:=-fPIC else FPIC:=-fpic endif HOST_FPIC:=-fPIC To have the FPIC and HOST_FPIC definitions include -DPIC? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/1] build: make sure asm gets built with -DPIC
From: Philip Prindeville Fixes issue #14921, whereby inline ASM wasn't getting built as PIC; look at gmp-6.2.1/mpn/x86/pentium/popcount.asm for example: ifdef(`PIC',` ... for a routine that exists in both PIC and non-PIC versions. Make sure that wherever $(FPIC) gets passed as a variable expansion that it gets quoted where necessary (such as setting environment variables in shell commands). Signed-off-by: Philip Prindeville --- package/libs/libnfnetlink/Makefile | 4 ++-- rules.mk | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/package/libs/libnfnetlink/Makefile b/package/libs/libnfnetlink/Makefile index 7d65d6385784e3d418f714386efe505b905c3b3e..bc64ff111d1f37e64463d519736d013679ccebf0 100644 --- a/package/libs/libnfnetlink/Makefile +++ b/package/libs/libnfnetlink/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=libnfnetlink PKG_VERSION:=1.0.1 -PKG_RELEASE:=3 +PKG_RELEASE:=4 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:= \ @@ -45,7 +45,7 @@ CONFIGURE_ARGS += \ --enable-shared CONFIGURE_VARS += \ - lt_prog_compiler_pic=$(FPIC) + lt_prog_compiler_pic="$(FPIC)" define Build/InstallDev $(INSTALL_DIR) $(1)/usr/include/libnfnetlink diff --git a/rules.mk b/rules.mk index 8dee9e8489ac81ee524ca096e38355cea9730368..cb165f954892578f7c11e872d1ff921c96df90da 100644 --- a/rules.mk +++ b/rules.mk @@ -76,12 +76,12 @@ IS_PACKAGE_BUILD := $(if $(filter package/%,$(BUILD_SUBDIR)),1) OPTIMIZE_FOR_CPU=$(subst i386,i486,$(ARCH)) ifneq (,$(findstring $(ARCH) , aarch64 aarch64_be powerpc )) - FPIC:=-fPIC + FPIC:=-DPIC -fPIC else - FPIC:=-fpic + FPIC:=-DPIC -fpic endif -HOST_FPIC:=-fPIC +HOST_FPIC:=-DPIC -fPIC ARCH_SUFFIX:=$(call qstrip,$(CONFIG_CPU_TYPE)) GCC_ARCH:= -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] gmp: compile with -DPIC to use correct asm code
> On Mar 19, 2021, at 4:06 PM, Eneas U de Queiroz wrote: > > On Fri, Mar 19, 2021 at 5:08 PM Philip Prindeville > wrote: >> >> >> Maybe I'm missing something, but why not just fix rules.mk: >> >> >> ifneq (,$(findstring $(ARCH) , aarch64 aarch64_be powerpc )) >> FPIC:=-fPIC >> else >> FPIC:=-fpic >> endif >> >> HOST_FPIC:=-fPIC >> >> >> To have the FPIC and HOST_FPIC definitions include -DPIC? > > I think it would be the proper way to handle this. I was initially > fearful of changing too much and breaking things, but I think it > should be expected behaviour. What else would you use a 'PIC' > definition for? I will resend a patch changing rules.mk instead. Just saw this... Turns out that this would break a couple of packages (both in openwrt and in packages), so I've included those as well. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH firewall3 v1 0/2] fix DSCP/MARK target implementation
Are you aware that many open source apps already do DSCP marking? I submitted the changes to Firefox, Thunderbird, Cyrus, Proftpd, Sendmail, Postfix, Curl, Wget, Apache... and this was more than 15 years ago. Why would you want to overwrite marking if it's already present? > On Mar 21, 2021, at 7:06 PM, Tony Ambardar via openwrt-devel > wrote: > > 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. > From: Tony Ambardar > Subject: [PATCH firewall3 v1 0/2] fix DSCP/MARK target implementation > Date: March 21, 2021 at 7:06:17 PM MDT > To: openwrt-devel@lists.openwrt.org > Cc: Jo-Philipp Wich , Tony Ambardar > > > Currently, fw3 places all DSCP/MARK target rules into the PREROUTING chain, > and accepts but ignores a src device. This behaviour is impractical for > most common applications (e.g. QOS setup), since rules are applied to all > devices and in all directions. Fix this generally by honouring src/dest > device selection and placing the rules into the appropriate chain of the > mangle table. > > These changes revealed the process of resolving zones to devices can add > duplicates due to the presence of aliased interfaces. Fix this by filtering > the fw3_zone->devices list during creation. > > Thanks go to Jo-Philipp Wich for sharing proof of concept code > on IRC and providing additional review afterwards. > > Tony Ambardar (2): > zone: avoid duplicates in devices list > rules: fix device and chain usage for DSCP/MARK targets > > rules.c | 68 - > zones.c | 9 +++- > 2 files changed, 51 insertions(+), 26 deletions(-) > > Testing > === > > Regression testing was done to confirm the default OpenWrt firewall rules > are unchanged before and after this patch. > > Functional testing was carried out using the UCI firewall rules below. This > set of test cases would normally yield the following incorrect iptables > rules (from iptables-save, sorted by test): > > -A PREROUTING -p udp -m udp --dport 1945 -m comment --comment "!fw3: > Test-1-Zone-Any-PRE" -j DSCP --set-dscp 0x00 > -A PREROUTING -p tcp -m tcp --dport 1960 -m comment --comment "!fw3: > Test-4-Any-Any-FORW" -j MARK --set-xmark 0x7/0xff > -A PREROUTING -p udp -m udp --dport 1965 -m comment --comment "!fw3: > Test-5-Zone-Dev-IN" -j DSCP --set-dscp 0x2e > -A OUTPUT -p udp -m udp --dport 1975 -m comment --comment "!fw3: > Test-7-Dev-Dev-OUT" -j DSCP --set-dscp 0x30 > > After this change, the resulting iptables rules use the expected devices > and chains: > > -A PREROUTING -i br-lan -p udp -m udp --dport 1945 -m comment --comment > "!fw3: Test-1-Zone-Any-PRE" -j DSCP --set-dscp 0x00 > -A FORWARD -i br-lan -o eth0 -p udp -m udp --dport 1950 -m comment --comment > "!fw3: Test-2-Zone-Zone-FORW" -j DSCP --set-dscp 0x08 > -A POSTROUTING -o eth0 -p tcp -m tcp --dport 1955 -m comment --comment "!fw3: > Test-3-Any-Zone-POST" -j MARK --set-xmark 0x3/0xff > -A FORWARD -p tcp -m tcp --dport 1960 -m comment --comment "!fw3: > Test-4-Any-Any-FORW" -j MARK --set-xmark 0x7/0xff > -A INPUT -i br-lan -p udp -m udp --dport 1965 -m comment --comment "!fw3: > Test-5-Zone-Dev-IN" -j DSCP --set-dscp 0x2e > -A OUTPUT -o eth0 -p tcp -m tcp --dport 1970 -m comment --comment "!fw3: > Test-6-Dev-Zone-OUT" -j MARK --set-xmark 0xf/0xff > -A OUTPUT -p udp -m udp --dport 1975 -m comment --comment "!fw3: > Test-7-Dev-Dev-OUT" -j DSCP --set-dscp 0x30 > > UCI FW Rules > > > config rule >option enabled '1' >option target 'DSCP' >option set_dscp 'BE' >option proto 'udp' >option dest_port '1945' >option name 'Test-1-Zone-Any-PRE' >option src 'lan' >option dest '*' > > config rule >option enabled '1' >option target 'DSCP' >option set_dscp 'CS1' >option proto 'udp' >option dest_port '1950' >option name 'Test-2-Zone-Zone-FORW' >option src 'lan' >option dest 'wan' > > config rule >option enabled '1' >option target 'MARK' >option set_mark '0x03/0xff' >option proto 'tcp' >option dest_port '1955' >option name 'Test-3-Any-Zone-POST' >option src '*' >option dest 'wan' > > config rule >option enabled '1' >option target 'MARK' >option set_mark '0x07/0xff' >option proto 'tcp' >option dest_port '1960' >option name 'Test-4-Any-Any-FORW' >option src '*' >option dest '*' > > config rule >option enabled '1' >option target 'DSCP' >option set_dscp 'EF' >option proto 'udp' >option dest_port '1965' >option name 'Test-5-Zone-Dev-IN' >option src 'lan' > > config rule >option enabled '1
Build changes correcting FPIC definition (was: [PATCH] gmp: compile with -DPIC to use correct asm code)
> On Mar 19, 2021, at 4:59 PM, Philip Prindeville > wrote: > > > >> On Mar 19, 2021, at 4:06 PM, Eneas U de Queiroz >> wrote: >> >> On Fri, Mar 19, 2021 at 5:08 PM Philip Prindeville >> wrote: >>> >>> >>> Maybe I'm missing something, but why not just fix rules.mk: >>> >>> >>> ifneq (,$(findstring $(ARCH) , aarch64 aarch64_be powerpc )) >>> FPIC:=-fPIC >>> else >>> FPIC:=-fpic >>> endif >>> >>> HOST_FPIC:=-fPIC >>> >>> >>> To have the FPIC and HOST_FPIC definitions include -DPIC? >> >> I think it would be the proper way to handle this. I was initially >> fearful of changing too much and breaking things, but I think it >> should be expected behaviour. What else would you use a 'PIC' >> definition for? I will resend a patch changing rules.mk instead. > > > Just saw this... Turns out that this would break a couple of packages (both > in openwrt and in packages), so I've included those as well. > > -Philip > Hi all, I think that Eneas and I have converged on a fix, it should help with some of the CircleCI issues we've been having with x86_64 (which oddly isn't our most leveraged architecture for CI/CD testing, even though it's the easiest to cloud deploy... but that's a separate discussion). We've both built and tested with this patch and no ill effects. There's actually a surprising number of places where the symbol "PIC" is tested, not just in asm files (which was the original libgmp problem), but also in C files supporting dlopen(), stack unwinding, etc. If you go into build_dir/target-*/ and run: % find . \( -name "*.[hc]" -o -name "*.[hc]pp" -o -name "*.asm" \) -print | xargs egrep -r -n '\' You'll get about 200+ hits (modulo some occurrences of "PIC" in comments), very close to 50% of those being in gmp-6.2.1 itself (not surprising because it has a lot of asm code). Other hits are also where you'd expect them: elfutils, binutils, gdb, etc. i.e. things that need to be relocation-aware or else projects with plugin support in the form of .so's (such as cyrus-sasl). The fix itself is trivial: it's 3 lines of changes. Can we please get core reviewers to consider and merge this? https://github.com/openwrt/openwrt/pull/4006 Thanks! -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Requiring 2FA on OpenWrt GitHub organization
Go for it. > On Apr 11, 2021, at 8:50 AM, Etienne Champetier > wrote: > > Hi All, > > There are currently 65 members in OpenWrt org, 58 of them with 2FA enabled. > Requiring 2FA would kick out the 7 users without 2FA, 6 of them have > no OpenWrt related activity for more than 2 or 3 years, I've emailed > the 7th one privately. > > Anyone see any problem enforcing 2FA ? > > Best > Etienne > > ___ > 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
Strongswan 6.0 removing ipsec CLI
Hi all, Word is that strongswan-6.0 will remove the ipsec interface. No idea how many 5.9.x releases will come out before that happens. Doing some prediction based on the past roadmap: The cadence in the past has been every 3 months, and typically x.y.3 or x.y.4 is the maximum release until 'y' gets bumped. We're at 5.9.2 (2021/2/26) currently, so .3 or .4 could be out in 1 month and 4 months, respectively. With this news, I'm disinclined (and I believe Noel concurs) to put a lot of effort into maintaining the ipsec UCI initd scripting. I'd rather just focus on adding Wiki documentation on how to tweak your /etc/config/ipsec configuration to work with swanctl instead. Anyone have an objection to this plan? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Request] Build x86_64 with EFI Images for ext4 combined
Yup, amen to that, but it seems to be something that’s for whatever reason is not quick to happen… > On Aug 22, 2018, at 1:17 AM, Joel Wirāmu Pauling wrote: > > Currently the Auto-generated x86/64 images are all msdos > partition/boot layouts. Which means they are a PITA to run on > increasingly UEFI only hardware. > > It would be great to have the release images and snapshots build have > two new variants a combined ext4 efi in particular would be very > useful. > > Cheers > > -Joel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Rebasing "Generate EFI grub images for x86 platforms" (resend)
Hi all. I was trying to rebase my branch to upstream/master recently, but I couldn’t because this commit conflicted: commit 9e3edeb55a2f85ecf6233a5780e495ea1755c998 Author: DUPONCHEEL Sébastien Date: Tue Apr 11 12:46:44 2017 +0200 Generate EFI grub images for x86 platforms Signed-off-by: DUPONCHEEL Sébastien here are the conflicts: CONFLICT (content): Merge conflict in target/linux/x86/image/Makefile CONFLICT (content): Merge conflict in package/boot/grub2/common.mk CONFLICT (content): Merge conflict in config/Config-images.in It might be related to: commit 55b808e0c4be681a0aab565d32a70f5af06a1f8a Author: Tomasz Maciej Nowak Date: Sun Jan 13 21:39:36 2019 +0100 x86: image: add test module to bootloader It was previously added in 546fced, which was part of "intel-microcode: load as early as possible" series. Unfortunately the conditionals added to GRUB config caused error on boot, because on sysupgrade, bootloader is not updated and is left with old features/modules. Since this module is needed for early microcode load and transition to this needs to be done step by step, enable the test module now, so that every newly created image has it already embedded. Signed-off-by: Tomasz Maciej Nowak or: commit bb0e4f9fb0c101b86b1a0c2785fec9b38b19fd02 Author: Tomasz Maciej Nowak Date: Sun Jan 13 21:37:47 2019 +0100 build: remove leftovers from previous x86 commits VBoxManage is not used and the image is created with proper permisions: 0f5d0f6 image: use internal qemu-img for vmdk and vdi images drop host dependencies on qemu-utils and VirtualBox Unreachable config symbols: 9e0759e x86: merge all geode based subtargets into one No need to define those symbols since x86_64 is subtarget of x86: 196fb76 x86: make x86_64 a subtarget instead of a standalone target Unreachable config symbols, so remove GRUB_ROOT: 371b382 x86: remove the xen_domu subtarget Signed-off-by: Tomasz Maciej Nowak Sebastian or Jo-Philipp: Is there a rebased version of this I can grab? What’s the state of the EFI changes making it into master, anyway? I’ve not been able to build an image in 3 months now. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Problems w/ "make defconfig oldconfig" after rebasing
I’ve been busy with other things, and just had a chance to try to get caught up with OpenWRT and my tickets, etc. I rebased openwrt and packages, then did “make defconfig oldconfig” but I’m seeing: WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libmariadbclient', which does not exist WARNING: Makefile 'package/feeds/packages/zabbix/Makefile' has a dependency on 'libmariadbclient', which does not exist tmp/.config-package.in:55: syntax error tmp/.config-package.in:54: invalid option tmp/.config-package.in:13106: syntax error tmp/.config-package.in:13105: invalid option Looking at this file, I get: 53 select PACKAGE_attendedsysupgrade-common 54 select PACKAGE_ucert if PACKAGE_ucert-full Date: Thu Apr 4 03:42:16 2019 + x86: add EFI images and make iso images EFI bootable cherry-picked into my tree, but this should be the cause. Anyone have an idea of what’s going on? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Problems w/ "make defconfig oldconfig" after rebasing
> On Jun 30, 2019, at 1:03 PM, Kevin Darbyshire-Bryant > wrote: > > >> On 30 Jun 2019, at 19:27, Philip Prindeville >> wrote: >> >> [snip] >> >> Anyone have an idea of what’s going on? > > There were some tweaks to how config interpreted package definitions. > Unfortunately ‘make’ doesn’t pick up the changes to config’s source, so it > needs to be manually cleaned. > > make -C scripts/config clean > > Should do the trick. I got bitten by this too :-) > > > Cheers, > > Kevin D-B > > gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A Thanks, that worked! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Issues with 4.19 and nft_reject_ipv4.ko after rebasing/updating
I’m seeing the following failure after rebasing to master and 4.19: make[3]: Entering directory '/home/philipp/lede/package/kernel/linux' mkdir -p /home/philipp/lede/staging_dir/target-x86_64_musl/root-x86/stamp SHELL= flock /home/philipp/lede/tmp/.root-copy.flock -c 'cp -fpR /home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/packages/.pkgdir/kernel/. /home/philipp/lede/staging_dir/target-x86_64_musl/root-x86/' touch /home/philipp/lede/staging_dir/target-x86_64_musl/root-x86/stamp/.kernel_installed ERROR: module '/home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-4.19.56/net/ipv4/netfilter/nft_reject_ipv4.ko' is missing. modules/netfilter.mk:1079: recipe for target '/home/philipp/lede/bin/targets/x86/64/packages/kmod-nft-core_4.19.56-1_x86_64.ipk' failed make[3]: *** [/home/philipp/lede/bin/targets/x86/64/packages/kmod-nft-core_4.19.56-1_x86_64.ipk] Error 1 make[3]: Leaving directory '/home/philipp/lede/package/kernel/linux' time: package/kernel/linux/compile#5.23#0.26#5.77 package/Makefile:107: recipe for target 'package/kernel/linux/compile' failed make[2]: *** [package/kernel/linux/compile] Error 2 make[2]: Leaving directory '/home/philipp/lede' package/Makefile:103: recipe for target '/home/philipp/lede/staging_dir/target-x86_64_musl/stamp/.package_compile' failed make[1]: *** [/home/philipp/lede/staging_dir/target-x86_64_musl/stamp/.package_compile] Error 2 make[1]: Leaving directory '/home/philipp/lede' /home/philipp/lede/include/toplevel.mk:216: recipe for target 'world’ failed I had previously been building 4.19 a couple of months ago and wasn’t seeing this. Who has been working on this stuff? I noticed that there’s now nf_reject_ipv4.c and nft_reject_ipv4.c, etc. and am wondering if both are now required in 4.19. Any ideas? Thanks ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Issues with 4.19 and nft_reject_ipv4.ko after rebasing/updating
> On Jun 30, 2019, at 6:13 PM, Philip Prindeville > wrote: > > I’m seeing the following failure after rebasing to master and 4.19: > > make[3]: Entering directory '/home/philipp/lede/package/kernel/linux' > mkdir -p /home/philipp/lede/staging_dir/target-x86_64_musl/root-x86/stamp > > SHELL= flock /home/philipp/lede/tmp/.root-copy.flock -c 'cp -fpR > /home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/packages/.pkgdir/kernel/. > /home/philipp/lede/staging_dir/target-x86_64_musl/root-x86/' > touch > /home/philipp/lede/staging_dir/target-x86_64_musl/root-x86/stamp/.kernel_installed > ERROR: module > '/home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-4.19.56/net/ipv4/netfilter/nft_reject_ipv4.ko' > is missing. > modules/netfilter.mk:1079: recipe for target > '/home/philipp/lede/bin/targets/x86/64/packages/kmod-nft-core_4.19.56-1_x86_64.ipk' > failed > make[3]: *** > [/home/philipp/lede/bin/targets/x86/64/packages/kmod-nft-core_4.19.56-1_x86_64.ipk] > Error 1 > make[3]: Leaving directory '/home/philipp/lede/package/kernel/linux' > time: package/kernel/linux/compile#5.23#0.26#5.77 > package/Makefile:107: recipe for target 'package/kernel/linux/compile' failed > make[2]: *** [package/kernel/linux/compile] Error 2 > make[2]: Leaving directory '/home/philipp/lede' > package/Makefile:103: recipe for target > '/home/philipp/lede/staging_dir/target-x86_64_musl/stamp/.package_compile' > failed > make[1]: *** > [/home/philipp/lede/staging_dir/target-x86_64_musl/stamp/.package_compile] > Error 2 > make[1]: Leaving directory '/home/philipp/lede' > /home/philipp/lede/include/toplevel.mk:216: recipe for target 'world’ failed > > I had previously been building 4.19 a couple of months ago and wasn’t seeing > this. > > Who has been working on this stuff? > > I noticed that there’s now nf_reject_ipv4.c and nft_reject_ipv4.c, etc. and > am wondering if both are now required in 4.19. > > Any ideas? > > Thanks That should say, “I had previously been building 4.14 a couple of months ago and wasn’t seeing this.” ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Issues with 4.19 and nft_reject_ipv4.ko after rebasing/updating
> On Jun 30, 2019, at 9:54 PM, Philip Prindeville > wrote: > > > >> On Jun 30, 2019, at 6:13 PM, Philip Prindeville >> wrote: >> >> I’m seeing the following failure after rebasing to master and 4.19: >> >> make[3]: Entering directory '/home/philipp/lede/package/kernel/linux' >> mkdir -p /home/philipp/lede/staging_dir/target-x86_64_musl/root-x86/stamp >> >> SHELL= flock /home/philipp/lede/tmp/.root-copy.flock -c 'cp -fpR >> /home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/packages/.pkgdir/kernel/. >> /home/philipp/lede/staging_dir/target-x86_64_musl/root-x86/' >> touch >> /home/philipp/lede/staging_dir/target-x86_64_musl/root-x86/stamp/.kernel_installed >> ERROR: module >> '/home/philipp/lede/build_dir/target-x86_64_musl/linux-x86_64/linux-4.19.56/net/ipv4/netfilter/nft_reject_ipv4.ko' >> is missing. >> modules/netfilter.mk:1079: recipe for target >> '/home/philipp/lede/bin/targets/x86/64/packages/kmod-nft-core_4.19.56-1_x86_64.ipk' >> failed >> make[3]: *** >> [/home/philipp/lede/bin/targets/x86/64/packages/kmod-nft-core_4.19.56-1_x86_64.ipk] >> Error 1 >> make[3]: Leaving directory '/home/philipp/lede/package/kernel/linux' >> time: package/kernel/linux/compile#5.23#0.26#5.77 >> package/Makefile:107: recipe for target 'package/kernel/linux/compile' failed >> make[2]: *** [package/kernel/linux/compile] Error 2 >> make[2]: Leaving directory '/home/philipp/lede' >> package/Makefile:103: recipe for target >> '/home/philipp/lede/staging_dir/target-x86_64_musl/stamp/.package_compile' >> failed >> make[1]: *** >> [/home/philipp/lede/staging_dir/target-x86_64_musl/stamp/.package_compile] >> Error 2 >> make[1]: Leaving directory '/home/philipp/lede' >> /home/philipp/lede/include/toplevel.mk:216: recipe for target 'world’ failed >> >> I had previously been building 4.19 a couple of months ago and wasn’t seeing >> this. >> >> Who has been working on this stuff? >> >> I noticed that there’s now nf_reject_ipv4.c and nft_reject_ipv4.c, etc. and >> am wondering if both are now required in 4.19. >> >> Any ideas? >> >> Thanks > > > That should say, “I had previously been building 4.14 a couple of months ago > and wasn’t seeing this.” > Anyone? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] libtirpc broken Makefile?
I just ran: % scripts/feeds update -i packages % rm -rf tmp/ % make defconfig oldconfig % grep libtirpc .config % grep "Package: libtirpc” tmp/.packageinfo % ls tmp/info/.packageinfo-feeds_packages_libtirpc ls: cannot access 'tmp/info/.packageinfo-feeds_packages_libtirpc': No such file or directory % What am I missing? I can’t build lsof without this now. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: execute package prerm script in a subshell
LGTM
> On Aug 23, 2018, at 6:21 PM, Luis Araneda wrote:
>
> This fixes a problem that's causing an early return of
> default_prerm() when the package prerm script has an
> exit statement at the end, which is implemented as
> "exit 0" by most of the packages that use prerm
>
> With the new behavior, the execution of default_prerm()
> will continue only if the prerm script returns 0,
> otherwise the function will return the error code
>
> Additionally, this makes the execution consistent with
> the postinst script
>
> Signed-off-by: Luis Araneda
> ---
> Compile and run tested on ipq40xx
>
> ---
> package/base-files/files/lib/functions.sh | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/package/base-files/files/lib/functions.sh
> b/package/base-files/files/lib/functions.sh
> index 318e91856b..579aa93dca 100755
> --- a/package/base-files/files/lib/functions.sh
> +++ b/package/base-files/files/lib/functions.sh
> @@ -153,9 +153,14 @@ config_list_foreach() {
> default_prerm() {
> local root="${IPKG_INSTROOT}"
> local name
> + local ret
>
> name=$(basename ${1%.*})
> - [ -f "$root/usr/lib/opkg/info/${name}.prerm-pkg" ] && .
> "$root/usr/lib/opkg/info/${name}.prerm-pkg"
> + if [ -f "$root/usr/lib/opkg/info/${name}.prerm-pkg" ]; then
> + ( . "$root/usr/lib/opkg/info/${name}.prerm-pkg" )
> + ret=$?
> + [ $ret -ne 0 ] && return $ret
> + fi
>
> local shell="$(which bash)"
> for i in `cat "$root/usr/lib/opkg/info/${name}.list" | grep
> "^/etc/init.d/"`; do
> --
> 2.18.0
>
>
> ___
> 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] Minimum UCI to change macaddr of wlan0
I have some boards that came from the factory with the wrong MAC address burned into wlan0. What’s the minimum UCI required to associate a new MAC with them regardless of what configurations they might appear in (i.e. in the be: “option ifname ‘eth0 wlan0’” etc). Thanks. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.01 plans
> On Sep 22, 2018, at 4:42 PM, Hauke Mehrtens wrote: > > Signed PGP part > Hi, > > We talked about plans for the next OpenWrt releases in this mail thread: > http://lists.infradead.org/pipermail/openwrt-adm/2018-July/000849.html > This mail is more or less a summary of the conclusions, this is still > open for change especially the dates as this depends on people having > time to do the work. > > The next release, lets call it OpenWrt 19.01, should happen in January > 2019, we would branch off from master in December 2018. This is the > current plan, but based on past experience it could also happen later. > > OpenWrt 19.01 will ship with kernel 4.14 only, we encourage everyone to > update the targets to kernel 4.14, support for kernel 4.19 will probably > be added to OpenWrt master soon, but we will not select it as the > default kernel for any target till OpenWrt 19.01 is branched off, to get > more testing on 4.14. The release after 19.01, which should happen in > late summer 2019, should then use kernel 4.19 only. > > For OpenWrt 19.01 GCC will stay on the 7.X branch, binutils and musl > already got some upgrades after the 18.06 release and could get some > more updates. > > We are currently working on updating the wireless drivers and getting > them closer to upstream. The wireless driver in OpenWrt 19.01 will be > taken from kernel 4.19 or later and we want to update them more > frequently in master. > > Otherwise we will have the normal changes in all places like with every > release. > > LEDE 17.01 will get security updates and occasional bug fixes till > OpenWrt 19.01 was released, but we encourage everyone to upgrade to > 18.06 to get full security support already now, as especially some of > the packages are not well maintained any more. > > Hauke > Hi Hauke, This reminds me of an issue I’ve run into. xtables-addons-3.0 will build on 4.14, but xtables-addons-3.1 requires 4.19 at a minimum. Is it reasonable to have xtables-addons/Makefile pick a version based on the kernel version? -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: add network_get_metric() to /lib/functions/network.sh
LGTM
Sent from my iPhone
> On Sep 24, 2018, at 6:20 AM, Florian Eckert wrote:
>
> Signed-off-by: Florian Eckert
> ---
> package/base-files/files/lib/functions/network.sh | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/package/base-files/files/lib/functions/network.sh
> b/package/base-files/files/lib/functions/network.sh
> index d7fd2dea57..4fdcb66302 100644
> --- a/package/base-files/files/lib/functions/network.sh
> +++ b/package/base-files/files/lib/functions/network.sh
> @@ -271,6 +271,11 @@ network_is_up()
> # 2: interface
> network_get_protocol() { __network_ifstatus "$1" "$2" ".proto"; }
>
> +# determine the metric of the given logical interface
> +# 1: destination variable
> +# 2: interface
> +network_get_metric() { __network_ifstatus "$1" "$2" ".metric"; }
> +
> # determine the layer 3 linux network device of the given logical interface
> # 1: destination variable
> # 2: interface
> --
> 2.11.0
>
>
> ___
> 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] Tarpit support in firewall
Jo-Philipp, Felix, et al:
I’ve added the following to my /etc/firewall.user but I was thinking it might
be useful for others, and worth integrating into the firewall.
It’s currently implemented in Shell, but should be trivial in C.
The relevant config (/etc/config/firewall) looks like:
config tarpit
option name 'misc'
option src wan
option dest_port
'22,23,113,119,123,161,220,222,389,397,515,623,873,1433,1720,1723,1812,2323,2375-2376,3128,3306,3388-3398,5000-5001,5038,5060,5351,5353,5358,5431,,5900-5959,6000-6063,6379,7000-7009,7547,9000,9200,10250,11211'
config tarpit
option name 'mail'
option src wan
option dest_port '110,143,465,995'
config tarpit
option name 'web'
option src wan
option dest_port '81-94,1080,8000-8001,8080-8088,8181,'
config tarpit
option name 'netbios'
option src wan
option dest_port '137-139’
The scripting looks like:
…
tarpit_add() {
local cfg="$1"
local name src ports
config_get name "$cfg" name
[ -n "$name" ] || return 0
config_get src "$cfg" "src"
[ -n "$src" ] || return 0
local initial="${src:0:1}"
iptables -D "input_${src}_rule" -m set --match-set "tarpit_${name}" dst
-j "i${initial}r_${name}" 2>/dev/null
iptables -F "i${initial}r_${name}" 2>/dev/null
iptables -X "i${initial}r_${name}" 2>/dev/null
ipset list "tarpit_${name}" >/dev/null 2>&1 && ipset destroy
"tarpit_${name}"
ipset create "tarpit_${name}" bitmap:port range 0-65535
config_get ports "$cfg" "dest_port"
local port IFS=', '
for port in $ports; do
ipset add "tarpit_${name}" "${port}" \
|| echo "Couldn't add ${port} to tarpit_${name}" >&2
done
iptables -N "i${initial}r_${name}"
iptables -A "i${initial}r_${name}" -m limit --limit 1/sec --limit-burst
5 -j LOG --log-level 4 --log-prefix "TARPIT ${name}: "
iptables -A "i${initial}r_${name}" -m tcp -p tcp -j TARPIT
iptables -A "input_${src}_rule" -m set --match-set "tarpit_${name}" dst
-m tcp -p tcp -j "i${initial}r_${name}"
return 0
}
. /lib/functions/network.sh
config_load firewall
config_foreach tarpit_add tarpit "$@“
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Quick question about firewall patch
I’m looking at: https://git.openwrt.org/?p=project/firewall3.git;a=commitdiff;h=c03e20d7f594058ff223f30cf34de1b5e8210b8d;hp=b59934331c4b9271ceb5e30b793a552618299d39 and wondering, why not just do: v4->s_addr = htonl(~(UINT_MAX >> bits)); For instance, with bits == 14, we get: UINT_MAX >> 14 == 0x0003 ~0x0003 == 0xfffc Checking the case for bits == 0, we get: UINT_MAX >> 0 == 0x ~0x == 0x And for bits == 32, we get: UINT_MAX >> 32 == 0x ~0x == 0x ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] fstools: mount ntfs with ntfs-3g utility if it exists
Comments inline
> On Sep 29, 2018, at 9:04 PM, Rosy Song wrote:
>
> From: Rosy Song
> Subject: [OpenWrt-Devel] [PATCH] fstools: mount ntfs with ntfs-3g utility if
> it exists
>
> This patch can mount ntfs with fuseblk fs type and make the deivces to be
> mounted writable.
>
> --- a/block.c
> +++ b/block.c
> @@ -881,7 +881,13 @@ static int handle_mount(const char *sour
> size_t mount_opts_len;
> char *mount_opts = NULL, *ptr;
>
> - err = mount(source, target, fstype, m ? m->flags : 0,
> + if (!strncmp(fstype, "ntfs", strlen(fstype)) &&
How is this any different from !strcmp(fstype, “ntfs”) ?
> + !access("/sbin/mount.ntfs-3g", X_OK)) {
> + // mount ntfs filesystem with ntfs-3g utility
> + err = -1;
> + errno = ENODEV;
> + } else
> + err = mount(source, target, fstype, m ? m->flags : 0,
> (m && m->options) ? m->options : "");
>
> /* Requested file system type is not available in kernel,
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH, V2] fstools: mount ntfs with ntfs-3g utility if it exist
I’m not seeing where “mount.ntfs-3g” is being set as the program to use... and
should the test for the presence and modes of the program be generic? i.e.
regardless of what type of FS or which program you use to mount it, you’ll want
to test for its presence.
So these are really two independent things.
> On Sep 30, 2018, at 9:04 PM, Rosy Song wrote:
>
> Signed-off-by: Rosy Song
> ---
> block.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/block.c b/block.c
> index 2651c86..b2cd32b 100644
> --- a/block.c
> +++ b/block.c
> @@ -881,7 +881,13 @@ static int handle_mount(const char *source, const char
> *target,
>size_t mount_opts_len;
>char *mount_opts = NULL, *ptr;
>
> -err = mount(source, target, fstype, m ? m->flags : 0,
> +/* Mount ntfs filesystem with ntfs-3g utility */
> +if (!strcmp(fstype, "ntfs") &&
> +!access("/sbin/mount.ntfs-3g", X_OK)) {
> +err = -1;
> +errno = ENODEV;
> +} else
> +err = mount(source, target, fstype, m ? m->flags : 0,
>(m && m->options) ? m->options : "");
>
>/* Requested file system type is not available in kernel,
> --
> 2.17.0
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH, V2] fstools: mount ntfs with ntfs-3g utility if it exist
> On Oct 1, 2018, at 10:22 AM, Jérôme Benoit wrote:
>
> Signed PGP part
> Le 01/10/2018 à 06:21, Philip Prindeville a écrit :
>> I’m not seeing where “mount.ntfs-3g” is being set as the program to use...
>
> I think this patch is just plain wrong.
> A correct one has been done here :
> http://lists.infradead.org/pipermail/openwrt-devel/2018-September/014108.html
That one is buggy, too.
@@ -725,6 +726,8 @@ static void check_filesystem(struct probe_info *pr)
ckfs = e2fsck;
} else if (!strncmp(pr->type, "btrfs", 5)) {
ckfs = btrfsck;
+ } else if (!strncmp(pr->type, "ntfs", 5)) {
+ ckfs = ntfsck;
} else {
ULOG_ERR("check_filesystem: %s is not supported\n", pr->type);
return;
@@ -743,6 +746,9 @@ static void check_filesystem(struct probe_info *pr)
} else if(!strncmp(pr->type, "btrfs", 5)) {
execl(ckfs, ckfs, "--repair", pr->dev, NULL);
exit(-1);
+ } else if(!strncmp(pr->type, "ntfs", 5)) {
+ execl(ckfs, ckfs, "-b", pr->dev, NULL);
+ exit(-1);
} else {
execl(ckfs, ckfs, "-p", pr->dev, NULL);
exit(-1);
@@ -1437,8 +1443,9 @@ static int mount_extroot(char *cfg)
if (strncmp(pr->type, "ext", 3) &&
strncmp(pr->type, "f2fs", 4) &&
strncmp(pr->type, "btrfs", 5) &&
+ strncmp(pr->type, "ntfs", 5) &&
strncmp(pr->type, "ubifs", 5)) {
- ULOG_ERR("extroot: unsupported filesystem %s, try ext4,
f2fs, btrfs or ubifs\n", pr->type);
+ ULOG_ERR("extroot: unsupported filesystem %s, try ext4,
f2fs, btrfs, ntfs or ubifs\n", pr->type);
return -1;
}
Uhhh… by my count, “ntfs” is 4 letters, not 5.
>
> ++
>
signature.asc
Description: Message signed with OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH, V2] fstools: mount ntfs with ntfs-3g utility if it exist
> On Oct 1, 2018, at 10:22 AM, Jérôme Benoit wrote:
>
> Signed PGP part
> Le 01/10/2018 à 06:21, Philip Prindeville a écrit :
>> I’m not seeing where “mount.ntfs-3g” is being set as the program to use...
>
> I think this patch is just plain wrong.
> A correct one has been done here :
> http://lists.infradead.org/pipermail/openwrt-devel/2018-September/014108.html
That one is buggy, too.
@@ -725,6 +726,8 @@ static void check_filesystem(struct probe_info *pr)
ckfs = e2fsck;
} else if (!strncmp(pr->type, "btrfs", 5)) {
ckfs = btrfsck;
+ } else if (!strncmp(pr->type, "ntfs", 5)) {
+ ckfs = ntfsck;
} else {
ULOG_ERR("check_filesystem: %s is not supported\n", pr->type);
return;
@@ -743,6 +746,9 @@ static void check_filesystem(struct probe_info *pr)
} else if(!strncmp(pr->type, "btrfs", 5)) {
execl(ckfs, ckfs, "--repair", pr->dev, NULL);
exit(-1);
+ } else if(!strncmp(pr->type, "ntfs", 5)) {
+ execl(ckfs, ckfs, "-b", pr->dev, NULL);
+ exit(-1);
} else {
execl(ckfs, ckfs, "-p", pr->dev, NULL);
exit(-1);
@@ -1437,8 +1443,9 @@ static int mount_extroot(char *cfg)
if (strncmp(pr->type, "ext", 3) &&
strncmp(pr->type, "f2fs", 4) &&
strncmp(pr->type, "btrfs", 5) &&
+ strncmp(pr->type, "ntfs", 5) &&
strncmp(pr->type, "ubifs", 5)) {
- ULOG_ERR("extroot: unsupported filesystem %s, try ext4,
f2fs, btrfs or ubifs\n", pr->type);
+ ULOG_ERR("extroot: unsupported filesystem %s, try ext4,
f2fs, btrfs, ntfs or ubifs\n", pr->type);
return -1;
}
Uhhh… by my count, “ntfs” is 4 letters, not 5.
>
> ++
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Use binutils 2.31.1 by default
> On Aug 27, 2018, at 4:41 AM, Daniel Engberg > wrote: > > As per request, > > https://github.com/openwrt/openwrt/pull/1297 > > Longer tests with > https://lists.openwrt.org/pipermail/openwrt-devel/2018-July/013394.html > without issues > > Not subscribed so please cc > > Best regards, > Daniel Engberg I just realized that it breaks grub-efi but there’s a patch for this. I’ll post it as soon as I have a chance to test it. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: tolerate using UBI/UBIFS on MLC flash (FS#1830)
Can you drop the CAPS on words (not acronyms) and the _markup_?
Sent from my iPhone
> On Oct 18, 2018, at 6:28 AM, Koen Vandeputte
> wrote:
>
> starting from upstream commit 577b4eb23811 ("ubi: Reject MLC NAND")
> it is not allowed to use UBI and UBIFS on a MLC flavoured NAND flash chip. [1]
>
> According to David Oberhollenzer [2]:
>
> The real problem is that on MLC NAND, pages come in pairs.
>
> Multiple voltage levels inside a single, physical memory cell are used to
> encode more than one bit. Instead of just having pages that are twice as big,
> the flash exposes them as *two different pages*. Those pages are usually not
> ordered sequentially either, but according to a vendor/device specific
> pairing scheme.
>
> Within OpenWrt, devices utilizing this type of flash,
> combined with ubi(fs) will be bricked when a user upgrades
> from 17.01.4 to a newer version as the MLC will be refused.
>
> As these devices are currently advertised as supported by OpenWrt,
> we should at least maintain the original state during the lifecycle
> of the current releases.
>
> Support can be gracefully ended when a new release-branch is created.
>
> Signed-off-by: Koen Vandeputte
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.14.77&id=577b4eb23811dfc8e38924dc476dbc866be74253
> [2] https://lore.kernel.org/patchwork/patch/920344/
> ---
>
> Mainly intended for discussion first on this approach before applying it.
> Can be cherrypicked to 18.06.
>
> Feel free to drop your (n)ack on this approach
>
>
>
> .../hack-4.14/420-allow-ubi-mlc-support.patch | 13 +
> .../hack-4.9/420-allow-ubi-mlc-support.patch| 13 +
> 2 files changed, 26 insertions(+)
> create mode 100644
> target/linux/generic/hack-4.14/420-allow-ubi-mlc-support.patch
> create mode 100644
> target/linux/generic/hack-4.9/420-allow-ubi-mlc-support.patch
>
> diff --git a/target/linux/generic/hack-4.14/420-allow-ubi-mlc-support.patch
> b/target/linux/generic/hack-4.14/420-allow-ubi-mlc-support.patch
> new file mode 100644
> index ..595936f13791
> --- /dev/null
> +++ b/target/linux/generic/hack-4.14/420-allow-ubi-mlc-support.patch
> @@ -0,0 +1,13 @@
> +--- a/drivers/mtd/ubi/build.c
> b/drivers/mtd/ubi/build.c
> +@@ -851,9 +851,8 @@ int ubi_attach_mtd_dev(struct mtd_info *
> + * will die soon and you will lose all your data.
> + */
> +if (mtd->type == MTD_MLCNANDFLASH) {
> +-pr_err("ubi: refuse attaching mtd%d - MLC NAND is not supported\n",
> ++pr_warn("ubi: mtd%d has been identified as a MLC NAND!! - MLC is
> not supported by UBI and UBIFS and _WILL_ cause corruption in the near
> future!\n",
> +mtd->index);
> +-return -EINVAL;
> +}
> +
> +if (ubi_num == UBI_DEV_NUM_AUTO) {
> diff --git a/target/linux/generic/hack-4.9/420-allow-ubi-mlc-support.patch
> b/target/linux/generic/hack-4.9/420-allow-ubi-mlc-support.patch
> new file mode 100644
> index ..552ae5da75cf
> --- /dev/null
> +++ b/target/linux/generic/hack-4.9/420-allow-ubi-mlc-support.patch
> @@ -0,0 +1,13 @@
> +--- a/drivers/mtd/ubi/build.c
> b/drivers/mtd/ubi/build.c
> +@@ -900,9 +900,8 @@ int ubi_attach_mtd_dev(struct mtd_info *
> + * will die soon and you will lose all your data.
> + */
> +if (mtd->type == MTD_MLCNANDFLASH) {
> +-pr_err("ubi: refuse attaching mtd%d - MLC NAND is not supported\n",
> ++pr_warn("ubi: mtd%d has been identified as a MLC NAND!! - MLC is
> not supported by UBI and UBIFS and _WILL_ cause corruption in the near
> future!\n",
> +mtd->index);
> +-return -EINVAL;
> +}
> +
> +if (ubi_num == UBI_DEV_NUM_AUTO) {
> --
> 2.17.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3] kernel: revert bad module stripping patch
Some hardware (it’s rare but not unheard of) can only be reset by unloading and reloading the module that controls it. Otherwise, you have to reboot the box. If you build all of your drivers in, then rebooting is all you have. My firewall has been up for 3 years. I update it with opkg, including modules. It would have been up longer, but I have to swap out the UPS that it’s on tomorrow. Well, at least now I can sysupgrade to a newer kernel… > On Oct 29, 2018, at 5:01 PM, Daniel Santos wrote: > > I would like to take this opportunity to mention that the best way to > save space here is to not build modules -- make them built-ins. I did a > quick experiment of this and instead of saving 4k, my *image* is a full > 256k smaller. I haven't analysed the specifics, but also this means > less RAM consumed because squashfs uses the page cache for uncompressed > files. Further, modules inherently have greater overhead, even after > __init sections have been discarded. > > sed -i 's/=m/=y/g;' > build_dir/target-mipsel_24kc_musl/linux-ramips_mt7620/linux-4.14.63/.config > make > > The only downside is that built-ins cannot be unloaded and will always > occupy a portion of RAM. But having them built into the kernel is far > more efficient. > > Daniel > > On 10/29/2018 05:54 PM, Daniel Santos wrote: >> Never EVER do this! Decades of computer science has taught us "best >> practices" -- ways of doing things that provide an optimal outcome for >> all parties involved. While this type of hack is fine if you're working >> alone, it is not a "best practice" and is completely unacceptable for a >> large FOSS project. This is especially insidious because it goes behind >> the back of the programmer / user / hacker and makes a change without >> their consent or direction -- this is the type of behaviour we've come >> to expect from Google, m$, Apple and the like, not from FOSS. >> >> Doing --strip-all is not appropriate default behaviour as this includes >> relocation data and breaks things like kmemleak. The presence of debug >> information in modules is already controlled by CONFIG_DEBUG_INFO, >> CONFIG_DEBUG_INFO_REDUCED, etc. Force-stripping just makes life crappy >> for anybody who needs to debug the a kernel built in OpenWRT. (Some of >> us do run gdb on the kernel.) >> >> If --strip-all really is desired, it should probably be added to the >> CONFIG_MODULE_STRIPPED patch, and should be done at install time >> (probably via objcopy), not at link time. This leaves the in-tree >> modules useful for debugging, decompiling, diagnostics, profiling, etc. >> >> Signed-off-by: Daniel Santos >> --- >> .../generic/hack-4.14/202-reduce_module_size.patch | 24 >> -- >> .../generic/hack-4.9/202-reduce_module_size.patch | 24 >> -- >> 2 files changed, 48 deletions(-) >> delete mode 100644 >> target/linux/generic/hack-4.14/202-reduce_module_size.patch >> delete mode 100644 target/linux/generic/hack-4.9/202-reduce_module_size.patch >> >> diff --git a/target/linux/generic/hack-4.14/202-reduce_module_size.patch >> b/target/linux/generic/hack-4.14/202-reduce_module_size.patch >> deleted file mode 100644 >> index 2cbb6add9a..00 >> --- a/target/linux/generic/hack-4.14/202-reduce_module_size.patch >> +++ /dev/null >> @@ -1,24 +0,0 @@ >> -From fd66884da2f96d2a7ea73f58b1b86251b959a913 Mon Sep 17 00:00:00 2001 >> -From: Felix Fietkau >> -Date: Fri, 7 Jul 2017 16:56:19 +0200 >> -Subject: kernel: strip unnecessary symbol table information from kernel >> modules >> - >> -reduces default squashfs size on ar71xx by about 4k >> - >> -lede-commit: 058d331a39077f159ca8922f1f422a1346d6aa67 >> -Signed-off-by: Felix Fietkau >> >> - Makefile | 2 +- >> - 1 file changed, 1 insertion(+), 1 deletion(-) >> - >> a/Makefile >> -+++ b/Makefile >> -@@ -425,7 +425,7 @@ KBUILD_AFLAGS_KERNEL := >> - KBUILD_CFLAGS_KERNEL := >> - KBUILD_AFLAGS_MODULE := -DMODULE >> - KBUILD_CFLAGS_MODULE := -DMODULE >> --KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds >> -+KBUILD_LDFLAGS_MODULE = -T $(srctree)/scripts/module-common.lds $(if >> $(CONFIG_PROFILING),,-s) >> - GCC_PLUGINS_CFLAGS := >> - >> - export ARCH SRCARCH SUBARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE >> AS LD >> diff --git a/target/linux/generic/hack-4.9/202-reduce_module_size.patch >> b/target/linux/generic/hack-4.9/202-reduce_module_size.patch >> deleted file mode 100644 >> index f744b945fe..00 >> --- a/target/linux/generic/hack-4.9/202-reduce_module_size.patch >> +++ /dev/null >> @@ -1,24 +0,0 @@ >> -From fd66884da2f96d2a7ea73f58b1b86251b959a913 Mon Sep 17 00:00:00 2001 >> -From: Felix Fietkau >> -Date: Fri, 7 Jul 2017 16:56:19 +0200 >> -Subject: kernel: strip unnecessary symbol table information from kernel >> modules >> - >> -reduces default squashfs size on ar71xx by about 4k >> - >> -lede-commit: 058d331a39077f159ca8922f1f422a1346d6aa67 >> -Signed-off-by: Felix Fietkau >>
Re: [OpenWrt-Devel] [PATCH v3 3/6] x86: add packages files to image bootfs
Inline > On Oct 31, 2018, at 11:02 AM, Tomasz Maciej Nowak wrote: > > Add files to bootfs image from selected as built-in packages, which want > to install files to targets boot file system. > > Signed-off-by: Tomasz Maciej Nowak > --- > target/linux/x86/image/Makefile | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/image/Makefile > index b537c40f24..310a143e13 100644 > --- a/target/linux/x86/image/Makefile > +++ b/target/linux/x86/image/Makefile > @@ -85,6 +85,7 @@ ifneq ($(CONFIG_GRUB_IMAGES),) >-e 's#@ROOT@#$(GRUB_ROOT)#g' \ >-e 's#@TITLE@#$(GRUB_TITLE)#g' \ >./grub.cfg > $(KDIR)/root.grub/boot/grub/grub.cfg > +-$(CP) $(STAGING_DIR_ROOT)/boot/* $(KDIR)/root.grub/boot/ Per below >PADDING="$(CONFIG_TARGET_IMAGES_PAD)" SIGNATURE="$(SIGNATURE)" > PATH="$(TARGET_PATH)" $(SCRIPT_DIR)/gen_image_generic.sh \ >$(BIN_DIR)/$(IMG_PREFIX)-combined-$(1).img \ >$(CONFIG_TARGET_KERNEL_PARTSIZE) $(KDIR)/root.grub \ > @@ -123,6 +124,7 @@ define Image/Build/iso >-e 's#@TIMEOUT@#$(GRUB_TIMEOUT)#g' \ >-e 's#@TITLE@#$(GRUB_TITLE)#g' \ >./grub-iso.cfg > $(KDIR)/root.grub/boot/grub/grub.cfg > +-$(CP) $(STAGING_DIR_ROOT)/boot/* $(KDIR)/root.grub/boot/ I’d use . instead of * >mkisofs -R -b boot/grub/eltorito.img -no-emul-boot -boot-info-table \ >-o $(KDIR)/root.iso $(KDIR)/root.grub $(TARGET_DIR) > endef > -- > 2.19.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC 4/6] x86: geode: shrink amount of default packages
Why is the hwclock being dropped everywhere? And who says the geos2, net5501, or alix2 are obsolete? I have some running right here… > On Jan 13, 2019, at 2:49 PM, Tomasz Maciej Nowak wrote: > > Drop excesive amount of default packages, instead, rely on packages > specified in device definitions. > > Signed-off-by: Tomasz Maciej Nowak > --- > target/linux/x86/geode/target.mk | 12 +--- > 1 file changed, 1 insertion(+), 11 deletions(-) > > diff --git a/target/linux/x86/geode/target.mk > b/target/linux/x86/geode/target.mk > index 5473d2a32b..cd7afef944 100644 > --- a/target/linux/x86/geode/target.mk > +++ b/target/linux/x86/geode/target.mk > @@ -1,16 +1,6 @@ > BOARDNAME:=AMD Geode based systems > FEATURES+=pci usb gpio > -DEFAULT_PACKAGES += \ > - kmod-crypto-hw-geode kmod-crypto-cbc \ > - kmod-ath5k kmod-ath9k \ > - kmod-button-hotplug \ > - kmod-ledtrig-heartbeat kmod-ledtrig-gpio \ > - kmod-ledtrig-netdev hwclock wpad-basic > -# Geos > -DEFAULT_PACKAGES += \ > - soloscli linux-atm br2684ctl ppp-mod-pppoa pppdump pppstats \ > - hwclock flashrom tc kmod-pppoa kmod-8139cp kmod-mppe \ > - kmod-usb-ohci-pci kmod-hwmon-lm90 > +DEFAULT_PACKAGES+=kmod-button-hotplug > > define Target/Description > Build firmware images for AMD Geode GX/LX based systems (net5501, alix, > geos) > -- > 2.20.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC 4/6] x86: geode: shrink amount of default packages
Inline > On Jan 15, 2019, at 12:40 AM, Tomasz Maciej Nowak wrote: > > Hi Philip > > W dniu 14.01.2019 o 21:10, Philip Prindeville pisze: > >> Why is the hwclock being dropped everywhere? > > It's provided by busybox and installed by default, also greping for its usage > in target/linux/x86/base-files returned nothing. Am I missing something, is > the full fledged one used somewhere or by something? It’s used at least two places. When you first get the board and bring it up and set the clock, since it’s not usually set correctly by the factory, and it’s used by the ntpd script to save the synchronized time when the system is taken down. > >> And who says the geos2, net5501, or alix2 are obsolete? > > They are not obsolete by any means, only the way to assign packages for > specific device changes. Please take a look at patch nr 2 in this RFC and > section adding target/linux/x86/image/geode.mk. There You have almost all > packages replicated with additional geos device profile. Now You'll get two > images, one generic, and one for geos. This distinction is here because with > old way of adding packages, the generic image would end up with lot of > useless, geos/dsl specific packages. So why is there a Device/geos but none of the other SBC’s? And why doesn’t the geos DEVICE_PACKAGES include -kmod-via-rhine, since it uses the kmod-8139cp instead? -Philip > >> I have some running right here… > > I have WRAP which runs perfectly fine with these changes. > > Regards, Tomasz > > -- > TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Problem building modules out-of-tree (kbuild) for x86
Hi. I’m trying to add the Intel e1000e, igb, and ixgbe drivers that are on Source Forge. A snapshot of my work is here: https://github.com/pprindeville/packages/tree/sf-ether When I build this as “make -j1 V=s” using a mostly unmodified x86_64 generic configuration, I get: make[3]: Entering directory `/home/philip/bertram/bmu-philip.sanity/openwrt/feeds/packages/kernel/e1000e' . /home/philip/bertram/bmu-philip.sanity/openwrt/include/shell.sh; gzip -dc /home/philip/bertram/bmu-philip.sanity/openwrt/dl/e1000e-3.3.5.3.tar.gz | tar -C /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3/.. -xf - touch /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3/.prepared_b318088b5b0515ca987313e94558d492 rm -f /home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/target-x86_64_musl-1.1.15_powercode-bmu/stamp/.e1000e_installed (cd /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3/./; if [ -x ./configure ]; then find /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3/ -name config.guess | xargs -r chmod u+w; find /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3/ -name config.guess | xargs -r -n1 cp --remove-destination /home/philip/bertram/bmu-philip.sanity/openwrt/scripts/config.guess; find /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3/ -name config.sub | xargs -r chmod u+w; find /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3/ -name config.sub | xargs -r -n1 cp --remove-destination /home/philip/bertram/bmu-philip.sanity/openwrt/scripts/config.sub; AR="x86_64-openwrt-linux-musl-gcc-ar" AS="x86_64-openwrt-linux-musl-gcc -c -Os -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -iremap /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3:e1000e-3.3.5.3 -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro" LD=x86_64-openwrt-linux-musl-ld NM="x86_64-openwrt-linux-musl-gcc-nm" CC="x86_64-openwrt-linux-musl-gcc" GCC="x86_64-openwrt-linux-musl-gcc" CXX="x86_64-openwrt-linux-musl-g++" RANLIB="x86_64-openwrt-linux-musl-gcc-ranlib" STRIP=x86_64-openwrt-linux-musl-strip OBJCOPY=x86_64-openwrt-linux-musl-objcopy OBJDUMP=x86_64-openwrt-linux-musl-objdump SIZE=x86_64-openwrt-linux-musl-size CFLAGS="-Os -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -iremap /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3:e1000e-3.3.5.3 -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro " CXXFLAGS="-Os -pipe -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -iremap /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e1000e-3.3.5.3:e1000e-3.3.5.3 -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro " CPPFLAGS="-I/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/target-x86_64_musl-1.1.15_powercode-bmu/usr/include -I/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/target-x86_64_musl-1.1.15_powercode-bmu/include -I/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/toolchain-x86_64_gcc-5.3.0_musl-1.1.15/usr/include -I/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/toolchain-x86_64_gcc-5.3.0_musl-1.1.15/include/fortify -I/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/toolchain-x86_64_gcc-5.3.0_musl-1.1.15/include " LDFLAGS="-L/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/target-x86_64_musl-1.1.15_powercode-bmu/usr/lib -L/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/target-x86_64_musl-1.1.15_powercode-bmu/lib -L/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/toolchain-x86_64_gcc-5.3.0_musl-1.1.15/usr/lib -L/home/philip/bertram/bmu-philip.sanity/openwrt/staging_dir/toolchain-x86_64_gcc-5.3.0_musl-1.1.15/lib -znow -zrelro " ./configure --target=x86_64-openwrt-linux --host=x86_64-openwrt-linux --build=x86_64-linux-gnu --program-prefix="" --program-suffix="" --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --sysconfdir=/etc --datadir=/usr/share --localstatedir=/var --mandir=/usr/man --infodir=/usr/info --disable-nls ; fi; ) rm -f /home/philip/bertram/bmu-philip.sanity/openwrt/build_dir/target-x86_64_musl-1.1.15_powercode-bmu/linux-x86_64/e100
Re: [OpenWrt-Devel] Problem building modules out-of-tree (kbuild) for x86
> On Dec 19, 2016, at 1:25 AM, Alexandru Ardelean > wrote: > > On Mon, Dec 19, 2016 at 1:41 AM, Philip Prindeville > wrote: >> Hi. >> >> I’m trying to add the Intel e1000e, igb, and ixgbe drivers that are on >> Source Forge. >> >> A snapshot of my work is here: >> >> https://github.com/pprindeville/packages/tree/sf-ether >> >> When I build this as “make -j1 V=s” using a mostly unmodified x86_64 generic >> configuration, I get: >> >> >> […] > > Maybe your host gcc is being picked by `make` ? > In that case, it probably detects that option as valid/available. > > I don't know how to better address this ; I'd assume, maybe by > ensuring that the CC variable points to the right GCC. > Tho, curiously, CROSS_COMPILE="x86_64-openwrt-linux-musl-" should > that be x86_64-openwrt-linux-musl-gcc ? > > Maybe, also look for missing env vars that point to the right GCC. No, not for $(CROSS_COMPILE)… it’s a prefix that gets added before “cc”, “g++”, “ld”, “as”, etc. to make sure that the appropriate version gets invoked. It typically gets invoked as $(CROSS_COMPILE)cc for instance. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] Talks between OpenWrt and LEDE
On Dec 21, 2016, at 10:13 PM, Russell Senior wrote: >> "Florian" == Florian Fainelli writes: > >>> However, I also agree with Dave, Alberto and Stefan that a name >>> change may be a really smart way to communicate the fresh start of >>> the project, a reboot, especially if the new name rides on the >>> popularity of "OpenWRT". It could be for example "OpenLD" (LD for >>> Linux Device) or "LibreWRT". Of course this is all conditional on the >>> merge of OpenWRT and LEDE. If the projects do not merge, the OpenWRT >>> folks and SPI may have a claim against the use of OpenLD or LibreWRT >>> or alike. > > Florian> The point was that OpenWrt is already registered and managed by > Florian> SPI, so we may as well keep using it, and that is just what I > Florian> meant to say here, nothing more. -- Florian > > Not that a choice on a name, with taste and discretion, isn't going to be > needed, but I can't help but think of this: > > https://en.wikipedia.org/wiki/Law_of_triviality > > > PS: OpenLEDE. ;-) > > OpenBikeShed? "All the convenience with none of the security..." -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Any interest in adding runit to OpenWRT?
> On Dec 25, 2016, at 1:01 PM, Denys Vlasenko wrote: > > In my humble opinion, for distros which can't use systemd because > of the size, or won't use systemd because they don't like it, > a good contender is daemontools or one of its clones. > It is especially suited for a distros which target smaller systems, > because of its minimalistic and "Unix-like" design. What about a skinnied-down systemd? -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Scripting builds... how to?
Hi. I wanted to be able to script building images completely. I understand how to do: cp ../my-saved-config .config make defconfig make oldconfig to generate the .config file in a completely scripted way, by seeding it with the minimum set of relevant parameters (the deltas) per the steps described here: https://wiki.openwrt.org/doc/howto/build Is there an equivalent way to generate the kernel config by seeding it with minimum state? I don’t want to save the complete .config because that changes from release to release, so there wouldn’t be any point… all I care about is how I’m differentiating my build from the defaults. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Bug in ipkg?
I just saw something bizarre. I had a Perl module (CGI v4.35) which contained the following: my $appease_cpants_kwalitee = q/ use strict; use warnings; #/; which is just a quoted string containing the lines that some sanity checking code expects to see (albeit as actual code, and not embedded as a string constant). That was in the original source. Getting into build_dir/target-xxx/perl/CGI-4.35/ and looking at ipkg-install/usr/lib/perl5/5.22/CGI.pm it’s identical to what’s in the tarball. However, looking at ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22/CGI.pm I see that every line starting with /^#/ has been deleted. WTH??? Interestingly, lines beginning with /^[ \t]+#/ are untouched. Is ipkg doing something evil like stripping lines that it (apparently incorrectly) thinks are comments to save space? And if so, why How do I disable this? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] Bug in ipkg?
> On Jan 2, 2017, at 9:32 PM, Philip Prindeville > wrote: > > I just saw something bizarre. > > I had a Perl module (CGI v4.35) which contained the following: > > my $appease_cpants_kwalitee = q/ > use strict; > use warnings; > #/; > > which is just a quoted string containing the lines that some sanity checking > code expects to see (albeit as actual code, and not embedded as a string > constant). > > That was in the original source. > > Getting into build_dir/target-xxx/perl/CGI-4.35/ and looking at > ipkg-install/usr/lib/perl5/5.22/CGI.pm it’s identical to what’s in the > tarball. > > However, looking at ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22/CGI.pm I see that > every line starting with /^#/ has been deleted. WTH??? > > Interestingly, lines beginning with /^[ \t]+#/ are untouched. > > Is ipkg doing something evil like stripping lines that it (apparently > incorrectly) thinks are comments to save space? And if so, why > > How do I disable this? > > Thanks, > > -Philip > And here’s the offending code: (cd /home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-install/usr/lib/perl5/5.22 && rsync --relative -rlHp --itemize-changes --exclude=\*.pod --exclude=.packlist --prune-empty-dirs CGI CGI.pm auto/CGI /home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22) >f+ CGI.pm cd+ CGI/ >f+ CGI/Carp.pm >f+ CGI/Cookie.pm >f+ CGI/Pretty.pm >f+ CGI/Push.pm >f+ CGI/Util.pm cd+ CGI/File/ >f+ CGI/File/Temp.pm cd+ CGI/HTML/ >f+ CGI/HTML/Functions.pm chmod -R u+w /home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22 ---> Stripping modules in: /home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22 find /home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22 -name \*.pm -or -name \*.pl | xargs -r sed -i -e '/^=\(head\|pod\|item\|over\|back\|encoding\|begin\|end\|for\)/,/^=cut/d' -e '/^=\(head\|pod\|item\|over\|back\|encoding\|begin\|end\|for\)/,$d' -e '/^#$/d' -e '/^#[^!"'"'"']/d’ those last 2 expressions being passed to sed… If I have something like: my $hdr = <<__EOF__ ; #!/bin/bash -x __EOF__ then it’s going to totally do the wrong thing… It thinks that’s a comment but it’s not, it’s a literal in a here-document… ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] Bug in ipkg?
> On Jan 2, 2017, at 9:59 PM, Philip Prindeville > wrote: > > >> On Jan 2, 2017, at 9:32 PM, Philip Prindeville >> wrote: >> >> I just saw something bizarre. >> >> I had a Perl module (CGI v4.35) which contained the following: >> >> my $appease_cpants_kwalitee = q/ >> use strict; >> use warnings; >> #/; >> >> which is just a quoted string containing the lines that some sanity checking >> code expects to see (albeit as actual code, and not embedded as a string >> constant). >> >> That was in the original source. >> >> Getting into build_dir/target-xxx/perl/CGI-4.35/ and looking at >> ipkg-install/usr/lib/perl5/5.22/CGI.pm it’s identical to what’s in the >> tarball. >> >> However, looking at ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22/CGI.pm I see >> that every line starting with /^#/ has been deleted. WTH??? >> >> Interestingly, lines beginning with /^[ \t]+#/ are untouched. >> >> Is ipkg doing something evil like stripping lines that it (apparently >> incorrectly) thinks are comments to save space? And if so, why >> >> How do I disable this? >> >> Thanks, >> >> -Philip >> > > > And here’s the offending code: > > (cd > /home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-install/usr/lib/perl5/5.22 > && rsync --relative -rlHp --itemize-changes --exclude=\*.pod > --exclude=.packlist --prune-empty-dirs CGI CGI.pm auto/CGI > /home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22) >> f+ CGI.pm > cd+ CGI/ >> f+ CGI/Carp.pm >> f+ CGI/Cookie.pm >> f+ CGI/Pretty.pm >> f+ CGI/Push.pm >> f+ CGI/Util.pm > cd+ CGI/File/ >> f+ CGI/File/Temp.pm > cd+ CGI/HTML/ >> f+ CGI/HTML/Functions.pm > chmod -R u+w > /home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22 > ---> Stripping modules in: > /home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22 > find > /home/philip/bertram/bmu-philip/openwrt/build_dir/target-x86_64_core2_musl-1.1.15_powercode-bmu/perl/CGI-4.35/ipkg-x86_64/perl-cgi/usr/lib/perl5/5.22 > -name \*.pm -or -name \*.pl | xargs -r sed -i -e > '/^=\(head\|pod\|item\|over\|back\|encoding\|begin\|end\|for\)/,/^=cut/d' -e > '/^=\(head\|pod\|item\|over\|back\|encoding\|begin\|end\|for\)/,$d' -e > '/^#$/d' -e '/^#[^!"'"'"']/d’ > > > those last 2 expressions being passed to sed… > > If I have something like: > > my $hdr = <<__EOF__ ; > #!/bin/bash -x > > __EOF__ > > then it’s going to totally do the wrong thing… It thinks that’s a comment > but it’s not, it’s a literal in a here-document… > Okay, resolved…. I needed to change the Package/perl-cgi/install macro in the Makefile to invoke perlmod/Install/NoStrip instead of perlmod/Install. Sigh. Would it be reasonable to add a global variable which disables the stripping in perlmod/Install? If you’re on a box with a decent amount of cycles and adequate flash, then I don’t really see the point of stripping comments from the Perl anyway… -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] Bug in ipkg?
> On Jan 2, 2017, at 10:08 PM, Philip Prindeville > wrote: > > Okay, resolved…. I needed to change the Package/perl-cgi/install macro in > the Makefile to invoke perlmod/Install/NoStrip instead of perlmod/Install. > Sigh. > > Would it be reasonable to add a global variable which disables the stripping > in perlmod/Install? > > If you’re on a box with a decent amount of cycles and adequate flash, then I > don’t really see the point of stripping comments from the Perl anyway… > > -Philip > Okay, and here’s a fix… though it might also be nice to allow packages themselves to indicate that they’re known to get mangled by perlmod.mk… perlmod-unstripped.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH oldpackage/eventlog oldpackage/syslog-ng3] version bump to latest
update-syslog-eventlog.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] PHP at build time
Hi. I’m working on a project (some GUI interfaces and a back end for generating traffic shaping using netfilter/tc) written in PHP7. It uses PHP’s “composer”. I could install composer (it’s only ever run once on a released project) on the target machine, and run it on first boot. But that seems like a waste of space, and if there are any packaging problems, I’d rather detect them early on at build time. But that requires having PHP in the build environment at build time. Which is the lessor of the two evils? And do we go with the OS distribution of PHP7 (assuming it’s available… and it’s not on Ubuntu 14.04 LTS)? Or build a staging version of? What are the currently “blessed” list of OSes and releases to build on, anyway? I thought I had seen a list somewhere a while ago calling out Ubuntu 14.04 and 16.04 LTS, but couldn’t find it again when I went looking for it. One last and unrelated question: I tried to build a package (syslog-ng) in parallel mode on a 12-core system, and it built fine. But I understand that parallel build conditions are sometimes hard to reproduce. How does one adequately prove that a package is parallel-build safe? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Race condition in openssh build?
I did a “make dirclean” and then “make -j12” and I end up seeing the following (it’s reproducible): ... make[3] -C feeds/packages/utils/bash compile make[3] -C feeds/packages/utils/bc compile make[3] -C feeds/packages/net/bmon compile make[3] -C package/network/utils/iptables compile make[3] -C feeds/packages/libs/liboping compile make[3] -C package/network/utils/iproute2 compile make[3] -C feeds/packages/net/isc-dhcp compile make[3] -C feeds/packages/net/openssh compile make[3] -C feeds/packages/net/openssh compile make[3] -C feeds/packages/net/openssh compile make[3] -C feeds/packages/net/openssh compile make[3] -C feeds/packages/net/openssh compile make[3] -C feeds/packages/net/openssh compile make -r world: build failed. Please re-run make with -j1 V=s to see what's going on /home/philipp/bertram/bmu-philip/openwrt/include/toplevel.mk:192: recipe for target 'world' failed make: *** [world] Error 1 philipp@ubuntu16:~/bertram/bmu-philip/openwrt$ make -j4 package/openssh/clean make[1] package/openssh/clean make[2] -C feeds/packages/net/openssh clean make[2] -C feeds/packages/net/openssh clean make[2] -C feeds/packages/net/openssh clean make[2] -C feeds/packages/net/openssh clean make[2] -C feeds/packages/net/openssh clean make[2] -C feeds/packages/net/openssh clean make[2] -C feeds/packages/net/openssh clean philipp@ubuntu16:~/bertram/bmu-philip/openwrt$ philipp@ubuntu16:~/bertram/bmu-philip/openwrt$ make -j12 package/openssh/compile make[1] package/openssh/compile make[2] -C package/libs/toolchain compile make[2] -C feeds/packages/libs/libpam compile make[2] -C package/libs/zlib compile make[2] -C package/libs/openssl compile make[2] -C feeds/packages/net/openssh compile make[2] -C feeds/packages/net/openssh compile make[2] -C feeds/packages/net/openssh compile make[2] -C feeds/packages/net/openssh compile make[2] -C feeds/packages/net/openssh compile make[2] -C feeds/packages/net/openssh compile make[2] -C feeds/packages/net/openssh compile philipp@ubuntu16:~/bertram/bmu-philip/openwrt$ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] autoconf getting inconsistent results
I’m looking at a configure.ac which is trying to detect if the platform has
snprintf() or not, and it’s generating the wrong results. Ditto for strip().
In configure.ac:
dnl Checks for library functions.
AC_PROG_GCC_TRADITIONAL
AC_TYPE_SIGNAL
AC_CHECK_FUNCS(select socket strdup strerror strtol uname cfmakeraw snprintf)
but config.log tells a different story:
configure:6281: checking for snprintf
configure:6281: x86_64-openwrt-linux-musl-gcc -o conftest -Wall -Os -pipe
-march=westmere -fno-caller-saves -fno-plt -fhonour-copts
-Wno-error=unused-but-set-variable -Wno-error=unused-result -iremap
/home/philipp/bertram/bmu-philip/openwrt/build_dir/target-x86_64_westmere_musl-1.1.16_powercode-bmu/lcdproc-0.5.8:lcdproc-0.5.8
-fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -Wall -Werror
-Wno-unused-function
-I/home/philipp/bertram/bmu-philip/openwrt/staging_dir/target-x86_64_westmere_musl-1.1.16_powercode-bmu/usr/include
-I/home/philipp/bertram/bmu-philip/openwrt/staging_dir/target-x86_64_westmere_musl-1.1.16_powercode-bmu/include
-I/home/philipp/bertram/bmu-philip/openwrt/staging_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl-1.1.16/usr/include
-I/home/philipp/bertram/bmu-philip/openwrt/staging_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl-1.1.16/include/fortify
-I/home/philipp/bertram/bmu-philip/openwrt/staging_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl-1.1.16/include
-L/home/philipp/bertram/bmu-philip/openwrt/staging_dir/target-x86_64_westmere_musl-1.1.16_powercode-bmu/usr/lib
-L/home/philipp/bertram/bmu-philip/openwrt/staging_dir/target-x86_64_westmere_musl-1.1.16_powercode-bmu/lib
-L/home/philipp/bertram/bmu-philip/openwrt/staging_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl-1.1.16/usr/lib
-L/home/philipp/bertram/bmu-philip/openwrt/staging_dir/toolchain-x86_64_westmere_gcc-5.3.0_musl-1.1.16/lib
-znow -zrelro conftest.c >&5
conftest.c:81:6: error: conflicting types for built-in function 'snprintf'
[-Werror]
char snprintf ();
^
cc1: all warnings being treated as errors
configure:6281: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "lcdproc"
| #define PACKAGE_TARNAME "lcdproc"
| #define PACKAGE_VERSION "0.5.8"
| #define PACKAGE_STRING "lcdproc 0.5.8"
| #define PACKAGE_BUGREPORT "https://github.com/lcdproc/lcdproc/issues/";
| #define PACKAGE_URL ""
| #define PACKAGE "lcdproc"
| #define VERSION "0.5.8"
| #define LINUX 1
| #define SYSTEM_HOST Linux
| #define HAVE_GETLOADAVG 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_SYS_PROCFS_H 1
| #define HAVE_UTMPX_H 1
| #define HAVE_SCHED_H 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYSV_IPC 1
| #define HAVE_SCHED_SETSCHEDULER 1
| #define HAVE_SCHED_SETSCHEDULER 1
| #define HAVE_IOPL 1
| #define HAVE_IOPERM 1
| #define HAVE_SYS_IO_H 1
| #define HAVE_LINUX_I2C_DEV_H 1
| #define HAVE_I2C 1
| #define HAVE_LINUX_SPI_SPIDEV_H 1
| #define HAVE_SPI 1
| #define HAVE_DIRENT_H 1
| #define STDC_HEADERS 1
| #define HAVE_FCNTL_H 1
| #define HAVE_SYS_IOCTL_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_SYS_IO_H 1
| #define HAVE_ERRNO_H 1
| #define HAVE_LIMITS_H 1
| #define HAVE_SYS_PARAM_H 1
| #define HAVE_STDBOOL_H 1
| #define HAVE_SA_RESTART 1
| #define TIME_WITH_SYS_TIME 1
| #define RETSIGTYPE void
| #define HAVE_SELECT 1
| #define HAVE_SOCKET 1
| #define HAVE_STRERROR 1
| #define HAVE_STRTOL 1
| #define HAVE_UNAME 1
| #define HAVE_CFMAKERAW 1
| /* end confdefs.h. */
| /* Define snprintf to an innocuous variant, in case declares
snprintf.
|For example, HP-UX 11i declares gettimeofday. */
| #define snprintf innocuous_snprintf
|
| /* System header to define __stub macros and hopefully few prototypes,
| which can conflict with char snprintf (); below.
| Prefer to if __STDC__ is defined, since
| exists even on freestanding compilers. */
|
| #ifdef __STDC__
| # include
| #else
| # include
| #endif
|
| #undef snprintf
|
| /* Override any GCC internal prototype to avoid an error.
|Use char because int might match the return type of a GCC
|builtin and then its argument prototype would still apply. */
| #ifdef __cplusplus
| extern "C"
| #endif
| char snprintf ();
| /* The GNU C library defines this for functions which it implements
| to always fail with ENOSYS. Some functions are actually named
| something starting with __ and the normal name is an alias. */
| #if defined __stub_snprintf || defined __stub___snprintf
| choke me
| #endif
|
| int
| main ()
| {
| return snprintf ();
| ;
| return 0;
| }
configure:6281: result: no
Is this a MUSLism (no pun intended), and if so, what’s the workaround?
It’s doing the same thing for strdup(), declaring it as:
char strdup();
which of course is wr
[OpenWrt-Devel] Bounty: simplify extracting/restoring kernel .config
Hi. I’m working on a project where I need to be able to force certain kernel configuration parameters from a script, to automate building tailored kernels for performance testing, certification, etc. I love the way that I can use “scripts/diffconfig.sh” to save the deltas into a file… update the cloning/checkout of master over time, yet retain my saved overrides by doing a “cp ../my.config .config ; make defconfig oldconfig” and always end up with a known/good configuration. Alas, I can’t do the same for the target kernel in a scripted way. I’d like to put out a bounty for doing so. If you’re interested, contact me via email to discuss the deliverable and the terms of payment. Ideally, this would be of broad enough applicability that I’d want to upstream this back to OpenWRT for everyone, so keep that in mind as well. Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Observing procd progress
One thing I was wondering about was, on a headless system, but that does have an LCD display, is maybe capturing the progress of procd as it runs and displaying it on that LCD. Looking at /var/log/messages, I see: 2017-02-12T05:49:52+00:00 Powercode kernel:4.660666] procd: - early - 2017-02-12T05:49:52+00:00 Powercode kernel:5.253264] procd: - watchdog - 2017-02-12T05:49:52+00:00 Powercode kernel:5.256546] procd: - ubus - 2017-02-12T05:49:52+00:00 Powercode kernel:5.323323] procd: - init - 2017-02-12T05:50:28+00:00 Powercode procd: - init complete - and I see where those are generated in the procd source. I don’t see where procd communicates (logs) it’s progress that we could attach an observer. Maybe in q_initd_run() where the DEBUG(2, “start %s %s \n”…) happens, and in q_initd_complete() where the DEBUG(2, “stop %s %s \n”, …) happens? Hmm… for that matter, I also don’t know where procd does a wait() or wait3() or waitpid() on the rc.d/ scripts... I’m not sufficiently versed in procd to guess at how to go about this. Anyone else know? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] Makefile question
> On Feb 12, 2017, at 10:04 PM, Yousong Zhou wrote: > > On 13 February 2017 at 11:23, Philip Prindeville > wrote: >> >>> On Feb 11, 2017, at 8:29 PM, David Lang wrote: >>> >>> On Sat, 11 Feb 2017, Philip Prindeville wrote: >>> >>>>> This can't eliminate the /etc/rc.d/S* files as it only adds files, and >>>>> it's not as flexibile as adding a user or changing a password (as it >>>>> would just let you replace the /etc/passwd, /etc/shadow files, not modify >>>>> them). >>>>> >>>>> If you look for where the /files/* are copied into the filesystem, that >>>>> is probably the place you would want to add your scripting hooks. >>>> >>>> Good idea. I’ll look there. >>> >>> Once you find this, may I suggest that you create /scripts/* and contribute >>> the infrastructure to support it back upstream? >>> >>> I have seen a lot of people wanting to do similar things. >> >> >> Surprisingly, I’m still trying to find in the Makefiles where >> $(topdir)/files/ gets copied over… >> >> -Philip > > It's prepare_rootfs doing this job at the moment. > >yousong Hi Yousong, I’ve been working on both OpenWRT and LEDE and needed to get some hooks working in OpenWRT so I focused on that first. These are the changes I made, but I couldn’t get it to work. Was wondering if anyone can run with this. Part of the problem is making package/Makefile recurse with additional arguments and a different working directory… When I try to do this, the submake of package/Makefile gets run without inherited variables like $(INCLUDE_DIR), etc. Also odd is even though the top of package/Makefile says: curdir:=package when it recurses $(curdir) retains some other value like “target” or “toolchain”. Not sure why. Any guidance appreciated. -Philip install-hooks.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] Observing procd progress
> On Feb 14, 2017, at 2:45 AM, Petr Štetiar wrote:
>
> Philip Prindeville [2017-02-12 12:57:19]:
>
> Hi,
>
>> One thing I was wondering about was, on a headless system, but that does
>> have an LCD display, is maybe capturing the progress of procd as it runs and
>> displaying it on that LCD.
>
> BTW, what kind of platform and LCD is that?
It’s a Lanner network appliance FW-8771 with an ST-7066U LCD module.
The module is hd44780 compatible, but with LCM-162-like wiring (at least that’s
the interface type I select in lcdproc).
> I would probably get the total number of scripts planned to be run, the total
> count, 100% on progress bar from glob() as it's used in rcS.c/_rc(). Then I
> would probably update the position of the progress bar, the current % position
> in q_initd_complete() callback.
I’m more interested in knowing the name of a particular script should it cause
the boot process to hang… but maybe both could be done.
>
>> Maybe in q_initd_run() where the DEBUG(2, “start %s %s \n”…) happens, and in
>
> Look at libubox/runqueue.c, search for '->run(' callback.
>
>> q_initd_complete() where the DEBUG(2, “stop %s %s \n”, …) happens?
>
> Look at libubox/runqueue.c, search for '->complete(' callback.
Thanks.
>
>> Hmm… for that matter, I also don’t know where procd does a wait() or wait3()
>> or waitpid() on the rc.d/ scripts...
>
> procd is using runqueue task helper, which in turn uses uloop_process_*
> functions, so look at libubox at runqueue.c and uloop.c for details.
>
> — ynezz
Will do!
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] Makefile question
> On Feb 13, 2017, at 11:25 PM, Yousong Zhou wrote: > > On 14 February 2017 at 10:51, Philip Prindeville > wrote: >> >> Hi Yousong, >> >> I’ve been working on both OpenWRT and LEDE and needed to get some hooks >> working in OpenWRT so I focused on that first. >> >> These are the changes I made, but I couldn’t get it to work. >> >> Was wondering if anyone can run with this. >> >> Part of the problem is making package/Makefile recurse with additional >> arguments and a different working directory… When I try to do this, the >> submake of package/Makefile gets run without inherited variables like >> $(INCLUDE_DIR), etc. > > package/Makefile was included by $(TOPDIR)/Makefile which included > $(TOPDIR)/rules.mk first and that's where was INCLUDE_DIR defined but > not exported. Okay, so just add “export INCLUDE_DIR” and I’m done? > >> >> Also odd is even though the top of package/Makefile says: >> >> curdir:=package >> >> when it recurses $(curdir) retains some other value like “target” or >> “toolchain”. Not sure why. >> > > No idea how this happened as I do not yet have time to check the patch > in details. Does it take these values in a random way? On two different runs, I seem to remember them being either value. And that was with -j1 so it’s not a parallelism indeterminism. > > The other thing is if it's just about pre/post hooks, then I guess the > Build/IncludeOverlay mechanism should already fulfil most (if not all) > of your needs. > >yousong Well, I need to get things working with OpenWRT and then move the entire product over to LEDE. Are you on IRC? -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Using kdump... persistent logs, etc.
Hi, Has anyone managed to use kdump with OpenWRT/LEDE? I have a box which periodically panics, and since /var is a link to /tmp/ there are no persistent logs. Which reminds me: is it safe to configure a third partition on my CF card, format it as ext3, and mount that as /var/log in /etc/fstab? And how would I modify the build process if I wanted to add additional partitions? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Using kdump... persistent logs, etc.
Thanks for that. > On Feb 22, 2017, at 11:44 PM, Syrone Wong wrote: > > According to LEDE's source code: > > config KERNEL_CRASHLOG > bool "Crash logging" > depends on !(arm || powerpc || sparc || TARGET_uml || i386 || x86_64) > default y > > https://github.com/lede-project/source/blob/master/config/Config-kernel.in > > It is enabled by default on some targets and will be available at > `/sys/kernel/debug/crashlog` on next boot after crash. > > The implementation detail can be found here: > https://github.com/lede-project/source/blob/master/target/linux/generic/patches-4.9/930-crashlog.patch > > > Best Regards, > Syrone Wong > > > On Thu, Feb 23, 2017 at 10:05 AM, Philip Prindeville > wrote: >> Hi, >> >> Has anyone managed to use kdump with OpenWRT/LEDE? >> >> I have a box which periodically panics, and since /var is a link to /tmp/ >> there are no persistent logs. Which reminds me: is it safe to configure a >> third partition on my CF card, format it as ext3, and mount that as /var/log >> in /etc/fstab? >> >> And how would I modify the build process if I wanted to add additional >> partitions? >> >> Thanks, >> >> -Philip >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] Using kdump... persistent logs, etc.
I built an x86_64 image and turned on crash logging, and then forced a crash with: echo c >/proc/sysrq-trigger it rebooted, but when it did there was nothing in /sys/kernel/debug/ (i.e. no crashlog file). What am I missing? Does this not work with x86_64? -Philip > On Feb 23, 2017, at 10:27 AM, Philip Prindeville > wrote: > > Thanks for that. > > >> On Feb 22, 2017, at 11:44 PM, Syrone Wong wrote: >> >> According to LEDE's source code: >> >> config KERNEL_CRASHLOG >> bool "Crash logging" >> depends on !(arm || powerpc || sparc || TARGET_uml || i386 || x86_64) >> default y >> >> https://github.com/lede-project/source/blob/master/config/Config-kernel.in >> >> It is enabled by default on some targets and will be available at >> `/sys/kernel/debug/crashlog` on next boot after crash. >> >> The implementation detail can be found here: >> https://github.com/lede-project/source/blob/master/target/linux/generic/patches-4.9/930-crashlog.patch >> >> >> Best Regards, >> Syrone Wong >> >> >> On Thu, Feb 23, 2017 at 10:05 AM, Philip Prindeville >> wrote: >>> Hi, >>> >>> Has anyone managed to use kdump with OpenWRT/LEDE? >>> >>> I have a box which periodically panics, and since /var is a link to /tmp/ >>> there are no persistent logs. Which reminds me: is it safe to configure a >>> third partition on my CF card, format it as ext3, and mount that as >>> /var/log in /etc/fstab? >>> >>> And how would I modify the build process if I wanted to add additional >>> partitions? >>> >>> Thanks, >>> >>> -Philip >>> ___ >>> openwrt-devel mailing list >>> openwrt-devel@lists.openwrt.org >>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > ___ > Lede-dev mailing list > lede-...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] Using kdump... persistent logs, etc.
Looks like it got changed here: commit 749918911d35613f8bf7852d2a91f78ff625739e Author: Felix Fietkau Date: Fri Jan 13 14:48:25 2017 +0100 x86: disable crashlog It could cause crashes with some forms of virtualization, and it is unlikely to work properly with most systems. It's safer to just disable it. Signed-off-by: Felix Fietkau diff --git a/config/Config-kernel.in b/config/Config-kernel.in index 3f30013..a4c46f5 100644 --- a/config/Config-kernel.in +++ b/config/Config-kernel.in @@ -26,7 +26,7 @@ config KERNEL_PRINTK config KERNEL_CRASHLOG bool "Crash logging" - depends on !(arm || powerpc || sparc || TARGET_uml) + depends on !(arm || powerpc || sparc || TARGET_uml || i386 || x86_64) default y config KERNEL_SWAP I must have missed the discussion about this. I’m not using virtualization, but I’m definitely seeing crashing without it. Can we get more details on "and it is unlikely to work properly with most systems”? -Philip > On Mar 3, 2017, at 12:23 AM, Syrone Wong wrote: > > depends on !(arm || powerpc || sparc || TARGET_uml || i386 || x86_64) > > x86_64 is disabled by default. You may want to enable it yourself. I > don't know why. > > > Best Regards, > Syrone Wong > > > On Fri, Mar 3, 2017 at 2:31 PM, Philip Prindeville > wrote: >> I built an x86_64 image and turned on crash logging, and then forced a crash >> with: >> >> echo c >/proc/sysrq-trigger >> >> it rebooted, but when it did there was nothing in /sys/kernel/debug/ (i.e. >> no crashlog file). >> >> What am I missing? Does this not work with x86_64? >> >> -Philip >> >> >>> On Feb 23, 2017, at 10:27 AM, Philip Prindeville >>> wrote: >>> >>> Thanks for that. >>> >>> >>>> On Feb 22, 2017, at 11:44 PM, Syrone Wong wrote: >>>> >>>> According to LEDE's source code: >>>> >>>> config KERNEL_CRASHLOG >>>> bool "Crash logging" >>>> depends on !(arm || powerpc || sparc || TARGET_uml || i386 || x86_64) >>>> default y >>>> >>>> https://github.com/lede-project/source/blob/master/config/Config-kernel.in >>>> >>>> It is enabled by default on some targets and will be available at >>>> `/sys/kernel/debug/crashlog` on next boot after crash. >>>> >>>> The implementation detail can be found here: >>>> https://github.com/lede-project/source/blob/master/target/linux/generic/patches-4.9/930-crashlog.patch >>>> >>>> >>>> Best Regards, >>>> Syrone Wong >>>> >>>> >>>> On Thu, Feb 23, 2017 at 10:05 AM, Philip Prindeville >>>> wrote: >>>>> Hi, >>>>> >>>>> Has anyone managed to use kdump with OpenWRT/LEDE? >>>>> >>>>> I have a box which periodically panics, and since /var is a link to /tmp/ >>>>> there are no persistent logs. Which reminds me: is it safe to configure >>>>> a third partition on my CF card, format it as ext3, and mount that as >>>>> /var/log in /etc/fstab? >>>>> >>>>> And how would I modify the build process if I wanted to add additional >>>>> partitions? >>>>> >>>>> Thanks, >>>>> >>>>> -Philip >>>>> ___ >>>>> openwrt-devel mailing list >>>>> openwrt-devel@lists.openwrt.org >>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >>> >>> >>> ___ >>> Lede-dev mailing list >>> lede-...@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/lede-dev >> ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
> On May 8, 2017, at 7:29 AM, David Woodhouse wrote: > > On Mon, 2017-05-08 at 15:19 +0200, John Crispin wrote: >> >> *) mailing list >> - ask david to add the openwrt-adm and openwrt lists >> - announce the switch to the infradead serves, asking people to >> unsubscribe if they have privacy issues with this >> - import the user DB from the current openwrt and lede ML into the 2 new >> mailing lists >> - find out if we can redirect/auto-reply the existing lists to the new ones > > Yes, we can redirect the existing lists to the new ones — so for > example, mail sent to lede-dev will just turn up on the openwrt-dev > list instead. Assuming that's what you meant. > > For importing subscribers, if that's what you want to do, I'd be > inclined to send *invitations* not just subscribe people. So each > person will get the 'someone has requested that your address be > subscribed; click here to actually do it' message. We can write our own > blurb to go out at the top of those invitations. I think that would be better. I whitelist all of my mailing list subscriptions, so the reminder that I need to add a new one (when I’m not actually subscribing myself) is always helpful. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
> On May 8, 2017, at 7:19 AM, John Crispin wrote: > > Hi, > > Felix, Imre and myself had 2 calls last week lasting several hours and > discussed the following proposal of conditions for a remerge that we would > like to propose and have people vote on. > > *) branding > - the owrt side sees no option of using the lede brand > > - a (minor) majority voted for openwrt as a name over lede whilst most people > said they did not care > > - as the last vote had a 100% ACK for a remerge using the owrt brand is the > only feasible option > > *) domain > - transfer owner ship to SPI for openwrt.org and lede-project.org > - add them to the pool of urls at digital ocean > - post remerge build a setup where we have several DNS servers in various > locations > - point git.openwrt.org at the lede git server > - point bugs.openwrt.org to the lede flyspray instance > - keep both wikis and forums as is (we should decide post remerge how to > proceed to avoid these issues blocking the progress) > - update the lede domain entries for build/download/rsync/... servers so that > the openwrt domain also points at them > > *) SPI > - TBD post remerge > > *) github > - stop pushing to lede-project organisation > - start pushing to the openwrt organisation > - cleanup the list of owners in the openwrt organisation > - obsolete all issues on the openwrt organisation and close the issue tracker > - go through the open openwrt and lede PRs, pickup whats useful and close the > rest, asking people to repost (things wont be rebasable anyhow) > - close the lede PR tracker > - keep the lede organisation in its current state so that forked trees dont > get obsoleted > > - obsolete the lede github org after a grace period of 3-6 months > > *) landing page > - update the lede landing page to represent the openwrt name > - update the landing page to have the same look & feel as the current openwrt > landing page > - point openwrt.org at the lede landing page > > *) trac > - trac is already readonly, keep content so that search engines can still > find the it > - edit the trac html templates, adding a note pointing at the bug.openwrt.org > instance > > *) email accounts > - currently there are around ~20 active openwrt.org mail accounts > - turn all the webmaster@, hostmaster@, ... accounts into aliases that anyone > with voting rights can be subscribed to > - ask those people that are no longer active to voluntarily give up their > accounts > - mail addresses may under no conditions be used for any personal business, > consultancy, applying for jobs, ... purposes > > - any mail sent from an openwrt.org account needs to adhere the trademark > policy and should only be used for FOSS purposes > > > *) wiki / forum > - TBD > - asking in either forum/wiki will get a biased vote so keep them both around > - start a separate discussion regarding these post remerge > > *) LF > - find out what doubts folks have about LF > - find out benefits - we would have their hosting and sponsorship ?! > - start a separate discussion regarding these post remerge > > *) git trees > - rebrand the lede tree to openwrt > - work out what has happened inside the openwrt tree since the reboot and > pick up the useful bits (zoltan has done some prior work on this already) > > *) mailing list > - ask david to add the openwrt-adm and openwrt lists > - announce the switch to the infradead serves, asking people to unsubscribe > if they have privacy issues with this > - import the user DB from the current openwrt and lede ML into the 2 new > mailing lists > - find out if we can redirect/auto-reply the existing lists to the new ones > > *) trademark/sponsorship policy > - review/ack imres trademark policy > - review/ack jows sponsorship policy > > *) timeline > - refine / vote / agree on the proposal withing the next 2 week > - work on the action items in the 4 weeks after that > >John I’d like to suggest one more action item to this list if I can. It would be handy to have a single database for user authentication/identification for submitting bugs, editing the Wiki, etc. Previously there were too many places where you had to create an account. If we can’t do “single sign-on”, can we at least do “single sign-up”? And part of a user’s profile should include their IRC handle (assuming they have one). Thanks. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] openwrt and lede - remerge proposal
> On May 11, 2017, at 4:53 AM, Stijn Segers > wrote: > > Some of the OpenWrt veterans come across as if they want the re-merge to be > rushed, ignoring the actual issues that caused the fork in the first place. Yeah, I have to agree with this. You don’t get married, then define your vows afterwards… -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
