date:20181217

[OpenWrt-Devel] [PATCH] ipq40xx: clean up netgear-dni image generation

2018-12-17 Thread David Bauer

The NETGEAR EX61x0v2 does only validate the DNI header, neither it needs
the kernel to be a specific size nor a fake filesystem header to be
present.

This has been tested using the NETGEAR Web-UI and the pushbutton TFTP
recovery.

Signed-off-by: David Bauer 
---
 target/linux/ipq40xx/image/Makefile | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/target/linux/ipq40xx/image/Makefile 
b/target/linux/ipq40xx/image/Makefile
index eaf9f68395..af953def41 100644
--- a/target/linux/ipq40xx/image/Makefile
+++ b/target/linux/ipq40xx/image/Makefile
@@ -40,8 +40,8 @@ define Device/DniImage
NETGEAR_BOARD_ID :=
NETGEAR_HW_ID :=
IMAGES := factory.img sysupgrade.bin
-   IMAGE/factory.img := append-kernel | pad-offset 64k 64 | 
append-uImage-fakehdr filesystem | pad-to (KERNEL_SIZE) | append-rootfs | 
pad-rootfs | netgear-dni
-   IMAGE/sysupgrade.bin := append-kernel | pad-offset 64k 64 | 
append-uImage-fakehdr filesystem | pad-to (KERNEL_SIZE) | append-rootfs | 
pad-rootfs | append-metadata
+   IMAGE/factory.img := append-kernel | append-rootfs | pad-rootfs | 
netgear-dni
+   IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | 
append-metadata
 endef
 DEVICE_VARS += NETGEAR_BOARD_ID NETGEAR_HW_ID
 
@@ -144,7 +144,6 @@ TARGET_DEVICES += meraki_mr33
 
 define Device/netgear_ex61x0v2
$(call Device/DniImage)
-   KERNEL_SIZE := 3080192
DEVICE_DTS_CONFIG := config@4
NETGEAR_BOARD_ID := EX6150v2series
NETGEAR_HW_ID := 29765285+16+0+128+2x2
-- 
2.20.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] ath79: seting GPIO registers to specific values via DTS?

2018-12-17 Thread Roger Pueyo Centelles | Guifi.net

Hi,

Thank you very much for clarifying that. :)

After looking a little bit into other devices' configurations, this line
in etc/board.d/01_leds will do the trick:

    ucidef_set_led_switch "wan" "WAN" "$boardname:green:wan" "switch0"
"0x02"


Last thing, I managed to get inside the stock firmware (a customized
OpenWrt version, by the way) and I saw that:

   - the port labeled "LAN", in U-Boot is eth0, in the stock firmware is
eth1
   - the port labeled "WAN", in U-Boot is eth1, in the stock firmware is
eth0

Should I be coherent to U-Boot and use the more common
LAN-eth0//WAN-eth1 assignation, or do it the other way round
(LAN-eth1//WAN-eth0) as in the stock firmware?


Thanks for your comments,

Roger


El 17/12/18 a les 5:50, Chuanhong Guo ha escrit:
> Hi!
>
> On Mon, Dec 17, 2018 at 7:43 AM Roger Pueyo Centelles | Guifi.net
>  wrote:
>> Hi Seb,
>>
>> You nailed it! :-)
>>
>> I was missing the ' "pinctrl-names = "default"; ' line. I must have
>> removed it from the .dts file I used as the source for mine at some
>> point. Then I just sorted the pinctrl-0/1 issue, which I had already
>> tried in any possible combination.
>>
>> After fixing this, I have detected another issue that had passed
>> unnoticed to me before. The eth1 interface always appears as UP (i.e.,
>> having link), even if I unplug the cable.
> This is expected. gmac1 is connected to builtin switch, which means
> this link is always up. Link changes happen in builtin switch, not
> gmac.
> ar71xx mixed switch and gmac driver together and it uses switch port
> status for gmac link. These two drivers are separated in ath79.
>> According to the datasheet, GMAC1 (eth1 here) is internally connected to
>> the integrated switch. The "swconfig dev switch0 show" command gives:
>>
>> Port 0:
>> enable_mirror_rx: 0
>> enable_mirror_tx: 0
>> pvid: 0
>> link: port:0 link:up speed:1000baseT full-duplex txflow rxflow
>> Port 1:
>> enable_mirror_rx: 0
>> enable_mirror_tx: 0
>> pvid: 1
>> link: port:1 link:up speed:100baseT full-duplex auto
>>
>> How should I manage this?
>>
>> Thank you very much for your support.
>>
>> Best,
>>
>> Roger
>>
>> El 16/12/18 a les 19:07, Sebastian Kemper ha escrit:
>>> On Sun, Dec 16, 2018 at 06:23:53PM +0100, Roger Pueyo Centelles | Guifi.net 
>>> wrote:
 Hi,
>>> Hello Roger!
>>>
 [...]

 leds {
 compatible = "gpio-leds";
 pinctrl-1 = <_rssilow_pin _rssimediumhigh_pin
 _rssihigh_pin>;

 [...]

  {
 led_rssilow_pin: pinmux_rssilow_pin {
 pinctrl-single,bits = <0x8 0x0 0xff00>;
 };

 led_rssimediumhigh_pin: pinmux_rssimediumhigh_pin {
 pinctrl-single,bits = <0xc 0x0 0x00ff>;
 };

 led_rssihigh_pin: pinmux_rssihigh_pin {
 pinctrl-single,bits = <0x10 0x0 0x00ff>;
 };
 };

 [...]
>>> The pinmux part looks OK to me. Could you change the leds part to the
>>> below and try again?
>>>
>>>   leds {
>>>   compatible = "gpio-leds";
>>>
>>>   pinctrl-names = "default";
>>>   pinctrl-0 = <_disable_pins _rssilow_pin 
>>> _rssimediumhigh_pin _rssihigh_pin>;
>>>
>>>   [...]
>>>
>>> I added the jtag bit because I saw that you use it under keys. You have
>>> to remove
>>>
>>> pinctrl-0 = <_disable_pins>;
>>>
>>> under keys. Just put them all in one place.
>>>
>>> From my testing, when defining pinctrl-0 and pinctrl-1, the second one
>>> doesn't do anything. For example:
>>>
>>> pinctrl-0 = <_disable_pins>; // works
>>> pinctrl-1 = <_gpio_11>; // nothing happens
>>>
>>> But
>>>
>>> pinctrl-0 = <_disable_pins _gpio_11>; // both are applied - 
>>> works
>>>
>>>
>>> Kind regards,
>>> Seb
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v3 1/2] ath79: add support for devolo WiFi pro 1200e

2018-12-17 Thread David Bauer

Hardware

CPU:   Qualcomm Atheros QCA9558
RAM:   128M DDR2
FLASH: 16MiB
ETH:   1x Atheros AR8035 (PoE in)
   1x Atheros AR8033
WiFi2: QCA9558 2T2R
WiFi5: QCA9880 2T2R
BTN:   1x Reset
LED:   1x LED blue
   1x LED red
BUZZ:  1x GPIO attached piezo buzzer (controllable ass LED)
UART:  3.3V GND TX RX (115200-N-8) (3.3V is square pad)
   Header is located next to reset-button

Installation

Make sure you set a password for the root user as prompted on first
setup!

1. Upload OpenWRT sysupgrade image via SSH to the device.
Use /tmp as the destination folder on the device.
User is root, password the one set in the web interface.

2. Install OpenWRT with

> sysupgrade -n -F /tmp/

Signed-off-by: David Bauer 
---
v2:
 - fixed whitespace issues
 - activate CONFIG_GPIO_WATCHDOG_ARCH_INITCALL kernel config symbol
v3:
 - refactored LED DT-nodes
 - fixed GMAC config for dvl1200e
 - add patch for dvl1750c

 .../ath79/base-files/etc/board.d/02_network   |   3 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |   4 +
 .../ath79/dts/qca9558_devolo_dvl1200e.dts |  47 ++
 .../ath79/dts/qca9558_devolo_dvl1xxx.dtsi | 156 ++
 target/linux/ath79/generic/config-default |   3 +
 target/linux/ath79/image/generic.mk   |   8 +
 6 files changed, 221 insertions(+)
 create mode 100644 target/linux/ath79/dts/qca9558_devolo_dvl1200e.dts
 create mode 100644 target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi

diff --git a/target/linux/ath79/base-files/etc/board.d/02_network 
b/target/linux/ath79/base-files/etc/board.d/02_network
index 43b537835c..e090396708 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -58,6 +58,9 @@ ath79_setup_interfaces()
ucidef_add_switch "switch0" \
"0@eth0" "1:lan:1" "3:lan:4" "4:lan:3" "5:lan:2" "2:wan"
;;
+   devolo,dvl1200e)
+   ucidef_set_interface_lan "eth0 eth1"
+   ;;
dlink,dir-825-b1)
ucidef_set_interface_wan "eth1"
ucidef_add_switch "switch0" \
diff --git 
a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 82c23e3079..d1b3bbdcb5 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -87,6 +87,10 @@ board=$(board_name)
 case "$FIRMWARE" in
 "ath10k/cal-pci-:00:00.0.bin")
case $board in
+   devolo,dvl1200e)
+   ath10kcal_extract "art" 20480 2116
+   ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary art 0) 
-1)
+   ;;
glinet,gl-x750)
ath10kcal_extract "art" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(cat 
/sys/class/net/eth0/address) +1)
diff --git a/target/linux/ath79/dts/qca9558_devolo_dvl1200e.dts 
b/target/linux/ath79/dts/qca9558_devolo_dvl1200e.dts
new file mode 100644
index 00..185745199d
--- /dev/null
+++ b/target/linux/ath79/dts/qca9558_devolo_dvl1200e.dts
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include 
+#include 
+
+#include "qca9558_devolo_dvl1xxx.dtsi"
+
+/ {
+   compatible = "devolo,dvl1200e", "qca,qca9557";
+   model = "devolo WiFi pro 1200e";
+
+   aliases {
+   led-boot = _blue;
+   led-failsafe = _red;
+   led-running = _blue;
+   led-upgrade = _red;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   status_blue: status_blue {
+   label = "dvl1200e:blue:status";
+   gpios = < 14 GPIO_ACTIVE_LOW>;
+   default-state = "on";
+   };
+
+   status_red: status_red {
+   label = "dvl1200e:red:status";
+   gpios = < 15 GPIO_ACTIVE_LOW>;
+   };
+
+   buzzer {
+   label = "dvl1200e:gpio:buzzer";
+   gpios = < 4 GPIO_ACTIVE_HIGH>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi 
b/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi
new file mode 100644
index 00..17c0a3135d
--- /dev/null
+++ b/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+/*
+ * The hardware of this board family is most likely shared with other devices 
from other manufacturers.
+ * Devolo seems to use hardware from Edimax, namely the Edimax WAP1750.
+ *
+ * The base board is identical but the single models differ in number of 
buttons, ethernet ports,
+ * external console, USB, external / internal antennas and number of spatial

[OpenWrt-Devel] [PATCH v3 2/2] ath79: add support for devolo WiFi pro 1750c

2018-12-17 Thread David Bauer

Hardware

CPU:   Qualcomm Atheros QCA9558
RAM:   128M DDR2
FLASH: 16MiB
ETH:   1x Atheros AR8035 (PoE in)
WiFi2: QCA9558 3T3R
WiFi5: QCA9880 3T3R
BTN:   1x Reset
LED:   1x LED blue
   1x LED red
BUZZ:  1x GPIO attached piezo buzzer (controllable ass LED)
UART:  3.3V GND TX RX (115200-N-8) (3.3V is square pad)
   Header is located next to reset-button

There is also a Micro-B USB-port present but this only seems to be a
dummy as the circuit next to it is not present (at least in my unit).

It is also not mentioned in the devolo manual.

Installation

Make sure you set a password for the root user as prompted on first
setup!

1. Upload OpenWRT sysupgrade image via SSH to the device.
Use /tmp as the destination folder on the device.
User is root, password the one set in the web interface.

2. Install OpenWRT with

> sysupgrade -n -F /tmp/

Signed-off-by: David Bauer 
---
 .../ath79/base-files/etc/board.d/02_network   |  1 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |  3 +-
 .../ath79/dts/qca9558_devolo_dvl1750c.dts | 46 +++
 .../ath79/dts/qca9558_devolo_dvl1xxx.dtsi |  2 +-
 target/linux/ath79/image/generic.mk   |  8 
 5 files changed, 58 insertions(+), 2 deletions(-)
 create mode 100644 target/linux/ath79/dts/qca9558_devolo_dvl1750c.dts

diff --git a/target/linux/ath79/base-files/etc/board.d/02_network 
b/target/linux/ath79/base-files/etc/board.d/02_network
index e090396708..594cadb1e1 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -10,6 +10,7 @@ ath79_setup_interfaces()
 
case "$board" in
avm,fritz300e|\
+   devolo,dvl1750c|\
ocedo,koala|\
ocedo,raccoon|\
pcs,cap324|\
diff --git 
a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index d1b3bbdcb5..681a397efc 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -87,7 +87,8 @@ board=$(board_name)
 case "$FIRMWARE" in
 "ath10k/cal-pci-:00:00.0.bin")
case $board in
-   devolo,dvl1200e)
+   devolo,dvl1200e|\
+   devolo,dvl1750c)
ath10kcal_extract "art" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary art 0) 
-1)
;;
diff --git a/target/linux/ath79/dts/qca9558_devolo_dvl1750c.dts 
b/target/linux/ath79/dts/qca9558_devolo_dvl1750c.dts
new file mode 100644
index 00..20860b6806
--- /dev/null
+++ b/target/linux/ath79/dts/qca9558_devolo_dvl1750c.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include 
+#include 
+
+#include "qca9558_devolo_dvl1xxx.dtsi"
+
+/ {
+   compatible = "devolo,dvl1750c", "qca,qca9557";
+   model = "devolo WiFi pro 1750c";
+
+   aliases {
+   led-boot = _blue;
+   led-failsafe = _red;
+   led-running = _blue;
+   led-upgrade = _red;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   status_blue: status_blue {
+   label = "dvl1750c:blue:status";
+   gpios = < 14 GPIO_ACTIVE_LOW>;
+   default-state = "on";
+   };
+
+   status_red: status_red {
+   label = "dvl1750c:red:status";
+   gpios = < 15 GPIO_ACTIVE_LOW>;
+   };
+
+   buzzer {
+   label = "dvl1750c:gpio:buzzer";
+   gpios = < 21 GPIO_ACTIVE_HIGH>;
+   };
+   };
+};
+
+_config {
+   rxdv-delay = <3>;
+   rxd-delay = <3>;
+   txen-delay = <3>;
+   txd-delay = <3>;
+};
diff --git a/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi 
b/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi
index 17c0a3135d..25f0ed56df 100644
--- a/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi
+++ b/target/linux/ath79/dts/qca9558_devolo_dvl1xxx.dtsi
@@ -120,7 +120,7 @@
 
pll-data = <0xae00 0x8101 0x80001313>;
 
-   gmac-config {
+   gmac_config: gmac-config {
device = <>;
 
rxdv-delay = <3>;
diff --git a/target/linux/ath79/image/generic.mk 
b/target/linux/ath79/image/generic.mk
index 17f55d120c..dafb92773f 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -136,6 +136,14 @@ define Device/devolo_dvl1200e
 endef
 TARGET_DEVICES += devolo_dvl1200e
 
+define Device/devolo_dvl1750c
+  ATH_SOC := qca9558
+  DEVICE_TITLE := devolo WiFi pro 1750c
+  DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca988x-ct
+  IMAGE_SIZE := 15936k
+endef
+TARGET_DEVICES += devolo_dvl1750c
+
 define Device/dlink_dir-825-b1
   ATH_SOC := ar7161
   DEVICE_TITLE := D-LINK DIR-825 B1
-- 
2.20.0

Re: [OpenWrt-Devel] MIPS stack security and other problems

2018-12-17 Thread Rosen Penev

On Mon, Dec 17, 2018 at 4:34 PM Rosen Penev  wrote:
>
> On Mon, Dec 17, 2018 at 3:40 PM Dave Taht  wrote:
> >
> > John Crispin  writes:
> >
> > > On 17/12/2018 23:18, Dave Taht wrote:
> > >> Rosen Penev  writes:
> > >>
> > >>> On Sun, Dec 16, 2018 at 4:54 PM Dave Taht  wrote:
> > 
> >  A pretty deep look at home MIPS and arm routers, and a surprising
> >  bug in Linux/MIPS - by mudge and co:
> > 
> >  https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html
> > 
> >  I have no idea if current openwrt, or what prior releases... are 
> >  subject to
> >  the problems they outline.
> > >>> As of kernel 4.14.88, I see the same problems.
> > >> Well, I see that the stack, at least, on kernel 4.4.92 on mips and
> > >> 4.14 on openwrt 18.06...
> > >>
> > >> is mapped rw only, with no execute bit.
> > >>
> > >> That doesn't mean the other other flaws discussed in the paper don't
> > >> exist, but at least current openwrt HEAD is using the right gcc version
> > >> to turn the right linkage on. Someone here with wy more expertise in
> > >> the compiler, here, should take a hard look at this and the paper.
> > >>
> > >>
> > >> root@lupin-jeff:~# cat /proc/self/maps
> > >> 0040-0044b000 r-xp  1f:04 879/bin/busybox
> > >> 0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox
> > >> 77182000-771a4000 r-xp  1f:04 611/lib/libgcc_s.so.1
> > >> 771a4000-771a5000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1
> > >> 771a6000-77238000 r-xp  1f:04 653/lib/libc.so
> > >> 77245000-77246000 r--p  00:00 0  [vvar]
> > >> 77246000-77247000 r-xp  00:00 0  [vdso]
> > >> 77247000-77249000 rw-p 00091000 1f:04 653/lib/libc.so
> > >> 77249000-7724b000 rwxp  00:00 0 # is this the heap?
> > >> 7fe06000-7fe27000 rw-p  00:00 0  [stack]
> > >>
> > >>
> >  ___
> >  openwrt-devel mailing list
> >  openwrt-devel@lists.openwrt.org
> >  https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> > >> ___
> > >> openwrt-devel mailing list
> > >> openwrt-devel@lists.openwrt.org
> > >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> > >
> > > Dave,
> > >
> > > too lazy to read thd pdf, in a nutshell whats the issue and what do we
> > > need to do do to mitigate it ?
> >
> > From the paper: (It's the second comment regarding ALSR bypass via a
> > deterministic segment that concerns me most). They are claiming that the
> > emulation segment at
> >
> > 7000-8000 rwxp  00:00 0
> >
> > is a bad idea, in the paper. Which openwrt has.
> >
> >
> > "Timeline Key:
> > (A)
> > 2001: Linux introduces FPU emulation in kernel 2.4.3.4. This puts code on 
> > the stack and
> > executes it there requiring the stack be marked as readable, writable, and 
> > executable.
> > (B)
> > 2016 July:  a new page was introduced to execute branch delay slot 
> > instructions. This
> > was introduced to remove the code being inserted and executed on the 
> > program stack.
> > However, this fix introduced a new fixed location segment that can be used 
> > to bypass
> > ASLR defenses.
> > 3
> > (C)
> > 2016 August:  a patch to make the stack and heap non-execute was 
> > introduced, if a
> > PT_GNU_STACK was present. However, as noted in the patch none of the 
> > toolchains
> > used to build executables created a PT_GNU_STACK and the stack would remain
> > executable until this was addressed in compiler toolchains.
> > 4
> > In summary, Linux MIPS binaries have been easier to exploit by way of 
> > classic stack overflow
> > attacks for over a decade, and continue to be so according to our 
> > examination of toolchain
> > patches. Additionally, the fix that moved FPU emulation off the stack 
> > created a separate DEP
> > and
> >
> > ASLR exposure.  Even if patches were introduced today for both the kernel 
> > and the
> > toolchains, the lag in adoption implies it could be years before Linux MIPS 
> > devices can be
> > expected to have basic DEP and ASLR.
> > "
> >
> > Their proof of concept for exploiting this on mipsel is:
> >
> > include 
> > #include 
> > #include 
> > #include 
> >
> > int main(void) {
> > // set a pointer to the vfpu emulation page address
> > void* p = (void *)0x7000;
> > printf("%p\n", (void*)p);
> > // construct a function pointer from p
> > void (*func_ptr)(void) = p;
> > // 'jr $ra' mips32el instruction bytes
> > char code[] = {0x08, 0x00, 0xe0, 0x03, 0x00, 0x00, 0x00, 0x00};
> > // copy the instruction to the vfpu page
> > memcpy(p, code, 8);
> > // call the function pointer, this should then directly return back
> > (*func_ptr)();
> > // print out the current maps of the process
> > char cmd[200];
> > sprintf(cmd, "cat /proc/%d/maps", getpid());
> > system(cmd);
> >

Re: [OpenWrt-Devel] MIPS stack security and other problems

2018-12-17 Thread Rosen Penev

On Mon, Dec 17, 2018 at 3:40 PM Dave Taht  wrote:
>
> John Crispin  writes:
>
> > On 17/12/2018 23:18, Dave Taht wrote:
> >> Rosen Penev  writes:
> >>
> >>> On Sun, Dec 16, 2018 at 4:54 PM Dave Taht  wrote:
> 
>  A pretty deep look at home MIPS and arm routers, and a surprising
>  bug in Linux/MIPS - by mudge and co:
> 
>  https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html
> 
>  I have no idea if current openwrt, or what prior releases... are subject 
>  to
>  the problems they outline.
> >>> As of kernel 4.14.88, I see the same problems.
> >> Well, I see that the stack, at least, on kernel 4.4.92 on mips and
> >> 4.14 on openwrt 18.06...
> >>
> >> is mapped rw only, with no execute bit.
> >>
> >> That doesn't mean the other other flaws discussed in the paper don't
> >> exist, but at least current openwrt HEAD is using the right gcc version
> >> to turn the right linkage on. Someone here with wy more expertise in
> >> the compiler, here, should take a hard look at this and the paper.
> >>
> >>
> >> root@lupin-jeff:~# cat /proc/self/maps
> >> 0040-0044b000 r-xp  1f:04 879/bin/busybox
> >> 0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox
> >> 77182000-771a4000 r-xp  1f:04 611/lib/libgcc_s.so.1
> >> 771a4000-771a5000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1
> >> 771a6000-77238000 r-xp  1f:04 653/lib/libc.so
> >> 77245000-77246000 r--p  00:00 0  [vvar]
> >> 77246000-77247000 r-xp  00:00 0  [vdso]
> >> 77247000-77249000 rw-p 00091000 1f:04 653/lib/libc.so
> >> 77249000-7724b000 rwxp  00:00 0 # is this the heap?
> >> 7fe06000-7fe27000 rw-p  00:00 0  [stack]
> >>
> >>
>  ___
>  openwrt-devel mailing list
>  openwrt-devel@lists.openwrt.org
>  https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >> ___
> >> openwrt-devel mailing list
> >> openwrt-devel@lists.openwrt.org
> >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >
> > Dave,
> >
> > too lazy to read thd pdf, in a nutshell whats the issue and what do we
> > need to do do to mitigate it ?
>
> From the paper: (It's the second comment regarding ALSR bypass via a
> deterministic segment that concerns me most). They are claiming that the
> emulation segment at
>
> 7000-8000 rwxp  00:00 0
>
> is a bad idea, in the paper. Which openwrt has.
>
>
> "Timeline Key:
> (A)
> 2001: Linux introduces FPU emulation in kernel 2.4.3.4. This puts code on the 
> stack and
> executes it there requiring the stack be marked as readable, writable, and 
> executable.
> (B)
> 2016 July:  a new page was introduced to execute branch delay slot 
> instructions. This
> was introduced to remove the code being inserted and executed on the program 
> stack.
> However, this fix introduced a new fixed location segment that can be used to 
> bypass
> ASLR defenses.
> 3
> (C)
> 2016 August:  a patch to make the stack and heap non-execute was introduced, 
> if a
> PT_GNU_STACK was present. However, as noted in the patch none of the 
> toolchains
> used to build executables created a PT_GNU_STACK and the stack would remain
> executable until this was addressed in compiler toolchains.
> 4
> In summary, Linux MIPS binaries have been easier to exploit by way of classic 
> stack overflow
> attacks for over a decade, and continue to be so according to our examination 
> of toolchain
> patches. Additionally, the fix that moved FPU emulation off the stack created 
> a separate DEP
> and
>
> ASLR exposure.  Even if patches were introduced today for both the kernel and 
> the
> toolchains, the lag in adoption implies it could be years before Linux MIPS 
> devices can be
> expected to have basic DEP and ASLR.
> "
>
> Their proof of concept for exploiting this on mipsel is:
>
> include 
> #include 
> #include 
> #include 
>
> int main(void) {
> // set a pointer to the vfpu emulation page address
> void* p = (void *)0x7000;
> printf("%p\n", (void*)p);
> // construct a function pointer from p
> void (*func_ptr)(void) = p;
> // 'jr $ra' mips32el instruction bytes
> char code[] = {0x08, 0x00, 0xe0, 0x03, 0x00, 0x00, 0x00, 0x00};
> // copy the instruction to the vfpu page
> memcpy(p, code, 8);
> // call the function pointer, this should then directly return back
> (*func_ptr)();
> // print out the current maps of the process
> char cmd[200];
> sprintf(cmd, "cat /proc/%d/maps", getpid());
> system(cmd);
> return 0;
> }
I tested this. Output on current master:

root@OpenWrt:/tmp# ./a.out
0x7000[ 1213.393861] do_page_fault(): sending SIGSEGV to a.out for
invalid write access to 7003

[ 1213.402945] epc = 555757ac in a.out[55575000+1000]
[ 1213.407816] ra  = 55575774 in a.out[55575000+1000]
Segmentation

Re: [OpenWrt-Devel] MIPS stack security and other problems

2018-12-17 Thread Rosen Penev

On Mon, Dec 17, 2018 at 2:49 PM John Crispin  wrote:
>
>
> On 17/12/2018 23:18, Dave Taht wrote:
> > Rosen Penev  writes:
> >
> >> On Sun, Dec 16, 2018 at 4:54 PM Dave Taht  wrote:
> >>>
> >>> A pretty deep look at home MIPS and arm routers, and a surprising
> >>> bug in Linux/MIPS - by mudge and co:
> >>>
> >>> https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html
> >>>
> >>> I have no idea if current openwrt, or what prior releases... are subject 
> >>> to
> >>> the problems they outline.
> >> As of kernel 4.14.88, I see the same problems.
> > Well, I see that the stack, at least, on kernel 4.4.92 on mips and
> > 4.14 on openwrt 18.06...
> >
> > is mapped rw only, with no execute bit.
> >
> > That doesn't mean the other other flaws discussed in the paper don't
> > exist, but at least current openwrt HEAD is using the right gcc version
> > to turn the right linkage on. Someone here with wy more expertise in
> > the compiler, here, should take a hard look at this and the paper.
> >
> >
> > root@lupin-jeff:~# cat /proc/self/maps
> > 0040-0044b000 r-xp  1f:04 879/bin/busybox
> > 0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox
> > 77182000-771a4000 r-xp  1f:04 611/lib/libgcc_s.so.1
> > 771a4000-771a5000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1
> > 771a6000-77238000 r-xp  1f:04 653/lib/libc.so
> > 77245000-77246000 r--p  00:00 0  [vvar]
> > 77246000-77247000 r-xp  00:00 0  [vdso]
> > 77247000-77249000 rw-p 00091000 1f:04 653/lib/libc.so
> > 77249000-7724b000 rwxp  00:00 0 # is this the heap?
> > 7fe06000-7fe27000 rw-p  00:00 0  [stack]
> >
> >
> >>> ___
> >>> openwrt-devel mailing list
> >>> openwrt-devel@lists.openwrt.org
> >>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> Dave,
>
> too lazy to read thd pdf, in a nutshell whats the issue and what do we
> need to do do to mitigate it ?
Mostly nothing. Main problem that they find is the lack of GNU_STACK
in program headers in MIPS binaries.

However on master builds, the headers are there.

There's also the issue of rwx mappings caused by enabling softfloat.
But the heap and stack seem to be rw and not x.
>
>  John
>
>
>
>

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] kernel: Fix rtc-ds1307 dependency on hwmon-core for 4.19

2018-12-17 Thread Petr Štetiar

It seems, that since Linux 4.18-rc1 rtc-ds1307 depends on hwmon-core.

 commit 6b583a64fd1e019fd01626b46892ebf2361951c5
 Author: Heiner Kallweit 
 Date:   Wed Sep 27 22:41:26 2017 +0200

rtc: ds1307: simplify hwmon config

We don't have to define an extra config symbol, IS_REACHABLE does
what we need. And having this config symbol just to save the few
bytes of hwmon support on non-DS3231 chips isn't worth it IMO
(especially as the symbol is set per default).

Signed-off-by: Petr Štetiar 
---
 package/kernel/linux/modules/other.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/kernel/linux/modules/other.mk 
b/package/kernel/linux/modules/other.mk
index c521405..c9f4c33 100644
--- a/package/kernel/linux/modules/other.mk
+++ b/package/kernel/linux/modules/other.mk
@@ -476,7 +476,7 @@ define KernelPackage/rtc-ds1307
   SUBMENU:=$(OTHER_MENU)
   TITLE:=Dallas/Maxim DS1307 (and compatible) RTC support
   DEFAULT:=m if ALL_KMODS && RTC_SUPPORT
-  DEPENDS:=+kmod-i2c-core +LINUX_4_14:kmod-regmap
+  DEPENDS:=+kmod-i2c-core +LINUX_4_14:kmod-regmap +LINUX_4_19:kmod-hwmon-core
   KCONFIG:=CONFIG_RTC_DRV_DS1307 \
CONFIG_RTC_CLASS=y
   FILES:=$(LINUX_DIR)/drivers/rtc/rtc-ds1307.ko
-- 
1.9.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MIPS stack security and other problems

2018-12-17 Thread Dave Taht

John Crispin  writes:

> On 17/12/2018 23:18, Dave Taht wrote:
>> Rosen Penev  writes:
>>
>>> On Sun, Dec 16, 2018 at 4:54 PM Dave Taht  wrote:

 A pretty deep look at home MIPS and arm routers, and a surprising
 bug in Linux/MIPS - by mudge and co:

 https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html

 I have no idea if current openwrt, or what prior releases... are subject to
 the problems they outline.
>>> As of kernel 4.14.88, I see the same problems.
>> Well, I see that the stack, at least, on kernel 4.4.92 on mips and
>> 4.14 on openwrt 18.06...
>>
>> is mapped rw only, with no execute bit.
>>
>> That doesn't mean the other other flaws discussed in the paper don't
>> exist, but at least current openwrt HEAD is using the right gcc version
>> to turn the right linkage on. Someone here with wy more expertise in
>> the compiler, here, should take a hard look at this and the paper.
>>
>>
>> root@lupin-jeff:~# cat /proc/self/maps
>> 0040-0044b000 r-xp  1f:04 879/bin/busybox
>> 0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox
>> 77182000-771a4000 r-xp  1f:04 611/lib/libgcc_s.so.1
>> 771a4000-771a5000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1
>> 771a6000-77238000 r-xp  1f:04 653/lib/libc.so
>> 77245000-77246000 r--p  00:00 0  [vvar]
>> 77246000-77247000 r-xp  00:00 0  [vdso]
>> 77247000-77249000 rw-p 00091000 1f:04 653/lib/libc.so
>> 77249000-7724b000 rwxp  00:00 0 # is this the heap?
>> 7fe06000-7fe27000 rw-p  00:00 0  [stack]
>>
>>
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> Dave,
>
> too lazy to read thd pdf, in a nutshell whats the issue and what do we
> need to do do to mitigate it ?

From the paper: (It's the second comment regarding ALSR bypass via a
deterministic segment that concerns me most). They are claiming that the
emulation segment at

7000-8000 rwxp  00:00 0 

is a bad idea, in the paper. Which openwrt has.

"Timeline Key:
(A)
2001: Linux introduces FPU emulation in kernel 2.4.3.4. This puts code on the 
stack and
executes it there requiring the stack be marked as readable, writable, and 
executable.
(B)
2016 July:  a new page was introduced to execute branch delay slot 
instructions. This
was introduced to remove the code being inserted and executed on the program 
stack.
However, this fix introduced a new fixed location segment that can be used to 
bypass
ASLR defenses.
3
(C)
2016 August:  a patch to make the stack and heap non-execute was introduced, if 
a
PT_GNU_STACK was present. However, as noted in the patch none of the toolchains
used to build executables created a PT_GNU_STACK and the stack would remain
executable until this was addressed in compiler toolchains.
4
In summary, Linux MIPS binaries have been easier to exploit by way of classic 
stack overflow
attacks for over a decade, and continue to be so according to our examination 
of toolchain
patches. Additionally, the fix that moved FPU emulation off the stack created a 
separate DEP
and 

ASLR exposure.  Even if patches were introduced today for both the kernel and 
the
toolchains, the lag in adoption implies it could be years before Linux MIPS 
devices can be
expected to have basic DEP and ASLR.
"

Their proof of concept for exploiting this on mipsel is:

include 
#include 
#include 
#include 

int main(void) {
// set a pointer to the vfpu emulation page address
void* p = (void *)0x7000;
printf("%p\n", (void*)p);
// construct a function pointer from p
void (*func_ptr)(void) = p;
// 'jr $ra' mips32el instruction bytes
char code[] = {0x08, 0x00, 0xe0, 0x03, 0x00, 0x00, 0x00, 0x00};
// copy the instruction to the vfpu page
memcpy(p, code, 8);
// call the function pointer, this should then directly return back
(*func_ptr)();
// print out the current maps of the process
char cmd[200];
sprintf(cmd, "cat /proc/%d/maps", getpid());
system(cmd);
return 0;
}

>
>     John
>
>
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] kernel: Fix usb-chipidea dependency on ulpi.ko for 4.19

2018-12-17 Thread Petr Štetiar

It seems, that since Linux 4.18-rc2 ci_hdrc depends on ulpi.

 commit a930d8bd94d8db7715d1af74299f710b1fb22fc8
 Author: Fabio Estevam 
 Date:   Wed Jul 4 10:09:58 2018 -0300

usb: chipidea: Always build ULPI code

Commit 03e6275ae381 ("usb: chipidea: Fix ULPI on imx51") causes a kernel
hang on imx51 systems that use the ULPI interface and do not select the
CONFIG_USB_CHIPIDEA_ULPI option.

In order to avoid such potential misuse, let's always build the
chipidea ULPI code into the final ci_hdrc object.

Signed-off-by: Petr Štetiar 
---
 package/kernel/linux/modules/usb.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/kernel/linux/modules/usb.mk 
b/package/kernel/linux/modules/usb.mk
index 748e7ed..fafa9a0 100644
--- a/package/kernel/linux/modules/usb.mk
+++ b/package/kernel/linux/modules/usb.mk
@@ -1565,7 +1565,8 @@ define KernelPackage/usb-chipidea
   FILES:= \
$(LINUX_DIR)/drivers/extcon/extcon.ko@lt4.9 \
$(LINUX_DIR)/drivers/extcon/extcon-core.ko@ge4.9 \
-   $(LINUX_DIR)/drivers/usb/chipidea/ci_hdrc.ko
+   $(LINUX_DIR)/drivers/usb/chipidea/ci_hdrc.ko \
+   $(LINUX_DIR)/drivers/usb/common/ulpi.ko@ge4.18
   AUTOLOAD:=$(call AutoLoad,39,ci_hdrc,1)
   $(call AddDepends/usb)
 endef
-- 
1.9.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MIPS stack security and other problems

2018-12-17 Thread John Crispin



On 17/12/2018 23:18, Dave Taht wrote:

Rosen Penev  writes:


On Sun, Dec 16, 2018 at 4:54 PM Dave Taht  wrote:


A pretty deep look at home MIPS and arm routers, and a surprising
bug in Linux/MIPS - by mudge and co:

https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html

I have no idea if current openwrt, or what prior releases... are subject to
the problems they outline.

As of kernel 4.14.88, I see the same problems.

Well, I see that the stack, at least, on kernel 4.4.92 on mips and
4.14 on openwrt 18.06...

is mapped rw only, with no execute bit.

That doesn't mean the other other flaws discussed in the paper don't
exist, but at least current openwrt HEAD is using the right gcc version
to turn the right linkage on. Someone here with wy more expertise in
the compiler, here, should take a hard look at this and the paper.


root@lupin-jeff:~# cat /proc/self/maps
0040-0044b000 r-xp  1f:04 879/bin/busybox
0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox
77182000-771a4000 r-xp  1f:04 611/lib/libgcc_s.so.1
771a4000-771a5000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1
771a6000-77238000 r-xp  1f:04 653/lib/libc.so
77245000-77246000 r--p  00:00 0  [vvar]
77246000-77247000 r-xp  00:00 0  [vdso]
77247000-77249000 rw-p 00091000 1f:04 653/lib/libc.so
77249000-7724b000 rwxp  00:00 0 # is this the heap?
7fe06000-7fe27000 rw-p  00:00 0  [stack]



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Dave,

too lazy to read thd pdf, in a nutshell whats the issue and what do we 
need to do do to mitigate it ?


    John





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] kernel: Fix kmod-w1 dependency on hwmon-core for 4.19

2018-12-17 Thread Petr Štetiar

kmod-w1 depends on kmod-hwmon-core since Linux 4.14

Signed-off-by: Petr Štetiar 
---
 package/kernel/linux/modules/w1.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/kernel/linux/modules/w1.mk 
b/package/kernel/linux/modules/w1.mk
index e936a28..d9f20c7 100644
--- a/package/kernel/linux/modules/w1.mk
+++ b/package/kernel/linux/modules/w1.mk
@@ -14,7 +14,7 @@ define KernelPackage/w1
   TITLE:=Dallas's 1-wire support
   KCONFIG:=CONFIG_W1
   FILES:=$(LINUX_DIR)/drivers/w1/wire.ko
-  DEPENDS:=+LINUX_4_14:kmod-hwmon-core
+  DEPENDS:=+LINUX_4_14:kmod-hwmon-core +LINUX_4_19:kmod-hwmon-core
 endef
 
 define KernelPackage/w1/description
-- 
1.9.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ipq806x: add ath10k calibration data MAC addresses patching

2018-12-17 Thread Mathias Kresin


17/12/2018 19:05, Christian Lamparter:

On Saturday, December 15, 2018 9:10:39 PM CET Christian Lamparter wrote:

On Wednesday, November 14, 2018 8:39:22 PM CET Ben Greear wrote:

On 11/01/2018 03:18 AM, Felix Fietkau wrote:

On 2018-10-28 17:39, Christian Lamparter wrote:

Ben Greear reported in his patch:
|Subject: netgear r7800: Fix mac address of radios.
|
|Reloading the driver causes the phyX to change, and that
|caused the MAC address to change.

This is because all ODM/OEMs except QCA bothered to write
the correct MAC address for the ath10k wifi into the
calibration data.

I don't think that's a strong enough reason to further propagate the
messy calibration data patching.
How about checking the sysfs device path in the hotplug script instead
to make sure we're changing the MAC for the right wifi device?


Would this mean that the NIC is loaded with one (potentially bogus)
MAC, and then hotplug would very soon after set the proper MAC?

If so, that is liable to mess up stock ath10k firmware since it will not
properly calculate its rx-bssid mask.


Let's test it then.

Ben, Felix: I've prepared a big, one in all, test patch for the R7800 -
that if viable will be split up, upstreamed and merged accordingly.

This patch contains:

0. ath10k and ath10k-ct fixes that implement Felix request to
"call pdev_set_base_macaddr_cmdid before bringing up the first vif".
This is in the "976-ath10k-implement-set-base-macaddr" patch.
(Note: the ath10k driver had no support code for this function, nor
does it mention what the data the pdev_set_base_macaddr_cmdid takes.
I assume it's just 6-bytes for the base MAC.)

Ben: Can you please comment if this is all right, or if something
 needs to be changed?

1. 998-ath10k-retrieve-MAC-address-from-system-firmware-if-.patch
This is an upstream patch

2. 950-call-of_get_mac_address-from-device.patch
A hack that makes it work. This could be a point of conflict.

3. R7800 dts changes
I hope they are correct enough. I don't have the hardware to test
it.

4. (userspace code).

In the mean time, because this is so much new, experimental stuff. I'll go
ahead with the ugly firmware patching for now until this is ready for
prime time.

Regards,
Christian



Update: Mathias wrote me yesterday that the ath10k-ct was not working because
the ath10k-ct driver now uses the ath10k-4.19 branch. This (and the missing
"retrieve MAC address from system firmware if provided" for ath10k-ct) patch
has been fixed.


The (updated) patches from your staging tree are working fine.

Tested on a Homehub 5a (QCA9880) with ath10k and ath10k-ct using the 
following changes:


diff --git 
a/target/linux/lantiq/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/lantiq/base-files/etc/hotplug.d/firmware/11-ath10k-caldata

index 6b4d09dd33..65038180bb 100644
--- 
a/target/linux/lantiq/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ 
b/target/linux/lantiq/base-files/etc/hotplug.d/firmware/11-ath10k-caldata

@@ -40,7 +40,6 @@ case "$FIRMWARE" in
case $board in
bt,homehub-v5a)
ath10k_caldata_extract_ubi "caldata" 20480 2116
-			ath10k_caldata_set_macaddr $(macaddr_add $(mtd_get_mac_binary_ubi 
caldata 4364) +3)

;;
*)
ath10k_caldata_die "board $board is not supported yet"
diff --git 
a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/BTHOMEHUBV5A.dts 
b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/BTHOMEHUBV5A.dts

index c251fc3fc7..3db3a7af19 100644
--- a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/BTHOMEHUBV5A.dts
+++ b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/BTHOMEHUBV5A.dts
@@ -253,7 +253,7 @@
#address-cells = <1>;
#size-cells = <1>;

-   partition@0 {
+   fake: partition@0 {
label = "u-boot";
reg = <0x0 0xa>;
read-only;
@@ -278,6 +278,21 @@
};
 };

+ {
+   bridge@1,0 {
+   #size-cells = <2>;
+   #address-cells = <3>;
+   reg = <0x1 0 0 0 0>;
+   ranges;
+
+   wifi@2,0 {
+   compatible = "pci168c,003c";
+   reg = <0x2 0 0 0 0>;
+   mtd-mac-address = < 0>;
+   };
+   };
+};
+
  {
status = "okay";
gpio-reset = < 21 GPIO_ACTIVE_HIGH>;

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] MIPS stack security and other problems

2018-12-17 Thread Dave Taht

Rosen Penev  writes:

> On Sun, Dec 16, 2018 at 4:54 PM Dave Taht  wrote:
>>
>>
>> A pretty deep look at home MIPS and arm routers, and a surprising
>> bug in Linux/MIPS - by mudge and co:
>>
>> https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html
>>
>> I have no idea if current openwrt, or what prior releases... are subject to
>> the problems they outline.
> As of kernel 4.14.88, I see the same problems.

Well, I see that the stack, at least, on kernel 4.4.92 on mips and
4.14 on openwrt 18.06...

is mapped rw only, with no execute bit.

That doesn't mean the other other flaws discussed in the paper don't
exist, but at least current openwrt HEAD is using the right gcc version
to turn the right linkage on. Someone here with wy more expertise in
the compiler, here, should take a hard look at this and the paper.


root@lupin-jeff:~# cat /proc/self/maps
0040-0044b000 r-xp  1f:04 879/bin/busybox
0045b000-0045c000 rw-p 0004b000 1f:04 879/bin/busybox
77182000-771a4000 r-xp  1f:04 611/lib/libgcc_s.so.1
771a4000-771a5000 rw-p 00012000 1f:04 611/lib/libgcc_s.so.1
771a6000-77238000 r-xp  1f:04 653/lib/libc.so
77245000-77246000 r--p  00:00 0  [vvar]
77246000-77247000 r-xp  00:00 0  [vdso]
77247000-77249000 rw-p 00091000 1f:04 653/lib/libc.so
77249000-7724b000 rwxp  00:00 0 # is this the heap?
7fe06000-7fe27000 rw-p  00:00 0  [stack]


>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ipq40xx: add support for ASUS Lyra

2018-12-17 Thread Marius Genheimer

SoC:   Qualcomm IPQ4019 (Dakota) 717 MHz, 4 cores
RAM:   256 MiB (Nanya NT5CC128M16IP-DI)
FLASH: 128 MiB (Macronix NAND)
WiFi0: Qualcomm IPQ4019 b/g/n 2x2
WiFi1: Qualcomm IPQ4019 a/n/ac 2x2
WiFi2: Qualcomm Atheros QCA9886 a/n/ac
BT:Atheros AR3012
IN:WPS Button, Reset Button
OUT:   RGB-LED via TI LP5523 9-channel Controller
UART:  Front of Device - 115200 N-8
   Pinout 3.3v - RX - TX - GND (Square is VCC)

Installation:
1. Transfer OpenWRT-initrams image to the device via SSH to /tmp.
Login credentials are identical to the Web UI.

2. Login to the device via SSH.

3. Flash the initramfs image using

> mtd-write -d linux -i openwrt-image-file

4. Power-cycle the device and wait for OpenWRT to boot.

5. From there flash the OpenWRT-sysupgrade image.

Ethernet-Ports: Although labeled identically, the port next to
the power socket is the LAN port and the other one is WAN. This
ist the same behavior as in the stock firmware.

Signed-off-by: Marius Genheimer 
---
 package/firmware/ipq-wifi/Makefile |   2 +
 package/firmware/ipq-wifi/map-ac2200.bin   | Bin 0 -> 24324 bytes
 .../ipq40xx/base-files/etc/board.d/02_network  |   8 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata   |   9 +
 .../ipq40xx/base-files/lib/upgrade/platform.sh |   4 +
 target/linux/ipq40xx/config-4.14   |   1 +
 .../arch/arm/boot/dts/qcom-ipq4019-map-ac2200.dts  | 311 +
 target/linux/ipq40xx/image/Makefile|  11 +
 .../patches-4.14/901-arm-boot-add-dts-files.patch  |   3 +-
 9 files changed, 348 insertions(+), 1 deletion(-)
 create mode 100644 package/firmware/ipq-wifi/map-ac2200.bin
 create mode 100644 
target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4019-map-ac2200.dts

diff --git a/package/firmware/ipq-wifi/Makefile 
b/package/firmware/ipq-wifi/Makefile
index 4b39f970dd..d5d039d93b 100644
--- a/package/firmware/ipq-wifi/Makefile
+++ b/package/firmware/ipq-wifi/Makefile
@@ -54,4 +54,6 @@ endef
 #$(eval $(call 
generate-ipq-wifi-package,,,))
 $(eval $(call 
generate-ipq-wifi-package,engenius_eap1300,board-engenius_eap1300.bin,EnGenius 
EAP1300))
 
+$(eval $(call generate-ipq-wifi-package,map-ac2200,map-ac2200.bin,ASUS 
MAP-AC2200))
+
 $(foreach PACKAGE,$(ALLWIFIPACKAGES),$(eval $(call BuildPackage,$(PACKAGE
diff --git a/package/firmware/ipq-wifi/map-ac2200.bin 
b/package/firmware/ipq-wifi/map-ac2200.bin
new file mode 100644
index 
..372936010a4723ee0197dc56cbfd3a193e559552
GIT binary patch
literal 24324
zcmeHPeNak-f$|Vq#_}SHh=UL>2J)qF*bY=ny#pH1~^Bu7H`L7>iDn%Zh=dF6z`3y}w9AY!C+OCE1C;w!|6
z4#_g)hDOlH9Z#fVlE+kc4tui2_PEy_7?-$Wlan`;i4|
zZ}OE7T_~=LD-@{$l%I81zq|RUxO~kkAN5wXY}abidr3|5tGrb24I`b!htrBf
zvwRhoE~=YT>ep2T6b@akJQsN=sKh(($wG;amO{XT_0;mGS7P2it5yfB38KF7EjjTW
zYZ1!JDu){)xV>O7nM?+8c60Oa@K|CN*4JH)2l76DYm1O05b)t&2roF8@9vfY>3
zdrx9D8eNzZ0*#H8mD{!{lci|+@+C{iuB4(6K93g!1rF;!zl@LjfJWK~;~GyE)7|}l
zrlt%b)D!(Va{B;C=+UFFDlEMHCt%TdG*(h^@X+D68%|!Jl;#NqMaPmdFrmoIa_s>M8)u8zci5Oe
z?l1ONdf{G}AD)OOiWBc7Vrh7qI87-dF%0AP!I_;YnjjSUR3APFKd@F=H`U93Cf*Q<|=a
zc}0-dCWu(t?GHYiP$L1G)0tSiC2t%0CZ~`_Wwtg~xF@COV9(X3QKC_r
z0Rehx%m9p)c~PQdg#cZk5ug#E5ug#E5ug!R#0adCtipoWFG^m-HnZ1D)?@MPrIet|
zf~E@tBa_djXKja1)5my<5~q!^h%X^Mbyq>aPS%2}?j$I873v4?A_VyXeaGP4sX4r<
zhIiC>;A#$^~`egSK#NJP=cSekO%@InP;0wqOu$5a7286v~eGDFeHyf
zNYBO?z95a}{FFHtF2#@x$=u}#L%$ml)gly)_!vT5Al~qR~{*b_ZOUna6dzlTKR
zrsU<0Ay%yiw+rg;efb^w>Z|WeIiVAY7S~1Ke!nM&$=nS)5C}1t?n~bVIS)e3_$tU;
zY|0(*<=Qd$#Y}lvXoz4w6S;Fo?$wdIbIL8-cI?XAU8rw7)!f$6+11xSc=h@xpMG)I
z@e1VdE$fr!fK2Fv
z{ZyX^mN^^_A`=+<=HgiG$^*K`7VR<~(Gk!cFTy$+_vn_1)rI>)UUMa#~B<
zhQE_?+jcEwZEG7HZR_y#wC2Q6wT|bDayyrvv^@)D0itA2*v@H#=@8lqU(gkPOmyjw
z3{$FuyzW~DIv`-8o<1h({eg+@UUfrbGIzA{x;u*B=z%aFHxHI`LZEx05ug!RbO`L&
zk(ohq?0^3G$A3=d*b}__|9BGYtSsb`}_a++n>Jw{;yzL2{*eI|DS#u`=0cd
z$zr3(KF7!Z{R3%pCa|`6_mPoeF_FX(;o)nAz`4hrqlK?qYwC`RJ4dsHgDu{@g>FB=
zeV=%HbB%f^vrBojyn8AXm!ZGU+l1_SheED}$!AlzY8*6lXf}Y54GO3{Bc1RiczjI9$IK7KTjC
zG}>%!_UK2(HhqO=t7^URBmEgoS`0f&>?*C~e^x57kd^qR3E?(~gkY-YjK>WX`aB59U^t>L)vAmi7|v;mQWB(*qaPbD=`rT(OY
zD3q8(li{F#k2V7;+w})DTU3z{NQ<^Yl`a*HUNN54muWVq2ndHyZixV;4~JU}<@#K$
zV)QChmTPxu(jd(9fTdiDLv5R(N|Thb+T`#l%)t>^fVcW|NcLPn8YLQ~84z%Vr7^?Q
zX!D{)pm|{5rT9}3x`4{_#$UB6j)(-naiu@?lY_e}QN6*{J2ewn}w=VE?7W
zlaacBih=$;hO`swejQMJyd%3I`XE=cGUK!E*PGEq4Td?k>Ar_^`5*zShK27-h3tLIg+U#@T2To+sEr}9ksu=nND(zk+&
zd~z=u)#nt)xfNJmcW=2tc7#{zr5Zd}){s;aUgVqk`TJ?d!mC@!HDGfPQTbyd^YYdzl@W6wmZKi;aG4vJNMK@^;uaRzubG*
zI}O|4h}H0RvgHFkFU9<~_o;Zzw3m{Mop}E(fL;lWhvQ~#
zmNq)Rx!||(*LySy1twG|uxL8rCp!h6kbngv2cG=0PEjq9(r#Juyd@Z7GToQ$g51js
zF%-bZU;CV(bm7mFj=0=$yFPssy!ff(IlDX)-=4D1C+D6R`|?LmTWCCC6}F~8+a3=B_UswY#I>Jnw?w-x);YSRm-*D@z`Msy
OaX
+#include 
+#include 
+
+/ {
+   model = "ASUS Lyra MAP-AC2200";
+   compatible = "asus,map-ac2200", "qcom,ipq4019";
+
+   aliases {
+   led-boot = _blue0;
+   led-failsafe = _red0;
+   led-running = _blue0;
+   led-upgrade = _red0;
+   };
+
+   soc {
+

[OpenWrt-Devel] [PATCH] kernel: Add missing symbols to 4.19

2018-12-17 Thread Petr Štetiar

While building 4.19 for ath79 with CONFIG_ALL_KMODS=y with verbose mode
enabled I was asked by kernel config about few symbols/modules so I'm
adding those missing symbols to the generic config.

Signed-off-by: Petr Štetiar 
---
 target/linux/generic/config-4.19 | 4 
 1 file changed, 4 insertions(+)

diff --git a/target/linux/generic/config-4.19 b/target/linux/generic/config-4.19
index 4a956a9..dc3d80b 100644
--- a/target/linux/generic/config-4.19
+++ b/target/linux/generic/config-4.19
@@ -3661,7 +3661,10 @@ CONFIG_PCI_SYSCALL=y
 # CONFIG_PHY_PXA_28NM_HSIC is not set
 # CONFIG_PHY_PXA_28NM_USB2 is not set
 # CONFIG_PHY_QCOM_DWC3 is not set
+# CONFIG_PHY_QCOM_USB_HS is not set
+# CONFIG_PHY_QCOM_USB_HSIC is not set
 # CONFIG_PHY_SAMSUNG_USB2 is not set
+# CONFIG_PHY_TUSB1210 is not set
 # CONFIG_PHY_XGENE is not set
 # CONFIG_PI433 is not set
 # CONFIG_PID_IN_CONTEXTIDR is not set
@@ -5326,6 +5329,7 @@ CONFIG_USB_DEFAULT_PERSIST=y
 # CONFIG_USB_DWC3_OF_SIMPLE is not set
 # CONFIG_USB_DWC3_PCI is not set
 # CONFIG_USB_DWC3_QCOM is not set
+# CONFIG_USB_DWC3_ULPI is not set
 # CONFIG_USB_DYNAMIC_MINORS is not set
 # CONFIG_USB_EG20T is not set
 # CONFIG_USB_EHCI_ATH79 is not set
-- 
1.9.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Missing GPG signatures

2018-12-17 Thread Jo-Philipp Wich

Hi,

> It seems only Robert Call of the LibreCMC fork is consistently signing 
> releases
> with the same key. But how is he verifying upstream...?

probably by trusting https://openwrt.org/docs/guide-user/security/signatures


I cross-signed the 18.06 key with the 17.01 one now and signed both
using my personal key.

~ Jo



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ipq806x: add ath10k calibration data MAC addresses patching

2018-12-17 Thread Christian Lamparter

On Saturday, December 15, 2018 9:10:39 PM CET Christian Lamparter wrote:
> On Wednesday, November 14, 2018 8:39:22 PM CET Ben Greear wrote:
> > On 11/01/2018 03:18 AM, Felix Fietkau wrote:
> > > On 2018-10-28 17:39, Christian Lamparter wrote:
> > >> Ben Greear reported in his patch:
> > >> |Subject: netgear r7800: Fix mac address of radios.
> > >> |
> > >> |Reloading the driver causes the phyX to change, and that
> > >> |caused the MAC address to change.
> > >>
> > >> This is because all ODM/OEMs except QCA bothered to write
> > >> the correct MAC address for the ath10k wifi into the
> > >> calibration data.
> > > I don't think that's a strong enough reason to further propagate the
> > > messy calibration data patching.
> > > How about checking the sysfs device path in the hotplug script instead
> > > to make sure we're changing the MAC for the right wifi device?
> > 
> > Would this mean that the NIC is loaded with one (potentially bogus)
> > MAC, and then hotplug would very soon after set the proper MAC?
> > 
> > If so, that is liable to mess up stock ath10k firmware since it will not
> > properly calculate its rx-bssid mask.
> 
> Let's test it then.
> 
> Ben, Felix: I've prepared a big, one in all, test patch for the R7800 -
> that if viable will be split up, upstreamed and merged accordingly.
> 
> This patch contains:
> 
> 0. ath10k and ath10k-ct fixes that implement Felix request to 
>"call pdev_set_base_macaddr_cmdid before bringing up the first vif".
>This is in the "976-ath10k-implement-set-base-macaddr" patch.
>(Note: the ath10k driver had no support code for this function, nor
>does it mention what the data the pdev_set_base_macaddr_cmdid takes.
>I assume it's just 6-bytes for the base MAC.) 
> 
>Ben: Can you please comment if this is all right, or if something
> needs to be changed? 
> 
> 1. 998-ath10k-retrieve-MAC-address-from-system-firmware-if-.patch
>This is an upstream patch
> 
> 2. 950-call-of_get_mac_address-from-device.patch
>A hack that makes it work. This could be a point of conflict.
> 
> 3. R7800 dts changes
>I hope they are correct enough. I don't have the hardware to test
>it.
> 
> 4. (userspace code).
> 
> In the mean time, because this is so much new, experimental stuff. I'll go
> ahead with the ugly firmware patching for now until this is ready for
> prime time.
> 
> Regards,
> Christian
> 

Update: Mathias wrote me yesterday that the ath10k-ct was not working because
the ath10k-ct driver now uses the ath10k-4.19 branch. This (and the missing
"retrieve MAC address from system firmware if provided" for ath10k-ct) patch
has been fixed.


---
>From d0b9a5338aca246f77e12cb6858df926252dea90 Mon Sep 17 00:00:00 2001
From: Christian Lamparter 
Date: Sat, 15 Dec 2018 10:56:14 +0100
Subject: [PATCH] ipq806x: R7800: mtd-mac-address test

---
 ...76-ath10k-implement-set-base-macaddr.patch | 172 ++
 ...MAC-address-from-system-firmware-if-.patch |  48 +
 ...77-ath10k-implement-set-base-macaddr.patch | 172 ++
 ...MAC-address-from-system-firmware-if-.patch |  51 ++
 ...-call-of_get_mac_address-from-device.patch |  23 +++
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |   3 +-
 .../arch/arm/boot/dts/qcom-ipq8065-r7800.dts  |  34 +++-
 7 files changed, 499 insertions(+), 4 deletions(-)
 create mode 100644 
package/kernel/ath10k-ct/patches/976-ath10k-implement-set-base-macaddr.patch
 create mode 100644 
package/kernel/ath10k-ct/patches/998-ath10k-retrieve-MAC-address-from-system-firmware-if-.patch
 create mode 100644 
package/kernel/mac80211/patches/ath/977-ath10k-implement-set-base-macaddr.patch
 create mode 100644 
package/kernel/mac80211/patches/ath/998-ath10k-retrieve-MAC-address-from-system-firmware-if-.patch
 create mode 100644 
target/linux/generic/hack-4.14/950-call-of_get_mac_address-from-device.patch

diff --git 
a/package/kernel/ath10k-ct/patches/976-ath10k-implement-set-base-macaddr.patch 
b/package/kernel/ath10k-ct/patches/976-ath10k-implement-set-base-macaddr.patch
new file mode 100644
index 00..23495b17cf
--- /dev/null
+++ 
b/package/kernel/ath10k-ct/patches/976-ath10k-implement-set-base-macaddr.patch
@@ -0,0 +1,172 @@
+--- a/ath10k-4.19/core.c
 b/ath10k-4.19/core.c
+@@ -2938,6 +2938,13 @@ int ath10k_core_start(struct ath10k *ar,
+   goto err_hif_stop;
+   }
+ 
++  status = ath10k_wmi_pdev_set_base_macaddr(ar, ar->mac_addr);
++  if (status) {
++  ath10k_err(ar,
++ "failed to set base mac address: %d\n", status);
++  goto err_hif_stop;
++  }
++
+   /* Some firmware revisions do not properly set up hardware rx filter
+* registers.
+*
+--- a/ath10k-4.19/wmi-ops.h
 b/ath10k-4.19/wmi-ops.h
+@@ -64,6 +64,8 @@ struct wmi_ops {
+ 
+   enum wmi_txbf_conf (*get_txbf_conf_scheme)(struct ath10k *ar);
+ 
++  struct sk_buff *(*gen_pdev_set_base_macaddr)(struct ath10k *ar,
++

[OpenWrt-Devel] [PATCH] hotplug: Allow renaming wireless phy devices.

2018-12-17 Thread greearb

From: Ben Greear 

uci set wireless.@wifi-device[0].phyname=wiphy0

Then reboot and/or re-plug that device, and this will
name the phy wiphy0 instead of phy0, phy1, etc.

This can help keep phy names consistent through driver reloads
which may make the system easier to configure properly or to
make different systems have the same naming (where wiphy0 is always
the 2.4Ghz radio, for instance).

Signed-off-by: Ben Greear 
---
 .../kernel/mac80211/files/mac80211.hotplug| 32 +++
 1 file changed, 32 insertions(+)

diff --git a/package/kernel/mac80211/files/mac80211.hotplug 
b/package/kernel/mac80211/files/mac80211.hotplug
index b865552661..a394e3195e 100644
--- a/package/kernel/mac80211/files/mac80211.hotplug
+++ b/package/kernel/mac80211/files/mac80211.hotplug
@@ -3,3 +3,35 @@
 [ "${ACTION}" = "add" ] && {
/sbin/wifi config
 }
+
+
+OPATH=${DEVPATH##/devices/platform/}
+OPATH=${OPATH%%/ieee*}
+
+# For USB, OPATH looks like this at this point in this script:
+# soc/soc:usb30@0/1100.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1:1.0
+# But, the uci path has a platform/ prefix on that:
+# platform/soc/soc:usb30@0/1100.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1:1.0
+OPATH_USB="platform/$OPATH";
+
+# 10 radios is enough for anyone!
+#echo "fix-wifi-mac, OPATH: $OPATH" >> /tmp/foo.txt
+for i in `seq 0 9`;
+  do
+  BUS=`uci get wireless.@wifi-device[$i].path`
+  #echo "fix-wifi-mac, BUS[$i]: $BUS" >> /tmp/foo.txt
+  if [ "$BUS " == "$OPATH " ] || [ "$BUS " == "$OPATH_USB " ]
+  then
+  PHYNAME=${DEVPATH##*ieee80211/}
+  NPHYNAME=`uci get wireless.@wifi-device[$i].phyname`
+  #echo "fix-wifi-mac, PHYNAME[$i]: $PHYNAME  NPHYNAME: $NPHYNAME" >> 
/tmp/foo.txt;
+  if [ "$NPHYNAME " != " " ]
+  then
+  if [ "$PHYNAME " != "$NPHYNAME " ]
+  then
+ #echo "fix-wifi-mac, renaming..." >> /tmp/foo.txt;
+  iw $PHYNAME set name $NPHYNAME
+  fi
+  fi
+  fi
+done
-- 
2.19.2


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] hotplug: Allow renaming phy devices.

2018-12-17 Thread Ben Greear





On 12/16/2018 11:14 PM, John Crispin wrote:


I'd like to review your patch but it hits the ML as an attachment making it 
impossible. regardless, the subject is misleading, there are lots of phy types 
and i fail to understand why this is required.

John


The attachment was due to us enabling DMARC support on our email system to help 
decrease spam, but
we can disable that.  I'll resend the patch later today.

The phy type in question is wireless phy devices.  Is just putting 'wireless' 
in front of it
sufficient to make it more understandable?

The patch is helpful to me because if I remove and replace a USB wireless NIC, 
or reload another wifi driver,
then by default it will change name, from /kernel/debug/ieee80211/phy1 to phy2, 
for instance.  My software wants
the names to stay the same to make it easier to have a persistent 
representation of a 'radio'.

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] build: fix build dependency of kmod .ipk with version filtered files

2018-12-17 Thread Yousong Zhou

We need to use resolved file list as prerequisites for repacking kmod
.ipk files.  Note that currently version_filter uses a Makefile macro
KERNEL_PATCHVER that should be available at ipk building time.

Reported-by: Rafał Miłecki 
Signed-off-by: Yousong Zhou 
---
 include/kernel.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/kernel.mk b/include/kernel.mk
index 38613756c7..19ecf4fa9a 100644
--- a/include/kernel.mk
+++ b/include/kernel.mk
@@ -259,7 +259,7 @@ $(call KernelPackage/$(1)/config)
   endif
   $$(eval $$(call BuildPackage,kmod-$(1)))
 
-  $$(IPKG_kmod-$(1)): $$(wildcard $$(FILES))
+  $$(IPKG_kmod-$(1)): $$(wildcard $$(call version_filter,$$(FILES)))
 
 endef
 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Missing GPG signatures

2018-12-17 Thread autosend

Hello

I couldn't find a way to cross verify the 18.06 key using the 17.01 key.
So it seems anyone with the 17.01 key is not at any advantage over a totally new
user, when upgrading to 18.06.

This is a very unusual situation compared to what all major Linux distributions
are doing nowadays.

I then imported all GPG keys associated with OpenWRT and was confused to find
that there seems to be no cross-signing of keys anywhere?

It seems only Robert Call of the LibreCMC fork is consistently signing releases
with the same key. But how is he verifying upstream...?

Below is a full output of the situation.


gpg --fingerprint --list-sigs

pub   rsa4096 2017-01-16 [SC] [expires: 2019-01-16]
  B09BE781AE8A0CD4702FDCD3833C6010D52BBB6B
uid   [ unknown] LEDE Release Builder (17.01 "Reboot" Signing Key) 

sig 3833C6010D52BBB6B 2017-01-16  LEDE Release Builder (17.01 "Reboot" 
Signing Key) 

pub   rsa4096 2018-05-16 [SC] [expires: 2020-05-15]
  6768C55E79B032D77A28DA5F0F20257417E1CE16
uid   [ unknown] OpenWrt Release Builder (18.06 Signing Key) 

sig 30F20257417E1CE16 2018-05-18  OpenWrt Release Builder (18.06 
Signing Key) 


pub   rsa4096 2016-07-26 [SC]
  54CC74307A2C6DC9CE618269CD84BCED626471F1
uid   [ unknown] LEDE Build System (LEDE GnuPG key for unattended build 
jobs) 
sig 3CD84BCED626471F1 2016-07-26  LEDE Build System (LEDE GnuPG key for 
unattended build jobs) 
sub   rsa4096 2016-07-26 [S]
sig  CD84BCED626471F1 2016-07-26  LEDE Build System (LEDE GnuPG key for 
unattended build jobs) 


pub   rsa4096 2016-08-26 [SC]
  10BDEE38E7DFDFC7D5D3CC09ED7282E208DAF586
uid   [ unknown] Florian Fainelli (LEDE Signing Key) 

sig 3ED7282E208DAF586 2016-08-26  Florian Fainelli (LEDE Signing Key) 


pub   rsa4096 2016-12-06 [SC]
  569E3F24712DEF28C2448C12AAD7E1690C74E7B8
uid   [ unknown] Hans Dedecker (LEDE Signing Key) 
sig 3AAD7E1690C74E7B8 2016-12-06  Hans Dedecker (LEDE Signing Key) 

sub   rsa4096 2016-12-06 [S] [expires: 2018-12-06]
sig  AAD7E1690C74E7B8 2016-12-06  Hans Dedecker (LEDE Signing Key) 


pub   rsa4096 2016-12-11 [SC]
  3176362F0318F3C17DBF89DE818021EBB6C9ECDA
uid   [ unknown] Stijn Tintel (LEDE Signing Key) 
sig 3818021EBB6C9ECDA 2016-12-11  Stijn Tintel (LEDE Signing Key) 

sub   rsa4096 2016-12-11 [S] [expires: 2018-12-11]
sig  818021EBB6C9ECDA 2016-12-11  Stijn Tintel (LEDE Signing Key) 


pub   rsa4096 2016-04-26 [SC]
  C2C9C93BF4775C11D4F6617C9C46FAFC12D89000
uid   [ unknown] Ted Hess (LEDE Signing Key) 
sig 39C46FAFC12D89000 2016-04-26  Ted Hess (LEDE Signing Key) 


pub   rsa4096 2016-04-14 [SC]
  B4DE4970B205473D26CD818F9E8F1F2934E5BBCC
uid   [ unknown] John Crispin (LEDE Signing Key) 
sig 39E8F1F2934E5BBCC 2016-04-14  John Crispin (LEDE Signing Key) 


pub   rsa4096 2016-04-05 [SC]
  69B26A2762D065E66F596755C76FDE50612A0E98
uid   [ unknown] Jo-Philipp Wich (LEDE Signing Key) 
sig 3C76FDE50612A0E98 2016-04-05  Jo-Philipp Wich (LEDE Signing Key) 


pub   rsa4096 2012-12-18 [SC] [expires: 2019-06-08]
  390DCF788BF9AA504F8FF1E2C29E9DA6A0DF8604
uid   [ unknown] Alexander Couzens 
sig 3C29E9DA6A0DF8604 2016-08-20  Alexander Couzens 
sig  61D851D9A6822153 2015-12-06  [User ID not found]
sig  01E670EFB6ED1A3A 2016-04-04  [User ID not found]
sig  EA71ABC5AB83B1C3 2014-06-28  [User ID not found]
sig  091AB856069AAA1C 2016-04-20  [User ID not found]
sig  EBF67A846AABE354 2016-10-03  [User ID not found]
sig  6C6580E77BD756C4 2016-05-22  [User ID not found]
sig 378D4EEEF482CB982 2015-08-30  [User ID not found]
sig  4B043FCDB9444540 2016-12-29  [User ID not found]
sig  153FE398821C8394 2018-08-22  [User ID not found]
sig 3C29E9DA6A0DF8604 2013-08-19  Alexander Couzens 
sig 3C29E9DA6A0DF8604 2014-10-27  Alexander Couzens 
sig 2   P1318EFAC5FBBDBCE 2015-12-06  [User ID not found]
sig 3C29E9DA6A0DF8604 2017-09-12  Alexander Couzens 
sig 3C29E9DA6A0DF8604 2018-06-08  Alexander Couzens 
uid   [ unknown] Alexander Couzens 
sig 3C29E9DA6A0DF8604 2016-08-20  Alexander Couzens 
sig  61D851D9A6822153 2015-12-06  [User ID not found]
sig  01E670EFB6ED1A3A 2016-04-04  [User ID not found]
sig  EA71ABC5AB83B1C3 2014-06-28  [User ID not found]
sig  091AB856069AAA1C 2016-04-20  [User ID not found]
sig  EBF67A846AABE354 2016-10-03  [User ID not found]
sig  6C6580E77BD756C4 2016-05-22  [User ID not found]
sig 378D4EEEF482CB982 2015-08-30  [User ID not found]
sig  4B043FCDB9444540 2016-12-29  [User ID not found]
sig  153FE398821C8394 2018-08-22  [User ID not found]
sig 3C29E9DA6A0DF8604 2014-10-27  Alexander Couzens 
sig 3C29E9DA6A0DF8604 2013-01-01  Alexander Couzens 
sig 2   P1318EFAC5FBBDBCE

Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300

2018-12-17 Thread Christian Lamparter

On Monday, December 17, 2018 1:08:27 PM CET you wrote:
> 
> On 17/12/18 12:39, Christian Lamparter wrote:
> > On Monday, December 17, 2018 10:31:51 AM CET Alberto Bursi wrote:
> >> On 15/12/18 22:02, Christian Lamparter wrote:
> >>> Specify firmware partition format by compatible string.
> >>>
> >>> Signed-off-by: Christian Lamparter 
> >>> ---
> >>>.../files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts   | 1 +
> >>>1 file changed, 1 insertion(+)
> >>>
> >>> diff --git 
> >>> a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts
> >>>  
> >>> b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts
> >>> index 53cb1b727f..39616ec2ac 100644
> >>> --- 
> >>> a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts
> >>> +++ 
> >>> b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts
> >>> @@ -210,6 +210,7 @@
> >>>   };
> >>>
> >>>   firmware@18 {
> >>> + compatible = "denx,fit";
> >>>   label = "firmware";
> >>>   reg = <0x18 0x1e8>;
> >>>   };
> >> [I've sent this to mailing list too, I send this email to you directly
> >> as I didn't add you in cc for that mail]
> >>
> >> This patch prevents boot on my B1300. I compiled from latest sources.
> >>
> > Thank you for reporting this issue. I put a patch into my staging tree:
> > https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=73a12ba5a370d67df19b64eaea56f6c62be1a9c0
> >
> >
> >
> >
> 
> With that patch the "firmware" partition is detected and it boots 
> successfully. Thanks for the quick fix.
> 
Thank you for the quick response. I pushed it to master, the next round
of images should boot again.

Thanks,
Christian




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken packaging of modules (updating them) when using @lt or @gt

2018-12-17 Thread Rafał Miłecki


On 17.12.2018 07:20, Yousong Zhou wrote:

On Mon, 17 Dec 2018 at 12:59, Rafał Miłecki  wrote:


On Sat, 15 Dec 2018 at 08:05, Yousong Zhou  wrote:


On Sat, 15 Dec 2018 at 06:00, Rafał Miłecki  wrote:


I've noticed a problem with kmod-phy-bcm-ns-usb2 defined in the
target/linux/bcm53xx/modules.mk

Steps to reproduce:
1) Setup .config with:
CONFIG_TARGET_bcm53xx
CONFIG_TARGET_MULTI_PROFILE
TARGET_ALL_PROFILES
CONFIG_TARGET_PER_DEVICE_ROOTFS
2) make V=s
3) vim build_dir/target-*/linux-*/linux-*/drivers/phy/broadcom/phy-bcm-ns-usb2.c
4) make V=s

That will result in rebuilding:
build_dir/target-*/linux-*/linux-*/drivers/phy/broadcom/phy-bcm-ns-usb2.ko
(expected).

However it won't update:
build_dir/target-*/linux-*/target-dir-*/lib/modules/4.14.88/phy-bcm-ns-usb2.ko

I've bisected/notices it's caused by using:
$(LINUX_DIR)/drivers/phy/phy-bcm-ns-usb2.ko@lt4.13 \
$(LINUX_DIR)/drivers/phy/broadcom/phy-bcm-ns-usb2.ko@gt4.13

If I drop old kernel compatibility and simply use:
$(LINUX_DIR)/drivers/phy/broadcom/phy-bcm-ns-usb2.ko
the problem disappears.


Probably because kmod .ipk was not rebuilt.  How about also applying
version_filter $(FILES) in the following line [1]

 $$(IPKG_kmod-$(1)): $$(wildcard $$(FILES))

[1] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=include/kernel.mk;h=38613756c71d8d5511a72849354bf818f57043ea;hb=HEAD#l262


Can you provide a diff or at least a complete line I should replace
above one with, please?


Something like the following.  Note that version_filter requires macro
KERNEL_PATCHVER from target makefile which I assume is not available
at dump time, but this should work at ipk packaging time.

diff --git a/include/kernel.mk b/include/kernel.mk
index 38613756c7..19ecf4fa9a 100644
--- a/include/kernel.mk
+++ b/include/kernel.mk
@@ -259,7 +259,7 @@ $(call KernelPackage/$(1)/config)
endif
$$(eval $$(call BuildPackage,kmod-$(1)))

-  $$(IPKG_kmod-$(1)): $$(wildcard $$(FILES))
+  $$(IPKG_kmod-$(1)): $$(wildcard $$(call version_filter,$$(FILES)))

  endef


It works!

Could you send a patch with that fix, please?

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300

2018-12-17 Thread Alberto Bursi




On 17/12/18 12:39, Christian Lamparter wrote:

On Monday, December 17, 2018 10:31:51 AM CET Alberto Bursi wrote:

On 15/12/18 22:02, Christian Lamparter wrote:

Specify firmware partition format by compatible string.

Signed-off-by: Christian Lamparter 
---
   .../files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts   | 1 +
   1 file changed, 1 insertion(+)

diff --git 
a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts 
b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts
index 53cb1b727f..39616ec2ac 100644
--- 
a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts
+++ 
b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts
@@ -210,6 +210,7 @@
};
   
   		firmware@18 {

+   compatible = "denx,fit";
label = "firmware";
reg = <0x18 0x1e8>;
};

[I've sent this to mailing list too, I send this email to you directly
as I didn't add you in cc for that mail]

This patch prevents boot on my B1300. I compiled from latest sources.


Thank you for reporting this issue. I put a patch into my staging tree:
https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=73a12ba5a370d67df19b64eaea56f6c62be1a9c0






With that patch the "firmware" partition is detected and it boots 
successfully. Thanks for the quick fix.



-Alberto


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300

2018-12-17 Thread Christian Lamparter

On Monday, December 17, 2018 10:31:51 AM CET Alberto Bursi wrote:
> 
> On 15/12/18 22:02, Christian Lamparter wrote:
> > Specify firmware partition format by compatible string.
> >
> > Signed-off-by: Christian Lamparter 
> > ---
> >   .../files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts   | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git 
> > a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts
> >  
> > b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts
> > index 53cb1b727f..39616ec2ac 100644
> > --- 
> > a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts
> > +++ 
> > b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts
> > @@ -210,6 +210,7 @@
> > };
> >   
> > firmware@18 {
> > +   compatible = "denx,fit";
> > label = "firmware";
> > reg = <0x18 0x1e8>;
> > };
> 
> [I've sent this to mailing list too, I send this email to you directly 
> as I didn't add you in cc for that mail]
> 
> This patch prevents boot on my B1300. I compiled from latest sources.
> 
Thank you for reporting this issue. I put a patch into my staging tree:
https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=73a12ba5a370d67df19b64eaea56f6c62be1a9c0





___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300

2018-12-17 Thread Alberto Bursi

On 17/12/18 10:57, Petr Štetiar wrote:

Alberto Bursi [2018-12-17 10:29:36]:

Hi Alberto,

firmware@18 {
+ compatible = "denx,fit";
label = "firmware";
reg = <0x18 0x1e8>;
};

This patch prevents boot on my B1300. I compiled from latest sources.

could you please try to compile from chunkeey's staging tree[1]? You're
probably missing patch `kernel: add DT binding support to the fit parser`[2]
in your tree, don't you?

1. https://git.openwrt.org/?p=openwrt/staging/chunkeey.git
2.
https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=29dc965dc03dda96126a59e7fcb34bee369e54ec

-- ynezz

I'm compiling from openwrt master, that patch should be in master
already
https://github.com/openwrt/openwrt/commit/40180b6305f55a7926153705eb5a84a9da33e597

output of git log (and scrolling a bit) in my clone

commit 40180b6305f55a7926153705eb5a84a9da33e597
Author: Christian Lamparter
Date: Sat Dec 8 21:54:10 2018 +0100

kernel: add DT binding support to the fit parser

It allows specifying default and Netgear parsers directly in the DT.

Signed-off-by: Christian Lamparter

Can't compile from his staging, I'm getting errors about applying patches

Applying
/run/media/alby/data_xeon_ext4/source_code/OpenWrt_source/test/chunkeey/target/linux/ipq40xx/patches-4.14/900-dts-ipq4019-ap-dk01.1.patch
using plaintext:

patching file arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
Hunk #1 FAILED at 15.
Hunk #2 succeeded at 74 (offset 8 lines).
Hunk #3 succeeded at 102 (offset 8 lines).
1 out of 3 hunks FAILED -- saving rejects to file
arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi.rej

patching file arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c1.dts
Patch failed! Please fix
/run/media/alby/data_xeon_ext4/source_code/OpenWrt_source/test/chunkeey/target/linux/ipq40xx/patches-4.14/900-dts-ipq4019-ap-dk01.1.patch!

Also it shows weird dates, in his staging it shows all commits are far
newer than the ones in master. The commit checksum id thing is different
too.

-Alberto

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH V2] procd: simplify code in procd_inittab_run

2018-12-17 Thread Bjørn Mork

John Crispin  writes:
> On 09/12/2018 22:54, Michael Heimpold wrote:
>> This is a trial to make it more obvious what the historically
>> grown code is actually doing.
>>
>> Signed-off-by: Michael Heimpold 
>> ---
>> V2: use Jo-Philipp Wich's proposal
>>
>>   inittab.c | 7 ++-
>>   1 file changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/inittab.c b/inittab.c
>> index 4b9..c9e6c13 100644
>> --- a/inittab.c
>> +++ b/inittab.c
>> @@ -259,12 +259,9 @@ void procd_inittab_run(const char *handler)
>>  list_for_each_entry(a, , list)
>>  if (!strcmp(a->handler->name, handler)) {
>> -if (a->handler->multi) {
>> -a->handler->cb(a);
>> -continue;
>> -}
>>  a->handler->cb(a);
>> -break;
>> +if (!a->handler->multi)
>> +break;
>
> this changes the logic. the cb() needs to be below and not above the
> if clause

I don't think it does?  The original code calls cb() in two places to
achieve the same effect.  The proposed patch makes this a lot cleaner
and clearer IMHO



Bjørn

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] kernel: backport ifconfig ioctl support for class e addresses

2018-12-17 Thread Kevin 'ldir' Darbyshire-Bryant

Backport net: Allow class-e address assignment via ifconfig ioctl
While most distributions long ago switched to the iproute2 suite
of utilities, which allow class-e (240.0.0.0/4) address assignment,
distributions relying on busybox, toybox and other forms of
ifconfig cannot assign class-e addresses without this kernel patch.

While CIDR has been obsolete for 2 decades, and a survey of all the
open source code in the world shows the IN_whatever macros are also
obsolete... rather than obsolete CIDR from this ioctl entirely, this
patch merely enables class-e assignment, sanely.

https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=65cab850f0eeaa9180bd2e10a231964f33743edf

Signed-off-by: Kevin Darbyshire-Bryant 
---
v2 - change patch number

 ...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++
 ...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++
 ...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++
 3 files changed, 237 insertions(+)
 create mode 100644 
target/linux/generic/backport-4.14/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
 create mode 100644 
target/linux/generic/backport-4.19/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
 create mode 100644 
target/linux/generic/backport-4.9/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch

diff --git 
a/target/linux/generic/backport-4.14/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
 
b/target/linux/generic/backport-4.14/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
new file mode 100644
index 00..fec083dadb
--- /dev/null
+++ 
b/target/linux/generic/backport-4.14/095-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
@@ -0,0 +1,79 @@
+From 46bf067870156abd61fe24d14c2486d15b8b502c Mon Sep 17 00:00:00 2001
+From: Dave Taht 
+Date: Fri, 14 Dec 2018 18:38:40 +
+Subject: [PATCH 1/1] Allow class-e address assignment in ifconfig and early
+ boot
+
+While the linux kernel became mostly "class-e clean" a decade ago,
+and most distributions long ago switched to the iproute2 suite
+of utilities, which allow class-e (240.0.0.0/4) address assignment,
+distributions relying on busybox, toybox and other forms of
+ifconfig cannot assign class-e addresses without this kernel patch.
+
+With this patch, also, a boot command line on these addresses is feasible:
+(ip=248.0.1.2::248.0.1.1:255.255.255.0).
+
+While CIDR has been obsolete for 2 decades, and a survey of all the
+userspace open source code in the world shows most IN_whatever macros
+are also obsolete... rather than obsolete CIDR from this ioctl entirely,
+this patch merely enables class-e assignment, sanely.
+
+H/T to Vince Fuller and his original patch here:
+https://lkml.org/lkml/2008/1/7/370
+
+Signed-off-by: Dave Taht 
+Reviewed-by: John Gilmore 
+---
+ include/uapi/linux/in.h | 8 ++--
+ net/ipv4/devinet.c  | 4 +++-
+ net/ipv4/ipconfig.c | 2 ++
+ 3 files changed, 11 insertions(+), 3 deletions(-)
+
+--- a/include/uapi/linux/in.h
 b/include/uapi/linux/in.h
+@@ -268,8 +268,12 @@ struct sockaddr_in {
+ #define   IN_MULTICAST(a) IN_CLASSD(a)
+ #define IN_MULTICAST_NET  0xF000
+ 
+-#define   IN_EXPERIMENTAL(a)  long int) (a)) & 0xf000) == 
0xf000)
+-#define   IN_BADCLASS(a)  IN_EXPERIMENTAL((a))
++#define   IN_BADCLASS(a)  long int) (a) ) == 0x)
++#define   IN_EXPERIMENTAL(a)  IN_BADCLASS((a))
++
++#define   IN_CLASSE(a)long int) (a)) & 0xf000) == 
0xf000)
++#define   IN_CLASSE_NET   0x
++#define   IN_CLASSE_NSHIFT0
+ 
+ /* Address to accept any incoming messages. */
+ #define   INADDR_ANY  ((unsigned long int) 0x)
+--- a/net/ipv4/devinet.c
 b/net/ipv4/devinet.c
+@@ -921,7 +921,7 @@ static int inet_abc_len(__be32 addr)
+ {
+   int rc = -1;/* Something else, probably a multicast. */
+ 
+-  if (ipv4_is_zeronet(addr))
++  if (ipv4_is_zeronet(addr) || ipv4_is_lbcast(addr))
+   rc = 0;
+   else {
+   __u32 haddr = ntohl(addr);
+@@ -932,6 +932,8 @@ static int inet_abc_len(__be32 addr)
+   rc = 16;
+   else if (IN_CLASSC(haddr))
+   rc = 24;
++  else if (IN_CLASSE(haddr))
++  rc = 32;
+   }
+ 
+   return rc;
+--- a/net/ipv4/ipconfig.c
 b/net/ipv4/ipconfig.c
+@@ -457,6 +457,8 @@ static int __init ic_defaults(void)
+   ic_netmask = htonl(IN_CLASSB_NET);
+   else if (IN_CLASSC(ntohl(ic_myaddr)))
+   ic_netmask = htonl(IN_CLASSC_NET);
++  else if (IN_CLASSE(ntohl(ic_myaddr)))
++  ic_netmask = htonl(IN_CLASSE_NET);
+   else {
+   pr_err("IP-Config: Unable to guess netmask for address 
%pI4\n",
+

[OpenWrt-Devel] [PATCH] kernel: backport ifconfig ioctl support for class e addresses

2018-12-17 Thread Kevin 'ldir' Darbyshire-Bryant

Backport net: Allow class-e address assignment via ifconfig ioctl
While most distributions long ago switched to the iproute2 suite
of utilities, which allow class-e (240.0.0.0/4) address assignment,
distributions relying on busybox, toybox and other forms of
ifconfig cannot assign class-e addresses without this kernel patch.

While CIDR has been obsolete for 2 decades, and a survey of all the
open source code in the world shows the IN_whatever macros are also
obsolete... rather than obsolete CIDR from this ioctl entirely, this
patch merely enables class-e assignment, sanely.

https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=65cab850f0eeaa9180bd2e10a231964f33743edf

Signed-off-by: Kevin Darbyshire-Bryant 
---
 ...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++
 ...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++
 ...ddress-assignment-via-ifconfig-ioctl.patch | 79 +++
 3 files changed, 237 insertions(+)
 create mode 100644 
target/linux/generic/backport-4.14/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
 create mode 100644 
target/linux/generic/backport-4.19/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
 create mode 100644 
target/linux/generic/backport-4.9/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch

diff --git 
a/target/linux/generic/backport-4.14/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
 
b/target/linux/generic/backport-4.14/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
new file mode 100644
index 00..fec083dadb
--- /dev/null
+++ 
b/target/linux/generic/backport-4.14/700-Allow-class-e-address-assignment-via-ifconfig-ioctl.patch
@@ -0,0 +1,79 @@
+From 46bf067870156abd61fe24d14c2486d15b8b502c Mon Sep 17 00:00:00 2001
+From: Dave Taht 
+Date: Fri, 14 Dec 2018 18:38:40 +
+Subject: [PATCH 1/1] Allow class-e address assignment in ifconfig and early
+ boot
+
+While the linux kernel became mostly "class-e clean" a decade ago,
+and most distributions long ago switched to the iproute2 suite
+of utilities, which allow class-e (240.0.0.0/4) address assignment,
+distributions relying on busybox, toybox and other forms of
+ifconfig cannot assign class-e addresses without this kernel patch.
+
+With this patch, also, a boot command line on these addresses is feasible:
+(ip=248.0.1.2::248.0.1.1:255.255.255.0).
+
+While CIDR has been obsolete for 2 decades, and a survey of all the
+userspace open source code in the world shows most IN_whatever macros
+are also obsolete... rather than obsolete CIDR from this ioctl entirely,
+this patch merely enables class-e assignment, sanely.
+
+H/T to Vince Fuller and his original patch here:
+https://lkml.org/lkml/2008/1/7/370
+
+Signed-off-by: Dave Taht 
+Reviewed-by: John Gilmore 
+---
+ include/uapi/linux/in.h | 8 ++--
+ net/ipv4/devinet.c  | 4 +++-
+ net/ipv4/ipconfig.c | 2 ++
+ 3 files changed, 11 insertions(+), 3 deletions(-)
+
+--- a/include/uapi/linux/in.h
 b/include/uapi/linux/in.h
+@@ -268,8 +268,12 @@ struct sockaddr_in {
+ #define   IN_MULTICAST(a) IN_CLASSD(a)
+ #define IN_MULTICAST_NET  0xF000
+ 
+-#define   IN_EXPERIMENTAL(a)  long int) (a)) & 0xf000) == 
0xf000)
+-#define   IN_BADCLASS(a)  IN_EXPERIMENTAL((a))
++#define   IN_BADCLASS(a)  long int) (a) ) == 0x)
++#define   IN_EXPERIMENTAL(a)  IN_BADCLASS((a))
++
++#define   IN_CLASSE(a)long int) (a)) & 0xf000) == 
0xf000)
++#define   IN_CLASSE_NET   0x
++#define   IN_CLASSE_NSHIFT0
+ 
+ /* Address to accept any incoming messages. */
+ #define   INADDR_ANY  ((unsigned long int) 0x)
+--- a/net/ipv4/devinet.c
 b/net/ipv4/devinet.c
+@@ -921,7 +921,7 @@ static int inet_abc_len(__be32 addr)
+ {
+   int rc = -1;/* Something else, probably a multicast. */
+ 
+-  if (ipv4_is_zeronet(addr))
++  if (ipv4_is_zeronet(addr) || ipv4_is_lbcast(addr))
+   rc = 0;
+   else {
+   __u32 haddr = ntohl(addr);
+@@ -932,6 +932,8 @@ static int inet_abc_len(__be32 addr)
+   rc = 16;
+   else if (IN_CLASSC(haddr))
+   rc = 24;
++  else if (IN_CLASSE(haddr))
++  rc = 32;
+   }
+ 
+   return rc;
+--- a/net/ipv4/ipconfig.c
 b/net/ipv4/ipconfig.c
+@@ -457,6 +457,8 @@ static int __init ic_defaults(void)
+   ic_netmask = htonl(IN_CLASSB_NET);
+   else if (IN_CLASSC(ntohl(ic_myaddr)))
+   ic_netmask = htonl(IN_CLASSC_NET);
++  else if (IN_CLASSE(ntohl(ic_myaddr)))
++  ic_netmask = htonl(IN_CLASSE_NET);
+   else {
+   pr_err("IP-Config: Unable to guess netmask for address 
%pI4\n",
+  _myaddr);
diff --git

Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300

2018-12-17 Thread Petr Štetiar

Alberto Bursi  [2018-12-17 10:29:36]:

Hi Alberto,

> > firmware@18 {
> > +   compatible = "denx,fit";
> > label = "firmware";
> > reg = <0x18 0x1e8>;
> > };
> 
> This patch prevents boot on my B1300. I compiled from latest sources.

could you please try to compile from chunkeey's staging tree[1]? You're
probably missing patch `kernel: add DT binding support to the fit parser`[2]
in your tree, don't you?

1. https://git.openwrt.org/?p=openwrt/staging/chunkeey.git
2. 
https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=29dc965dc03dda96126a59e7fcb34bee369e54ec

-- ynezz

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300

2018-12-17 Thread Alberto Bursi



On 15/12/18 22:02, Christian Lamparter wrote:

Specify firmware partition format by compatible string.

Signed-off-by: Christian Lamparter 
---
  .../files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts   | 1 +
  1 file changed, 1 insertion(+)

diff --git 
a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts 
b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts
index 53cb1b727f..39616ec2ac 100644
--- 
a/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts
+++ 
b/target/linux/ipq40xx/files-4.14/arch/arm/boot/dts/qcom-ipq4029-gl-b1300.dts
@@ -210,6 +210,7 @@
};
  
  		firmware@18 {

+   compatible = "denx,fit";
label = "firmware";
reg = <0x18 0x1e8>;
};



This patch prevents boot on my B1300. I compiled from latest sources.

Flashed the image with the sysupgrade and also again with with uboot 
interface (after it was not booting fine)


This is serial bootlog of the non-booting firmware

[    0.00] Booting Linux on physical CPU 0x0
[    0.00] Linux version 4.14.88 (alby@openSUSE-xeon) (gcc version 
7.4.0 (OpenWrt GCC 7.4.0 r8788-6b63595fec)) #0 SMP Mon Dec 17 07:16:28 2018
[    0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), 
cr=10c5387d

[    0.00] CPU: div instructions available: patching division code
[    0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache

[    0.00] OF: fdt: Machine model: GL.iNet GL-B1300
[    0.00] Memory policy: Data cache writealloc
[    0.00] random: get_random_bytes called from 
start_kernel+0x88/0x3c0 with crng_init=0
[    0.00] percpu: Embedded 15 pages/cpu @cfdb s29324 r8192 
d23924 u61440

[    0.00] Built 1 zonelists, mobility grouping on.  Total pages: 64512
[    0.00] Kernel command line: rootfsname=rootfs rootwait
[    0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 
bytes)

[    0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.00] Memory: 249952K/260096K available (4237K kernel code, 
137K rwdata, 1176K rodata, 1024K init, 228K bss, 10144K reserved, 0K 
cma-reserved, 0K highmem)

[    0.00] Virtual kernel memory layout:
[    0.00] vector  : 0x - 0x1000   (   4 kB)
[    0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[    0.00] vmalloc : 0xd080 - 0xff80   ( 752 MB)
[    0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
[    0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[    0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[    0.00]   .text : 0xc0208000 - 0xc0723750   (5230 kB)
[    0.00]   .init : 0xc090 - 0xc0a0   (1024 kB)
[    0.00]   .data : 0xc0a0 - 0xc0a22740   ( 138 kB)
[    0.00]    .bss : 0xc0a24000 - 0xc0a5d258   ( 229 kB)
[    0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.00] Hierarchical RCU implementation.
[    0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.00] arch_timer: cp15 timer(s) running at 48.00MHz (virt).
[    0.00] clocksource: arch_sys_counter: mask: 0xff 
max_cycles: 0xb11fd3bfb, max_idle_ns: 440795203732 ns
[    0.09] sched_clock: 56 bits at 48MHz, resolution 20ns, wraps 
every 4398046511096ns

[    0.23] Switching to timer-based delay loop, resolution 20ns
[    0.000239] Calibrating delay loop (skipped), value calculated using 
timer frequency.. 96.00 BogoMIPS (lpj=48)

[    0.000258] pid_max: default: 32768 minimum: 301
[    0.000398] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000416] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 
bytes)

[    0.001028] CPU: Testing write buffer coherency: ok
[    0.001712] Setting up static identity map for 0x8030 - 0x80300060
[    0.001858] Hierarchical SRCU implementation.
[    0.002491] smp: Bringing up secondary CPUs ...
[    0.005187] smp: Brought up 1 node, 4 CPUs
[    0.005205] SMP: Total of 4 processors activated (384.00 BogoMIPS).
[    0.005213] CPU: All CPU(s) started in SVC mode.
[    0.009055] VFP support v0.3: implementor 41 architecture 2 part 30 
variant 7 rev 5
[    0.009229] clocksource: jiffies: mask: 0x max_cycles: 
0x, max_idle_ns: 1911260446275 ns

[    0.009251] futex hash table entries: 1024 (order: 4, 65536 bytes)
[    0.009450] pinctrl core: initialized pinctrl subsystem
[    0.010397] NET: Registered protocol family 16
[    0.010682] DMA: preallocated 256 KiB pool for atomic coherent 
allocations

[    0.011708] cpuidle: using governor ladder
[    0.011748] cpuidle: using governor menu
[    0.028670] usbcore: registered new interface driver usbfs
[    0.028734] usbcore: registered new interface driver hub
[    0.028809]

Re: [OpenWrt-Devel] ath79: seting GPIO registers to specific values via DTS?

2018-12-17 Thread Petr Štetiar

Sebastian Kemper  [2018-12-16 19:07:52]:

Hi Sebastian,

> pinctrl-0 = <_disable_pins>; // works
> pinctrl-1 = <_gpio_11>; // nothing happens

hm, that's strange, it should work if you provide proper `pinctrl-names`
property:

 pinctrl-names = "disable_jtag", "enable_gpio11";
 pinctrl-0 = <_disable_pins>;
 pinctrl-1 = <_gpio_11>;

If it doesn't work, then it's probably issue with the documentation[1] or
pinctrl.

1. 
https://elixir.bootlin.com/linux/v4.14.89/source/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt

-- ynezz

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ipq40xx: clean up netgear-dni image generation

Re: [OpenWrt-Devel] ath79: seting GPIO registers to specific values via DTS?

[OpenWrt-Devel] [PATCH v3 1/2] ath79: add support for devolo WiFi pro 1200e

[OpenWrt-Devel] [PATCH v3 2/2] ath79: add support for devolo WiFi pro 1750c

Re: [OpenWrt-Devel] MIPS stack security and other problems

Re: [OpenWrt-Devel] MIPS stack security and other problems

Re: [OpenWrt-Devel] MIPS stack security and other problems

[OpenWrt-Devel] [PATCH] kernel: Fix rtc-ds1307 dependency on hwmon-core for 4.19

Re: [OpenWrt-Devel] MIPS stack security and other problems

[OpenWrt-Devel] [PATCH] kernel: Fix usb-chipidea dependency on ulpi.ko for 4.19

Re: [OpenWrt-Devel] MIPS stack security and other problems

[OpenWrt-Devel] [PATCH] kernel: Fix kmod-w1 dependency on hwmon-core for 4.19

Re: [OpenWrt-Devel] [PATCH] ipq806x: add ath10k calibration data MAC addresses patching

Re: [OpenWrt-Devel] MIPS stack security and other problems

[OpenWrt-Devel] [PATCH] ipq40xx: add support for ASUS Lyra

[OpenWrt-Devel] [PATCH] kernel: Add missing symbols to 4.19

Re: [OpenWrt-Devel] Missing GPG signatures

Re: [OpenWrt-Devel] [PATCH] ipq806x: add ath10k calibration data MAC addresses patching

[OpenWrt-Devel] [PATCH] hotplug: Allow renaming wireless phy devices.

Re: [OpenWrt-Devel] [PATCH] hotplug: Allow renaming phy devices.

[OpenWrt-Devel] [PATCH] build: fix build dependency of kmod .ipk with version filtered files

[OpenWrt-Devel] Missing GPG signatures

Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300

Re: [OpenWrt-Devel] Broken packaging of modules (updating them) when using @lt or @gt

Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300

Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300

Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300

Re: [OpenWrt-Devel] [PATCH V2] procd: simplify code in procd_inittab_run

[OpenWrt-Devel] [PATCH v2] kernel: backport ifconfig ioctl support for class e addresses

[OpenWrt-Devel] [PATCH] kernel: backport ifconfig ioctl support for class e addresses

Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300

Re: [OpenWrt-Devel] [PATCH v2 6/7] ipq40xx: specify "firmware" partition format for GL.iNet GL-B1300

Re: [OpenWrt-Devel] ath79: seting GPIO registers to specific values via DTS?

33 matches

Site Navigation

Mail list logo

Footer information