[LEDE-DEV] [PATCH netifd] interface: fix "ifup-failed" hotplug event handling

2018-04-09 Thread Martin Schiller 
The ifup-failed event should only be triggered when the former
interface state is IFS_SETUP.

Otherwise, there will also be an ifup-failed event in the
IFS_TEARDOWN stateif you do an manual ifdown .

Signed-off-by: Martin Schiller 
---
 interface.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/interface.c b/interface.c
index 900a523..2a23984 100644
--- a/interface.c
+++ b/interface.c
@@ -267,10 +267,16 @@ mark_interface_down(struct interface *iface)
 
iface->link_up_event = false;
iface->state = IFS_DOWN;
-   if (state == IFS_UP)
+   switch (state) {
+   case IFS_UP:
interface_event(iface, IFEV_DOWN);
-   else
+   break;
+   case IFS_SETUP:
interface_event(iface, IFEV_UP_FAILED);
+   break;
+   default:
+   break;
+   }
interface_ip_set_enabled(>config_ip, false);
interface_ip_set_enabled(>proto_ip, false);
interface_ip_flush(>proto_ip);
-- 
2.11.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

2018-04-09 Thread Philip Prindeville 
Inline

> On Apr 9, 2018, at 2:11 PM, Tomasz Maciej Nowak  wrote:
> 
> W dniu 09.04.2018 o 21:05, Philip Prindeville pisze:
>> 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?
> 
> 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_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

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

2018-04-09 Thread Tomasz Maciej Nowak 

W dniu 09.04.2018 o 21:05, Philip Prindeville pisze:

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?


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.






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

2018-04-09 Thread Tomasz Maciej Nowak 

W dniu 09.04.2018 o 21:00, Philip Prindeville pisze:

Inline.  Has this been tested with UEFI?


No, I don't have any UEFI system which can be employed for testing.





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.


Thanks, will change in v2.





+   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 module for shell-like tests, used in grub-iso.cfg and grub-cfg see 
below.






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




Thank You for the review.

--
TMN

___
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

2018-04-09 Thread Philip Prindeville 


> On Feb 16, 2018, at 1:32 PM, Philip Prindeville 
>  wrote:
> 
> 
> 
>> 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.


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

2018-04-09 Thread 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

2018-04-09 Thread 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

2018-04-09 Thread 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

Re: [LEDE-DEV] [OpenWrt-Devel] kernel version status

2018-04-09 Thread Roman Yeryomin 

On 2018-04-01 17:48, Hauke Mehrtens wrote:

The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending
on the target. All targets that are *not* on either kernel 4.9 or 4.14
will not be included in the next release.

The following targets are on kernel 4.4 and will probably not be
included in the next release:
* gemini
There are patches for kernel 4.14 on the mailing list, we will
probably get them in before the release and ship this with 4.14


Hi Hauke, I have a working 4.9, is it too late to submit?
I'll also work on 4.14 submitted by Linus, but it didn't work out of the 
box, so probably will take more time.


Regards,
Roman

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

Re: [LEDE-DEV] [PATCH 0/4] Gemini forward-port to kernel v4.14

2018-04-09 Thread Roman Yeryomin 

On 2018-04-04 23:34, Linus Walleij wrote:

This patch set forward-ports Gemini to v4.14 with as good
support as I can get.

I don't know if all or any patches actually make it through
to the devel list. They are also posted here:

https://dflund.se/~triad/krad/gemini/openwrt/

It would be nice if we could apply this and get a working
modernized base for the Gemini platforms.

The v4.14 is a bit patchy. With v4.16 we will be looking
pretty neat.

Linus Walleij (4):
  firmware-utils: Add the DNS-313 image header tool
  gemini: Forward-port to v4.14
  gemini: Add kernel v4.14 patches
  gemini: Delete kernel 4.4 patches



Hi Linus, thanks for the patches!
I have tested them quickly yesterday on nas4220b board. Although I've 
managed to boot it (had to fix rootfs image) ethernet and usb didn't 
work. And I didn't check anything else.
I didn't yet look at the code but before I dive there I have a question: 
did you have a chance to test it yourself on any of the boards? And if 
yes, which one?


Regards,
Roman

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

[LEDE-DEV] (V)HT mode selection for meshpoint (was "ath10k + ap + encryption")

2018-04-09 Thread Sven Eckelmann 
On Mittwoch, 6. Dezember 2017 22:26:09 CEST Sven Eckelmann wrote:
> On Mittwoch, 6. Dezember 2017 18:52:01 CET Daniel Hernandez wrote:
> > So  been running this mesh  patch  on  4  routers in my home for  over a 
> > month and  it  works  great !  
> > Reporting my  feedback to  see  if  it can  be  in the next  release  of  
> > LEDE  .
> 
> Felix Fietkau worked hard to get something into LEDE. I think all(?)  
> relevant 
> changes [1] are now in LEDE master (added 21 days ago). So you could try the 
> current master and send him some feedback.
...[

We have now noticed that your related change [1] will create a VHT80 mesh 
interface when you specified VHT40 in for the wifi-device. For example like 
the this configuration:

config wifi-device 'radio1'
option type 'mac80211'
option channel '44'
option disabled '0'
option beacon_int '100'
option distance '300'
option path 'platform/soc/a80.wifi'
option htmode 'VHT40'
option noscan '1'
option ldpc '0'
option hwmode '11na'
option txpower '26'

config wifi-iface 'wmesh3'
option device 'radio1'
option ifname 'mesh3'
option network 'mesh3'
option mode 'mesh'
option mesh_id 'mesh'
option disabled '0'
option mcast_rate '18000'
option mesh_ttl '1'
option mesh_fwding '0'
option region_disable '0'
option macaddr 'AE:86:74:AB:77:F5'
option encryption 'psk2'
option key 'fb719b4e5ecd1bca734c1af1b59d28c7'

The new interface then looks like:

phy#1
Interface mesh3
ifindex 8
wdev 0x10003
addr ae:86:74:ab:77:f5
type mesh point
channel 44 (5220 MHz), width: 80 MHz, center1: 5210 MHz
txpower 23.00 dBm

Problem is here that max_oper_chwidth is not parsed by 
wpa_supplicant_join_mesh and instead overwritten by it. It will therefore just 
use the highest oper mode it can use for the selected frequency. And because 
vht is also overwritten, the same will happen with HT40.

Kind regards,
Sven

[1] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=d91494eedf06ac6b31c1aa9f7172871b16af96c8

signature.asc
Description: This is a digitally signed message part.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev