Re: [LEDE-DEV] [RFC PATCH] tools/squashfs: change to upstream and update to new version 5.0-rc1

[Philip Prindeville]

Me too.


> On May 5, 2018, at 7:36 AM, Paul Spooren  wrote:
> 
> Are there any updates on this issue? I'd really like to see squasfs 5.0 used 
> in OpenWrt!
> 
> On Sat, May 27, 2017 at 8:51 PM, Hauke Mehrtens  wrote:
>> On 05/26/2017 06:13 PM, Alexander Couzens wrote:
>>> squashfs is quite long unmaintained. All patches from major
>>> distributions are integrated.
>>> Fixed timestamp is now using the environment SOURCE_DATE_EPOCH
>>> instead of arguments.
>>> Signed-off-by: Alexander Couzens 
>> Thanks for working on this.
>>> ---
>>>  include/image.mk   |   3 +-
>>>  tools/squashfs4/Makefile   |  12 +-
>>>  tools/squashfs4/patches/100-portability.patch  |  40 -
>>>  .../patches/110-allow_static_liblzma.patch |  30 -
>>>  tools/squashfs4/patches/120-cygwin_fixes.patch | 153 
>>>  tools/squashfs4/patches/150-freebsd_fixes.patch|  10 -
>>>  .../patches/160-expose_lzma_xz_options.patch   | 929 
>>> -
>>>  ...0-add_support_for_LZMA_MAGIC_to_unsqashfs.patch |  72 --
>>>  tools/squashfs4/patches/180-openbsd_compat.patch   |  24 -
>>>  .../patches/190-no_nonstatic_inline.patch  |  36 -
>>>  .../patches/200-add-fixed-timestamp-option.patch   |  82 --
>>>  11 files changed, 6 insertions(+), 1385 deletions(-)
>>>  delete mode 100644 tools/squashfs4/patches/100-portability.patch
>>>  delete mode 100644 tools/squashfs4/patches/110-allow_static_liblzma.patch
>>>  delete mode 100644 tools/squashfs4/patches/120-cygwin_fixes.patch
>>>  delete mode 100644 tools/squashfs4/patches/150-freebsd_fixes.patch
>>>  delete mode 100644 tools/squashfs4/patches/160-expose_lzma_xz_options.patch
>>>  delete mode 100644 
>>> tools/squashfs4/patches/170-add_support_for_LZMA_MAGIC_to_unsqashfs.patch
>>>  delete mode 100644 tools/squashfs4/patches/180-openbsd_compat.patch
>>>  delete mode 100644 tools/squashfs4/patches/190-no_nonstatic_inline.patch
>>>  delete mode 100644 
>>> tools/squashfs4/patches/200-add-fixed-timestamp-option.patch
>>> diff --git a/include/image.mk b/include/image.mk
>>> index ad9535d018..eaabba2d0e 100644
>>> --- a/include/image.mk
>>> +++ b/include/image.mk
>>> @@ -203,8 +203,7 @@ define Image/mkfs/squashfs
>>> $(STAGING_DIR_HOST)/bin/mksquashfs4 $(call mkfs_target_dir,$(1)) $@ \
>>> -nopad -noappend -root-owned \
>>> -comp $(SQUASHFSCOMP) $(SQUASHFSOPT) \
>>> -   -processors 1 \
>>> -   $(if $(SOURCE_DATE_EPOCH),-fixed-time $(SOURCE_DATE_EPOCH))
>>> +   -processors 1
>>>  endef
>>>  # $(1): board name
>>> diff --git a/tools/squashfs4/Makefile b/tools/squashfs4/Makefile
>>> index e2c9fc91cc..e176f06e86 100644
>>> --- a/tools/squashfs4/Makefile
>>> +++ b/tools/squashfs4/Makefile
>>> @@ -7,14 +7,12 @@
>>>  include $(TOPDIR)/rules.mk
>>>  PKG_NAME:=squashfs4
>>> -PKG_VERSION:=4.2
>>> +PKG_VERSION:=5.0
>>> -PKG_SOURCE:=squashfs$(PKG_VERSION).tar.gz
>>> -PKG_SOURCE_URL:=@SF/squashfs
>>> -PKG_HASH:=d9e0195aa922dbb665ed322b9aaa96e04a476ee650f39bbeadb0d00b24022e96
>>> -PKG_CAT:=zcat
>>> -
>>> -HOST_BUILD_DIR:=$(BUILD_DIR_HOST)/squashfs$(PKG_VERSION)
>>> +PKG_SOURCE_PROTO:=git
>>> +PKG_SOURCE_DATE:=2017-05-25
>>> +PKG_SOURCE_URL:=https://github.com/lynxis/squashfs-tools.git
>>> +PKG_SOURCE_VERSION:=32a07d4156a281084c90a4b78affc8b0b32a26fc
>>>  include $(INCLUDE_DIR)/host-build.mk
>> Why not use https://github.com/squashfs-tools/squashfs-tools or what
>> will be the official repo?
>>> index 9e1c1fbb1e..00
>>> --- a/tools/squashfs4/patches/160-expose_lzma_xz_options.patch
>>> +++ /dev/null
>>> @@ -1,929 +0,0 @@
>>>  /dev/null
>>> -+++ b/squashfs-tools/lzma_xz_options.h
>> ..
>>> -+struct lzma_opts {
>>> -+  uint32_t dict_size;
>>> -+  uint32_t flags;
>>> -+#define LZMA_OPT_FLT_MASK 0x
>>> -+#define LZMA_OPT_PRE_OFF  16
>>> -+#define LZMA_OPT_PRE_MASK (0xf << LZMA_OPT_PRE_OFF)
>>> -+#define LZMA_OPT_EXTREME  20
>>> -+  uint16_t bit_opts;
>>> -+#define LZMA_OPT_LC_OFF   0
>>> -+#define LZMA_OPT_LC_MASK  (0x7 << LZMA_OPT_LC_OFF)
>>> -+#define LZMA_OPT_LP_OFF   3
>>> -+#define LZMA_OPT_LP_MASK  (0x7 << LZMA_OPT_LP_OFF)
>>> -+#define LZMA_OPT_PB_OFF   6
>>> -+#define LZMA_OPT_PB_MASK  (0x7 << LZMA_OPT_PB_OFF)
>>> -+  uint16_t fb;
>>> -+};
>> Nice that you got this change upstream. The kernel version of this
>> structure only has the first two members, but it still works.
>> See struct disk_comp_opts in fs/squashfs/xz_wrapper.c
>> Hauke
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH v2 4/4] base-files: add sysupgrade -k to save list of pkgs

[Philip Prindeville]

Inline

> On Apr 4, 2018, at 5:28 PM, Luiz Angelo Daros de Luca  
> wrote:
> 
> When '-k' is used, sysupgrade inserts into backup a new file
> /etc/sysupgrade.installed which contains pkgname and
> origin (rom, overlay, unknown).
> 
> It's maily used to reinstall all extra packages:
> 
> # opkg update
> # grep "\toverlay" etc/sysupgrade.installed | cut -f1 | xargs opkg install
> # rm etc/sysupgrade.installed
> 
> Signed-off-by: Luiz Angelo Daros de Luca 
> ---
> package/base-files/files/sbin/sysupgrade | 30 ++
> 1 file changed, 30 insertions(+)
> 
> diff --git a/package/base-files/files/sbin/sysupgrade 
> b/package/base-files/files/sbin/sysupgrade
> index 01a942bac6..c5067a757b 100755
> --- a/package/base-files/files/sbin/sysupgrade
> +++ b/package/base-files/files/sbin/sysupgrade
> @@ -11,6 +11,7 @@ export SAVE_CONFIG=1
> export SAVE_OVERLAY=0
> export SAVE_OVERLAY_PATH=
> export SAVE_PARTITIONS=1
> +export SAVE_INSTALLED_PKGS=0
> export SKIP_UNCHANGED=0
> export CONF_IMAGE=
> export CONF_BACKUP_LIST=0
> @@ -31,6 +32,7 @@ while [ -n "$1" ]; do
>   -c) export SAVE_OVERLAY=1 SAVE_OVERLAY_PATH=/etc;;
>   -o) export SAVE_OVERLAY=1 SAVE_OVERLAY_PATH=/;;
>   -p) export SAVE_PARTITIONS=0;;
> + -k) export SAVE_INSTALLED_PKGS=1;;
>   -u) export SKIP_UNCHANGED=1;;
>   -b|--create-backup) export CONF_BACKUP="$2" NEED_IMAGE=1; 
> shift;;
>   -r|--restore-backup) export CONF_RESTORE="$2" NEED_IMAGE=1; 
> shift;;
> @@ -50,6 +52,7 @@ done
> 
> export CONFFILES=/tmp/sysupgrade.conffiles
> export CONF_TAR=/tmp/sysupgrade.tgz
> +export INSTALLED_PACKAGES=/etc/sysupgrade.installed
> 
> IMAGE="$1"
> 
> @@ -67,6 +70,8 @@ upgrade-option:
>   -u   skip from backup files that are equals to those in /rom
>   -n   do not save configuration over reflash
>   -p   do not attempt to restore the partition table after flash.
> + -k   include in backup a list of current installed packages at
> +  $INSTALLED_PACKAGES
>   -T | --test
>Verify image and config .tar.gz but do not actually flash.
>   -F | --force
> @@ -203,6 +208,15 @@ fi
> 
> include /lib/upgrade
> 
> +targz_append() {
> + local tar="$1"
> + local append_tar="$2"
> + (   gunzip -c "$tar" | head -c -1024;
> + gunzip -c $append_tar
> + ) | gzip > $tar.new


This seems a bit fragile…  Isn’t there a better way to do this?


> + mv -f $tar.new $tar
> +}
> +
> do_save_conffiles() {
>   local conf_tar="$1"
> 
> @@ -219,6 +233,22 @@ do_save_conffiles() {
>   [ "$VERBOSE" -gt 1 ] && TAR_V="v" || TAR_V=""
>   tar c${TAR_V}zf "$conf_tar" -T "$CONFFILES" 2>/dev/null
> 
> + if [ "$SAVE_INSTALLED_PKGS" -eq 1 ]; then
> + mkdir -p /tmp/etc
> + cd /tmp/
> +
> + # Format: pkg-name{rom,overlay,unkown}
> + # rom is used for pkgs in /rom, even if updated later
> + find /usr/lib/opkg/info -name "*.control" \( \
> + \( -exec test -f /rom/{} \; -exec echo {} rom \; \) -o \
> + \( -exec test -f /overlay/upper/{} \; -exec echo {} 
> overlay \; \) -o \
> + \( -exec echo {} unknown \; \) \
> + \) | sed -e 's,.*/,,;s/\.control /\t/' > 
> ${INSTALLED_PACKAGES:1}
> +
> + tar c${TAR_V}zf sysupgrade.installed.packages.tgz 
> ${INSTALLED_PACKAGES:1}
> + targz_append "$conf_tar" sysupgrade.installed.packages.tgz
> + rm -f sysupgrade.installed.packages.tgz ${INSTALLED_PACKAGES:1}
> + fi
>   rm -f "$CONFFILES"
> }
> 
> --
> 2.16.3



signature.asc
Description: Message signed with OpenPGP
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2 5/6] x86: add intel microcode entries to grub config

[Philip Prindeville]

Is there a downside to forcing AMD to also do early firmware updates?



> On Apr 17, 2018, at 12:50 PM, Tomasz Maciej Nowak  wrote:
> 
> Create initrd enries for x86 images, that'll load intel microcode as
> early as possible. Also restrict the late load of microcode to AMD
> processors.
> 
> Signed-off-by: Tomasz Maciej Nowak 
> ---
> target/linux/x86/base-files/lib/preinit/02_load_x86_ucode | 6 --
> target/linux/x86/image/Makefile   | 4 ++--
> target/linux/x86/image/grub-iso.cfg   | 3 +++
> target/linux/x86/image/grub.cfg   | 3 +++
> 4 files changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/target/linux/x86/base-files/lib/preinit/02_load_x86_ucode 
> b/target/linux/x86/base-files/lib/preinit/02_load_x86_ucode
> index fb309c75c1..d3a23e24b2 100644
> --- a/target/linux/x86/base-files/lib/preinit/02_load_x86_ucode
> +++ b/target/linux/x86/base-files/lib/preinit/02_load_x86_ucode
> @@ -2,8 +2,10 @@
> # Copyright (C) 2018 OpenWrt.org
> 
> do_load_x86_ucode() {
> - if [ -e "/sys/devices/system/cpu/microcode/reload" ]; then
> - echo 1 > /sys/devices/system/cpu/microcode/reload
> + if grep -q AuthenticAMD /proc/cpuinfo; then
> + if [ -e "/sys/devices/system/cpu/microcode/reload" ]; then
> + echo 1 > /sys/devices/system/cpu/microcode/reload
> + fi
>   fi
> }
> 
> diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/image/Makefile
> index cf1e1a9edf..523c07eb75 100644
> --- a/target/linux/x86/image/Makefile
> +++ b/target/linux/x86/image/Makefile
> @@ -9,8 +9,8 @@ include $(INCLUDE_DIR)/image.mk
> 
> export PATH=$(TARGET_PATH):/sbin
> 
> -GRUB2_MODULES = biosdisk boot chain configfile ext2 linux ls part_msdos 
> reboot serial vga
> -GRUB2_MODULES_ISO = biosdisk boot chain configfile iso9660 linux ls 
> part_msdos reboot serial vga
> +GRUB2_MODULES = biosdisk boot chain configfile ext2 linux ls part_msdos 
> reboot serial test vga
> +GRUB2_MODULES_ISO = biosdisk boot chain configfile iso9660 linux ls 
> part_msdos reboot serial test vga
> GRUB_TERMINALS =
> GRUB_SERIAL_CONFIG =
> GRUB_TERMINAL_CONFIG =
> diff --git a/target/linux/x86/image/grub-iso.cfg 
> b/target/linux/x86/image/grub-iso.cfg
> index 3d47a95a4b..30b587bd1c 100644
> --- a/target/linux/x86/image/grub-iso.cfg
> +++ b/target/linux/x86/image/grub-iso.cfg
> @@ -7,4 +7,7 @@ set root='(cd)'
> 
> menuentry "OpenWrt" {
>   linux /boot/vmlinuz @CMDLINE@ noinitrd
> + if [ -e /boot/intel-ucode.img ]; then
> + initrd /boot/intel-ucode.img
> + fi
> }
> diff --git a/target/linux/x86/image/grub.cfg b/target/linux/x86/image/grub.cfg
> index 9ec6b2d39c..dde24b95ce 100644
> --- a/target/linux/x86/image/grub.cfg
> +++ b/target/linux/x86/image/grub.cfg
> @@ -7,6 +7,9 @@ set root='(@ROOT@)'
> 
> menuentry "OpenWrt" {
>   linux /boot/vmlinuz @CMDLINE@ noinitrd
> + if [ -e /boot/intel-ucode.img ]; then
> + initrd /boot/intel-ucode.img
> + fi
> }
> menuentry "OpenWrt (failsafe)" {
>   linux /boot/vmlinuz failsafe=true @CMDLINE@ noinitrd
> -- 
> 2.17.0
> 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 3/3] intel-microcode: create early load microcode image

[Philip Prindeville]

Inline

> On Apr 9, 2018, at 2:11 PM, Tomasz Maciej Nowak <tmn...@gmail.com> wrote:
> 
> W dniu 09.04.2018 o 21:05, Philip Prindeville pisze:
>> Inline
>>> On Apr 3, 2018, at 7:13 AM, Tomasz Maciej Nowak <tome...@o2.pl> wrote:
>>> 
>>> Create initrd image with packed microcode. This'll allow to load it at
>>> early boot stage. Unfortunately the package can't install files directly
>>> to /boot directory, therefore additional installation hooks are placed
>>> for standalone package and when building directly into target image.
>>> 
>>> Signed-off-by: Tomasz Maciej Nowak <tome...@o2.pl>
>>> ---
>>> package/firmware/intel-microcode/Makefile | 32 
>>> +--
>>> target/linux/x86/image/Makefile   |  6 ++
>>> 2 files changed, 32 insertions(+), 6 deletions(-)
>>> 
>>> diff --git a/package/firmware/intel-microcode/Makefile 
>>> b/package/firmware/intel-microcode/Makefile
>>> index d2663bb901..9970f8f072 100644
>>> --- a/package/firmware/intel-microcode/Makefile
>>> +++ b/package/firmware/intel-microcode/Makefile
>>> @@ -35,15 +35,35 @@ define Package/intel-microcode
>>> endef
>>> 
>>> define Build/Compile
>>> -   IUCODE_TOOL=$(STAGING_DIR)/../host/bin/iucode_tool $(MAKE) -C 
>>> $(PKG_BUILD_DIR)
>>> -   mkdir $(PKG_BUILD_DIR)/intel-ucode
>>> -   $(STAGING_DIR)/../host/bin/iucode_tool -q \
>>> -   --write-firmware=$(PKG_BUILD_DIR)/intel-ucode 
>>> $(PKG_BUILD_DIR)/$(MICROCODE).bin
>>> +   IUCODE_TOOL=$(STAGING_DIR)/../host/bin/iucode_tool \
>>> +   $(MAKE) -C $(PKG_BUILD_DIR)
>>> +   $(STAGING_DIR)/../host/bin/iucode_tool -q --mini-earlyfw \
>>> +   --write-earlyfw=$(PKG_BUILD_DIR)/intel-ucode.cpio \
>>> +   $(PKG_BUILD_DIR)/$(MICROCODE).bin
>>> endef
>>> 
>>> define Package/intel-microcode/install
>>> -   $(INSTALL_DIR) $(1)/lib/firmware/intel-ucode
>>> -   $(INSTALL_DATA) $(PKG_BUILD_DIR)/intel-ucode/* 
>>> $(1)/lib/firmware/intel-ucode
>>> +   $(INSTALL_DIR) $(1)/lib/firmware
>>> +   $(INSTALL_DATA) $(PKG_BUILD_DIR)/intel-ucode.cpio \
>>> +   $(1)/lib/firmware/intel-ucode.img
>>> +endef
>>> +
>>> +ifeq ($(CONFIG_PACKAGE_intel-microcode),m)
>>> +define Package/intel-microcode/postinst
>>> +#!/bin/sh
>>> +
>>> +mount /boot -o remount,rw,noatime
>>> +cp -f /lib/firmware/intel-ucode.img /boot/
>> Can we preserve the timestamp (-p) on the microcode file, too?
> 
> Will add in v2.
> 
>>> +mount /boot -o remount,ro,noatime
>>> +endef
>>> +endif
>>> +
>>> +define Package/intel-microcode/prerm
>>> +#!/bin/sh
>>> +
>>> +mount /boot -o remount,rw,noatime
>>> +rm /boot/intel-ucode.img
>> “rm -f” so that if the uninstall fails it’s idempotent and doesn’t leave 
>> things in a weird state.
> 
> Good catch, had this locally but sent the wrong version.
> 
>>> +mount /boot -o remount,ro,noatime
>>> endef
>>> 
>>> $(eval $(call BuildPackage,intel-microcode))
>>> diff --git a/target/linux/x86/image/Makefile 
>>> b/target/linux/x86/image/Makefile
>>> index a05f4babd9..4d6a3016d2 100644
>>> --- a/target/linux/x86/image/Makefile
>>> +++ b/target/linux/x86/image/Makefile
>>> @@ -83,6 +83,9 @@ ifneq ($(CONFIG_GRUB_IMAGES),)
>>> -e 's#@TIMEOUT@#$(GRUB_TIMEOUT)#g' \
>>> -e 's#@ROOT@#$(GRUB_ROOT)#g' \
>>> ./grub.cfg > $(KDIR)/root.grub/boot/grub/grub.cfg
>>> +ifeq ($(CONFIG_PACKAGE_intel-microcode),y)
>>> +   $(CP) $(STAGING_DIR)/root-x86/lib/firmware/intel-ucode.img 
>>> $(KDIR)/root.grub/boot/
>>> +endif
>> Do we need this?  Won’t the postinst happen during “make world”?
> 
> Yes it's needed, the package doesn't install files directly to /boot, and 
> when executing postinst it'll naturally fail trying to mount host file system 
> and stop the whole build process.
> 
> What can be changed is handling of this command, instead conditional, mark it 
> as non-fatal.


Okay, I assumed that mkimage (or whatever) ran in a chroot with /boot mounted…


> 
>>> 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_

Re: [LEDE-DEV] [OpenWrt-Devel] 18.03/4

[Philip Prindeville]

> On Feb 16, 2018, at 1:32 PM, Philip Prindeville 
> <philipp_s...@redfish-solutions.com> wrote:
> 
> 
> 
>> On Feb 16, 2018, at 5:46 AM, John Crispin <j...@phrozen.org> wrote:
>> 
>> Hi,
>> 
>> whats on the critical todo list for the upcoming release ? i still have a 
>> few minor things that I'll be adding shortly, apart from that I am currently 
>> not aware of any huge problems. the release will be a mix between 4.9 and 
>> 4.14 afaik !?
>> 
>>John
> 
> 
> I wouldn’t mind bumping ISC-DHCP to 4.4.0 but I need someone to test it on a 
> non-x86 platform…
> 
> The PR is sitting waiting for another tester.
> 
> https://github.com/openwrt/packages/pull/5579
> 
> And iperf3 has a pending PR to 3.4 but I don’t think that’s critical, but it 
> might be nice to have it be tested and get in.
> 
> I’m running it (again on x86_64 hardware) but an “alien” cross-build would be 
> better.


There was a bug in the dhcpd.init script that got fixed yesterday.  It wasn’t a 
showstopper and only affected people doing their own explicit “list dhcp_option 
‘option:xxx,yyy’” stuff.

-Philip



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCHv2] firewall: fix logging of dropped & rejected packets

[Philip Prindeville]

“guest” or “salon”?



> On Apr 3, 2018, at 8:51 AM, Alin Nastac  wrote:
> 
> From: Alin Nastac 
> 
> Reproduction scenario:
> - use 3 interfaces with 3 different zones - lan, wan and guest
> - configure firewall to allow forwarding from lan to wan
> - add DROP rule to prevent forwarding from lan to guest
> - although packets are forwarded from lan to wan, "DROP(dest guest)"
> traces are generated by zone_guest_dest_DROP chain
> 
> Signed-off-by: Alin Nastac 
> ---
> zones.c | 72 ++---
> 1 file changed, 60 insertions(+), 12 deletions(-)
> 
> diff --git a/zones.c b/zones.c
> index e00d527..9f00aca 100644
> --- a/zones.c
> +++ b/zones.c
> @@ -20,6 +20,8 @@
> #include "ubus.h"
> #include "helpers.h"
> 
> +#define filter_target(t) \
> + ((t == FW3_FLAG_REJECT) ? "reject" : fw3_flag_names[t])
> 
> #define C(f, tbl, tgt, fmt) \
>   { FW3_FAMILY_##f, FW3_TABLE_##tbl, FW3_FLAG_##tgt, fmt }
> @@ -401,6 +403,19 @@ print_zone_chain(struct fw3_ipt_handle *handle, struct 
> fw3_state *state,
>   set(zone->flags, handle->family, handle->table);
> }
> 
> +static const char*
> +jump_target(enum fw3_flag t, bool src, struct fw3_zone *zone, char *buf, 
> size_t size)
> +{
> + if ((zone->log & FW3_ZONE_LOG_FILTER) && t > FW3_FLAG_ACCEPT)
> + {
> + snprintf(buf, size, "%s_%s_%s", fw3_flag_names[t],
> + src ? "src" : "dest", zone->name);
> + return buf;
> + }
> +
> + return filter_target(t);
> +}
> +
> static void
> print_interface_rule(struct fw3_ipt_handle *handle, struct fw3_state *state,
>bool reload, struct fw3_zone *zone,
> @@ -420,9 +435,6 @@ print_interface_rule(struct fw3_ipt_handle *handle, 
> struct fw3_state *state,
>   "forward", "FORWARD",
>   };
> 
> -#define jump_target(t) \
> - ((t == FW3_FLAG_REJECT) ? "reject" : fw3_flag_names[t])
> -
>   if (handle->table == FW3_TABLE_FILTER)
>   {
>   for (t = FW3_FLAG_ACCEPT; t <= FW3_FLAG_DROP; t++)
> @@ -430,7 +442,7 @@ print_interface_rule(struct fw3_ipt_handle *handle, 
> struct fw3_state *state,
>   if (has(zone->flags, handle->family, 
> fw3_to_src_target(t)))
>   {
>   r = fw3_ipt_rule_create(handle, NULL, dev, 
> NULL, sub, NULL);
> - fw3_ipt_rule_target(r, jump_target(t));
> + fw3_ipt_rule_target(r, jump_target(t, true, 
> zone, buf, sizeof(buf)));
>   fw3_ipt_rule_extra(r, zone->extra_src);
> 
>   if (t == FW3_FLAG_ACCEPT && 
> !state->defaults.drop_invalid)
> @@ -455,7 +467,7 @@ print_interface_rule(struct fw3_ipt_handle *handle, 
> struct fw3_state *state,
>   }
> 
>   r = fw3_ipt_rule_create(handle, NULL, NULL, 
> dev, NULL, sub);
> - fw3_ipt_rule_target(r, jump_target(t));
> + fw3_ipt_rule_target(r, jump_target(t, false, 
> zone, buf, sizeof(buf)));
>   fw3_ipt_rule_extra(r, zone->extra_dest);
>   fw3_ipt_rule_replace(r, "zone_%s_dest_%s", 
> zone->name,
>fw3_flag_names[t]);
> @@ -503,7 +515,7 @@ print_interface_rule(struct fw3_ipt_handle *handle, 
> struct fw3_state *state,
>   {
>   if (zone->log & FW3_ZONE_LOG_MANGLE)
>   {
> - snprintf(buf, sizeof(buf) - 1, "MSSFIX(%s): ", 
> zone->name);
> + snprintf(buf, sizeof(buf), "MSSFIX(%s): ", 
> zone->name);
> 
>   r = fw3_ipt_rule_create(handle, , NULL, 
> dev, NULL, sub);
>   fw3_ipt_rule_addarg(r, false, "--tcp-flags", 
> "SYN,RST");
> @@ -640,30 +652,46 @@ print_zone_rule(struct fw3_ipt_handle *handle, struct 
> fw3_state *state,
>   {
>   if (has(zone->flags, handle->family, 
> fw3_to_src_target(t)))
>   {
> + fw3_ipt_create_chain(handle, 
> "%s_src_%s",
> +  fw3_flag_names[t], 
> zone->name);
> +
>   r = fw3_ipt_rule_new(handle);
> 
> - snprintf(buf, sizeof(buf) - 1, "%s(src 
> %s)",
> + snprintf(buf, sizeof(buf), "%s(src %s)",
>fw3_flag_names[t], zone->name);
> 
>   fw3_ipt_rule_limit(r, >log_limit);
>   fw3_ipt_rule_target(r, "LOG");
>   

Re: [LEDE-DEV] [PATCH 3/3] intel-microcode: create early load microcode image

[Philip Prindeville]

Inline

> On Apr 3, 2018, at 7:13 AM, Tomasz Maciej Nowak  wrote:
> 
> Create initrd image with packed microcode. This'll allow to load it at
> early boot stage. Unfortunately the package can't install files directly
> to /boot directory, therefore additional installation hooks are placed
> for standalone package and when building directly into target image.
> 
> Signed-off-by: Tomasz Maciej Nowak 
> ---
> package/firmware/intel-microcode/Makefile | 32 +--
> target/linux/x86/image/Makefile   |  6 ++
> 2 files changed, 32 insertions(+), 6 deletions(-)
> 
> diff --git a/package/firmware/intel-microcode/Makefile 
> b/package/firmware/intel-microcode/Makefile
> index d2663bb901..9970f8f072 100644
> --- a/package/firmware/intel-microcode/Makefile
> +++ b/package/firmware/intel-microcode/Makefile
> @@ -35,15 +35,35 @@ define Package/intel-microcode
> endef
> 
> define Build/Compile
> - IUCODE_TOOL=$(STAGING_DIR)/../host/bin/iucode_tool $(MAKE) -C 
> $(PKG_BUILD_DIR)
> - mkdir $(PKG_BUILD_DIR)/intel-ucode
> - $(STAGING_DIR)/../host/bin/iucode_tool -q \
> - --write-firmware=$(PKG_BUILD_DIR)/intel-ucode 
> $(PKG_BUILD_DIR)/$(MICROCODE).bin
> + IUCODE_TOOL=$(STAGING_DIR)/../host/bin/iucode_tool \
> + $(MAKE) -C $(PKG_BUILD_DIR)
> + $(STAGING_DIR)/../host/bin/iucode_tool -q --mini-earlyfw \
> + --write-earlyfw=$(PKG_BUILD_DIR)/intel-ucode.cpio \
> + $(PKG_BUILD_DIR)/$(MICROCODE).bin
> endef
> 
> define Package/intel-microcode/install
> - $(INSTALL_DIR) $(1)/lib/firmware/intel-ucode
> - $(INSTALL_DATA) $(PKG_BUILD_DIR)/intel-ucode/* 
> $(1)/lib/firmware/intel-ucode
> + $(INSTALL_DIR) $(1)/lib/firmware
> + $(INSTALL_DATA) $(PKG_BUILD_DIR)/intel-ucode.cpio \
> + $(1)/lib/firmware/intel-ucode.img
> +endef
> +
> +ifeq ($(CONFIG_PACKAGE_intel-microcode),m)
> +define Package/intel-microcode/postinst
> +#!/bin/sh
> +
> +mount /boot -o remount,rw,noatime
> +cp -f /lib/firmware/intel-ucode.img /boot/

Can we preserve the timestamp (-p) on the microcode file, too?


> +mount /boot -o remount,ro,noatime
> +endef
> +endif
> +
> +define Package/intel-microcode/prerm
> +#!/bin/sh
> +
> +mount /boot -o remount,rw,noatime
> +rm /boot/intel-ucode.img


“rm -f” so that if the uninstall fails it’s idempotent and doesn’t leave things 
in a weird state.


> +mount /boot -o remount,ro,noatime
> endef
> 
> $(eval $(call BuildPackage,intel-microcode))
> diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/image/Makefile
> index a05f4babd9..4d6a3016d2 100644
> --- a/target/linux/x86/image/Makefile
> +++ b/target/linux/x86/image/Makefile
> @@ -83,6 +83,9 @@ ifneq ($(CONFIG_GRUB_IMAGES),)
>   -e 's#@TIMEOUT@#$(GRUB_TIMEOUT)#g' \
>   -e 's#@ROOT@#$(GRUB_ROOT)#g' \
>   ./grub.cfg > $(KDIR)/root.grub/boot/grub/grub.cfg
> +ifeq ($(CONFIG_PACKAGE_intel-microcode),y)
> + $(CP) $(STAGING_DIR)/root-x86/lib/firmware/intel-ucode.img 
> $(KDIR)/root.grub/boot/
> +endif


Do we need this?  Won’t the postinst happen during “make world”?


>   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 \
> @@ -120,6 +123,9 @@ define Image/Build/iso
>   -e 's#@CMDLINE@#root=/dev/sr0 rootfstype=iso9660 rootwait 
> $(strip $(call Image/cmdline/$(1)) $(BOOTOPTS) $(GRUB_CONSOLE_CMDLINE))#g' \
>   -e 's#@TIMEOUT@#$(GRUB_TIMEOUT)#g' \
>   ./grub-iso.cfg > $(KDIR)/root.grub/boot/grub/grub.cfg
> +  ifeq ($(CONFIG_PACKAGE_intel-microcode),y)
> + $(CP) $(STAGING_DIR)/root-x86/lib/firmware/intel-ucode.img 
> $(KDIR)/root.grub/boot/
> +  endif


Ditto.


>   mkisofs -R -b boot/grub/eltorito.img -no-emul-boot -boot-info-table \
>   -o $(KDIR)/root.iso $(KDIR)/root.grub $(TARGET_DIR)
> endef
> -- 
> 2.16.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/3] x86: add intel microcode entries to grub config

[Philip Prindeville]

Inline.  Has this been tested with UEFI?


> On Apr 3, 2018, at 7:13 AM, Tomasz Maciej Nowak  wrote:
> 
> Create initrd enries for x86 images, that'll load intel microcode as
> early as possible. Also restrict the late load of microcode to AMD
> processors.
> 
> Signed-off-by: Tomasz Maciej Nowak 
> ---
> target/linux/x86/base-files/lib/preinit/02_load_x86_ucode | 6 --
> target/linux/x86/image/Makefile   | 4 ++--
> target/linux/x86/image/grub-iso.cfg   | 3 +++
> target/linux/x86/image/grub.cfg   | 3 +++
> 4 files changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/target/linux/x86/base-files/lib/preinit/02_load_x86_ucode 
> b/target/linux/x86/base-files/lib/preinit/02_load_x86_ucode
> index fb309c75c1..68ebdf8651 100644
> --- a/target/linux/x86/base-files/lib/preinit/02_load_x86_ucode
> +++ b/target/linux/x86/base-files/lib/preinit/02_load_x86_ucode
> @@ -2,8 +2,10 @@
> # Copyright (C) 2018 OpenWrt.org
> 
> do_load_x86_ucode() {
> - if [ -e "/sys/devices/system/cpu/microcode/reload" ]; then
> - echo 1 > /sys/devices/system/cpu/microcode/reload
> + if [ "$(grep -c AuthenticAMD /proc/cpuinfo)" -gt "0" ]; then


Way too complicated.  Try:

if grep -q AuthenticAMD /proc/cpuinfo; then

instead.  -q inhibits output, and instead you get true for having matches, and 
false for no matches.



> + if [ -e "/sys/devices/system/cpu/microcode/reload" ]; then
> + echo 1 > /sys/devices/system/cpu/microcode/reload
> + fi
>   fi
> }
> 
> diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/image/Makefile
> index 8a3cb327e3..a05f4babd9 100644
> --- a/target/linux/x86/image/Makefile
> +++ b/target/linux/x86/image/Makefile
> @@ -9,8 +9,8 @@ include $(INCLUDE_DIR)/image.mk
> 
> export PATH=$(TARGET_PATH):/sbin
> 
> -GRUB2_MODULES = biosdisk boot chain configfile ext2 linux ls part_msdos 
> reboot serial vga
> -GRUB2_MODULES_ISO = biosdisk boot chain configfile iso9660 linux ls 
> part_msdos reboot serial vga
> +GRUB2_MODULES = biosdisk boot chain configfile ext2 linux ls part_msdos 
> reboot serial test vga
> +GRUB2_MODULES_ISO = biosdisk boot chain configfile iso9660 linux ls 
> part_msdos reboot serial test vga


What is “test” in this case?


> GRUB_TERMINALS =
> GRUB_SERIAL_CONFIG =
> GRUB_TERMINAL_CONFIG =
> diff --git a/target/linux/x86/image/grub-iso.cfg 
> b/target/linux/x86/image/grub-iso.cfg
> index 3d47a95a4b..30b587bd1c 100644
> --- a/target/linux/x86/image/grub-iso.cfg
> +++ b/target/linux/x86/image/grub-iso.cfg
> @@ -7,4 +7,7 @@ set root='(cd)'
> 
> menuentry "OpenWrt" {
>   linux /boot/vmlinuz @CMDLINE@ noinitrd
> + if [ -e /boot/intel-ucode.img ]; then
> + initrd /boot/intel-ucode.img
> + fi
> }
> diff --git a/target/linux/x86/image/grub.cfg b/target/linux/x86/image/grub.cfg
> index 9ec6b2d39c..dde24b95ce 100644
> --- a/target/linux/x86/image/grub.cfg
> +++ b/target/linux/x86/image/grub.cfg
> @@ -7,6 +7,9 @@ set root='(@ROOT@)'
> 
> menuentry "OpenWrt" {
>   linux /boot/vmlinuz @CMDLINE@ noinitrd
> + if [ -e /boot/intel-ucode.img ]; then
> + initrd /boot/intel-ucode.img
> + fi
> }
> menuentry "OpenWrt (failsafe)" {
>   linux /boot/vmlinuz failsafe=true @CMDLINE@ noinitrd
> -- 
> 2.16.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Revamping ipcalc.sh

[Philip Prindeville]

Hi all,

What do people think of (a) rewriting ipcalc.sh to be in C instead, and (b) 
allowing it to perform multiple operations either with flags or perhaps with 
symlinks and examining argv[0] a la busybox?

It isn’t used in too many places so any sort of change won’t have too many 
repercussions.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] DNS split horizon *without* dnsmasq

[Philip Prindeville]

> On Mar 31, 2018, at 12:57 PM, Eric Luehrsen  wrote:
> 
> It seems I have static-stub wrong for its purpose. dhcpd and bind do work 
> together. To accomplish this, the bind instance needs to be master for the 
> domain zone and ptr zone where DHCP records will be entered. This master zone 
> needs to permit remote updates, preferably with a secure key. dhcpd needs to 
> be configure to dynamically update DNS through binds remote


Rather than using a secure key, what about listening on localhost: and 
allowing updates only from there?  Bind has reasonable ACL capabilities…

Formatting below got a little buggered up.

What are we looking at?

Thanks,

-Philip



> control, again with the key if configured.
> 
> dhcpd reference conf to get started, incomplete
> ```||
> |ddns-update-style standard;|||
> |ddns-rev-domainname "in-addr.arpa.";|||
> ||
> |zone openwrt.lan. {|
> |||   # where to send updates for hostid.openwrt.lan|
> |   primary 127.0.0.1; };|
> ||
> |zone 1.168.192.in-addr.arpa. {|
> |   primary 127.0.0.1; }|;
> ||
> |```|
> ||
> bind reference conf to get started, incomplete
> https://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html#dynamic_update_policies
> ```||
> |zone "|||openwrt.lan|" { |
> |  type master;|
> |  file "/var/lib/bind/db.openwrt.lan||"; |
> |  update-policy {
> # you can restrict record types, rather than "any"
> ||grant [key-name] zonesub any; |
> |  }; |
> |}; |
> ||
> |zone "1.168.192.in-addr.arpa" {|
> |  type master;|
> |  file "|||/var/lib/bind|/db.1.168.192.in-addr.arpa";|
> |  update-policy {|
> |grant [key-name] zonesub any;|
> |  };|
> |};|
> ```
> 
> 
> Both could include a key file like
> ```||
> |key "key-name" { |
> |  algorithm [hash];
>   secret "passphrase"; };|
> ```


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] DNS split horizon *without* dnsmasq

[Philip Prindeville]

> On Mar 31, 2018, at 9:03 AM, Eric Luehrsen <ericluehr...@gmail.com> wrote:
> 
> On 03/25/2018 03:27 AM, Philip Prindeville wrote:
>> Thinking Bind, probably.
>> 
>> 
>> 
>>> On Mar 23, 2018, at 5:38 PM, Eric Luehrsen <ericluehr...@gmail.com> wrote:
>>> 
>>> What do you want to serve your dns then? Unbound or Bind?
>>> 
>>> - Eric
>>> 
>>> On Fri, Mar 23, 2018, 1:31 PM Philip Prindeville 
>>> <philipp_s...@redfish-solutions.com> wrote:
>>> Hi all,
>>> 
>>> As the ISC-DHCP maintainer, I need to eat my own dogfood so I run that 
>>> here, before anyone quips, “Why don’t you just run dnsmasq instead?”
>>> 
>>> So… I have some internal names that I want to be able to resolve 
>>> internally, but I also need to provide DNS service for all of my DHCP 
>>> clients.
>>> 
>>> Is there a way to prime a “fake” local zone (or cache) and run a caching 
>>> only nameserver that’s been primed with this “split-horizon” info (i.e. the 
>>> local names for machines on 192.168.1.0/24, etc)?
>>> 
>>> Or equally, have DHCP prime the local names into the DNS as they get 
>>> allocated (well, that wouldn’t fully solve my problem as my mail server has 
>>> a statically allocated IP address, so DHCP wouldn’t know about that).
>>> 
>>> Any ideas?
>>> 
>>> Thanks,
>>> 
>>> -Philip
> With Bind, you will also need to install rndc "remote named control." 
> Otherwise you need to reload bind when the zonefile is changed. That purges 
> the recursion cache. You will need to declare the local domain and local ptr 
> domain as static-stub zones (data local only to bind). You can add forwarders 
> to those zones for static corporate resources manged by another DNS server. 
> You then need a script call from dhpcd to parse its lease file and write a 
> zonefile for the local domain and local pointer domain each. After those are 
> written, rndc calls to reload the two respective zones without restarting all 
> of Bind.
> 
> With Unbound, the OpenWrt package already supports odhcpd for this. It would 
> make a reasonable example for dhcpd and bind. Although both dhcpd and bind 
> have complex lease and configuration formats. I haven't used dhcpd on 
> embedded equipment. Maybe someone could add dhcpd to Unbound conversion 
> script.
> 
> - Eric
> 


Hi Eric,

Thanks for the great feedback.

I’m working with Daniel Golle and Noah Meyerhans on some “glue” to do the 
integration.

First off is adding support to ISC-DHCP to allow specifying a site-wide domain, 
and explicit DHCP options analogous to what dnsmasq supports.

That’s here:

https://github.com/openwrt/packages/pull/5819

Was going to add you to the discussion but can’t figure out your Github handle.

As soon as that’s merged (waiting on a sign-off from Golle) I’ll get back to 
working on the glue, which is in draft form.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] leds-apu2: add newer board names

[Philip Prindeville]

“recent”?  I thought APU2’s had been discontinued a while ago.



> On Mar 26, 2018, at 8:20 AM, Sebastian Fleer  wrote:
> 
> In recent firmware releases the board names changed from "apuX" to "PC 
> Engines apuX"
> 
> Signed-off-by: Sebastian Fleer 
> ---
> package/kernel/leds-apu2/src/leds-apu2.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/package/kernel/leds-apu2/src/leds-apu2.c 
> b/package/kernel/leds-apu2/src/leds-apu2.c
> index 4ea552c..2fefa85 100644
> --- a/package/kernel/leds-apu2/src/leds-apu2.c
> +++ b/package/kernel/leds-apu2/src/leds-apu2.c
> @@ -335,7 +335,10 @@ static int __init gpio_apu2_init (void)
>   if (!board_name \
>   || !board_vendor \
>   || strcasecmp(board_vendor, "PC Engines") \
> - || (strcasecmp(board_name, "apu2") && 
> strcasecmp(board_name, "apu3"))) {
> + || (strcasecmp(board_name, "apu2") \
> + && strcasecmp(board_name, "apu3") \
> + && strcasecmp(board_name, "PC Engines apu2") \
> + && strcasecmp(board_name, "PC Engines apu3"))) {
>   err = -ENODEV;
>   goto exit;
>   }


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Duplicates in bind subpackages?

[Philip Prindeville]

Anyone else seeing this issue with Bind?

Collected errors:
 * check_data_file_clashes: Package bind-check wants to install file 
/home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/sbin/named-checkconf
But that file is already provided by package  * bind-tools
 * check_data_file_clashes: Package bind-check wants to install file 
/home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/sbin/named-checkzone
But that file is already provided by package  * bind-tools
 * opkg_install_cmd: Cannot install package bind-check.
 * check_data_file_clashes: Package bind-dig wants to install file 
/home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/bin/dig
But that file is already provided by package  * bind-tools
 * opkg_install_cmd: Cannot install package bind-dig.
package/Makefile:65: recipe for target 'package/install’ failed

Here’s more info on what’s getting packaged where:

% find  bind-check bind-tools bind-dig -type f -print
bind-check/CONTROL/control
bind-check/CONTROL/postinst
bind-check/CONTROL/prerm
bind-check/usr/sbin/named-checkzone
bind-check/usr/sbin/named-checkconf
bind-tools/CONTROL/control
bind-tools/CONTROL/postinst
bind-tools/CONTROL/prerm
bind-tools/usr/bin/dig
bind-tools/usr/bin/host
bind-tools/usr/sbin/rndc
bind-tools/usr/sbin/named-checkzone
bind-tools/usr/sbin/dnssec-signzone
bind-tools/usr/sbin/dnssec-settime
bind-tools/usr/sbin/dnssec-keygen
bind-tools/usr/sbin/rndc-confgen
bind-tools/usr/sbin/named-checkconf
bind-dig/CONTROL/control
bind-dig/CONTROL/postinst
bind-dig/CONTROL/prerm
bind-dig/usr/bin/dig


Also, should sub-packages within the same package have the right to overlap 
contents?  I can think of cases where you might want to bundle utilities, for 
instance, in slightly different ways with overlap…

You just need to be careful to not remove a file when removing a subpackage 
until the last subpackage containing it (i.e. reference count goes to zero) 
gets removed.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Duplicates in bind subpackages?

[Philip Prindeville]

> On Mar 25, 2018, at 2:38 PM, Noah Meyerhans <fr...@morgul.net> wrote:
> 
> On Sun, Mar 25, 2018 at 02:24:57PM -0600, Philip Prindeville wrote:
>> Collected errors:
>> * check_data_file_clashes: Package bind-check wants to install file 
>> /home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/sbin/named-checkconf
>>  But that file is already provided by package  * bind-tools
>> * check_data_file_clashes: Package bind-check wants to install file 
>> /home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/sbin/named-checkzone
>>  But that file is already provided by package  * bind-tools
>> * opkg_install_cmd: Cannot install package bind-check.
>> * check_data_file_clashes: Package bind-dig wants to install file 
>> /home/philipp/lede/build_dir/target-x86_64_musl/root-x86/usr/bin/dig
>>  But that file is already provided by package  * bind-tools
>> * opkg_install_cmd: Cannot install package bind-dig.
>> package/Makefile:65: recipe for target 'package/install’ failed
> 
> Yeah, the intent is that the bind-tools package is a single package that
> includes all the tools, while packages such as bind-dig only contain a
> single specific tool. In theory bind-tools could be replaced by an empty
> package that simply declares dependencies on all the other tool
> packages.
> 
> I'm not sure when this configuration was originally introduced; it's
> been present since before I was involved in maintaining the packages. It
> always felt a little odd to me, but never so much so that I felt
> compelled to remove it. I'm happy to consider doing so if people feel
> strongly about it.
> 
> noah
> 


Yeah, a virtual package definitely sounds like the way to go.

Not urgent, but having clean builds is always nice…

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] DNS split horizon *without* dnsmasq

[Philip Prindeville]

Thinking Bind, probably.



> On Mar 23, 2018, at 5:38 PM, Eric Luehrsen <ericluehr...@gmail.com> wrote:
> 
> What do you want to serve your dns then? Unbound or Bind?
> 
> - Eric
> 
> On Fri, Mar 23, 2018, 1:31 PM Philip Prindeville 
> <philipp_s...@redfish-solutions.com> wrote:
> Hi all,
> 
> As the ISC-DHCP maintainer, I need to eat my own dogfood so I run that here, 
> before anyone quips, “Why don’t you just run dnsmasq instead?”
> 
> So… I have some internal names that I want to be able to resolve internally, 
> but I also need to provide DNS service for all of my DHCP clients.
> 
> Is there a way to prime a “fake” local zone (or cache) and run a caching only 
> nameserver that’s been primed with this “split-horizon” info (i.e. the local 
> names for machines on 192.168.1.0/24, etc)?
> 
> Or equally, have DHCP prime the local names into the DNS as they get 
> allocated (well, that wouldn’t fully solve my problem as my mail server has a 
> statically allocated IP address, so DHCP wouldn’t know about that).
> 
> Any ideas?
> 
> Thanks,
> 
> -Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] DNS split horizon *without* dnsmasq

[Philip Prindeville]

Hi all,

As the ISC-DHCP maintainer, I need to eat my own dogfood so I run that here, 
before anyone quips, “Why don’t you just run dnsmasq instead?”

So… I have some internal names that I want to be able to resolve internally, 
but I also need to provide DNS service for all of my DHCP clients.

Is there a way to prime a “fake” local zone (or cache) and run a caching only 
nameserver that’s been primed with this “split-horizon” info (i.e. the local 
names for machines on 192.168.1.0/24, etc)?

Or equally, have DHCP prime the local names into the DNS as they get allocated 
(well, that wouldn’t fully solve my problem as my mail server has a statically 
allocated IP address, so DHCP wouldn’t know about that).

Any ideas?

Thanks,

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] 18.03/4

[Philip Prindeville]

> On Mar 4, 2018, at 6:26 PM, Alif M. Ahmad  wrote:
> 
> On Fri, Feb 16, 2018 at 01:46:31PM +0100, John Crispin wrote:
>> Hi,
>> 
>> whats on the critical todo list for the upcoming release ? i still have 
>> a few minor things that I'll be adding shortly, apart from that I am 
>> currently not aware of any huge problems. the release will be a mix 
>> between 4.9 and 4.14 afaik !?
>> 
>> John
> 
> I would like to have uefi-gpt image for x86_64. For this feature, uefi
> related changes on Jow's staging repository should be merged.
> 
> I have fixed kernel panic issue when booting gpt image on bios based
> systems with my previous patch series.


There’s also the packaging issue of combining the target and host packaging of 
sgdisk.

Jo: did you have any time to look at that?

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] busybox: re-enable telnet applet

[Philip Prindeville]

> On Feb 18, 2018, at 11:25 AM, Philip Prindeville 
> <philipp_s...@redfish-solutions.com> wrote:
> 
> 
> 
>> On Feb 18, 2018, at 2:27 AM, John Crispin <j...@phrozen.org> wrote:
>> 
>> 
>> 
>>> On 20/06/17 19:13, Stefan Tomanek wrote:
>>> While sshd should be favoured over telnetd, having a telnet client on the
>>> router is useful for connecting to other devices in the same LAN.
>>> 
>>> Signed-off-by: Stefan Tomanek <stefan.toma...@wertarbyte.de>
>> 
>> sorry for the late reply, it has been discussed over and over and the 
>> decision was made to not enable telnet by default. sorry ...
>> 
>>John
> 
> Too bad.  While it’s a liability for logging in, it’s a great tool for 
> testing remote services like HTTP, SMTP, IMAP, JetDirect printers, etc.


Although we should be honest about it: the problem isn’t the host with the 
telnet client; it’s the one with the telnet server.

-Philip


>>> ---
>>> package/utils/busybox/Config-defaults.in |4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/package/utils/busybox/Config-defaults.in 
>>> b/package/utils/busybox/Config-defaults.in
>>> index 1977e7f..9e0efcf 100644
>>> --- a/package/utils/busybox/Config-defaults.in
>>> +++ b/package/utils/busybox/Config-defaults.in
>>> @@ -2289,10 +2289,10 @@ config BUSYBOX_DEFAULT_TCPSVD
>>> default n
>>> config BUSYBOX_DEFAULT_TELNET
>>> bool
>>> -default n
>>> +default y
>>> config BUSYBOX_DEFAULT_FEATURE_TELNET_TTYPE
>>> bool
>>> -default n
>>> +default y
>>> config BUSYBOX_DEFAULT_FEATURE_TELNET_AUTOLOGIN
>>> bool
>>> default n
>> 
>> 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] iproute2: Add support for ports in xfrm on SCTP

[Philip Prindeville]

Why did we even do this to begin with?


> On Feb 15, 2018, at 3:52 PM, Hauke Mehrtens  wrote:
> 
> Remove this old patch which prevents showing the xfrm ports for SCTP
> 
> This was added in commit 60c1f0f64d23 ("finally move buildroot-ng to trunk")
> ---
> .../network/utils/iproute2/patches/006-no_sctp.patch   | 18 --
> 1 file changed, 18 deletions(-)
> delete mode 100644 package/network/utils/iproute2/patches/006-no_sctp.patch
> 
> diff --git a/package/network/utils/iproute2/patches/006-no_sctp.patch 
> b/package/network/utils/iproute2/patches/006-no_sctp.patch
> deleted file mode 100644
> index e23fbcd77d..00
> --- a/package/network/utils/iproute2/patches/006-no_sctp.patch
> +++ /dev/null
> @@ -1,18 +0,0 @@
>  a/ip/ipxfrm.c
> -+++ b/ip/ipxfrm.c
> -@@ -454,7 +454,6 @@ void xfrm_selector_print(struct xfrm_sel
> -switch (sel->proto) {
> -case IPPROTO_TCP:
> -case IPPROTO_UDP:
> --case IPPROTO_SCTP:
> -case IPPROTO_DCCP:
> -default: /* XXX */
> -if (sel->sport_mask)
> -@@ -1329,7 +1328,6 @@ static int xfrm_selector_upspec_parse(st
> -switch (sel->proto) {
> -case IPPROTO_TCP:
> -case IPPROTO_UDP:
> --case IPPROTO_SCTP:
> -case IPPROTO_DCCP:
> -case IPPROTO_IP: /* to allow shared SA for different protocols */
> -break;
> -- 
> 2.11.0
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] busybox: re-enable telnet applet

[Philip Prindeville]

> On Feb 18, 2018, at 2:27 AM, John Crispin  wrote:
> 
> 
> 
>> On 20/06/17 19:13, Stefan Tomanek wrote:
>> While sshd should be favoured over telnetd, having a telnet client on the
>> router is useful for connecting to other devices in the same LAN.
>> 
>> Signed-off-by: Stefan Tomanek 
> 
> sorry for the late reply, it has been discussed over and over and the 
> decision was made to not enable telnet by default. sorry ...
> 
> John

Too bad.  While it’s a liability for logging in, it’s a great tool for testing 
remote services like HTTP, SMTP, IMAP, JetDirect printers, etc.


>> ---
>>  package/utils/busybox/Config-defaults.in |4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/package/utils/busybox/Config-defaults.in 
>> b/package/utils/busybox/Config-defaults.in
>> index 1977e7f..9e0efcf 100644
>> --- a/package/utils/busybox/Config-defaults.in
>> +++ b/package/utils/busybox/Config-defaults.in
>> @@ -2289,10 +2289,10 @@ config BUSYBOX_DEFAULT_TCPSVD
>>  default n
>>  config BUSYBOX_DEFAULT_TELNET
>>  bool
>> -default n
>> +default y
>>  config BUSYBOX_DEFAULT_FEATURE_TELNET_TTYPE
>>  bool
>> -default n
>> +default y
>>  config BUSYBOX_DEFAULT_FEATURE_TELNET_AUTOLOGIN
>>  bool
>>  default n
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] 18.03/4

[Philip Prindeville]

> On Feb 16, 2018, at 5:46 AM, John Crispin  wrote:
> 
> Hi,
> 
> whats on the critical todo list for the upcoming release ? i still have a few 
> minor things that I'll be adding shortly, apart from that I am currently not 
> aware of any huge problems. the release will be a mix between 4.9 and 4.14 
> afaik !?
> 
> John


I wouldn’t mind bumping ISC-DHCP to 4.4.0 but I need someone to test it on a 
non-x86 platform…

The PR is sitting waiting for another tester.

https://github.com/openwrt/packages/pull/5579

And iperf3 has a pending PR to 3.4 but I don’t think that’s critical, but it 
might be nice to have it be tested and get in.

I’m running it (again on x86_64 hardware) but an “alien” cross-build would be 
better.


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Philip Prindeville]

> On Feb 14, 2018, at 3:00 PM, Magnus Kroken  wrote:
> 
> On 14.02.2018 22.13, Michelle Sullivan wrote:
>> FWIW, I had misunderstood the intent of the original comments... OpenSSH
>> server vs Dropbear - if someone is using OpenSSH server they already
>> went in with advanced config as Dropbear is the default - I'd err on the
>> side of security as they should already know what they are doing  it
>> should be recoverable by webinterface though (rather than worrying about
>> people 'fixing' by using something not secure.)
> 
> The opposite argument applies equally well IMO: they already know what they 
> are doing, they should know how to allow key authentication only if they want 
> that.


Well, right!  That was my first approach with a “config" option to do exactly 
that, but it was shot down:

https://github.com/openwrt/packages/pull/5520

I even defaulted the option to continue to allow passwords so that only people 
who (a) selected OpenSSH and (b) turned this option off would be affected… 
which has to be a small portion of the population.


> 
> Consider a scenario where a user builds an image with OpenSSH, without 
> Dropbear (because they have OpenSSH), and without a web interface (because 
> they want to save space). This is easily done by selecting and deselecting 
> packages in menuconfig/imagebuilder, no custom files needed today. With this 
> change, if the image is missing authorized_keys, the only way to log in is 
> serial console (failsafe will be locked out too), which requires soldering - 
> or using bootloader recovery features, which may also require soldering and 
> aren't consistently documented.


Actually, most of the boxes that *I* work on (Geos, Alix 2D, net5501, Xeon 1U 
servers, etc.) all have serial ports and most of them have VGA as well (or 
could if you install the optional header).


> 
> This is just about the default configuration, it's not a choice between 
> conflicting compile time options with varying security implications. While 
> key authentication may be best practice, allowing SSH password logins isn't 
> on the level of reimplementing LuCI in PHP 4. The change is *literally* a 
> handful of sed commands, why can't advanced users take care of that 
> themselves? Why do we want to make it easier to build a soft-bricking image 
> than it is today?


Conversely, why can’t advanced users have a clear, standardized way of doing 
this?  That they’re “advanced” doesn’t mean they don’t also appreciate 
convenience, an easy way to save and export/import configurations, etc.

In a perfect world, no one should ever have to build with patches, anything in 
files/, cherry-picked commits, etc.  Everything would be expressed in the 
.config (or kernel-config).

And again, not every box would be bricked.  Like I said, all of mine have 
serial consoles and most of them have VGA.


> 
> How about adding a configuration flag to menuconfig for OpenSSH, which runs 
> said sed commands if the flag is set (disabled by default, for the reasons 
> above). It makes it easier to set for those who want it, and it will also be 
> saved in a diffconfig output if they set that.


Did exactly that in the original PR but it was vetoed.

-Philip


> 
> Regards
> /Magnus


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Philip Prindeville]

> On Feb 14, 2018, at 3:00 PM, Magnus Kroken  wrote:
> 
> On 14.02.2018 22.13, Michelle Sullivan wrote:
>> FWIW, I had misunderstood the intent of the original comments... OpenSSH
>> server vs Dropbear - if someone is using OpenSSH server they already
>> went in with advanced config as Dropbear is the default - I'd err on the
>> side of security as they should already know what they are doing  it
>> should be recoverable by webinterface though (rather than worrying about
>> people 'fixing' by using something not secure.)
> 
> The opposite argument applies equally well IMO: they already know what they 
> are doing, they should know how to allow key authentication only if they want 
> that.


Well, right!  That was my first approach with a “config" option to do exactly 
that, but it was shot down:

https://github.com/openwrt/packages/pull/5520

I even defaulted the option to continue to allow passwords so that only people 
who (a) selected OpenSSH and (b) turned this option off would be affected… 
which has to be a small portion of the population.


> 
> Consider a scenario where a user builds an image with OpenSSH, without 
> Dropbear (because they have OpenSSH), and without a web interface (because 
> they want to save space). This is easily done by selecting and deselecting 
> packages in menuconfig/imagebuilder, no custom files needed today. With this 
> change, if the image is missing authorized_keys, the only way to log in is 
> serial console (failsafe will be locked out too), which requires soldering - 
> or using bootloader recovery features, which may also require soldering and 
> aren't consistently documented.


Actually, most of the boxes that *I* work on (Geos, Alix 2D, net5501, Xeon 1U 
servers, etc.) all have serial ports and most of them have VGA as well (or 
could if you install the optional header).


> 
> This is just about the default configuration, it's not a choice between 
> conflicting compile time options with varying security implications. While 
> key authentication may be best practice, allowing SSH password logins isn't 
> on the level of reimplementing LuCI in PHP 4. The change is *literally* a 
> handful of sed commands, why can't advanced users take care of that 
> themselves? Why do we want to make it easier to build a soft-bricking image 
> than it is today?


Conversely, why can’t advanced users have a clear, standardized way of doing 
this?  That they’re “advanced” doesn’t mean they don’t also appreciate 
convenience, an easy way to save and export/import configurations, etc.

In a perfect world, no one should ever have to build with patches, anything in 
files/, cherry-picked commits, etc.  Everything would be expressed in the 
.config (or kernel-config).

And again, not every box would be bricked.  Like I said, all of mine have 
serial consoles and most of them have VGA.


> 
> How about adding a configuration flag to menuconfig for OpenSSH, which runs 
> said sed commands if the flag is set (disabled by default, for the reasons 
> above). It makes it easier to set for those who want it, and it will also be 
> saved in a diffconfig output if they set that.


Did exactly that in the original PR but it was vetoed.

-Philip


> 
> Regards
> /Magnus



signature.asc
Description: Message signed with OpenPGP
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Philip Prindeville]

> On Feb 14, 2018, at 1:25 AM, Stijn Segers  wrote:
> 
> Yousong Zhou  schreef op 14 februari 2018 09:06:11 CET:
>> 
>> No, it's just complicating things up.  When people really cares about
>> the default settings' security, the will override the default by also
>> specifying files/etc/ssh/sshd_config besides
>> files/root/.ssh/authorized_keys.  No need to pass on such complexity
>> as virtual packages and another config options for others.
>> 
>>   yousong
>> 
> 
> This only applies to OpenSSH, not Dropbear right? So this won't affect stock 
> images?
> 
> We should consider people rolling their own and using OpenSSH by default. 
> This might be a nasty surprise - flash, reboot, realise you're locked out.
> 
> SSH access from WAN is disabled by default anyway, as is access to the web 
> interface. We already switched from telnet to SSH for initial login. I don't 
> see any gaping security holes... 
> 
> On top of that, the project having a DIY spirit, if people start tinkering 
> with SSH, they should know what they're doing. Just like when they start 
> using LEDE/OpenWrt.
> 
> My 2 cents
> 
> Stijn
> 


Yes, this would be for OpenSSH only… Dropbear has a UCI control that you can 
change.  (Yes, we could implement UCI for the 60 or so OpenSSH knobs, but it’s 
sufficiently complicated that people might end up locking themselves out via 
misconfiguration… so KISS)

Actually, SSH access from WAN is blocked by Firewall, but not “disabled by 
default”.  If your firewall settings get munged, then SSH is wide open (because 
by default it listens to 0.0.0.0:22 which is unbound).  Not exactly “defense in 
depth”.

Once I was messing with firewall settings and accidentally disabled the 
firewall.  Within a few minutes, there were all sorts of password attacks on 
the WAN port.  Having a sufficiently complex password slowed things down long 
enough for me to re-secure the box.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Philip Prindeville]

> On Feb 14, 2018, at 1:06 AM, Yousong Zhou <yszhou4t...@gmail.com> wrote:
> 
> On 14 February 2018 at 11:53, Philip Prindeville
> <philipp_s...@redfish-solutions.com> wrote:
>> 
>>> On Feb 11, 2018, at 3:54 AM, Yousong Zhou <yszhou4t...@gmail.com> wrote:
>>> 
>>> On 9 February 2018 at 08:28, Philip Prindeville
>>> <phil...@redfish-solutions.com> wrote:
>>>> From: Philip Prindeville <phil...@redfish-solutions.com>
>>>> 
>>>> Allowing password logins leaves you vulnerable to dictionary
>>>> attacks.  We disable password-based authentication, limiting
>>>> authentication to keys only which are more secure.
>>>> 
>>>> Note: You'll need to pre-populate your image with some initial
>>>> keys. To do this:
>>>> 
>>>> 1. Create the appropriate directory as "mkdir -p files/root/.ssh"
>>>>  from your top-level directory;
>>>> 2. Copy your "~/.ssh/id_rsa.pub" (or as appropriate) into
>>>>  "files/root/.ssh/authorized_keys" and indeed, you can collect
>>>>  keys from several sources this way by concatenating them;
>>>> 3. Set the permissions on "authorized_keys" to 644 or 640.
>>>> 
>>> 
>>> If forgetting doing this means I may need physical connection like vga
>>> monitor or serial connection to "unlock" the device, very likely I
>>> will hate this security enforcement...  It's just the inconvenience
>>> regardless of whether the said situation should happen.  As a user I'd
>>> like to keep this level of convenience as using password
>>> authentication and turn it off when I see it appropriate.
>>> 
>>>   yousong
>>> 
>> 
>> 
>> Well, we’re at an impasse because some people have said “this should be the 
>> new norm and it’s a mistake not to disable it unconditionally” and others 
>> have said the opposite, “yes, okay, let’s do this but only as an option”.
>> 
>> So I’m happy to go other way but we should reach a consensus.
>> 
>> What if it *is* an option but depends on a virtual package that takes a 
>> value (like CONFIG_SSH_PUBLIC_KEYS) and squirts that into the 
>> /root/.ssh/authorized_keys file.
>> 
>> Would that work for everyone?
>> 
>> You could still lock yourself out of a box by (a) mis-formatting the keys or 
>> (b) getting the wrong public keys that don’t match your installed private 
>> keys, but getting this to be absolutely foolproof is a fool's errand.
>> 
>> So what constitutes “good enough”?
>> 
>> -Philip
>> 
> 
> No, it's just complicating things up.  When people really cares about
> the default settings' security, the will override the default by also
> specifying files/etc/ssh/sshd_config besides
> files/root/.ssh/authorized_keys.  No need to pass on such complexity
> as virtual packages and another config options for others.
> 
>yousong


The problem with that is that if OpenSSH gets updated upstream, including 
changing the configuration file to address a CVE, I don’t want to keep 
installing a slightly mangled snapshot of a now-obsolete and vulnerable 
configuration.

That’s just exchanging one liability for another.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Philip Prindeville]

> On Feb 13, 2018, at 9:14 PM, Michelle Sullivan  wrote:
> 
> [snip]
> Personally - my thoughts 
> 
> There should be an option to enable passwords (default off...)
> A warning should be placed on the checkbox to inform the user it is not a 
> good idea to enable them.
> SSH should be disabled on external interfaces unless specifically enabled. 
> (what constitutes 'external' if there is no 'wan' port? ...i.e. AP only?)
> SSH without password in place and no keys should be unconditionally disabled 
> (and not enable-able - except by hand editing.)
> One could try to do what some manufacturers have done and open ssh for a 
> period of time if the WPS button is depressed for a certain length of time  
> as a 'fool proof' command login personally though I think anyone using 
> SSH instead of the webinterface is more than likely going to know what they 
> are doing and therefore it should not be an issue... ie err on the side of 
> 'there is an idiot at the controls, lets make it default as secure as 
> possible'...
> 
> -- 
> Michelle Sullivan
> http://www.mhix.org/
> 


Thanks for the suggestion.  Alas OpenSSH allows one to specify a ListenAddress 
which you could match to the “lan” or “wan” address(es).  Problem is that if 
you’re using DHCP on the “wan”, you’d have to rewrite the file (and restart the 
service) every time DHCP changed the address on the interface.

What would be better is if OpenSSH had a ListenInterface configuration 
parameter instead, and used netlink to listen for address changes… but that 
would be a bit of complexity (although you’d think it would be a common enough 
requirement for applications that someone would have come up with a library to 
do exactly that in a portable fashion).

Your conclusion is spot on: it’s hard to offer good security and make it 
foolproof at the same time because the approaches go in exactly opposite 
directions.  Security requires extreme pessimism, even paranoia, and 
user-friendliness implies being extremely forgiving.

It’s hard to have both.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Philip Prindeville]

> On Feb 11, 2018, at 3:54 AM, Yousong Zhou <yszhou4t...@gmail.com> wrote:
> 
> On 9 February 2018 at 08:28, Philip Prindeville
> <phil...@redfish-solutions.com> wrote:
>> From: Philip Prindeville <phil...@redfish-solutions.com>
>> 
>> Allowing password logins leaves you vulnerable to dictionary
>> attacks.  We disable password-based authentication, limiting
>> authentication to keys only which are more secure.
>> 
>> Note: You'll need to pre-populate your image with some initial
>> keys. To do this:
>> 
>> 1. Create the appropriate directory as "mkdir -p files/root/.ssh"
>>   from your top-level directory;
>> 2. Copy your "~/.ssh/id_rsa.pub" (or as appropriate) into
>>   "files/root/.ssh/authorized_keys" and indeed, you can collect
>>   keys from several sources this way by concatenating them;
>> 3. Set the permissions on "authorized_keys" to 644 or 640.
>> 
> 
> If forgetting doing this means I may need physical connection like vga
> monitor or serial connection to "unlock" the device, very likely I
> will hate this security enforcement...  It's just the inconvenience
> regardless of whether the said situation should happen.  As a user I'd
> like to keep this level of convenience as using password
> authentication and turn it off when I see it appropriate.
> 
>yousong
> 


Well, we’re at an impasse because some people have said “this should be the new 
norm and it’s a mistake not to disable it unconditionally” and others have said 
the opposite, “yes, okay, let’s do this but only as an option”.

So I’m happy to go other way but we should reach a consensus.

What if it *is* an option but depends on a virtual package that takes a value 
(like CONFIG_SSH_PUBLIC_KEYS) and squirts that into the 
/root/.ssh/authorized_keys file.

Would that work for everyone?

You could still lock yourself out of a box by (a) mis-formatting the keys or 
(b) getting the wrong public keys that don’t match your installed private keys, 
but getting this to be absolutely foolproof is a fool's errand.

So what constitutes “good enough”?

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Philip Prindeville]

> On Feb 11, 2018, at 3:54 AM, Yousong Zhou <yszhou4t...@gmail.com> wrote:
> 
> On 9 February 2018 at 08:28, Philip Prindeville
> <phil...@redfish-solutions.com> wrote:
>> From: Philip Prindeville <phil...@redfish-solutions.com>
>> 
>> Allowing password logins leaves you vulnerable to dictionary
>> attacks.  We disable password-based authentication, limiting
>> authentication to keys only which are more secure.
>> 
>> Note: You'll need to pre-populate your image with some initial
>> keys. To do this:
>> 
>> 1. Create the appropriate directory as "mkdir -p files/root/.ssh"
>>   from your top-level directory;
>> 2. Copy your "~/.ssh/id_rsa.pub" (or as appropriate) into
>>   "files/root/.ssh/authorized_keys" and indeed, you can collect
>>   keys from several sources this way by concatenating them;
>> 3. Set the permissions on "authorized_keys" to 644 or 640.
>> 
> 
> If forgetting doing this means I may need physical connection like vga
> monitor or serial connection to "unlock" the device, very likely I
> will hate this security enforcement...  It's just the inconvenience
> regardless of whether the said situation should happen.  As a user I'd
> like to keep this level of convenience as using password
> authentication and turn it off when I see it appropriate.
> 
>yousong

I originally did it as a Config setting which modified the config file at 
build-time (PR #5520) but this was vetoed.

Personally I thought allowing everyone to crank down the system as much as they 
saw appropriate was the best solution.

-Philip

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Philip Prindeville]

> On Feb 11, 2018, at 3:54 AM, Yousong Zhou <yszhou4t...@gmail.com> wrote:
> 
> On 9 February 2018 at 08:28, Philip Prindeville
> <phil...@redfish-solutions.com> wrote:
>> From: Philip Prindeville <phil...@redfish-solutions.com>
>> 
>> Allowing password logins leaves you vulnerable to dictionary
>> attacks.  We disable password-based authentication, limiting
>> authentication to keys only which are more secure.
>> 
>> Note: You'll need to pre-populate your image with some initial
>> keys. To do this:
>> 
>> 1. Create the appropriate directory as "mkdir -p files/root/.ssh"
>>  from your top-level directory;
>> 2. Copy your "~/.ssh/id_rsa.pub" (or as appropriate) into
>>  "files/root/.ssh/authorized_keys" and indeed, you can collect
>>  keys from several sources this way by concatenating them;
>> 3. Set the permissions on "authorized_keys" to 644 or 640.
>> 
> 
> If forgetting doing this means I may need physical connection like vga
> monitor or serial connection to "unlock" the device, very likely I
> will hate this security enforcement...  It's just the inconvenience
> regardless of whether the said situation should happen.  As a user I'd
> like to keep this level of convenience as using password
> authentication and turn it off when I see it appropriate.
> 
>   yousong


I originally did it as a Config setting which modified the config file at 
build-time (PR #5520) but this was vetoed.

Personally I thought allowing everyone to crank down the system as much as they 
saw appropriate was the best solution.

-Philip
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Philip Prindeville]

Sent from my iPhone
> On Feb 11, 2018, at 4:11 AM, Torbjorn Jansson 
> <torbjorn.jans...@mbox200.swipnet.se> wrote:
> 
>> On 2018-02-11 11:54, Yousong Zhou wrote:
>> On 9 February 2018 at 08:28, Philip Prindeville
>> <phil...@redfish-solutions.com> wrote:
>>> From: Philip Prindeville <phil...@redfish-solutions.com>
>>> 
>>> Allowing password logins leaves you vulnerable to dictionary
>>> attacks.  We disable password-based authentication, limiting
>>> authentication to keys only which are more secure.
>>> 
>>> Note: You'll need to pre-populate your image with some initial
>>> keys. To do this:
>>> 
>>> 1. Create the appropriate directory as "mkdir -p files/root/.ssh"
>>>from your top-level directory;
>>> 2. Copy your "~/.ssh/id_rsa.pub" (or as appropriate) into
>>>"files/root/.ssh/authorized_keys" and indeed, you can collect
>>>keys from several sources this way by concatenating them;
>>> 3. Set the permissions on "authorized_keys" to 644 or 640.
>>> 
>> If forgetting doing this means I may need physical connection like vga
>> monitor or serial connection to "unlock" the device, very likely I
>> will hate this security enforcement...  It's just the inconvenience
>> regardless of whether the said situation should happen.  As a user I'd
>> like to keep this level of convenience as using password
>> authentication and turn it off when I see it appropriate.
>> yousong
> 
> yes and i assume this will be a feature that is off by default, especially in 
> images created as part of making a new release.
> 
> if it is on by default in images available for download on lede/openwrt site 
> then we have a big problem.


By default images are built using dropbear not openssh.




___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Philip Prindeville]

> On Feb 10, 2018, at 6:03 PM, Michelle Sullivan <miche...@sorbs.net> wrote:
> 
> Paul Oranje wrote:
>> Your aptness for seeing the possible attack vectors warrants your judgement 
>> ...
>> 
>>> Op 10 feb. 2018, om 17:07 heeft Philip Prindeville 
>>> <philipp_s...@redfish-solutions.com> het volgende geschreven:
>>> 
>>> 
>>>> On Feb 10, 2018, at 3:28 AM, Paul Oranje <p...@oranjevos.nl> wrote:
>>>> 
>>>> Wouldn't it be appropriate to disallow password authentication on wan only 
>>>> and allow it on all networks "behind" the router?
>>> Not necessarily.
>>> 
>>> That’s why UPnP is such an issue. A machine inside a firewall gets infected 
>>> by a virus through a download or email... then the first thing the virus 
>>> does is punch holes in the firewall to allow outside scans of the remaining 
>>> hosts.
>>> 
>>> Allowing password logins from an infected host just means that the virus 
>>> has to do slightly more work before it owns the router (ie run a password 
>>> attack).
>>> 
>>> Not substantially more secure...
>>> 
> 
> uPNP should be disabled by default and where possible as it is a security 
> hazard for those that understand it.  For those that don't it's a compromise 
> waiting to happen.
> 
> Juniper doesn't support uPNP in the commercial market at all (and even given 
> their statement in 
> https://kb.juniper.net/InfoCenter/index?page=content=KB5615 I can point 
> out that even in their semi-residential products - ie their small office gear 
> doesn't support it either I'd suggest that any support for uPNP is off by 
> default and gives a warning if someone tries to enable it.)
> 

My point was simply that sometimes attack come inside your own firewall. Don’t 
naively assume that all attacks are external only; that’s not “defense in 
depth”.

-Philip

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Philip Prindeville]

> On Feb 10, 2018, at 3:28 AM, Paul Oranje <p...@oranjevos.nl> wrote:
> 
> Wouldn't it be appropriate to disallow password authentication on wan only 
> and allow it on all networks "behind" the router?

Not necessarily.

That’s why UPnP is such an issue. A machine inside a firewall gets infected by 
a virus through a download or email... then the first thing the virus does is 
punch holes in the firewall to allow outside scans of the remaining hosts.

Allowing password logins from an infected host just means that the virus has to 
do slightly more work before it owns the router (ie run a password attack).

Not substantially more secure...

-Philip

> 
>> Op 9 feb. 2018, om 01:28 heeft Philip Prindeville 
>> <phil...@redfish-solutions.com> het volgende geschreven:
>> 
>> From: Philip Prindeville <phil...@redfish-solutions.com>
>> 
>> Allowing password logins leaves you vulnerable to dictionary
>> attacks.  We disable password-based authentication, limiting
>> authentication to keys only which are more secure.
>> 
>> Note: You'll need to pre-populate your image with some initial
>> keys. To do this:
>> 
>> 1. Create the appropriate directory as "mkdir -p files/root/.ssh"
>>  from your top-level directory;
>> 2. Copy your "~/.ssh/id_rsa.pub" (or as appropriate) into
>>  "files/root/.ssh/authorized_keys" and indeed, you can collect
>>  keys from several sources this way by concatenating them;
>> 3. Set the permissions on "authorized_keys" to 644 or 640.
>> 
>> Signed-off-by: Philip Prindeville <phil...@redfish-solutions.com>
>> ---
>> net/openssh/Makefile | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>> 
>> diff --git a/net/openssh/Makefile b/net/openssh/Makefile
>> index 
>> 3a19387b0d0110fc5c25d7ffccb524a61c0588c4..7ca61f6ce6d5916016a554b4a283a874e950232c
>>  100644
>> --- a/net/openssh/Makefile
>> +++ b/net/openssh/Makefile
>> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>> 
>> PKG_NAME:=openssh
>> PKG_VERSION:=7.6p1
>> -PKG_RELEASE:=1
>> +PKG_RELEASE:=2
>> 
>> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
>> PKG_SOURCE_URL:=https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/ \
>> @@ -248,7 +248,10 @@ define Package/openssh-server/install
>>$(INSTALL_DIR) $(1)/etc/ssh
>>chmod 0700 $(1)/etc/ssh
>>$(INSTALL_DATA) $(PKG_INSTALL_DIR)/etc/ssh/sshd_config $(1)/etc/ssh/
>> -sed -r -i 's,^#(HostKey 
>> /etc/ssh/ssh_host_(rsa|ecdsa|ed25519)_key),\1,' $(1)/etc/ssh/sshd_config
>> +sed -r -i \
>> +-e 's,^#(HostKey 
>> /etc/ssh/ssh_host_(rsa|ecdsa|ed25519)_key),\1,' \
>> +-e 's,^#PasswordAuthentication yes,PasswordAuthentication no,' \
>> +$(1)/etc/ssh/sshd_config
>>$(INSTALL_DIR) $(1)/etc/init.d
>>$(INSTALL_BIN) ./files/sshd.init $(1)/etc/init.d/sshd
>>$(INSTALL_DIR) $(1)/usr/sbin
>> -- 
>> 2.7.4
>> 
>> 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 0/5] x86: add support for microcode update

[Philip Prindeville]

> On Jan 18, 2018, at 2:15 PM, Hauke Mehrtens  wrote:
> 
> On 01/18/2018 01:51 PM, Nick Lowe wrote:
>> Does an update to the Kernel, 4.9.77 and 4.14.14 need to be made to
>> properly address this? There are fixes to mitigate Spectre.
> 
> We even need a patch for GCC which will be in GCC 8 and 7.3.
> For master we should backport it to GCC 5.5, but what do we want to do
> with 17.01 and 15.05 ?
> 
> The AMD microcoded updater needs at least kernel 4.15, 4.14.13, 4.9.76,
> 4.4.111  which we already have.
> 
> Hauke


For those of us following this from the sidelines (but not too closely), what’s 
the relationship of GCC to microcode updating?

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] base-files: quote values when evaluating uevent

[Philip Prindeville]

LGTM

Been using it here for a few days.


> On Feb 1, 2018, at 5:57 PM, Daniel Golle  wrote:
> 
> When sourcing /sys/class/block/*/uevent values have to be quoted as
> they may contain spaces (e.g. in PARTNAME).
> Fix this by pre-processing with sed before sourcing.
> 
> Signed-off-by: Daniel Golle 
> ---
> package/base-files/files/lib/upgrade/common.sh | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/package/base-files/files/lib/upgrade/common.sh 
> b/package/base-files/files/lib/upgrade/common.sh
> index 71cffc8587..616131c89c 100644
> --- a/package/base-files/files/lib/upgrade/common.sh
> +++ b/package/base-files/files/lib/upgrade/common.sh
> @@ -134,8 +134,7 @@ export_bootdevice() {
>   esac
> 
>   if [ -e "$uevent" ]; then
> - . "$uevent"
> -
> + eval "$(sed "s/=\(.*\)/=\'\1\'/" < "$uevent")"
>   export BOOTDEV_MAJOR=$MAJOR
>   export BOOTDEV_MINOR=$MINOR
>   return 0
> @@ -150,7 +149,7 @@ export_partdevice() {
>   local uevent MAJOR MINOR DEVNAME DEVTYPE
> 
>   for uevent in /sys/class/block/*/uevent; do
> - . "$uevent"
> + eval "$(sed "s/=\(.*\)/=\'\1\'/" < "$uevent")"
>   if [ $BOOTDEV_MAJOR = $MAJOR -a $(($BOOTDEV_MINOR + $offset)) = 
> $MINOR -a -b "/dev/$DEVNAME" ]; then
>   export "$var=$DEVNAME"
>   return 0
> -- 
> 2.16.1
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH v1 1/1] openssh: disable passwords for openssh server

[Philip Prindeville]

From: Philip Prindeville <phil...@redfish-solutions.com>

Allowing password logins leaves you vulnerable to dictionary
attacks.  We disable password-based authentication, limiting
authentication to keys only which are more secure.

Note: You'll need to pre-populate your image with some initial
keys. To do this:

1. Create the appropriate directory as "mkdir -p files/root/.ssh"
   from your top-level directory;
2. Copy your "~/.ssh/id_rsa.pub" (or as appropriate) into
   "files/root/.ssh/authorized_keys" and indeed, you can collect
   keys from several sources this way by concatenating them;
3. Set the permissions on "authorized_keys" to 644 or 640.

Signed-off-by: Philip Prindeville <phil...@redfish-solutions.com>
---
 net/openssh/Makefile | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/net/openssh/Makefile b/net/openssh/Makefile
index 
3a19387b0d0110fc5c25d7ffccb524a61c0588c4..7ca61f6ce6d5916016a554b4a283a874e950232c
 100644
--- a/net/openssh/Makefile
+++ b/net/openssh/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=openssh
 PKG_VERSION:=7.6p1
-PKG_RELEASE:=1
+PKG_RELEASE:=2
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/ \
@@ -248,7 +248,10 @@ define Package/openssh-server/install
$(INSTALL_DIR) $(1)/etc/ssh
chmod 0700 $(1)/etc/ssh
$(INSTALL_DATA) $(PKG_INSTALL_DIR)/etc/ssh/sshd_config $(1)/etc/ssh/
-   sed -r -i 's,^#(HostKey 
/etc/ssh/ssh_host_(rsa|ecdsa|ed25519)_key),\1,' $(1)/etc/ssh/sshd_config
+   sed -r -i \
+   -e 's,^#(HostKey 
/etc/ssh/ssh_host_(rsa|ecdsa|ed25519)_key),\1,' \
+   -e 's,^#PasswordAuthentication yes,PasswordAuthentication no,' \
+   $(1)/etc/ssh/sshd_config
$(INSTALL_DIR) $(1)/etc/init.d
$(INSTALL_BIN) ./files/sshd.init $(1)/etc/init.d/sshd
$(INSTALL_DIR) $(1)/usr/sbin
-- 
2.7.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Adding firewall extensions for xt_geoip usage

[Philip Prindeville]

> On Dec 9, 2017, at 1:33 AM, Arjen de Korte <arjen+l...@de-korte.org> wrote:
> 
> Citeren Philip Prindeville <philipp_s...@redfish-solutions.com>:
> 
>> Jo and others:
>> 
>> Is there an easy way to extend firewall rules?  I’d like to add support to 
>> blocking on a per-country basis, possibly with qualified exceptions.
> 
> Take a look at /etc/firewall.user. Most stuff you want to add fits nicely in 
> there. The comments in that file make the use pretty self explanatory.
> 


Problem is that only people such as ourselves who are comfortable hacking with 
iptables (and optionally ipset and tc, if we’re doing sophisticated 
rate-limiting, etc) could do this.

I’m trying to make it a little easier for the unsophisticated user.

-Philip



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Adding firewall extensions for xt_geoip usage

[Philip Prindeville]

Jo and others:

Is there an easy way to extend firewall rules?  I’d like to add support to 
blocking on a per-country basis, possibly with qualified exceptions.

For instance, if I wanted to block all ISP’s from RU, but allow email from 
Kaspersky’s servers in Russia.

I’d like to do something like:

iptables -A zone_wan_forward -m geoip --src-cc RU -j geoip_RU_forward

ipset create geoip_RU_except_kaspersky_servers ipaddr
ipset add geoip_RU_except_kaspersky_server 81.176.69.118
ipset add geoip_RU_except_kaspersky_server 81.176.230.4
ipset add geoip_RU_except_kaspersky_server 91.103.66.246
ipset add geoip_RU_except_kaspersky_server 91.103.66.248

iptables -N geoip_RU_forward
iptables -A geoip_RU_forward -m set —match-set 
geoip_RU_except_kaspersky_servers test src -p tcp —-dpt 25 -j RETURN
iptables -A geoip_RU_forward -m limit 10/minute —limit-burst 5 -j NFLOG 
—-nflog-prefix “cc RU drop”
iptables -A geoip_RU_forward -j DROP

but come up with a notation for extending /etc/config/firewall to do this.

Maybe:


config rule
option name Block-RU
option country  RU
option src  wan
list except kaspersky_servers
option log  1
option log_limit 10/min
option log_burst 5
option log_prefix “cc RU drop"
option target   drop

config rule
option name kaspersky_servers
option prototcp
option dest_port 25
list src81.176.69.118
list src81.176.230.4
list src91.103.66.246
list src91.103.66.248
option target   ACCEPT


although that’s still a little hairy and having rules refer to each other would 
be new…

Anyone have any ideas about how to do this better?

I’m happy to try to code it and debug it if we can come up with an acceptable 
notation.

Eventually I’d like to also do something with blocking ISPs (hello OVH? 
Cloudflare?), but for now countries would be easier with off-the-shelf stuff 
from xtables-addons.

Thanks,

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] glibc finally fixes /etc/resolv.conf handling

[Philip Prindeville]

Previous email was a little premature, but more news on the subject:

https://sourceware.org/bugzilla/show_bug.cgi?id=984

from what I can tell, MUSL reads the resolv.conf file on every call to 
__lookup_name()… so it shouldn’t have this issue.

Then again, it’s a problem that’s more likely to afflict clients (especially 
roaming WiFi clients) being an LEDE router than LEDE itself.

-Philip



> On Jul 3, 2017, at 2:04 PM, Philip Prindeville 
> <philipp_s...@redfish-solutions.com> wrote:
> 
> For everyone who has ever wondered why they need to stop and restart long 
> running services when they move from one network to another (as is common for 
> laptops using Wifi that are roaming around), this can be quite vexing.
> 
> The reason was that /etc/resolv.conf would get rewritten by DHCP when you 
> acquired a new DHCP lease, but programs which were running wouldn’t have 
> sufficient knowledge to force the resolver to re-initialize itself (and 
> arguably, they shouldn’t have to… it should just work).
> 
> This FINALLY (after many years) got fixed today:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=984
> 
> https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=aef16cc8a4c670036d45590877d411a97f01e0cd
> 
> So, hopefully that will make life easier for people who support their WiFi 
> users and will no longer have to say, “Have you tried stopping and restarting 
> the service?”
> 
> https://www.youtube.com/watch?v=PtXtIivRRKQ
> 
> Woot woot!
> 
> -Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Issues building libunwind for x86_32

[Philip Prindeville]

> On Nov 5, 2017, at 7:55 PM, Yousong Zhou <yszhou4t...@gmail.com> wrote:
> 
> On 6 November 2017 at 06:28, Philip Prindeville
> <philipp_s...@redfish-solutions.com> wrote:
>> I’m seeing the following when trying to build a Geode image:
>> 
>> [snip]
> 
> Hi, I have just pushed a change to disable ssp with libunwind [1].
> That should fix the issue.
> 
> [1] https://git.lede-project.org/f0c37f6ceb10a1db0193d4270c6807c0b2f7a3a0
> 
> Regards,
>yousong


Thanks for fixing that so quickly!

-Philip



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Issues building libunwind for x86_32

[Philip Prindeville]

> On Nov 5, 2017, at 3:28 PM, Philip Prindeville 
> <philipp_s...@redfish-solutions.com> wrote:
> 
> I’m seeing the following when trying to build a Geode image:
> 
> 
> make[6]: Entering directory 
> '/home/philipp/bertram/lede3/build_dir/target-i386_pentium_musl/libunwind-1.2.1/src'
> /bin/bash ../libtool  --tag=CC   --mode=link i486-openwrt-linux-musl-gcc  -Os 
> -pipe -march=pentium-mmx -fno-caller-saves -fno-plt -fhonour-copts 
> -Wno-error=unused-but-set-variable -Wno-error=unused-result 
> -iremap/home/philipp/bertram/lede3/build_dir/target-i386_pentium_musl/libunwind-1.2.1:libunwind-1.2.1
>  -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro  -fexceptions 
> -Wall -Wsign-compare -XCClinker -nostartfiles -XCClinker -nostdlib  
> -version-info 8:1:0 
> -L/home/philipp/bertram/lede3/staging_dir/target-i386_pentium_musl/usr/lib 
> -L/home/philipp/bertram/lede3/staging_dir/target-i386_pentium_musl/lib 
> -L/home/philipp/bertram/lede3/staging_dir/toolchain-i386_pentium_gcc-5.5.0_musl/usr/lib
>  
> -L/home/philipp/bertram/lede3/staging_dir/toolchain-i386_pentium_gcc-5.5.0_musl/lib
>  -znow -zrelro  -o libunwind.la -rpath /usr/lib os-linux.lo mi/init.lo 
> mi/flush_cache.lo mi/mempool.lo mi/strerror.lo x86/is_fpreg.lo x86/regname.lo 
> x86/Los-linux.lo  mi/backtrace.lo mi/dyn-cancel.lo mi/dyn-info-list.lo 
> mi/dyn-register.lo mi/Ldyn-extract.lo mi/Lfind_dynamic_proc_info.lo 
> mi/Lget_accessors.lo mi/Lget_proc_info_by_ip.lo mi/Lget_proc_name.lo 
> mi/Lput_dynamic_unwind_info.lo mi/Ldestroy_addr_space.lo mi/Lget_reg.lo 
> mi/Lset_reg.lo mi/Lget_fpreg.lo mi/Lset_fpreg.lo mi/Lset_caching_policy.lo  
> x86/Lcreate_addr_space.lo x86/Lget_save_loc.lo x86/Lglobal.lo x86/Linit.lo 
> x86/Linit_local.lo x86/Linit_remote.lo x86/Lget_proc_info.lo x86/Lregs.lo 
> x86/Lresume.lo x86/Lstep.lo x86/getcontext-linux.lo libunwind-dwarf-local.la 
> libunwind-elf32.la -lc -lgcc_s  
> OpenWrt-libtool: link: i486-openwrt-linux-musl-gcc -shared  -fPIC -DPIC  
> .libs/os-linux.o mi/.libs/init.o mi/.libs/flush_cache.o mi/.libs/mempool.o 
> mi/.libs/strerror.o x86/.libs/is_fpreg.o x86/.libs/regname.o 
> x86/.libs/Los-linux.o mi/.libs/backtrace.o mi/.libs/dyn-cancel.o 
> mi/.libs/dyn-info-list.o mi/.libs/dyn-register.o mi/.libs/Ldyn-extract.o 
> mi/.libs/Lfind_dynamic_proc_info.o mi/.libs/Lget_accessors.o 
> mi/.libs/Lget_proc_info_by_ip.o mi/.libs/Lget_proc_name.o 
> mi/.libs/Lput_dynamic_unwind_info.o mi/.libs/Ldestroy_addr_space.o 
> mi/.libs/Lget_reg.o mi/.libs/Lset_reg.o mi/.libs/Lget_fpreg.o 
> mi/.libs/Lset_fpreg.o mi/.libs/Lset_caching_policy.o 
> x86/.libs/Lcreate_addr_space.o x86/.libs/Lget_save_loc.o x86/.libs/Lglobal.o 
> x86/.libs/Linit.o x86/.libs/Linit_local.o x86/.libs/Linit_remote.o 
> x86/.libs/Lget_proc_info.o x86/.libs/Lregs.o x86/.libs/Lresume.o 
> x86/.libs/Lstep.o x86/.libs/getcontext-linux.o  -Wl,--whole-archive 
> ./.libs/libunwind-dwarf-local.a ./.libs/libunwind-elf32.a 
> -Wl,--no-whole-archive  
> -L/home/philipp/bertram/lede3/staging_dir/target-i386_pentium_musl/usr/lib 
> -L/home/philipp/bertram/lede3/staging_dir/target-i386_pentium_musl/lib 
> -L/home/philipp/bertram/lede3/staging_dir/toolchain-i386_pentium_gcc-5.5.0_musl/usr/lib
>  
> -L/home/philipp/bertram/lede3/staging_dir/toolchain-i386_pentium_gcc-5.5.0_musl/lib
>  -lc -lgcc_s  -Os -march=pentium-mmx -fstack-protector -Wl,-z -Wl,now -Wl,-z 
> -Wl,relro -nostartfiles -nostdlib   -Wl,-soname -Wl,libunwind.so.8 -o 
> .libs/libunwind.so.8.0.1
> .libs/os-linux.o: In function `_Ux86_get_elf_image':
> os-linux.c:(.text+0x58a): undefined reference to `__stack_chk_fail_local'
> x86/.libs/Lregs.o: In function `_ULx86_access_fpreg':
> Lregs.c:(.text+0x25b): undefined reference to `__stack_chk_fail_local'
> x86/.libs/Lresume.o: In function `_ULx86_resume':
> Lresume.c:(.text+0xdc): undefined reference to `__stack_chk_fail_local'
> collect2: error: ld returned 1 exit status
> Makefile:2582: recipe for target 'libunwind.la' failed
> make[6]: *** [libunwind.la] Error 1
> make[6]: Leaving directory 
> '/home/philipp/bertram/lede3/build_dir/target-i386_pentium_musl/libunwind-1.2.1/src'
> Makefile:1646: recipe for target 'all' failed
> make[5]: *** [all] Error 2
> make[5]: Leaving directory 
> '/home/philipp/bertram/lede3/build_dir/target-i386_pentium_musl/libunwind-1.2.1/src'
> Makefile:594: recipe for target 'all-recursive' failed
> make[4]: *** [all-recursive] Error 1
> make[4]: Leaving directory 
> '/home/philipp/bertram/lede3/build_dir/target-i386_pentium_musl/libunwind-1.2.1'
> Makefile:57: recipe for target 
> '/home/philipp/bertram/lede3/build_dir/target-i386_pentium_musl/libunwind-1.2.1/.built'
>  failed
> make[3]: *** 
> [/home/philipp/bertram/lede3/build_dir/target-i386_pentium_musl/

[LEDE-DEV] Issues building libunwind for x86_32

[Philip Prindeville]

I’m seeing the following when trying to build a Geode image:


make[6]: Entering directory 
'/home/philipp/bertram/lede3/build_dir/target-i386_pentium_musl/libunwind-1.2.1/src'
/bin/bash ../libtool  --tag=CC   --mode=link i486-openwrt-linux-musl-gcc  -Os 
-pipe -march=pentium-mmx -fno-caller-saves -fno-plt -fhonour-copts 
-Wno-error=unused-but-set-variable -Wno-error=unused-result 
-iremap/home/philipp/bertram/lede3/build_dir/target-i386_pentium_musl/libunwind-1.2.1:libunwind-1.2.1
 -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro  -fexceptions 
-Wall -Wsign-compare -XCClinker -nostartfiles -XCClinker -nostdlib  
-version-info 8:1:0   
-L/home/philipp/bertram/lede3/staging_dir/target-i386_pentium_musl/usr/lib 
-L/home/philipp/bertram/lede3/staging_dir/target-i386_pentium_musl/lib 
-L/home/philipp/bertram/lede3/staging_dir/toolchain-i386_pentium_gcc-5.5.0_musl/usr/lib
 
-L/home/philipp/bertram/lede3/staging_dir/toolchain-i386_pentium_gcc-5.5.0_musl/lib
 -znow -zrelro  -o libunwind.la -rpath /usr/lib os-linux.lo mi/init.lo 
mi/flush_cache.lo mi/mempool.lo mi/strerror.lo x86/is_fpreg.lo x86/regname.lo 
x86/Los-linux.lo  mi/backtrace.lo mi/dyn-cancel.lo mi/dyn-info-list.lo 
mi/dyn-register.lo mi/Ldyn-extract.lo mi/Lfind_dynamic_proc_info.lo 
mi/Lget_accessors.lo mi/Lget_proc_info_by_ip.lo mi/Lget_proc_name.lo 
mi/Lput_dynamic_unwind_info.lo mi/Ldestroy_addr_space.lo mi/Lget_reg.lo 
mi/Lset_reg.lo mi/Lget_fpreg.lo mi/Lset_fpreg.lo mi/Lset_caching_policy.lo  
x86/Lcreate_addr_space.lo x86/Lget_save_loc.lo x86/Lglobal.lo x86/Linit.lo 
x86/Linit_local.lo x86/Linit_remote.lo x86/Lget_proc_info.lo x86/Lregs.lo 
x86/Lresume.lo x86/Lstep.lo x86/getcontext-linux.lo libunwind-dwarf-local.la 
libunwind-elf32.la -lc -lgcc_s  
OpenWrt-libtool: link: i486-openwrt-linux-musl-gcc -shared  -fPIC -DPIC  
.libs/os-linux.o mi/.libs/init.o mi/.libs/flush_cache.o mi/.libs/mempool.o 
mi/.libs/strerror.o x86/.libs/is_fpreg.o x86/.libs/regname.o 
x86/.libs/Los-linux.o mi/.libs/backtrace.o mi/.libs/dyn-cancel.o 
mi/.libs/dyn-info-list.o mi/.libs/dyn-register.o mi/.libs/Ldyn-extract.o 
mi/.libs/Lfind_dynamic_proc_info.o mi/.libs/Lget_accessors.o 
mi/.libs/Lget_proc_info_by_ip.o mi/.libs/Lget_proc_name.o 
mi/.libs/Lput_dynamic_unwind_info.o mi/.libs/Ldestroy_addr_space.o 
mi/.libs/Lget_reg.o mi/.libs/Lset_reg.o mi/.libs/Lget_fpreg.o 
mi/.libs/Lset_fpreg.o mi/.libs/Lset_caching_policy.o 
x86/.libs/Lcreate_addr_space.o x86/.libs/Lget_save_loc.o x86/.libs/Lglobal.o 
x86/.libs/Linit.o x86/.libs/Linit_local.o x86/.libs/Linit_remote.o 
x86/.libs/Lget_proc_info.o x86/.libs/Lregs.o x86/.libs/Lresume.o 
x86/.libs/Lstep.o x86/.libs/getcontext-linux.o  -Wl,--whole-archive 
./.libs/libunwind-dwarf-local.a ./.libs/libunwind-elf32.a 
-Wl,--no-whole-archive  
-L/home/philipp/bertram/lede3/staging_dir/target-i386_pentium_musl/usr/lib 
-L/home/philipp/bertram/lede3/staging_dir/target-i386_pentium_musl/lib 
-L/home/philipp/bertram/lede3/staging_dir/toolchain-i386_pentium_gcc-5.5.0_musl/usr/lib
 
-L/home/philipp/bertram/lede3/staging_dir/toolchain-i386_pentium_gcc-5.5.0_musl/lib
 -lc -lgcc_s  -Os -march=pentium-mmx -fstack-protector -Wl,-z -Wl,now -Wl,-z 
-Wl,relro -nostartfiles -nostdlib   -Wl,-soname -Wl,libunwind.so.8 -o 
.libs/libunwind.so.8.0.1
.libs/os-linux.o: In function `_Ux86_get_elf_image':
os-linux.c:(.text+0x58a): undefined reference to `__stack_chk_fail_local'
x86/.libs/Lregs.o: In function `_ULx86_access_fpreg':
Lregs.c:(.text+0x25b): undefined reference to `__stack_chk_fail_local'
x86/.libs/Lresume.o: In function `_ULx86_resume':
Lresume.c:(.text+0xdc): undefined reference to `__stack_chk_fail_local'
collect2: error: ld returned 1 exit status
Makefile:2582: recipe for target 'libunwind.la' failed
make[6]: *** [libunwind.la] Error 1
make[6]: Leaving directory 
'/home/philipp/bertram/lede3/build_dir/target-i386_pentium_musl/libunwind-1.2.1/src'
Makefile:1646: recipe for target 'all' failed
make[5]: *** [all] Error 2
make[5]: Leaving directory 
'/home/philipp/bertram/lede3/build_dir/target-i386_pentium_musl/libunwind-1.2.1/src'
Makefile:594: recipe for target 'all-recursive' failed
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory 
'/home/philipp/bertram/lede3/build_dir/target-i386_pentium_musl/libunwind-1.2.1'
Makefile:57: recipe for target 
'/home/philipp/bertram/lede3/build_dir/target-i386_pentium_musl/libunwind-1.2.1/.built'
 failed
make[3]: *** 
[/home/philipp/bertram/lede3/build_dir/target-i386_pentium_musl/libunwind-1.2.1/.built]
 Error 2
make[3]: Leaving directory '/home/philipp/bertram/lede3/package/libs/libunwind'
package/Makefile:109: recipe for target 'package/libs/libunwind/compile' failed
make[2]: *** [package/libs/libunwind/compile] Error 2
make[2]: Leaving directory '/home/philipp/bertram/lede3'
package/Makefile:105: recipe for target 
'/home/philipp/bertram/lede3/staging_dir/target-i386_pentium_musl/stamp/.package_compile'
 failed
make[1]: *** 

Re: [LEDE-DEV] [PATCH] dropbear: make syslog support configurable

[Philip Prindeville]

> On Nov 4, 2017, at 3:14 AM, Petr Štetiar  wrote:
> 
> Hans Dedecker  [2017-11-03 13:46:14]:
> 
> Hi,
> 
>> By default dropbear logs to syslog which discloses info about account names
>> when doing connection attempts (e.g. "Bad password attempt for 'engineer'
>> from x.x.x.x:y")
> 
> I don't get it, syslog discloses this information to whom and how?
> 
>> As this facilitates brute force attempts against account names;
> 
> So instead of preventing this brute force attempts, you'll just ignore them
> now? I'm wondering how is the brute forcing easier with syslog logging.
> 
>> make syslog support configurable in order not to leak sensitive info via
>> syslog.
> 
> I think, that those are nice warning messages, reminding you, that you're
> doing it wrong:
> 
> 1. You should use pubkey auth.
> 2. You should limit access to your network services.
> 
> -- ynezz



Also a good point: we eliminated this problem by only allowing key-based logins 
and disallowing passwords.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] dropbear: make syslog support configurable

[Philip Prindeville]

NAK, inline:


> On Nov 3, 2017, at 6:46 AM, Hans Dedecker  wrote:
> 
> By default dropbear logs to syslog which discloses info about account names
> when doing connection attempts (e.g. "Bad password attempt for 'engineer' from
> x.x.x.x:y")
> As this facilitates brute force attempts against account names; make syslog
> support configurable in order not to leak sensitive info via syslog.
> 
> Signed-off-by: Hans Dedecker 
> ---
> package/network/services/dropbear/Config.in | 6 ++
> package/network/services/dropbear/Makefile  | 7 ---
> 2 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/package/network/services/dropbear/Config.in 
> b/package/network/services/dropbear/Config.in
> index ca0af9d..95316b9 100644
> --- a/package/network/services/dropbear/Config.in
> +++ b/package/network/services/dropbear/Config.in
> @@ -56,4 +56,10 @@ config DROPBEAR_PUTUTLINE
>   help
>   Dropbear will use pututline() to write the utmp structure into 
> the utmp file.
> 
> +config DROPBEAR_DISABLE_SYSLOG
> + bool "Disable syslog logging"
> + default n
> + help
> + Disables syslog log support; log messages will be redirected to 
> stderr.
> +


Not logging attacks at all is the worst possible option.  See the rational for 
auditing and logging in the NSA’s Red Book.

Better fix is a patch which logs different message contents (i.e. maybe one 
without the user name) based on a command-line option or that just logs this 
message at a different priority (info versus notice, for example) so they could 
be dropped just by raising the log level.

-Philip



> endmenu
> diff --git a/package/network/services/dropbear/Makefile 
> b/package/network/services/dropbear/Makefile
> index 2db2f81..32efa7b 100644
> --- a/package/network/services/dropbear/Makefile
> +++ b/package/network/services/dropbear/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
> 
> PKG_NAME:=dropbear
> PKG_VERSION:=2017.75
> -PKG_RELEASE:=4
> +PKG_RELEASE:=5
> 
> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
> PKG_SOURCE_URL:= \
> @@ -26,7 +26,8 @@ PKG_USE_MIPS16:=0
> PKG_CONFIG_DEPENDS:= \
>   CONFIG_TARGET_INIT_PATH CONFIG_DROPBEAR_ECC \
>   CONFIG_DROPBEAR_CURVE25519 CONFIG_DROPBEAR_ZLIB \
> - CONFIG_DROPBEAR_UTMP CONFIG_DROPBEAR_PUTUTLINE
> + CONFIG_DROPBEAR_UTMP CONFIG_DROPBEAR_PUTUTLINE \
> + CONFIG_DROPBEAR_DISABLE_SYSLOG
> 
> include $(INCLUDE_DIR)/package.mk
> 
> @@ -69,7 +70,7 @@ endef
> CONFIGURE_ARGS += \
>   --disable-pam \
>   --enable-openpty \
> - --enable-syslog \
> + $(if 
> $(CONFIG_DROPBEAR_DISABLE_SYSLOG),--disable-syslog,--enable-syslog) \
>   --disable-lastlog \
>   --disable-utmpx \
>   $(if $(CONFIG_DROPBEAR_UTMP),,--disable-utmp) \
> -- 
> 1.9.1
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v1 1/1] uclient-fetch: correct filename w/ multple URLs

[Philip Prindeville]

> On Nov 2, 2017, at 3:54 PM, Felix Fietkau <n...@nbd.name> wrote:
> 
> On 2017-11-02 22:50, Philip Prindeville wrote:
>> 
>> Okay, great.
>> 
>> When will this show up in LEDE?
> Pushed just now.
> 
> - Felix


Tested and confirmed!


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v1 1/1] uclient-fetch: correct filename w/ multple URLs

[Philip Prindeville]

> On Nov 2, 2017, at 3:03 PM, Felix Fietkau <n...@nbd.name> wrote:
> 
> On 2017-11-02 19:23, Philip Prindeville wrote:
>> From: Philip Prindeville <phil...@redfish-solutions.com>
>> 
>> When uclient-fetch is called with multiple URL's, it derives the
>> first filename based on the URL. When it then handles the 2nd and
>> subsequent URLs, it assumes that it was called with a -O filename
>> argument as the output file, because it tries to overload the
>> variable output_file to mean 2 different things.
>> 
>> The fix is to use a bool to remember whether we were called with
>> an explicit output filename, i.e. with the -O argument, and not
>> overload output_file for this purpose.
>> 
>> Signed-off-by: Philip Prindeville <phil...@redfish-solutions.com>
> Thanks for debugging this. I've decided to fix this with a different
> approach instead. I've pushed a change that avoids the overloading issue
> entirely by renaming the global variable and overwriting a local
> variable only.
> 
> - Felix


Okay, great.

When will this show up in LEDE?

Thanks.


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH v1 1/1] uclient-fetch: correct filename w/ multple URLs

[Philip Prindeville]

From: Philip Prindeville <phil...@redfish-solutions.com>

When uclient-fetch is called with multiple URL's, it derives the
first filename based on the URL. When it then handles the 2nd and
subsequent URLs, it assumes that it was called with a -O filename
argument as the output file, because it tries to overload the
variable output_file to mean 2 different things.

The fix is to use a bool to remember whether we were called with
an explicit output filename, i.e. with the -O argument, and not
overload output_file for this purpose.

Signed-off-by: Philip Prindeville <phil...@redfish-solutions.com>
---
 uclient-fetch.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/uclient-fetch.c b/uclient-fetch.c
index 
dff144b22b7b3cd2d5982a615b9c2d68deab5042..fb3ab45935d94dce4f40aeae9bea6d7f7edc1c37
 100644
--- a/uclient-fetch.c
+++ b/uclient-fetch.c
@@ -51,6 +51,7 @@ static bool proxy = true;
 static bool default_certs = false;
 static bool no_output;
 static const char *output_file;
+static bool saw_output_filename = false;
 static int output_fd = -1;
 static int error_ret;
 static off_t out_offset;
@@ -106,12 +107,12 @@ static int open_output_file(const char *path, uint64_t 
resume_offset)
else
flags = O_WRONLY | O_TRUNC;
 
-   if (!cur_resume && !output_file)
+   if (!cur_resume && !saw_output_filename)
flags |= O_EXCL;
 
flags |= O_CREAT;
 
-   if (output_file) {
+   if (saw_output_filename) {
if (!strcmp(output_file, "-")) {
if (!quiet)
fprintf(stderr, "Writing to stdout\n");
@@ -500,6 +501,16 @@ static int no_ssl(const char *progname)
return 1;
 }
 
+static int too_many_output_files(const char *progname)
+{
+   fprintf(stderr,
+   "%s: the -O output_file option can't be used for multiple "
+   "URLs unless its value is \"-\".\n",
+   progname);
+
+   return 1;
+}
+
 enum {
L_NO_CHECK_CERTIFICATE,
L_CA_CERTIFICATE,
@@ -616,6 +627,7 @@ int main(int argc, char **argv)
break;
case 'O':
output_file = optarg;
+   saw_output_filename = true;
break;
case 'P':
if (chdir(optarg)) {
@@ -651,6 +663,12 @@ int main(int argc, char **argv)
if (argc < 1)
return usage(progname);
 
+   /* doesn't make sense to use -O with multiple URL's unless you're
+* sending them all to stdout...
+*/
+   if (argc > 1 && saw_output_filename && strcmp(output_file, "-"))
+   return too_many_output_files(progname);
+
if (!ssl_ctx) {
for (i = 0; i < argc; i++) {
if (!strncmp(argv[i], "https", 5))
-- 
2.7.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Busybox weirdness

[Philip Prindeville]

> On Nov 2, 2017, at 4:24 AM, edgar.sol...@web.de wrote:
> 
> hey Phillip,
> 
> On 02.11.2017 03:36, Philip Prindeville wrote:
>> Can someone else please try to reproduce this?
> 
> yes, not exactly but wrong resulting file name nonetheless. it's obviously a 
> bug. looks like a variable reuse went awry as it always hit's the second 
> file, having fragments of the first file's name. i switched the files you 
> downloaded, just to test if there might be a server side influence.
> 
> :/tmp# wget 
> http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip 
> http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz
> Downloading 
> 'http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip'
> Connecting to 2400:cb00:2048:1::6810:262f:80
> Writing to 'GeoIPCountryCSV.zip'
> GeoIPCountryCSV.zip  100% |***|  2338k  0:00:00 
> ETA
> Download completed (2394696 bytes)
> Connecting to 2400:cb00:2048:1::6810:252f:80
> Writing to 'w;o▒w;o▒ntryCSV.zip'
> w;o▒w;o▒ntryCSV.zip  100% |***|  1496k  0:00:00 
> ETA
> Download completed (1532219 bytes)
> 
> vs.
> 
> :/tmp# wget http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz 
> http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip
> Downloading 
> 'http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz'
> Connecting to 2400:cb00:2048:1::6810:262f:80
> Writing to 'GeoIPv6.csv.gz'
> GeoIPv6.csv.gz   100% |***|  1496k  0:00:00 
> ETA
> Download completed (1532219 bytes)
> Connecting to 2400:cb00:2048:1::6810:252f:80
> Writing to 'w▒o▒w▒o▒csv.gz'
> w▒o▒w▒o▒csv.gz   100% |***|  2338k  0:00:00 
> ETA
> Download completed (2394696 bytes)
> 
> this is on a Lede 17.01-SNAPSHOT, r3535+35-ee32de4 with '/bin/wget -> 
> uclient-fetch' on an Ubiquiti Loco M2.
> 
> ..ede


Thank you both for looking into this.

I poked around the code last night after sending out that email, and found that 
“output_file” was being overloaded and this was causing some side-effects.

I have a tentative fix which I’ll send out.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Busybox weirdness

[Philip Prindeville]

> On Nov 1, 2017, at 8:36 PM, Philip Prindeville 
> <philipp_s...@redfish-solutions.com> wrote:
> 
> Can someone else please try to reproduce this?
> 
> I’m using busybox’s wget on x86_64 hardware, and when I do a “wget” of 2 
> http: URI’s, it mangles the second URI’s derived filename:
> 
> 
> root@lede:/tmp/x# wget 
> http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz 
> http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip
> Downloading 
> 'http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz'
> Connecting to 104.16.37.47:80
> Writing to 'GeoIPv6.csv.gz'
> GeoIPv6.csv.gz   100% |***|  1496k  0:00:00 
> ETA
> Download completed (1532219 bytes)
> Connecting to 104.16.37.47:80
> Writing to ' z;'
> z;   100% |***|  2338k  0:00:00 ETA
> Download completed (2394696 bytes)
> root@lede:/tmp/x# ls
> z;??  GeoIPv6.csv.gz
> root@lede:/tmp/x# 
> 
> 
> What the heck?
> 
> -Philip


Well, I was selecting busybox’s wget, but it was silently being overwritten by 
something else:

root@lede:/tmp/x# ls -l /bin/wget
lrwxrwxrwx1 root root13 Nov  1 19:17 /bin/wget -> 
uclient-fetch
root@lede:/tmp/x#

so that’s the real culprit.


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Busybox weirdness

[Philip Prindeville]

Can someone else please try to reproduce this?

I’m using busybox’s wget on x86_64 hardware, and when I do a “wget” of 2 http: 
URI’s, it mangles the second URI’s derived filename:


root@lede:/tmp/x# wget 
http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz 
http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip
Downloading 'http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz'
Connecting to 104.16.37.47:80
Writing to 'GeoIPv6.csv.gz'
GeoIPv6.csv.gz   100% |***|  1496k  0:00:00 ETA
Download completed (1532219 bytes)
Connecting to 104.16.37.47:80
Writing to ' z;'
 z;   100% |***|  2338k  0:00:00 ETA
Download completed (2394696 bytes)
root@lede:/tmp/x# ls
 z;??  GeoIPv6.csv.gz
root@lede:/tmp/x# 


What the heck?

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] kernel 4.9 migration for next release

[Philip Prindeville]

> On Oct 3, 2017, at 3:27 AM, Stijn Tintel  wrote:
> 
> On 03-10-17 03:31, David Lang wrote:
>> note that the kernel currently under development (4.14) is tagged to
>> be a LTS kernel (6 years of support), so it would be good to work on
>> that if possible.
> I would prefer to have a release based on 4.9 first. Many targets have
> already received extensive testing with 4.9 by users running master.
> Targetting a new kernel will delay a new major release too long to my
> liking.
> 
> Stijn


+1

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] [RFC] openssl: update to version 1.1.0f

[Philip Prindeville]

Inline…

> On Oct 31, 2017, at 3:56 AM, Baptiste Jonglez  
> wrote:
> 
> From: Baptiste Jonglez 
> 
> This patch is marked [RFC] because this is such a huge change, and some
> dependent packages now fail to build because of API changes.  Also, there
> is no parallel build for now, but this was already the case with 1.0.2l.
> Feedback is welcome!
> 
> Here is a summary of the changes:
> 
> 1) complete overhaul of the upstream build system, which allowed to remove
>   most local patches;
> 
> 2) upstream removal of KRB5, SSL2, JPAKE;
> 
> 3) upstream addition of BLAKE2, CHACHA20, POLY1305, OCB (disabled by
>   default in the package but configurable);
> 
> 4) clean-up configuration of optional features: in OpenSSL, some options
>   are enabled by default, while some are disabled by default.  As a
>   result, the package now explicitely enables or disables each optional
>   feature;


Yes, good idea.  If the upstream defaults change, we wouldn’t need to change 
our Makefiles if we continue to explicitly configure everything.


> 
> 5) new upstream async mode, primarily used for crypto engines.  It is
>   disabled in the package because musl does not seem to implement
>   getcontext/setcontext (see 52739e40ccc1b16cd966ea204bcfea3cc874fec8
>   upstream);
> 
> 6) a patch fixing build on Aarch64 has been added and sent upstream
>   https://github.com/openssl/openssl/pull/4617


I’d also note that some of the compatibility stuff has been deprecated, hasn’t 
it?


> 
> Here is the size increase for libopenssl.ipk compared to 1.0.2l, first
> 1.1.0f with default options and then 1.1.0f with all new options¹:
> 
> | Architecture  | 1.0.2l  | 1.1.0f  | 1.1.0f   |
> |   | Default | Default | All new options¹ |
> |---+-+-+--|
> | aarch64_cortex-a53| 634K| 831K| 844K |
> | aarch64_generic   | 628K| 662K| 672K |
> | arc_arc700| 573K| 610K| 621K |
> | arc_archs | 570K| 605K| 613K |
> | arm_arm1176jzf-s_vfp  | 631K| 823K| 833K |
> | arm_arm926ej-s| 631K| 824K| 835K |
> | arm_cortex-a15_neon-vfpv4 | 638K| 831K| 843K |
> | arm_cortex-a5 | 639K| 832K| 843K |
> | arm_cortex-a7_neon-vfpv4  | 638K| 830K| 843K |
> | arm_cortex-a8_vfpv3   | 639K| 831K| 843K |
> | armeb_xscale  | 639K| 834K| 844K |
> | arm_fa526 | 638K| 831K| 841K |
> | i386_pentium4 | 784K| 822K| 834K |
> | i386_pentium  | 795K| 832K| 842K |
> | mips_24kc | 701K| 742K| 755K |
> | mips64el_mips64   | 674K| 710K| 719K |
> | mips64_mips64 | 689K| 725K| 734K |
> | mipsel_24kc   | 688K| 728K| 740K |
> | mipsel_74kc   | 693K| 735K| 747K |
> | mipsel_mips32 | 691K| 731K| 744K |
> | mips_mips32   | 701K| 744K| 757K |
> | powerpc_464fp | 664K| 703K| 714K |
> | powerpc_8540  | 672K| 712K| 723K |
> | x86_64| 949K| 986K| 1002K|
> 
> ¹ All new options:
> CONFIG_OPENSSL_WITH_BLAKE2=y
> CONFIG_OPENSSL_WITH_CHACHA20=y
> CONFIG_OPENSSL_WITH_POLY1305=y
> CONFIG_OPENSSL_WITH_OCB=y
> ---
> package/libs/openssl/Config.in |  20 +++
> package/libs/openssl/Makefile  | 110 +++-
> ...g-Use-eventfd2-syscall-instead-of-eventfd.patch |  48 ++
> .../openssl/patches/110-optimize-for-size.patch|  43 +++--
> package/libs/openssl/patches/130-perl-path.patch   |  64 ---
> .../libs/openssl/patches/140-makefile-dirs.patch   |  11 --
> package/libs/openssl/patches/150-no_engines.patch  |  81 -
> .../openssl/patches/160-disable_doc_tests.patch|  58 ---
> package/libs/openssl/patches/170-bash_path.patch   |   8 -
> .../openssl/patches/180-fix_link_segfault.patch|  18 --
> .../patches/190-remove_timestamp_check.patch   |  23 ---
> .../libs/openssl/patches/200-parallel_build.patch  | 184 -
> 12 files changed, 168 insertions(+), 500 deletions(-)
> create mode 100644 
> package/libs/openssl/patches/0001-afalg-Use-eventfd2-syscall-instead-of-eventfd.patch
> delete mode 100644 package/libs/openssl/patches/130-perl-path.patch
> delete mode 100644 package/libs/openssl/patches/140-makefile-dirs.patch
> delete mode 100644 package/libs/openssl/patches/150-no_engines.patch
> delete mode 100644 

Re: [LEDE-DEV] [PATCH 1/9] hwmon-coretemp: add thermal monitor for Core/Core2/Atom

[Philip Prindeville]

> On Oct 22, 2017, at 11:57 PM, Felix Fietkau <n...@nbd.name> wrote:
> 
> On 2017-10-23 05:50, Yousong Zhou wrote:
>> On 23 October 2017 at 04:21, Zoltan HERPAI <wigy...@uid0.hu> wrote:
>>> From: Philip Prindeville <phil...@redfish-solutions.com>
>>> 
>>> Signed-off-by: Philip Prindeville <phil...@redfish-solutions.com>
>>> ---
>>> package/kernel/linux/modules/hwmon.mk | 15 +++
>>> 1 file changed, 15 insertions(+)
>>> 
>>> diff --git a/package/kernel/linux/modules/hwmon.mk 
>>> b/package/kernel/linux/modules/hwmon.mk
>>> index ed05cae..ae1a004 100644
>>> --- a/package/kernel/linux/modules/hwmon.mk
>>> +++ b/package/kernel/linux/modules/hwmon.mk
>>> @@ -108,6 +108,21 @@ endef
>>> $(eval $(call KernelPackage,hwmon-nct6775))
>>> 
>>> 
>>> +define KernelPackage/hwmon-coretemp
>>> +  TITLE:=Intel Core/Core2/Atom thermal monitoring support
>>> +  KCONFIG:=CONFIG_SENSORS_CORETEMP
>>> +  FILES:=$(LINUX_DIR)/drivers/hwmon/coretemp.ko
>>> +  AUTOLOAD:=$(call AutoProbe,coretemp)
>>> +  $(call AddDepends/hwmon,@TARGET_x86)
>>> +endef
>>> +
>>> +define KernelPackage/hwmon-coretemp/description
>>> + Kernel module for Intel Core/Core2/Atom thermal monitor chip
>>> +endef
>>> +
>>> +$(eval $(call KernelPackage,hwmon-coretemp))
>>> +
>>> +
>> 
>> This module is already builtin for x86/64 subtarget.  And since it's a
>> target-specific module, maybe we should move this to x86/modules.mk
> I don't think we should have this as a module at all. If this is needed
> for x86/generic as well, simply enable it in the kernel config there.
> 
> - Felix


And indeed, that’s why I closed PR #1470 and opened #1471 instead:

https://github.com/lede-project/source/pull/1471

if we’re all agreed this is the way to go, can someone please merge it?

Thanks,

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] merge: add OpenWrt branding

[Philip Prindeville]

Hi all,

Does it seem to anyone else that we’re making this more complicated than it 
needs to be?

If one of the goals we’re going for from here on out is “equality”, then a 
basic litmus test to be applied to any action might be “does this get us closer 
to a level playing field, or further away”?

Since not everyone gets an @openwrt.org email address, I think the answer to 
“can we use @openwrt.org email addresses in SOB’s?” is by extension, “no, 
because it doesn’t get us closer to a level playing field."

We don’t need to argue the finer points of the letter of the law if the spirit 
of the law is already adequately clear.

-Philip


> On Oct 28, 2017, at 10:56 AM, p...@oranjevos.nl wrote:
> 
> Dear Florian,
> 
> Seems the discussion that was raised on using a personal openwrt address in a 
> SOB does not do much good so far and it is certainly not my intention to go 
> against rule #12; I would be sorry if I did. The question I raised is, 
> although about personal addresses, absolutely not aimed at anyone personally.
> 
> Your thorough reading of the rules makes sense: the future tense of rule #10 
> might be interpreted as to mean that existing addresses are exempted. But the 
> principal reason, equality, mentioned in that very same rule for not offering 
> (new) accounts under the openwrt domain, is by its sheer nature not 
> restricted to the future. The wording in the remerge rules tries to leave 
> some fair lapse for existing accounts, but using that space to the (maximum) 
> extend that a strict reading of the words would allow, does not seem right. 
> Usage for the purpose of (still) receiving mail is reasonable, using it 
> actively for sending mail is ... more complicated.
> 
> On your question whether I purposely did not mention the restriction on 
> adherence to trademark policy and FOSS purpose, the answer is simple: it did 
> not seem relevant in this case (there is no reason to believe that the SOB 
> violated that rule).
> 
> I do not think this issue warrants much more discussion as most that's 
> relevant has probably been said and the relevance is relative.
> It's up to you guys to decide want you want, to weight the odds, regards from 
> a by-stander,
> Paul


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Testing ARM images

[Philip Prindeville]

> On Oct 25, 2017, at 8:32 PM, Yousong Zhou <yszhou4t...@gmail.com> wrote:
> 
> On 26 October 2017 at 08:08, Philip Prindeville
> <philipp_s...@redfish-solutions.com> wrote:
>> Hi.
>> 
>> I was recently working on updating Perl 5.26.1 which required making 
>> machine-specific parameters for cross-builds (because Perl doesn’t use 
>> autoconf), and was able to test for x86_64 on KVM/libvirt, but have not 
>> tried any other platforms (well, I built armvirt but haven’t run anything in 
>> a Qemu emulator).
>> 
>> Can someone please update the Wiki to include:
>> 
>> (1) what parameters to set when building a LEDE image like 
>> CONFIG_TARGET_, CONFIG_TARGET_BOARD, CONFIG_ARCH, etc.
> 
> I got two defconfigs for malta and armvirt at github
> 
> - https://github.com/yousong/gists/blob/master/lede/defconfig/malta-mini-be
> - https://github.com/yousong/gists/blob/master/lede/defconfig/armvirt-mini
> 
>> 
>> (2) also image parameters
>> 
>> (3) how to provision the VM itself, perhaps including the XML for 
>> virsh/libvirt.
>> 
> 
> scripts/qemustart can serve as a quickstart guide on running in QEMU machine.
> 
> Regards,
>yousong


Thanks.  Was hoping for a .xml template for “virsh” that I could use with 
“virsh define my_arm.xml” to provision.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Need review of Perl bump to 5.26.1

[Philip Prindeville]

Heads up that Perl has been updated to 5.26.1.  Please notify me of any ensuing 
related issues.

Thanks


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Testing ARM images

[Philip Prindeville]

Hi.

I was recently working on updating Perl 5.26.1 which required making 
machine-specific parameters for cross-builds (because Perl doesn’t use 
autoconf), and was able to test for x86_64 on KVM/libvirt, but have not tried 
any other platforms (well, I built armvirt but haven’t run anything in a Qemu 
emulator).

Can someone please update the Wiki to include:

(1) what parameters to set when building a LEDE image like CONFIG_TARGET_, 
CONFIG_TARGET_BOARD, CONFIG_ARCH, etc.

(2) also image parameters

(3) how to provision the VM itself, perhaps including the XML for virsh/libvirt.

Thanks,

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Need review of Perl bump to 5.26.1 (urgent)

[Philip Prindeville]

> On Oct 17, 2017, at 4:36 PM, Philip Prindeville 
> <philipp_s...@redfish-solutions.com> wrote:
> 
> [snip]
> 
> Since there ARE known and remedied CVE’s, I’d like to move quickly on this.
> 


I should have qualified that.  I’m going to commit 48 hours after sending out 
that last email unless anyone objects.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Need review of Perl bump to 5.26.1

[Philip Prindeville]

Hi.

We’re currently at Perl 5.24.1 but there are some known CVE’s in that version.  
5.26.1 was recently released with fixes.

New architecture specific parameters were added with 5.26.1 to the 
configuration, as well as a couple of new functions which (as best I can tell), 
both MUSL and glibc either both offer or both don’t offer... so that simplified 
that a bit.

The changes are straightforward.

https://github.com/openwrt/packages/pull/4956

I opportunistically tried to get rid of some noise from rules trying to remove 
targets which hadn’t been built yet when trying to (re)build those targets.  
That’s a self-contained patch and replaces:

-@rm -f xyzzy

with:

@$(RMS) xyzzy

where:

RMS:=rm -f

is a pre-existing macro.  I added a similar macro for when “rm -rf” is being 
done.

Not strictly necessary but it gets rid of noise to stderr and rules failing 
(Ignored).

Since there ARE known and remedied CVE’s, I’d like to move quickly on this.

Can anyone pull my patch and try it?  I’ve tested it for x86_64 but all other 
targets (including i486) need testing.

Or, just eyeballing the PR and reviewing it would be good, too.

Thanks,

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] openwrt/packages

[Philip Prindeville]

> On Oct 10, 2017, at 3:44 PM, Val Kulkov  wrote:
> 
> What is the most appropriate forum for discussing issues related to
> the community management of openwrt/packages?
> 
> Unless I am missing something, there is no forum, no wiki nor any
> other place for discussing openwrt/packages other than the "Issues"
> section at Github which is dedicated to discussing technical issues
> with particular packages.
> 
> The reason I am asking is that IMO there is quite a bit of easily
> avoidable digital rot at openwrt/packages. I would like to offer my
> thoughts to those who are in charge of openwrt/packages, but I don't
> know who they are and how to reach them.



For most packages, look at the PKG_MAINTAINER in the Makefile.

If there isn’t one, look at the git commit log.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Available for consulting services/contracting

[Philip Prindeville]

Hi all,

I’m available for LEDE/OpenWrt contracting work (platform bring-up, adding new 
packages, porting applications to the LEDE environment, customization, etc) if 
there’s such a need.

I’m on LinkedIn: https://www.linkedin.com/in/philipprindeville/ and GitHub as 
pprindeville, of course.

Please contact me out-of-band.

Thanks,

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Update to util-linux 2.30.1 breaks x86_64 squashfs-combined

[Philip Prindeville]

> On Sep 29, 2017, at 7:18 PM, Florian Fainelli <f.faine...@gmail.com> wrote:
> 
> 
> 
> On 09/29/2017 06:01 PM, Philip Prindeville wrote:
>> 
>> [snip]
>> Tested on x86_64.  Seems to work.
> 
> To avoid patching mored packages in the future, would it make sense to
> LD_PRELOAD a library which overrides the SYS_getrandom() with a non
> blocking version/early return at appropriate times during system
> boot/upgrades which would suffer from low entropy?
> -- 
> Florian


That’s the stuff that security exploits are made of.

-Philip



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 1/3] Remove ttl==255 restriction for queries

[Philip Prindeville]

> On Sep 29, 2017, at 3:49 AM, Matthias May <matthias@neratec.com> wrote:
> 
> The link from Philip Prindeville shows quite well why this removal was 
> required:
> [quote]
> check-response-ttl= Takes a boolean value ("yes" or "no"). If set to "yes", 
> an additional security check is activated:
> incoming IP packets will be ignored unless the IP TTL is 255. Earlier mDNS 
> specifications required this check. Since
> this feature may be incompatible with newer implementations of mDNS it 
> defaults to "no". On the other hand it provides
> extra security.
> [/quote]


Not actually my quote.

I think it was Christian.



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Update to util-linux 2.30.1 breaks x86_64 squashfs-combined

[Philip Prindeville]

> On Sep 29, 2017, at 4:39 AM, Felix Fietkau <n...@nbd.name> wrote:
> 
> On 2017-09-29 12:20, Felix Fietkau wrote:
>> On 2017-09-11 02:33, Philip Prindeville wrote:
>>> Changing the subject from the previous thread as it turned out to not have 
>>> to do with sysupgrade at all.
>>> 
>>> What I can tell is this, having added some tracing to fstools.
>>> 
>>> We get to the call to system() in rootdisk_volume_init():
>>> 
>>> https://git.lede-project.org/?p=project/fstools.git;a=blob;f=libfstools/rootdisk.c;h=dd00c1b4e5b4aa9b748610fa3e93d301a67101a7;hb=HEAD#l269
>>> 
>>> and it never seems to return.  The value of “str” is “mkfs.f2fs -q -l 
>>> rootfs_data /dev/loop0”.
>>> 
>>> What would cause this to hang rather than return an error?
>> I've used sysrq to trace this and found out that it's hanging in the
>> getrandom system call, which could be used through util-linux library
>> code. That also explains why the update broke it.
>> 
>> I will prepare a patch that forces util-linux to stick to /dev/urandom
>> instead - that should hopefully fix this for good.
> Pushed the fix, please test.
> 
> - Felix


Tested on x86_64.  Seems to work.

Thanks!


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH netifd] system-linux: add support for hotplug event 'move'

[Philip Prindeville]

Inline…


> On Sep 28, 2017, at 2:32 AM, Martin Schiller  wrote:
> 
> If you rename a network interface, there is a move uevent
> invoked instead of remove/add.
> 
> This patch adds support for this kind of event.
> 
> Signed-off-by: Martin Schiller 
> ---
> system-linux.c | 31 ---
> 1 file changed, 28 insertions(+), 3 deletions(-)
> 
> diff --git a/system-linux.c b/system-linux.c
> index 6d97a02..e2017d0 100644
> --- a/system-linux.c
> +++ b/system-linux.c
> @@ -543,16 +543,20 @@ out:
> static void
> handle_hotplug_msg(char *data, int size)
> {
> - const char *subsystem = NULL, *interface = NULL;
> + const char *subsystem = NULL, *interface = NULL, *interface_old = NULL;
>   char *cur, *end, *sep;
>   struct device *dev;
>   int skip;
> - bool add;
> + bool add, move = false;
> 
>   if (!strncmp(data, "add@", 4))
>   add = true;
>   else if (!strncmp(data, "remove@", 7))
>   add = false;
> + else if (!strncmp(data, "move@", 5)) {
> + add = true;
> + move = true;
> + }
>   else
>   return;
> 
> @@ -574,11 +578,32 @@ handle_hotplug_msg(char *data, int size)
>   if (strcmp(subsystem, "net") != 0)
>   return;
>   }
> - if (subsystem && interface)
> + else if (!strcmp(cur, "DEVPATH_OLD")) {
> + interface_old = strrchr(sep + 1, '/');
> + if (interface_old)
> + interface_old++;
> + }
> + }
> +
> + if (subsystem && interface) {
> + if (move && interface_old)
> + goto move;
> + else
>   goto found;
>   }
> +
>   return;
> 
> +move:
> + dev = device_find(interface_old);
> + if (!dev)
> + goto found;
> +
> + if (dev->type != _device_type)
> + goto found;
> +
> + device_set_present(dev, false);
> +
> found:
>   dev = device_find(interface);
>   if (!dev)
> 


I’m a little unclear about how all of this would work.

We have a platform where the kernel always detects certain devices (mostly i210 
and i350 Intel NICs) in the wrong order, so early on (S19) we run an init.d 
script which looks at their PCI bus information and then depending on whether 
it matches the pattern of the devices which get mis-numbered, we do the 
following:

ip link set eth0 name _eth0
ip link set eth1 name _eth1
...
ip link set eth7 name _eth7

ip link set _eth7 name eth0
ip link set _eth6 name eth1
...
ip link set _eth0 name eth7

so it seems to me that your logic would get confused by the “old” instance of 
“eth0” and the new one.

Am I missing anything?

And yes, we do this as a work-around to not having udev rules to handle the 
naming for us.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Updating Perl to 5.26.1

[Philip Prindeville]

> On Sep 28, 2017, at 4:04 PM, Russell Senior <russ...@personaltelco.net> wrote:
> 
>>>>>> "Philip" == Philip Prindeville <philipp_s...@redfish-solutions.com> 
>>>>>> writes:
> 
> Philip> Hi.  I’m trying to update Perl from 5.24.1 to 5.26.1 but running
> Philip> into some issues.
> 
> Philip> We don’t use ./Configure to build the target versions (just the
> Philip> host version), so when new settings are added, we need to figure
> Philip> out what they are… and what the appropriate settings are for all
> Philip> processors.
> 
> Philip> And word is from upstream that 5.28.1 will have even more stuff
> Philip> that we need to add to get it to build.
> 
> Philip> Wondering if there isn’t an easier way to figure out
> Philip> automatically what those settings should be.
> 
> Philip> Obviously we can’t compile and run for other platforms, but we
> Philip> can compile and extract information from those images (with
> Philip> objdump, nm, etc).
> 
> Philip> A lot of the tests that get run during Configure (grep ‘$run
> Philip> ./try’ Configure) are run just to dump out information about the
> Philip> result of compilation… most of which could also be extracted
> Philip> just by examining the generated object (such as with objdump
> Philip> -d).
> 
> Philip> Anyone have any suggestions for things we can try to make
> Philip> ./Configure work for cross-compiles as well?
> 
> Philip> Because doing version updates seems to involve a fair amount of
> Philip> guesswork about what the correct values are for a whole gamut of
> Philip> platforms, and this seems error-prone.
> 
> A long time ago, I tracked down a bug in the perl builds on a brcm47xx
> device by installing a native toolchain in an nfs-mounted rootfs and,
> over about 24 hours, running the auto configuration script on the target
> device.
> 
> I have no idea if the situation has improved since then, maybe 10 years
> ago.
> 


That sounds about as fun as spinning up a Qemu in the makefile and running 
configure inside that…

-Philip



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Updating Perl to 5.26.1

[Philip Prindeville]

Hi.

I’m trying to update Perl from 5.24.1 to 5.26.1 but running into some issues.

We don’t use ./Configure to build the target versions (just the host version), 
so when new settings are added, we need to figure out what they are… and what 
the appropriate settings are for all processors.

And word is from upstream that 5.28.1 will have even more stuff that we need to 
add to get it to build.

Wondering if there isn’t an easier way to figure out automatically what those 
settings should be.

Obviously we can’t compile and run for other platforms, but we can compile and 
extract information from those images (with objdump, nm, etc).

A lot of the tests that get run during Configure (grep ‘$run ./try’ Configure) 
are run just to dump out information about the result of compilation… most of 
which could also be extracted just by examining the generated object (such as 
with objdump -d).

Anyone have any suggestions for things we can try to make ./Configure work for 
cross-compiles as well?

Because doing version updates seems to involve a fair amount of guesswork about 
what the correct values are for a whole gamut of platforms, and this seems 
error-prone.

Thanks,

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 1/3] Remove ttl==255 restriction for queries

[Philip Prindeville]

> On Sep 28, 2017, at 2:32 PM, Christian Lamparter <chunk...@googlemail.com> 
> wrote:
> 
>> On Thursday, September 28, 2017 1:36:52 PM CEST Philip Prindeville wrote:
>> Why was this test there and equally why are we removing it?
> I guess it was there so umdns would ignore any forwarded mdns?
> This would stop two mDNS reflectors to ping-pong each other. 
> The avahi-daemon manpages speaks about this in:
> 
> <https://manpages.debian.org/jessie/avahi-daemon/avahi-daemon.conf.5.en.html#SECTION_%5BREFLECTOR%5D>

So why remove it in that case?


> 
> Regards,
> Christian
> 
>> 
>>> On Sep 28, 2017, at 1:09 AM, Philipp Meier <philipp.me...@neratec.com> 
>>> wrote:
>>> 
>>> Signed-off-by: Philipp Meier <philipp.me...@neratec.com>
>>> ---
>>> interface.c | 6 --
>>> 1 file changed, 6 deletions(-)
>>> 
>>> diff --git a/interface.c b/interface.c
>>> index 3904c89..7f814d2 100644
>>> --- a/interface.c
>>> +++ b/interface.c
>>> @@ -233,9 +233,6 @@ read_socket4(struct uloop_fd *u, unsigned int events)
>>>   }
>>>   }
>>> 
>>> -if (ttl != 255)
>>> -return;
>>> -
>>>   if (debug > 1) {
>>>   char buf[256];
>>> 
>>> @@ -310,9 +307,6 @@ read_socket6(struct uloop_fd *u, unsigned int events)
>>>   }
>>>   }
>>> 
>>> -if (ttl != 255)
>>> -return;
>>> -
>>>   if (debug > 1) {
>>>   char buf[256];
>>> 
>> 
>> 
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>> 
> 
> 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 1/3] Remove ttl==255 restriction for queries

[Philip Prindeville]

Why was this test there and equally why are we removing it?

> On Sep 28, 2017, at 1:09 AM, Philipp Meier  wrote:
> 
> Signed-off-by: Philipp Meier 
> ---
> interface.c | 6 --
> 1 file changed, 6 deletions(-)
> 
> diff --git a/interface.c b/interface.c
> index 3904c89..7f814d2 100644
> --- a/interface.c
> +++ b/interface.c
> @@ -233,9 +233,6 @@ read_socket4(struct uloop_fd *u, unsigned int events)
>}
>}
> 
> -if (ttl != 255)
> -return;
> -
>if (debug > 1) {
>char buf[256];
> 
> @@ -310,9 +307,6 @@ read_socket6(struct uloop_fd *u, unsigned int events)
>}
>}
> 
> -if (ttl != 255)
> -return;
> -
>if (debug > 1) {
>char buf[256];
> 
> -- 
> 2.7.4
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 3/3] Add debug output for service_timeout

[Philip Prindeville]

Inline

Sent from my iPhone
> On Sep 28, 2017, at 1:09 AM, Philipp Meier  wrote:
> 
> Signed-off-by: Philipp Meier 
> ---
> service.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/service.c b/service.c
> index 0a9e25d..97b6f91 100644
> --- a/service.c
> +++ b/service.c
> @@ -121,8 +121,10 @@ service_timeout(struct service *s)
> {
>time_t t = monotonic_time();
> 
> -if (t - s->t <= TOUT_LOOKUP)
> +if (t - s->t <= TOUT_LOOKUP) {
> +DBG(2, "t=%lu, s->t=%lu, t - s->t = %lu\n", t, s->t, t - s->t);

Do you need to write "t - s->t" or would "elapsed", "remaining", or even 
"delta" be more descriptive?


>return 0;
> +}
> 
>return t;
> }
> -- 
> 2.7.4
> 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] x86 sysupgrade: preserve partition table

[Philip Prindeville]

That’s what the -p flag to sysupgrade is for.

Also, there’s not much point in resizing the rootdisk partition: even applying 
several upgrades and maybe adding some new packages, the amount of used space 
isn’t going to grow significantly.

You’re better off creating a 3rd EXT4 partition as /var or something like that. 
 Logs and collectd information are what grow the most.




> On Sep 14, 2017, at 4:21 AM, Nishant Sharma  wrote:
> 
> Hi,
> 
> I am using Lede 17.01.2 on PCEngines APU2. In order to utilise full 16GB SSD, 
> I resize the partition after "dd"-ing the Lede image to it.
> 
> On sysupgrade, the partition table is re-written and "/" partition is back to 
> 256 MB.
> 
> Is there a way the existing partition table or at least "/" partition size 
> could be preserved?
> 
> Thanks in advance.
> 
> Regards,
> Nishant


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Starting logging earlier

[Philip Prindeville]

I was wondering why the loggers (except ubox) are all started as priority 20 
(same as “network”):

$ grep START= package/system/ubox/files/log.init 
feeds/packages/net/ulogd/files/ulogd.init 
feeds/packages/net/rsyslog/files/rsyslog.init 
feeds/packages/admin/syslog-ng/files/syslog-ng.init 
package/system/ubox/files/log.init:START=12
feeds/packages/net/ulogd/files/ulogd.init:START=20
feeds/packages/net/rsyslog/files/rsyslog.init:START=20
feeds/packages/admin/syslog-ng/files/syslog-ng.init:START=20
$ 

seems to me that (a) there’s no dependency on the network service being up 
before the logger starts, since it uses an unbound socket anyway (and hence 
will do the right thing if more interfaces are added, deleted, or otherwise 
changed) and (b) it’s entirely possible that at some point we might want to add 
logging to earlier startup scripts or services, such as S19dhcpd (also started 
before the network comes up)…

I’ve played with starting syslog-ng at level 12 (same as box’s logger) and it 
had no obvious ill-effects.

Anyone see any reason to not proceed with changing it?

Thanks,

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Update to util-linux 2.30.1 breaks x86_64 squashfs-combined

[Philip Prindeville]

Changing the subject from the previous thread as it turned out to not have to 
do with sysupgrade at all.

What I can tell is this, having added some tracing to fstools.

We get to the call to system() in rootdisk_volume_init():

https://git.lede-project.org/?p=project/fstools.git;a=blob;f=libfstools/rootdisk.c;h=dd00c1b4e5b4aa9b748610fa3e93d301a67101a7;hb=HEAD#l269

and it never seems to return.  The value of “str” is “mkfs.f2fs -q -l 
rootfs_data /dev/loop0”.

What would cause this to hang rather than return an error?

Thanks,

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Recent issues w/ sysupgrade

[Philip Prindeville]

> On Sep 5, 2017, at 8:50 PM, Ryan Mounce <r...@mounce.com.au> wrote:
> 
> On 31 August 2017 at 04:11, Philip Prindeville
> <philipp_s...@redfish-solutions.com> wrote:
>> Looking a little further into the console logging, what I’m seeing after a 
>> “dd” directly onto the flash is this:
>> 
>> Press the [f] key and hit [enter] to enter failsafe mode
>> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
>> [6.299598] mount_root: loading kmods from internal overlay
>> [6.307977] kmodloader: loading kernel modules from //etc/modules-boot.d/*
>> [6.316014] kmodloader: done loading kernel modules from 
>> //etc/modules-boot.d/*
>> [6.459868] block: attempting to load /etc/config/fstab
>> [6.472689] block: extroot: not configured
>> [6.488330] mount_root: rootdisk overlay filesystem has not been 
>> formatted yet
>> [6.517993] blk_update_request: I/O error, dev loop0, sector 0
>> [6.724898] block: attempting to load /etc/config/fstab
>> [6.730248] block: extroot: not configured
>> [6.734560] mount_root: overlay filesystem has not been fully initialized 
>> yet
>> [6.741823] mount_root: switching to f2fs overlay
>> 
>> 
>> if I take the exact same image and try to reinstall it with sysupgrade, I 
>> see this:
>> 
>> 
>> Press the [f] key and hit [enter] to enter failsafe mode
>> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
>> [5.319594] mount_root: loading kmods from internal overlay
>> [5.328062] kmodloader: loading kernel modules from //etc/modules-boot.d/*
>> [5.336078] kmodloader: done loading kernel modules from 
>> //etc/modules-boot.d/*
>> [5.480712] block: attempting to load /etc/config/fstab
>> [5.493487] block: extroot: not configured
>> [5.498237] random: procd: uninitialized urandom read (4 bytes read)
>> [5.515173] mount_root: rootdisk overlay filesystem has not been 
>> formatted yet
>> 
>> 
>> it’s tough to reproduce, which makes me wonder if it’s either a race 
>> condition or an uninitialized variable.
> 
> I can consistently reproduce this issue when testing my Turris Omnia
> patch set, hopefully I can help to narrow it down.
> 
> A couple of times interrupting boot into failsafe and then running
> mount_root has fixed things, however more often than not mount_root
> hangs in the same way.
> 
> This appears to have been introduced in the last couple of months so I
> will try to bisect it.


Thanks.

It’s not 100% reproducible which makes it time-consuming to bisect because you 
have to repeat steps a few times.

But I did conclude decisively that it did NOT present before:

5eb216e mediatek: update to latest kernel patchset from v4.13-rc

So you don’t have to search any earlier than that.

It’s in the last 3 weeks.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Recent issues w/ sysupgrade

[Philip Prindeville]

Looking a little further into the console logging, what I’m seeing after a “dd” 
directly onto the flash is this:

Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[6.299598] mount_root: loading kmods from internal overlay
[6.307977] kmodloader: loading kernel modules from //etc/modules-boot.d/*
[6.316014] kmodloader: done loading kernel modules from 
//etc/modules-boot.d/*
[6.459868] block: attempting to load /etc/config/fstab
[6.472689] block: extroot: not configured
[6.488330] mount_root: rootdisk overlay filesystem has not been formatted 
yet
[6.517993] blk_update_request: I/O error, dev loop0, sector 0
[6.724898] block: attempting to load /etc/config/fstab
[6.730248] block: extroot: not configured
[6.734560] mount_root: overlay filesystem has not been fully initialized yet
[6.741823] mount_root: switching to f2fs overlay


if I take the exact same image and try to reinstall it with sysupgrade, I see 
this:


Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[5.319594] mount_root: loading kmods from internal overlay
[5.328062] kmodloader: loading kernel modules from //etc/modules-boot.d/*
[5.336078] kmodloader: done loading kernel modules from 
//etc/modules-boot.d/*
[5.480712] block: attempting to load /etc/config/fstab
[5.493487] block: extroot: not configured
[5.498237] random: procd: uninitialized urandom read (4 bytes read)
[5.515173] mount_root: rootdisk overlay filesystem has not been formatted 
yet


it’s tough to reproduce, which makes me wonder if it’s either a race condition 
or an uninitialized variable.

This was after I rebased to:

2f0a855 lantiq: ACMP252: clean up device modules

What would be significantly different about dd’ing an image onto the CF versus 
the copy that sysupgrade performs?

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Recent issues w/ sysupgrade

[Philip Prindeville]

> On Aug 29, 2017, at 9:16 AM, Philip Prindeville 
> <philipp_s...@redfish-solutions.com> wrote:
> 
>> On Aug 29, 2017, at 1:19 AM, Stijn Tintel <st...@linux-ipv6.be> wrote:
>> 
>>> On 29-08-17 09:09, Philip Prindeville wrote:
>>> Hi all,
>>> 
>>> I don’t know if sysupgrade is the problem, or if this is where things 
>>> manifest.
>>> 
>>> But I recently (within the last week, but I only rebase once or twice a 
>>> week) started seeing issues with doing sysupgrade on x86_64 hardware.
>>> 
>>> The sysupgrade will appear to go okay, but then when the machine reboots, I 
>>> see:
>>> 
>>> ...
>>> Press the [f] key and hit [enter] to enter failsafe mode
>>> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
>>> [6.322701] mount_root: loading kmods from internal overlay
>>> [6.331183] kmodloader: loading kernel modules from 
>>> //etc/modules-boot.d/*
>>> [6.339194] kmodloader: done loading kernel modules from 
>>> //etc/modules-boot.d/*
>>> [6.470650] block: attempting to load /etc/config/fstab
>>> [6.483431] block: extroot: not configured
>>> [6.488267] random: procd: uninitialized urandom read (4 bytes read)
>>> [6.506070] mount_root: rootdisk overlay filesystem has not been 
>>> formatted yet
>>> 
>>> 
>>> Is this related to the mk.f2f changes on Thursday?
>> I doubt this will be related. The only real change is
>> https://git.lede-project.org/cdb494fd, and on little endian systems
>> cpu_to_le64 is a noop. Additionaly I tested this on x86/64 and didn't
>> notice any isses. Just look a bit further and you should see this:
>> 
>> Tue Aug 29 07:12:57 2017 user.info kernel: [5.607837] mount_root:
>> overlay filesystem has not been fully initialized yet
>> Tue Aug 29 07:12:57 2017 user.info kernel: [5.608986] mount_root:
>> switching to f2fs overlay
>> 
>> root@LEDE:~# mount  | grep overlay
>> /dev/loop0 on /overlay type f2fs
>> (rw,lazytime,noatime,background_gc=on,user_xattr,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6)
>> overlayfs:/overlay on / type overlay
>> (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
>> 
>> Stijn
> 
> It never gets to that point.
> 
> The message about it not being formatted is the last output then it hangs.
> 


I do not see that (the “switching to f2fs overlay” message) on the console when 
the hang happens at reboot following a sysupgrade (and sometimes even just 
reflashing the CF card).

I have noted, when sysupgrade runs, I do see:


[  379.758026] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
Upgrade completed
Rebooting system...
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource busy


but I was seeing those before.

So, some progress on the bi-section.

I can rebase to here:

af922c0 mediatek: update to latest kernel patchset from v4.13-rc
3ec259a procd: fix hotplug-preinit.json syntax
1a3b17a procd: fix hotplug.json syntax
a678eb0 ca-certificates: Update to 20170717
8e16e19 imx6: refresh kernel config
c0d5990 imx6: add driver for temp/voltage monitoring
2deed55 uboot-lantiq: Enable TFTP PUT support for backups
47dcfcf gpio-button-hotplug: leave platform_device.dev.platform_data untouched

but then I need to cherry-pick this fix so things will build:

dfee19f mediatek: drop kernel dep on userland module

If I try to rebase any further, to:

e622b30 netifd: update to latest git HEAD

then I see the flakiness at boot time.  John or Felix, are there any changes 
here that would affect booting if the way described above?

-Philip



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Sysupgrade and networking

[Philip Prindeville]

Hi.

I was wondering about why the network interfaces stay up during a sysupgrade.

No services are available, so about all you can do is ping the box or have your 
connections reset if you try to connect to it.

Would it make more sense to bring all network interfaces down?

Worst case scenario is you’re in the middle of an update, and then someone 
sends you a packet-of-death while the update is incomplete… now you’ve got a 
corrupted filesystem.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Recent issues w/ sysupgrade

[Philip Prindeville]

> On Aug 29, 2017, at 1:19 AM, Stijn Tintel <st...@linux-ipv6.be> wrote:
> 
>> On 29-08-17 09:09, Philip Prindeville wrote:
>> Hi all,
>> 
>> I don’t know if sysupgrade is the problem, or if this is where things 
>> manifest.
>> 
>> But I recently (within the last week, but I only rebase once or twice a 
>> week) started seeing issues with doing sysupgrade on x86_64 hardware.
>> 
>> The sysupgrade will appear to go okay, but then when the machine reboots, I 
>> see:
>> 
>> ...
>> Press the [f] key and hit [enter] to enter failsafe mode
>> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
>> [6.322701] mount_root: loading kmods from internal overlay
>> [6.331183] kmodloader: loading kernel modules from //etc/modules-boot.d/*
>> [6.339194] kmodloader: done loading kernel modules from 
>> //etc/modules-boot.d/*
>> [6.470650] block: attempting to load /etc/config/fstab
>> [6.483431] block: extroot: not configured
>> [6.488267] random: procd: uninitialized urandom read (4 bytes read)
>> [6.506070] mount_root: rootdisk overlay filesystem has not been 
>> formatted yet
>> 
>> 
>> Is this related to the mk.f2f changes on Thursday?
> I doubt this will be related. The only real change is
> https://git.lede-project.org/cdb494fd, and on little endian systems
> cpu_to_le64 is a noop. Additionaly I tested this on x86/64 and didn't
> notice any isses. Just look a bit further and you should see this:
> 
> Tue Aug 29 07:12:57 2017 user.info kernel: [5.607837] mount_root:
> overlay filesystem has not been fully initialized yet
> Tue Aug 29 07:12:57 2017 user.info kernel: [5.608986] mount_root:
> switching to f2fs overlay
> 
> root@LEDE:~# mount  | grep overlay
> /dev/loop0 on /overlay type f2fs
> (rw,lazytime,noatime,background_gc=on,user_xattr,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6)
> overlayfs:/overlay on / type overlay
> (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
> 
> Stijn

It never gets to that point.

The message about it not being formatted is the last output then it hangs.



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Recent issues w/ sysupgrade

[Philip Prindeville]

Hi all,

I don’t know if sysupgrade is the problem, or if this is where things manifest.

But I recently (within the last week, but I only rebase once or twice a week) 
started seeing issues with doing sysupgrade on x86_64 hardware.

The sysupgrade will appear to go okay, but then when the machine reboots, I see:

...
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[6.322701] mount_root: loading kmods from internal overlay
[6.331183] kmodloader: loading kernel modules from //etc/modules-boot.d/*
[6.339194] kmodloader: done loading kernel modules from 
//etc/modules-boot.d/*
[6.470650] block: attempting to load /etc/config/fstab
[6.483431] block: extroot: not configured
[6.488267] random: procd: uninitialized urandom read (4 bytes read)
[6.506070] mount_root: rootdisk overlay filesystem has not been formatted 
yet


Is this related to the mk.f2f changes on Thursday?

Or maybe the mkimage fix?

I’ll try resetting my cloning further and further back until I can’t reproduce 
the problem…

That might take me a day or so to isolate.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Strange build error

[Philip Prindeville]

> On Aug 28, 2017, at 6:17 PM, Zoltan Gyarmati  
> wrote:
> 
> On 08/28/2017 01:52 PM, Zoltan Gyarmati wrote:
>> Dear All,
>> 
>> i'm fighting with an odd build error on my build server VPS, using
>> current master and the RT5350F-OLINUXINO profile:
>> 
>> When trying to re-build the LEDE tree (after a successful initial
>> build), i get this error:
>> 
>>> make[5]: Entering directory
>>> '/home/zgyarmati/lede/build_dir/target-mipsel_24kc_musl/linux-ramips_rt305x/linux-4.9.44'
>>>  CHK include/config/kernel.release
>>>  CHK include/generated/uapi/linux/version.h
>>>  CHK include/generated/utsrelease.h
>>>  CHK include/generated/bounds.h
>>>  CHK include/generated/timeconst.h
>>>  CHK include/generated/asm-offsets.h
>>>  CALLscripts/checksyscalls.sh
>>>  CHK include/generated/compile.h
>>>  GEN usr/initramfs_data.cpio
>>>  AS  usr/initramfs_data.o
>>>  LD  usr/built-in.o
>>>  AR  lib/lib.a
>>>  EXPORTS lib/lib-ksyms.o
>>>  LD  lib/built-in.o
>>>  LD  vmlinux.o
>>>  MODPOST vmlinux.o
>>>  GEN .version
>>>  CHK include/generated/compile.h
>>> lib/lib.a(decompress.o):(.init.rodata+0x2c): undefined reference to
>>> `unlzma'
>>> lib/lib.a(decompress.o):(.init.rodata+0x38): undefined reference to
>>> `unlzma'
>>> Makefile:972: recipe for target 'vmlinux' failed
>> The odd thing is that the same config on my laptop (Debian
>> testing/Buster) builds and rebuilds correctly, while on the VPS (Debian
>> 9/Stretch) it fails with the error above.
>> I've checked all the dependencies, digged into the environment to figure
>> out what is the significant difference, but i couldn't hunt this down.
>> My best guess it that is related to the fact that the build server runs
>> on a VPS, but no solid evidence on this yet...
>> 
>> Do you have maybe an idea where to look?
>> 
> 
> I've tried cross check with building and rebuilding Atheros
> AR7xxx/AR9xxx/8devices Carambola2 profle,
> and it builds and rebuilds without the error above in the same
> environment...


I’ll ask the obvious question… Are the .config files identical in both cases?

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] proper protocol for submitting patches that should be upstreamed as well?

[Philip Prindeville]

> On Aug 28, 2017, at 6:15 AM, rpj...@crashcourse.ca wrote:
> 
> do the LEDE admins look for that stuff like that
> and upstream it automatically?


No, as it’s your patch, you need to be the one presenting it so you can answer 
questions about it, make changes if asked to do so, etc.



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Issues with xtables-addons after rebasing today

[Philip Prindeville]

> On Aug 22, 2017, at 1:56 PM, Arjen de Korte <arjen+l...@de-korte.org> wrote:
> 
> Citeren Philip Prindeville <philipp_s...@redfish-solutions.com>:
> 
>> Found the issue, and posted PR #1308 to fix it.  One-line fix.
>> 
>> 
>>> On Aug 19, 2017, at 3:06 PM, Philip Prindeville 
>>> <philipp_s...@redfish-solutions.com> wrote:
>>> 
>>> And it looks like Hannu is way ahead of me:
>>> 
>>> https://bugs.lede-project.org/index.php?do=details_id=969
>>> 
>>> 
>>>> On Aug 19, 2017, at 2:59 PM, Philip Prindeville 
>>>> <philipp_s...@redfish-solutions.com> wrote:
>>>> 
>>>> I rebased about an hour ago and then tried to rebuild everything.  Now I’m 
>>>> seeing what’s below.
>>>> 
>>>> I looked at the commit logs, though, and nothing stands out as a likely 
>>>> culprit… except maybe the bump from 4.9.40 to 4.9.44.
>>>> 
>>>> If I rebase back to
>>>> 
>>>> d9564d7 bcm53xx: backport DTS commits that setup USB LEDs
>>>> 
>>>> then things build again.
>>>> 
>>>> 
>>>> . /home/philipp/bertram/lede/include/shell.sh; export modules=; 
>>>> probe_module() { local mods="$1"; local boot="$2"; local params="$3"; 
>>>> local mod; shift 3; for mod in $mods; do mkdir -p 
>>>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules.d;
>>>>  local mod_params=""; for param in $params; do case $param in $mod.*) 
>>>> mod_params="$mod_params \"${param#$mod.}\""; ;; *.*) ;; *) 
>>>> mod_params="$mod_params \"$param\""; ;; esac; done; echo "$mod$mod_params" 
>>>> >> 
>>>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules.d/ipt-nathelper-rtsp;
>>>>  done; if [ -e 
>>>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules.d/ipt-nathelper-rtsp
>>>>  ]; then if [ "$boot" = "1" -a ! -e 
>>>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules-boot.d/ipt-nathelper-rtsp
>>>>  ]; then mkdir -p 
>>>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules-boot.d;
>>>>  ln -s ../modules.d/ipt-nathelper-rtsp 
>>>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules-boot.d/;
>>>>  fi; modules="${modules:+$modules }$mods"; fi; }; add_module() { local 
>>>> priority="$1"; local mods="$2"; local boot="$3"; local params="$4"; local 
>>>> mod; shift 4; for mod in $mods; do mkdir -p 
>>>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules.d;
>>>>  local mod_params=""; for param in $params; do case $param in $mod.*) 
>>>> mod_params="$mod_params \"${param#$mod.}\""; ;; *.*) ;; *) 
>>>> mod_params="$mod_params \"$param\""; ;; esac; done; echo "$mod$mod_params" 
>>>> >> 
>>>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules.d/$priority-ipt-nathelper-rtsp;
>>>>  done; if [ -e 
>>>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules.d/$priority-ipt-nathelper-rtsp
>>>>  ]; then if [ "$boot" = "1" -a ! -e 
>>>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules-boot.d/$priority-ipt-nathelper-rtsp
>>>>  ]; then mkdir -p 
>>>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules-boot.d;
>>>>  ln -s ../modules.d/$priority-ipt-nathelper-rts

Re: [LEDE-DEV] Issues with xtables-addons after rebasing today

[Philip Prindeville]

Found the issue, and posted PR #1308 to fix it.  One-line fix.


> On Aug 19, 2017, at 3:06 PM, Philip Prindeville 
> <philipp_s...@redfish-solutions.com> wrote:
> 
> And it looks like Hannu is way ahead of me:
> 
> https://bugs.lede-project.org/index.php?do=details_id=969
> 
> 
>> On Aug 19, 2017, at 2:59 PM, Philip Prindeville 
>> <philipp_s...@redfish-solutions.com> wrote:
>> 
>> I rebased about an hour ago and then tried to rebuild everything.  Now I’m 
>> seeing what’s below.
>> 
>> I looked at the commit logs, though, and nothing stands out as a likely 
>> culprit… except maybe the bump from 4.9.40 to 4.9.44.
>> 
>> If I rebase back to
>> 
>> d9564d7 bcm53xx: backport DTS commits that setup USB LEDs
>> 
>> then things build again.
>> 
>> 
>> . /home/philipp/bertram/lede/include/shell.sh; export modules=; 
>> probe_module() { local mods="$1"; local boot="$2"; local params="$3"; local 
>> mod; shift 3; for mod in $mods; do mkdir -p 
>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules.d;
>>  local mod_params=""; for param in $params; do case $param in $mod.*) 
>> mod_params="$mod_params \"${param#$mod.}\""; ;; *.*) ;; *) 
>> mod_params="$mod_params \"$param\""; ;; esac; done; echo "$mod$mod_params" 
>> >> 
>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules.d/ipt-nathelper-rtsp;
>>  done; if [ -e 
>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules.d/ipt-nathelper-rtsp
>>  ]; then if [ "$boot" = "1" -a ! -e 
>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules-boot.d/ipt-nathelper-rtsp
>>  ]; then mkdir -p 
>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules-boot.d;
>>  ln -s ../modules.d/ipt-nathelper-rtsp 
>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules-boot.d/;
>>  fi; modules="${modules:+$modules }$mods"; fi; }; add_module() { local 
>> priority="$1"; local mods="$2"; local boot="$3"; local params="$4"; local 
>> mod; shift 4; for mod in $mods; do mkdir -p 
>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules.d;
>>  local mod_params=""; for param in $params; do case $param in $mod.*) 
>> mod_params="$mod_params \"${param#$mod.}\""; ;; *.*) ;; *) 
>> mod_params="$mod_params \"$param\""; ;; esac; done; echo "$mod$mod_params" 
>> >> 
>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules.d/$priority-ipt-nathelper-rtsp;
>>  done; if [ -e 
>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules.d/$priority-ipt-nathelper-rtsp
>>  ]; then if [ "$boot" = "1" -a ! -e 
>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules-boot.d/$priority-ipt-nathelper-rtsp
>>  ]; then mkdir -p 
>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules-boot.d;
>>  ln -s ../modules.d/$priority-ipt-nathelper-rtsp 
>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp/etc/modules-boot.d/;
>>  fi; modules="${modules:+$modules }$priority-ipt-nathelper-rtsp"; fi; }; 
>> probe_module "nf_conntrack_rtsp nf_nat_rtsp" "" ""; if [ -n "$modules" ]; 
>> then modules="$(echo "$modules" | tr ' ' '\n' | sort | uniq | paste -s -d' ' 
>> -)"; mkdir -p 
>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/xtables-addons-2.12/ipkg-x86_64/kmod-ipt-nathelper-rtsp

Re: [LEDE-DEV] [PATCH 2/2] toolchain: gcc: drop MIPS patch

[Philip Prindeville]

> On Aug 22, 2017, at 4:01 AM, Kevin Darbyshire-Bryant 
>  wrote:
> 
> Drop 300-mips_Os_cpu_rtx_cost_model.patch for gcc 7.2
> 
> This was causing mis-compilation of dropbear with the default '-Os' size
> optimization as reported in FS#814
> 
> Tested on ar71xx, archer C7 v2.  For size comparison of my whole build:
> 
> 12058628 O2-withoutpatch-dropbearworks.bin
> 12058628 O2-withpatch-dropbearworks.bin
> 11468804 Os-withoutpatch-dropbearworks.bin
> 11468804 Os-withpatch-dropbearfails.bin
> 
> Signed-off-by: Kevin Darbyshire-Bryant 
> ---
> .../7.2.0/300-mips_Os_cpu_rtx_cost_model.patch  | 21 -
> 1 file changed, 21 deletions(-)
> delete mode 100644 
> toolchain/gcc/patches/7.2.0/300-mips_Os_cpu_rtx_cost_model.patch
> 
> diff --git a/toolchain/gcc/patches/7.2.0/300-mips_Os_cpu_rtx_cost_model.patch 
> b/toolchain/gcc/patches/7.2.0/300-mips_Os_cpu_rtx_cost_model.patch
> deleted file mode 100644
> index 84c0fda..000
> --- a/toolchain/gcc/patches/7.2.0/300-mips_Os_cpu_rtx_cost_model.patch
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -commit ecf7671b769fe96f7b5134be442089f8bdba55d2
> -Author: Felix Fietkau 
> -Date:   Thu Aug 4 20:29:45 2016 +0200
> -
> -gcc: add a patch to generate better code with Os on mips
> -
> -Also happens to reduce compressed code size a bit
> -
> -Signed-off-by: Felix Fietkau 
> -
>  a/gcc/config/mips/mips.c
> -+++ b/gcc/config/mips/mips.c
> -@@ -19784,7 +19784,7 @@ mips_option_override (void)
> - flag_pcc_struct_return = 0;
> - 
> -   /* Decide which rtx_costs structure to use.  */
> --  if (optimize_size)
> -+  if (0 && optimize_size)
> - mips_cost = _rtx_cost_optimize_size;
> -   else
> - mips_cost = _rtx_cost_data[mips_tune];
> -- 
> 2.7.4



LGTM


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] What to do when your PR stalls?

[Philip Prindeville]

Hi.

This was a bit of an issue with OpenWrt and I’m not sure if it’s starting to be 
a problem with LEDE or if August is just the month when all of Europe shuts 
down and nothing gets done…

I’m hoping it’s the latter.

Can we formalize what the procedures are for someone submitting a PR, how long 
they can reasonably expect a PR to go unreviewed, what are the steps when your 
PR languishes and you’d like to draw attention to that, etc?

When a package owner is MIA that’s one thing, and it’s a logical conclusion 
that if they’re not doing work on the packages that they own, they’re probably 
too busy to look at someone else’s PR’s as well…

But what about when you see an owner with a lot of churn on the same areas that 
your PR is in?  Obviously, the project or package isn’t suffering for lack of 
attention… so how to handle making sure your own PR’s get some attention too?

All of us want to be better contributors, I think it’s fair to say.

But it’s hard to improve when there's a lack of feedback telling you where 
change needs to come from.

It’s also hard to “prove your mettle” and show how capable you are if your PR’s 
are trickling through the process.  And as individuals, who may be contributing 
out of our free time, it’s hard to invest *more* time to show what valuable 
contributors we might potentially be if the effort that we’ve made so far is 
going unnoticed.

That’s not a criticism, just an observation.

So, what can we do to get everyone’s expectations on the same page about what 
contributors are required to do, and what they can expect in return if they 
meet those requirements?

Somewhat tangentially...

At one of the companies I used to work, a very large router company in the san 
franCisco area, was geographically distributed (much like LEDE is) with people 
working in all sorts of timezones.  Our BU had a policy about spending at least 
30-60 minutes first thing every morning answering Code Review requests, reading 
and commenting on White Papers, etc. so that things wouldn’t be pushed off 
indefinitely and so that the already significant delay that the Sydney and 
Chennai teams faced with getting answers from HQ the next business day wasn’t 
exacerbated by procrastination, making a 1 day delay turn into 2 or three.  It 
was a good policy and it made a challenging situation about as smooth running 
as it could be.

I’m not saying that we need the structure that was rigidly imposed there to be 
imposed here as well: I don’t think it could be, and most of us aren’t being 
paid for our time.  Many of the maintainers work on a as-time-available basis, 
and their efforts are appreciated and we don’t want to make it less agreeable 
for them to keep doing the work they do.

But perhaps each of us could make a private commitment to ourselves to spend a 
certain percentage of our efforts fostering others, engendering collaboration, 
etc?  Or, if you already have, maybe do a self-check to see if you’re 
satisfying that commitment...

Just an idea.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC] kernel patches cleanup

[Philip Prindeville]

> On Aug 7, 2017, at 3:48 PM, Rafał Miłecki <zaj...@gmail.com> wrote:
> 
> On 7 August 2017 at 21:20, Philip Prindeville
> <philipp_s...@redfish-solutions.com> wrote:
>>> On Jul 31, 2017, at 10:11 AM, John Crispin <j...@phrozen.org> wrote:
>>> 
>>> Hi,
>>> 
>>> I rebased my ages old kernel patch cleanup series. It can be found here [1].
>>> 
>>> the series annotates all patches and splits them up into 3 folders 
>>> backports/pending/hacks.
>> 
>> 
>> What’s the criteria for each?
>> 
>> And isn’t “hacks” kind of self-defeating?  If someone submits a PR that adds 
>> something to “hacks”, won’t the default position be, “since this is 
>> admittedly a hack, it’s not really needed and you should find a more 
>> compelling fix”?
> 
> Sometimes getting upstream-acceptable solution takes months (or
> years), so I'm OK accepting well-described and argumented "hacks”.


Fair enough.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Bind not building

[Philip Prindeville]

> On Aug 7, 2017, at 6:37 PM, Matthias Schiffer 
> <mschif...@universe-factory.net> wrote:
> 
> On 08/07/2017 06:14 PM, Philip Prindeville wrote:
>> I’m seeing the following when building bind:
>> 
>> OpenWrt-libtool: link: x86_64-openwrt-linux-musl-gcc -Os -pipe 
>> -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable 
>> -Wno-error=unused-result 
>> -iremap/home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/bind-9.10.5-P3:bind-9.10.5-P3
>>  -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z -Wl,now -Wl,-z -Wl,relro -znow 
>> -zrelro -o .libs/resolve .libs/resolve.o  
>> -L/home/philipp/bertram/lede/staging_dir/target-x86_64_musl_powercode-bmu/usr/lib
>>  
>> -L/home/philipp/bertram/lede/staging_dir/target-x86_64_musl_powercode-bmu/lib
>>  
>> -L/home/philipp/bertram/lede/staging_dir/toolchain-x86_64_gcc-5.4.0_musl/usr/lib
>>  
>> -L/home/philipp/bertram/lede/staging_dir/toolchain-x86_64_gcc-5.4.0_musl/lib 
>> ../irs/.libs/libirs.so ../dns/.libs/libdns.so ../isccfg/.libs/libisccfg.so 
>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/bind-9.10.5-P3/lib/dns/.libs/libdns.so
>>  
>> /home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/bind-9.10.5-P3/lib/isc/.libs/libisc.so
>>  -lcrypto ../isc/.libs/libisc.so -ldl 
>> ../dns/.libs/libdns.so: undefined reference to `ERR_remove_state'
>> ../dns/.libs/libdns.so: undefined reference to `CRYPTO_set_id_callback'
>> collect2: error: ld returned 1 exit status
>> Makefile:483: recipe for target 'resolve' failed
>> make[5]: *** [resolve] Error 1
>> 
>> anyone else seeing this?
>> 
>> I think a patch shouldn’t be too complicated, but I’m surprised that the 
>> buildbots didn’t catch this.
>> 
>> -Philip
> 
> Hmm, I wonder if the linker is picking up your host system libcrypto
> instead of the target build. Does your staging_dir/target-.../usr/lib have
> a libcrypto.so (that is a symlink to libcrypto.so.1.0.0)?


It does:

% ls -ltr staging_dir/target-x86_64_musl_powercode-bmu/usr/lib/libcrypto*
-rw-r--r-- 1 philipp philipp 5200098 Aug  7 13:35 
staging_dir/target-x86_64_musl_powercode-bmu/usr/lib/libcrypto.a
-r-xr-xr-x 1 philipp philipp 2162104 Aug  7 13:35 
staging_dir/target-x86_64_musl_powercode-bmu/usr/lib/libcrypto.so.1.0.0*
lrwxrwxrwx 1 philipp philipp  18 Aug  7 13:35 
staging_dir/target-x86_64_musl_powercode-bmu/usr/lib/libcrypto.so -> 
libcrypto.so.1.0.0*
%


And the configure happened as:

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/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/bind-9.11.2:bind-9.11.2
 -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/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/bind-9.11.2:bind-9.11.2
 -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/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/bind-9.11.2:bind-9.11.2
 -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro " 
CPPFLAGS="-I/home/philipp/bertram/lede/staging_dir/target-x86_64_musl_powercode-bmu/usr/include
 
-I/home/philipp/bertram/lede/staging_dir/target-x86_64_musl_powercode-bmu/include
 
-I/home/philipp/bertram/lede/staging_dir/toolchain-x86_64_gcc-5.4.0_musl/usr/include
 
-I/home/philipp/bertram/lede/staging_dir/toolchain-x86_64_gcc-5.4.0_musl/include/fortify
 
-I/home/philipp/bertram/lede/staging_dir/toolchain-x86_64_gcc-5.4.0_musl/include
 " 
LDFLAGS="-L/home/philipp/bertram/lede/staging_dir/target-x86_64_musl_powercode-bmu/usr/lib
 -L/home/philipp/bertram/lede/staging_dir/target-x86_64_musl_powercode-bmu/lib 
-L/home/philipp/bertram/lede/staging_dir/toolchain-x86_64_gcc-5.4.0_musl/usr/lib
 -L/home/philipp/bertram/lede/staging_dir/toolchain-x86_64_gcc-5.4.0_musl/lib 
-znow -zrelro "  BUILD_CC="x86_64-openwrt-linux-musl-gcc"   ./configure 
--target=x86_64-

Re: [LEDE-DEV] [RFC] kernel patches cleanup

[Philip Prindeville]

> On Jul 31, 2017, at 10:11 AM, John Crispin  wrote:
> 
> Hi,
> 
> I rebased my ages old kernel patch cleanup series. It can be found here [1].
> 
> the series annotates all patches and splits them up into 3 folders 
> backports/pending/hacks.


What’s the criteria for each?

And isn’t “hacks” kind of self-defeating?  If someone submits a PR that adds 
something to “hacks”, won’t the default position be, “since this is admittedly 
a hack, it’s not really needed and you should find a more compelling fix”?

-Philip


> 
> I'd like to push this asap if there are no mayor issues as it will be a pain 
> to rebase once again
> 
>John
> 
> 
> [1] 
> https://git.lede-project.org/?p=lede/blogic/staging.git;a=shortlog;h=refs/heads/patches-cleanup
> 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Bind not building

[Philip Prindeville]

I’m seeing the following when building bind:

OpenWrt-libtool: link: x86_64-openwrt-linux-musl-gcc -Os -pipe 
-fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable 
-Wno-error=unused-result 
-iremap/home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/bind-9.10.5-P3:bind-9.10.5-P3
 -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z -Wl,now -Wl,-z -Wl,relro -znow 
-zrelro -o .libs/resolve .libs/resolve.o  
-L/home/philipp/bertram/lede/staging_dir/target-x86_64_musl_powercode-bmu/usr/lib
 -L/home/philipp/bertram/lede/staging_dir/target-x86_64_musl_powercode-bmu/lib 
-L/home/philipp/bertram/lede/staging_dir/toolchain-x86_64_gcc-5.4.0_musl/usr/lib
 -L/home/philipp/bertram/lede/staging_dir/toolchain-x86_64_gcc-5.4.0_musl/lib 
../irs/.libs/libirs.so ../dns/.libs/libdns.so ../isccfg/.libs/libisccfg.so 
/home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/bind-9.10.5-P3/lib/dns/.libs/libdns.so
 
/home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/bind-9.10.5-P3/lib/isc/.libs/libisc.so
 -lcrypto ../isc/.libs/libisc.so -ldl 
../dns/.libs/libdns.so: undefined reference to `ERR_remove_state'
../dns/.libs/libdns.so: undefined reference to `CRYPTO_set_id_callback'
collect2: error: ld returned 1 exit status
Makefile:483: recipe for target 'resolve' failed
make[5]: *** [resolve] Error 1

anyone else seeing this?

I think a patch shouldn’t be too complicated, but I’m surprised that the 
buildbots didn’t catch this.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 3/4] x86: Move USB support from subtargets to target config

[Philip Prindeville]

Am I the only one who would prefer all of the virtualization support to be 
selected and default to off?

All the fuss we have about not burdening images with unnecessary functionality, 
yet no one blinks at this...

> On Jul 15, 2017, at 10:48 AM, Baptiste Jonglez  
> wrote:
> 
> From: Baptiste Jonglez 
> 
> All x86 subtargets enable USB support, so it makes sense to enable it
> in the target config instead, to avoid duplication.
> 
> Also refresh subtarget configs accordingly.
> 
> Signed-off-by: Baptiste Jonglez 
> ---
> target/linux/x86/64/config-default  |  9 -
> target/linux/x86/config-4.9 | 14 +++---
> target/linux/x86/generic/config-default |  9 -
> target/linux/x86/geode/config-default   |  8 
> target/linux/x86/legacy/config-default  |  9 -
> 5 files changed, 11 insertions(+), 38 deletions(-)
> 
> diff --git a/target/linux/x86/64/config-default 
> b/target/linux/x86/64/config-default
> index 8288c1ade2..5d259d3656 100644
> --- a/target/linux/x86/64/config-default
> +++ b/target/linux/x86/64/config-default
> @@ -150,7 +150,6 @@ CONFIG_HAVE_LIVEPATCH=y
> CONFIG_HAVE_MEMORY_PRESENT=y
> CONFIG_HAVE_STACK_VALIDATION=y
> CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
> -CONFIG_HID=y
> CONFIG_HID_BATTERY_STRENGTH=y
> CONFIG_HID_GENERIC=y
> CONFIG_HID_HYPERV_MOUSE=y
> @@ -278,16 +277,8 @@ CONFIG_TREE_RCU=y
> CONFIG_UCS2_STRING=y
> CONFIG_UCSI=y
> # CONFIG_UNISYSSPAR is not set
> -CONFIG_USB=y
> -CONFIG_USB_COMMON=y
> -CONFIG_USB_EHCI_HCD=y
> -# CONFIG_USB_EHCI_HCD_PLATFORM is not set
> -CONFIG_USB_EHCI_PCI=y
> -CONFIG_USB_OHCI_HCD=y
> CONFIG_USB_OHCI_HCD_PCI=y
> -# CONFIG_USB_OHCI_HCD_PLATFORM is not set
> CONFIG_USB_STORAGE=y
> -CONFIG_USB_UHCI_HCD=y
> CONFIG_USB_XHCI_HCD=y
> CONFIG_USB_XHCI_PCI=y
> # CONFIG_USB_XHCI_PLATFORM is not set
> diff --git a/target/linux/x86/config-4.9 b/target/linux/x86/config-4.9
> index 8965aba474..402c5fdddb 100644
> --- a/target/linux/x86/config-4.9
> +++ b/target/linux/x86/config-4.9
> @@ -216,9 +216,7 @@ CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
> CONFIG_HAVE_UID16=y
> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
> CONFIG_HAVE_USER_RETURN_NOTIFIER=y
> -CONFIG_HID_SUPPORT=y
> -CONFIG_USB_HID=y
> -CONFIG_USB_HIDDEV=y
> +CONFIG_HID=y
> CONFIG_HIGHMEM=y
> # CONFIG_HIGHMEM4G is not set
> CONFIG_HIGHMEM64G=y
> @@ -402,7 +400,17 @@ CONFIG_THREAD_INFO_IN_TASK=y
> CONFIG_TICK_CPU_ACCOUNTING=y
> # CONFIG_TOSHIBA is not set
> CONFIG_UP_LATE_INIT=y
> +CONFIG_USB=y
> +CONFIG_USB_COMMON=y
> +CONFIG_USB_EHCI_HCD=y
> +# CONFIG_USB_EHCI_HCD_PLATFORM is not set
> +CONFIG_USB_EHCI_PCI=y
> +CONFIG_USB_HID=y
> +CONFIG_USB_HIDDEV=y
> +CONFIG_USB_OHCI_HCD=y
> +# CONFIG_USB_OHCI_HCD_PLATFORM is not set
> CONFIG_USB_SUPPORT=y
> +CONFIG_USB_UHCI_HCD=y
> # CONFIG_USERIO is not set
> # CONFIG_USER_NS is not set
> CONFIG_USER_STACKTRACE_SUPPORT=y
> diff --git a/target/linux/x86/generic/config-default 
> b/target/linux/x86/generic/config-default
> index cef35fd157..310c37cf11 100644
> --- a/target/linux/x86/generic/config-default
> +++ b/target/linux/x86/generic/config-default
> @@ -154,7 +154,6 @@ CONFIG_HAVE_KVM_IRQ_ROUTING=y
> CONFIG_HAVE_KVM_MSI=y
> CONFIG_HDMI=y
> CONFIG_HIBERNATE_CALLBACKS=y
> -CONFIG_HID=y
> CONFIG_HID_BATTERY_STRENGTH=y
> CONFIG_HOTPLUG_CPU=y
> CONFIG_HPET=y
> @@ -306,15 +305,7 @@ CONFIG_TASK_DELAY_ACCT=y
> # CONFIG_TOSHIBA_BT_RFKILL is not set
> CONFIG_TREE_RCU=y
> CONFIG_UCS2_STRING=y
> -CONFIG_USB=y
> -CONFIG_USB_COMMON=y
> -CONFIG_USB_EHCI_HCD=y
> -# CONFIG_USB_EHCI_HCD_PLATFORM is not set
> -CONFIG_USB_EHCI_PCI=y
> -CONFIG_USB_OHCI_HCD=y
> -# CONFIG_USB_OHCI_HCD_PLATFORM is not set
> CONFIG_USB_STORAGE=y
> -CONFIG_USB_UHCI_HCD=y
> CONFIG_USER_RETURN_NOTIFIER=y
> CONFIG_VGACON_SOFT_SCROLLBACK=y
> CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
> diff --git a/target/linux/x86/geode/config-default 
> b/target/linux/x86/geode/config-default
> index 2820dfbf7d..69d31b00a5 100644
> --- a/target/linux/x86/geode/config-default
> +++ b/target/linux/x86/geode/config-default
> @@ -59,7 +59,6 @@ CONFIG_GPIO_SYSFS=y
> # CONFIG_GPIO_WS16C48 is not set
> CONFIG_HAVE_ACPI_APEI=y
> CONFIG_HAVE_ACPI_APEI_NMI=y
> -CONFIG_HID=y
> CONFIG_HIGHMEM4G=y
> # CONFIG_HIGHMEM64G is not set
> # CONFIG_HPET is not set
> @@ -117,14 +116,7 @@ CONFIG_SENSORS_LM90=y
> CONFIG_SERIAL_8250_PNP=y
> # CONFIG_SURFACE_PRO3_BUTTON is not set
> # CONFIG_TOSHIBA_BT_RFKILL is not set
> -CONFIG_USB=y
> -CONFIG_USB_COMMON=y
> -CONFIG_USB_EHCI_HCD=y
> -# CONFIG_USB_EHCI_HCD_PLATFORM is not set
> -CONFIG_USB_EHCI_PCI=y
> -CONFIG_USB_OHCI_HCD=y
> CONFIG_USB_OHCI_HCD_PCI=y
> -# CONFIG_USB_OHCI_HCD_PLATFORM is not set
> # CONFIG_USB_UHCI_HCD is not set
> CONFIG_VGACON_SOFT_SCROLLBACK=y
> CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
> diff --git a/target/linux/x86/legacy/config-default 
> b/target/linux/x86/legacy/config-default
> index 0802ee65e7..3e0b065253 100644
> --- a/target/linux/x86/legacy/config-default
> +++ 

Re: [LEDE-DEV] procd: cherry-pick kernel watchdog start/stop to lede-17.01 branch

[Philip Prindeville]

> On Jul 11, 2017, at 3:19 AM, Hans Dedecker  wrote:
> 
> Hi,
> 
> I would like to cherry-pick the start/stop kernel watchdog support to
> the lede-17.01 procd branch :
> 
> e5e99c4 watchdog: add support for starting/stopping kernel watchdog
> 
> It allows to gracefully stop the kernel watchdog via ubus which was
> before not possible as only the user space watchdog kicking could be
> stopped.
> 
> If nobody objects within the next few days I will take it as a passive
> consensus and update the procd lede-17.01 branch and the procd package
> Makefile in the lede-17.01 branch.
> 
> Thx,
> Hans


Hi Hans!

I’ve not been following this too closely, so forgive me if the question is a 
bit naive.

Since the sysupgrade process involves replacing procd now, would the watchdog 
need to be stopped as procd exits so that the hardware doesn’t reset itself 
during a particularly length update?  Let’s say you have a large FLASH with 
slow write times… that could take a long time and I don’t want a hardware 
watchdog thinking that the system has hung…

Thanks,

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Procd questions

[Philip Prindeville]

I came up with the following PR (https://github.com/openwrt/packages/pull/4568) 
thinking it would be a trivial substitution of the procd primitives for what 
the old shell script was doing.

Turns out, I wasn’t even close.

The problem turned out to be that when start_service() had exited, procd had 
received the request to start the service… but not acted on it.

So faster than the service could be started, other services (some of them not 
procd-based, and therefore not subject to any sort of procd FIFO policy) were 
being started up.

Indeed, even services that were procd-launched (like lighttpd and cron) were 
starting up ahead of syslog-ng, so part of their startup was spilling onto the 
console because they were failing to rendezvous with the logger.

This might be (I’ve not dug too much yet) the behavior of foreground vs. 
backgrounded servers, i.e. when running the non-procd script I suspect that the 
parent process wouldn’t exit until it’s child was successfully started and 
ready for requests.  Obviously when things are launched by procd 
fork'ing/exec'ing and then running them in the foreground, it’s different.  
There’s no obvious way to check for the status of the service…

Could that be changed?

Could some sort of synchronization primitives be added to start_service() where 
one could check to see if some observable external conditions had been met?  In 
the case of syslog-ng, for instance, it would open up /dev/log.

But there might be more complex (combinatorial) conditions, such as /dev/log 
being opened for reading, and there being a listener on UDP(0.0.0.0,514) (in 
the case of rsyslog).  Or maybe other operators like OR and NOT in addition to 
AND.

Then after the procd_close_instance, the script could choose to block on some 
condition that procd could instrument (or conversely a timeout for failure so 
it doesn’t block forever).

Anyone else encountered similar issues when moving to procd-based startup?

Thanks,

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] glibc finally fixes /etc/resolv.conf handling

[Philip Prindeville]

For everyone who has ever wondered why they need to stop and restart long 
running services when they move from one network to another (as is common for 
laptops using Wifi that are roaming around), this can be quite vexing.

The reason was that /etc/resolv.conf would get rewritten by DHCP when you 
acquired a new DHCP lease, but programs which were running wouldn’t have 
sufficient knowledge to force the resolver to re-initialize itself (and 
arguably, they shouldn’t have to… it should just work).

This FINALLY (after many years) got fixed today:

https://sourceware.org/bugzilla/show_bug.cgi?id=984

https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=aef16cc8a4c670036d45590877d411a97f01e0cd

So, hopefully that will make life easier for people who support their WiFi 
users and will no longer have to say, “Have you tried stopping and restarting 
the service?”

https://www.youtube.com/watch?v=PtXtIivRRKQ

Woot woot!

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Planning v17.01.2

[Philip Prindeville]

> On May 25, 2017, at 10:59 AM, Lucian Cristian  wrote:
> 
> On 24.05.2017 23:34, Jo-Philipp Wich wrote:
>> Hi,
>> 
>> I'd like to start preparing the v17.01.2 release during the upcoming
>> weekend with the goal to release final binaries within the next week
>> (~May 29th till June 3rd).
>> 
>> Changes that shall be part of 17.01.2 should be merged until Sunday, the
>> 28th.
>> 
>> You can find the current list of changes since v17.01.1 at
>> https://lede-project.org/releases/17.01/changelog-17.01.2
>> 
>> The most notable change is a security fix affecting the builtin dropbear
>> SSH server. While the default configuration does not appear to be
>> vulnerable, we still should provide updated images as soon as possible.
>> 
>> 
>> If you want specific fixes cherry-picked/backported to lede-17.01,
>> please mention them in a reply to this mail.
>> 
>> If you have any objections to the release time frame, please speak up
>> 
>> 
>> Like with the last 17.01.1 service release, there is no dedicated RC
>> phase planned.
>> 
>> 
>> Thanks,
>> Jo
>> 
>> 
>> 
>> 
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> it would be cool if we move in the modern age and have the usb HID included 
> by default
> 
> not merged: https://github.com/lede-project/source/pull/1125
> 
> regards


+1 (since been merged I think)


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] Remerge logo ideas

[Philip Prindeville]

Can we add “Powered by LEDE” in little tiny letters underneath?  ;-)


> On May 29, 2017, at 4:11 AM, Jamie Stuart  wrote:
> 
> Hi,
> First of all, I’m glad to hear the process of remerging LEDE with OpenWrt is 
> moving forward.
> For what it’s worth, if prefer the LEDE name (it’s friendlier - ‘leddy’ - and 
> not tied to the name of an old router!)
> 
> However, it seems the consensus is that the OpenWrt name should remain. I 
> thought that maybe we should take this opportunity to at least give the 
> project an updated look?
> Maybe a new logo? I’m personally not one for mascots, so I had a quick go at 
> a few simple text-based designs:
> 
> http://i.imgur.com/9zyXSYR.png
> 
> What are you thoughts?
> 
> Jamie, onebillion


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] add --extend-squasfs to qemustart script

[Philip Prindeville]

Inline

> On May 22, 2017, at 6:23 AM, Paul Spooren  wrote:
> 
> scripts/qemustart
> 
> using squashfs results in a "no space left on device" error. You need to
> manually extend the new build with a tool like dd.
> 
> This patch adds the --extend-squasfs parameter to enlarge the image to
> 64MB. The (64MB - 20MB =) ~44MB free space will be used by the
> overlayfs.
> 
> This approach is very simple and resets the overlayfs if used twices.
> 
> Signed-off-by: Paul Spooren 
> ---
> scripts/qemustart | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/qemustart b/scripts/qemustart
> index f77c674a9c..4dc4051696 100755
> --- a/scripts/qemustart
> +++ b/scripts/qemustart
> @@ -85,6 +85,7 @@ usage() {
>   cat >&2 < Usage: $SELF [-h|--help]
>  $SELF [--do-setup]
> +$SELF [--extend-squashfs]


Can it take an argument and extend it by that many MB?


>$SELF 
>  [ []]
>  [--kernel ]
> @@ -124,7 +125,8 @@ parse_args() {
>  echo "running setup"
>  do_setup 
>  exit 0
> -;;
> + ;;


Why does this line need to change?


> + --extend-squashfs) EXTEND_SQUASHFS=true; shift 1; ;;
>   --kernel) o_kernel="$2"; shift 2 ;;
>   --rootfs) o_rootfs="$2"; shift 2 ;;
>   --help|-h)
> @@ -223,6 +225,11 @@ start_qemu_x86() {
> 
>   [ -n "$rootfs" ] || {
>   
> rootfs="$o_bindir/lede-$o_target-${o_subtarget%-*}-combined-squashfs.img"
> + if [ -f "$rootfs" ] && [ "$EXTEND_SQUASHFS" ]; then
> + mv "$rootfs" "${rootfs}_org"
> + dd if=/dev/zero of="$rootfs" bs=1M count=64
> + dd if="${rootfs}_org" of="$rootfs" conv=notrunc


Also, can you use “conv=sparse” so it’s just allocating empty blocks?

-Philip


> + fi
>   if [ ! -f "$rootfs" ]; then
>   
> rootfs="$o_bindir/lede-$o_target-${o_subtarget%-*}-combined-ext4.img"
> 
> -- 
> 2.11.0
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Problem with commit "kernel: add hwmon for W83627EHF and family"

[Philip Prindeville]

> On May 21, 2017, at 10:03 AM, Daniel Golle <dan...@makrotopia.org> wrote:
> 
> Hi Rafal,
> 
> On Sun, May 21, 2017 at 05:02:44PM +0200, Rafał Miłecki wrote:
>> Hi,
>> 
>> I noticed commit 0dcc36fc7ddec ("kernel: add hwmon for W83627EHF and
>> family") in the LEDE tree that doesn't look OK to me.
>> 
>> 1) Package for hwmon-w83627ehf
>> Do we need it to be a package? Or could it be built-in into the kernel?
>> Do we need it to be a global package? Usually hwmon drivers are
>> designed for a specific device and it should be enough to have it in
>> target/linux/*/modules.mk
> 
> True, but all other x86-specific hwmon modules are in
> package/kernel/linux/modules as well and I'd rather wanted it to be
> consistent.
> 
>> 
>> 2) 800-hwmon-w83627ehf-dont-claim-nct677x.patch
>> I really don't like this one as it's totally unclear why we need this
>> change. What's wrong with NCT6775 and the w83627ehf driver? It should
>> be well described in the patch.
> 
> Sorry for the lack of a more detailed description.
> The problem here is that the W83627EHF driver also claims the NCT677x
> hardware but doesn't support all features (according to
> Philip Prindeville). I reckon he can provide more information regarding
> which features which are available when using the nct6776 driver are
> missing in the w83627ehf driver on NCT677x hardware.
> 
> Cheers
> 
> Daniel

To follow up on what Daniel said, yes, the older w83627 has a subset of 
functionality for the nct6775 chips, but the native nct6775 driver does a 
better job.

Quoting Documentation/hwmon/nct6775:

Note


This driver supersedes the NCT6775F and NCT6776F support in the W83627EHF
driver.

and drivers/hwmon/Kconfig:

config SENSORS_NCT6775
tristate "Nuvoton NCT6775F and compatibles"
depends on !PPC
select HWMON_VID
help
  If you say yes here you get support for the hardware monitoring
  functionality of the Nuvoton NCT6106D, NCT6775F, NCT6776F, NCT6779D,
  NCT6791D, NCT6792D, NCT6793D, and compatible Super-I/O chips. This
  driver replaces the w83627ehf driver for NCT6775F and NCT6776F.

  This driver can also be built as a module.  If so, the module
  will be called nct6775.

...
config SENSORS_W83627EHF
tristate "Winbond W83627EHF/EHG/DHG/UHG, W83667HG, NCT6775F, NCT6776F"
depends on !PPC
select HWMON_VID
help
  If you say yes here you get support for the hardware
  monitoring functionality of the Winbond W83627EHF Super-I/O chip.

  This driver also supports the W83627EHG, which is the lead-free
  version of the W83627EHF, and the W83627DHG, which is a similar
  chip suited for specific Intel processors that use PECI such as
  the Core 2 Duo. And also the W83627UHG, which is a stripped down
  version of the W83627DHG (as far as hardware monitoring goes.)

  This driver also supports Nuvoton W83667HG, W83667HG-B, NCT6775F
  (also known as W83667HG-I), and NCT6776F.

  This driver can also be built as a module.  If so, the module
  will be called w83627ehf.



If you definitely have NCT6775F hardware, they you don’t want to build both 
drivers into your kernel.

If you want to build a kernel that supports both the NCT6775 and W83627HF 
drivers, then you need this patch so that ONLY the NCT6775 will detect the 
chipset.

It’s not clear why a few of the patches to add partial NCT6775 support to the 
W83627HF driver weren’t backed out after the NCT6775 driver was merged…  
probably an oversight.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Scripted builds -- package selections reset by "make defconfig oldconfig"

[Philip Prindeville]

> On May 17, 2017, at 11:35 AM, Philip Prindeville 
> <philipp_s...@redfish-solutions.com> wrote:
> 
> [snip]

Ignore the title, I forgot to update that: it’s actually the “scripts/feeds 
update” which is clobbering the .config.


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Scripted builds -- package selections reset by "make defconfig oldconfig"

[Philip Prindeville]

Hi.

I have a requirement to be able to clone a snapshot of an Ubuntu 16.04-2 VM 
which has all of the appropriate packages already installed on it, scp over a 
build script, run it, and copy out the $(TOPDIR)/bin/targets/ directory when 
done and then destroy the VM.

From a working (development) cloning of GIT, I had done “scripts/diffconfig.sh 
> .config-compacted” and put that into the script, along with a copy of 
env/kernel-config.

The script does these steps:

* git clone’s the LEDE source URL

* cd into LEDE cloning

* scripts/env new pristine

* adds an additional line to feeds.conf.default and writes it out to feeds.conf

* installs a minor patch to package/base-files/files/sbin/upgrade (some extra 
delays that fix output on x86 hardware)

* cat <<__HERE__ > .config

* cat <<__HERE__ > env/kernel-config

* scripts/env save populated

* scripts/feeds update -a

__this is where things get weird… if I scp over a copy of the original .config 
file from my development cloning, and diff it against the just-created .config 
… feeds/luci and feeds/telephony have been updated, even though both were 
commented out… all of my optional package selections are gone… I’m not even 
sure why “scripts/feeds update” would touch my .config!__

* scripts/feeds install -a

* make defconfig oldconfig

* make -j8 world V= BUILD_LOG=1 CONFIG_PKG_BUILD_JOBS=8

* scp -rp bin/targets/ @my_nas_address:builds/$(date +”%Y%m%dT%H%M%S”)

* sudo shutdown now


The script seems simple enough.  Why are my package selections getting 
clobbered?   I can post the contents of my .config if it’s helpful, but of note 
is this section here:

CONFIG_PER_FEED_REPO=y
# CONFIG_PER_FEED_REPO_ADD_DISABLED is not set
# CONFIG_PER_FEED_REPO_ADD_COMMENTED is not set
CONFIG_FEED_packages=y
# CONFIG_FEED_luci is not set
CONFIG_FEED_routing=y
# CONFIG_FEED_telephony is not set
CONFIG_FEED_powercode=y

Why is scripts/feeds update modifying my .config file?  I see 
“refresh_config();” down at the bottom of update() but I don’t understand why 
it’s needed.

Thanks,

-Philip



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2 00/19] Universal staged sysupgrade and assorted fixes

[Philip Prindeville]

> On May 13, 2017, at 1:56 PM, Matthias Schiffer 
>  wrote:
> 
> Text from my RFC mail:
> 
> ---
> When talking about
> https://bugs.lede-project.org/index.php?do=details_id=685 with jow
> and lynxis, we came to the conclusion that the best way to fix sysupgrades
> would be to generalize the staged sysupgrade used on NAND devices to work
> on all targets. That is what this patchset does, with some nice extras
> like staged sysupgrade support from failsafe mode (which did not work at
> all on NAND devices before).
> 
> I have tested these patches on ar71xx (squashfs+jffs2), ramips (squashfs+
> ubifs) and x86 (ext4), and they seems to work perfectly; they should be
> tested on a lot more targets before they are applied though.
> 
> The same patchset can be found the "sysupgrade" branch of my staging tree
> at https://git.lede-project.org/?p=lede/neoraider/staging.git;a=summary
> 
> Note: the diffstat looks a lot scarier than it should; most of the added
> lines are the procd patches that I have included in the LEDE repo for now
> to facilitate testing the series.
> ---
> 
> Some highlights of v2:
> * split whitespace fixes into separate patches
> * add missing include guards to new procd header sysupgrade.h
> * support sysupgrade -p again (suggested by from Daniel Golle)
> * various x86 sysupgrade fixes (now sysupgrade with growing kernel
> partition actually works)
> * apply x86 sysupgrade fixes to sunxi as well
> 
> It would be great if someone with access to sunxi hardware could test my
> changes, the sunxi patches were not tested at all.
> 
> Thanks for the feedback I got so far.
> 
> Matthias
> 
> 
> Matthias Schiffer (19):
>  procd: clean up trailing whitespace in nand.sh
>  procd: prepare NAND sysupgrade for making upgraded dynamically linked
>  procd: system: always support staged sysupgrade
>  procd: upgraded: link dynamically, chroot during exec
>  procd: upgraded: add support for passing a "command" argument to
>stage2
>  procd: remove procd-nand package
>  base-files: always use staged sysupgrade
>  fstools: clean up trailing whitespace in snapshot script
>  fstools: snapshot: handle jffs2 conversion using upgraded
>  procd: remove code that has become unnecessary after sysupgrade
>changes
>  procd: init: add support for sysupgrades triggered from preinit
>  base-files: sysupgrade cleanup
>  base-files: add support for staged sysupgrades from failsafe mode
>  ramips: sysupgrade: move nand_do_upgrade call to platform_do_upgrade
>  x86: sysupgrade: move partition table change check to
>platform_check_image
>  x86: sysupgrade: refactor platform_do_upgrade
>  x86: sysupgrade: explicitly rescan disk after writing partition table
>  sunxi: sysupgrade: don't write partitions twice
>  sunxi: sysupgrade: sync with x86
> 
> package/base-files/Makefile|  13 +-
> .../files/lib/preinit/40_run_failsafe_hook |   6 +-
> .../files/lib/preinit/99_10_failsafe_login |  11 +-
> package/base-files/files/lib/upgrade/common.sh | 167 +++--
> .../files => base-files/files/lib/upgrade}/nand.sh |  63 +
> package/base-files/files/lib/upgrade/stage2| 149 +++
> package/base-files/files/sbin/sysupgrade   |  77 +++---
> package/system/fstools/Makefile|   2 +-
> package/system/fstools/files/snapshot  |  16 +-
> package/system/procd/Makefile  |  41 +--
> package/system/procd/files/nand-preinit.sh |  21 --
> ...1-system-always-support-staged-sysupgrade.patch | 112 +
> ...raded-link-dynamically-chroot-during-exec.patch | 231 +
> ...d-support-for-passing-a-command-argument-.patch | 104 
> ...-that-has-become-unnecessary-after-sysupg.patch | 120 +
> ...pport-for-sysupgrades-triggered-from-prei.patch | 278 +
> .../ramips/base-files/lib/upgrade/platform.sh  |   9 +-
> target/linux/sunxi/Makefile|   2 +-
> .../linux/sunxi/base-files/lib/upgrade/platform.sh | 120 +
> .../linux/x86/base-files/lib/upgrade/platform.sh   | 104 +---
> 20 files changed, 1259 insertions(+), 387 deletions(-)
> rename package/{system/procd/files => base-files/files/lib/upgrade}/nand.sh 
> (89%)
> create mode 100755 package/base-files/files/lib/upgrade/stage2
> delete mode 100644 package/system/procd/files/nand-preinit.sh
> create mode 100644 
> package/system/procd/patches/0001-system-always-support-staged-sysupgrade.patch
> create mode 100644 
> package/system/procd/patches/0002-upgraded-link-dynamically-chroot-during-exec.patch
> create mode 100644 
> package/system/procd/patches/0003-upgraded-add-support-for-passing-a-command-argument-.patch
> create mode 100644 
> package/system/procd/patches/0004-Remove-code-that-has-become-unnecessary-after-sysupg.patch
> create mode 100644 
> package/system/procd/patches/0005-init-add-support-for-sysupgrades-triggered-from-prei.patch
> 


I’ve 

[LEDE-DEV] Supporting RT linux

[Philip Prindeville]

I was trying to apply the linux 4.9.20-rt16 patchset…  This is as far as I got. 
 I applied it as 000-…


Applying 
/home/philipp/bertram/lede/target/linux/generic/patches-4.9/721-phy_packets.patch
 using plaintext: 
patching file include/linux/netdevice.h
Hunk #1 succeeded at 1409 (offset 12 lines).
Hunk #2 succeeded at 1439 (offset 12 lines).
Hunk #3 succeeded at 1726 (offset 12 lines).
Hunk #4 succeeded at 1798 (offset 12 lines).
patching file include/linux/skbuff.h
Hunk #1 succeeded at 2341 (offset 7 lines).
Hunk #2 succeeded at 2465 (offset 7 lines).
patching file net/Kconfig
patching file net/core/dev.c
Hunk #1 succeeded at 2939 (offset 8 lines).
patching file net/core/skbuff.c
Hunk #1 FAILED at 64.
Hunk #2 succeeded at 540 (offset 11 lines).
1 out of 2 hunks FAILED -- saving rejects to file net/core/skbuff.c.rej
patching file net/ethernet/eth.c
Patch failed!  Please fix 
/home/philipp/bertram/lede/target/linux/generic/patches-4.9/721-phy_packets.patch!
Makefile:24: recipe for target 
'/home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/linux-4.9.20/.prepared_7c7bcc1dee2fd1eac744dc0a5c09bca2'
 failed
make[3]: *** 
[/home/philipp/bertram/lede/build_dir/target-x86_64_musl_powercode-bmu/linux-x86_64/linux-4.9.20/.prepared_7c7bcc1dee2fd1eac744dc0a5c09bca2]
 Error 1
make[3]: Leaving directory '/home/philipp/bertram/lede/target/linux/x86'
Makefile:13: recipe for target 'prepare' failed
make[2]: *** [prepare] Error 2
make[2]: Leaving directory '/home/philipp/bertram/lede/target/linux'
target/Makefile:23: recipe for target 'target/linux/prepare' failed
make[1]: *** [target/linux/prepare] Error 2
make[1]: Leaving directory '/home/philipp/bertram/lede'
/home/philipp/bertram/lede/include/toplevel.mk:206: recipe for target 
'target/linux/prepare' failed
make: *** [target/linux/prepare] Error 2


Here’s what it takes to make the existing patches apply on top of it (I named 
the patchset as 000-linux-rt-4.9.20-rt16.patch):

diff --git a/target/linux/generic/patches-4.9/721-phy_packets.patch 
b/target/linux/generic/patches-4.9/721-phy_packets.patch
index 5b4ff07..5acf1d2 100644
--- a/target/linux/generic/patches-4.9/721-phy_packets.patch
+++ b/target/linux/generic/patches-4.9/721-phy_packets.patch
@@ -114,9 +114,9 @@
 --- a/net/core/skbuff.c
 +++ b/net/core/skbuff.c
 @@ -64,6 +64,7 @@
- #include 
  #include 
  #include 
+ #include 
 +#include 
  
  #include 


and that’s it… well, that and some quilt refreshes to update the line numbers, 
of course…

I also needed to set CONFIG_PREEMPT_RTB=y and CONFIG_RCU_BOOST=n as this was 
additional config state that gets injected by the patchset.

I booted the kernel but it panicked about 20 seconds in.  It might be something 
trivial.  I’ll follow up with more info as soon as I finish digging...

Thanks,

-Philip



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev