Re: [OpenWrt-Devel] Current "OpenWrt Style Guide for DTS"?

[Chuanhong Guo]

Hi!
I picked several things I could answer below :)
On Wed, Jan 23, 2019 at 6:07 AM Jeff Kletsky  wrote:
...
>
> Choice of Node Naming for Partitions
> 
>
> In some DTS files, the partitions are named using sequential integers.
> In others, the offset of the partition is used.
>
> * Which of the two is preferred?
>
>  uboot: u-boot@0 {
>  firmware@2 {
>  art: art@ff {
>
> vs.
>
>  partition@0 {
>  partition@1 {
>  partition@2 {
>  art: partition@3 {
Neither. It's partition@:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=6dd94c2781b79ffd20f1a57a48fa2314d67ee190
>
...
> TAB vs. SPACE Indentation
> =
>
> * It appears that TAB indentation is being used. Is this correct?
Yes.
>
> read-only Partitions
> 
>
> * Is it appropriate to mark the boot-loader partition as read-only?
>
> * What about the art partition?
>
> Doing so would seem to be able help prevent users following outdated
> or ill-advised suggestions to write to their file systems using
> low-level access.
Correct. Both of those partitions aren't supposed to be written normally.
>
> Advanced users that, for some reason, want to overwrite these critical
> partitions could always compile their own kernel with the restriction
> removed.
Yes. They are always able to make their custom firmware for this purpose.
>
>
>
> ---
> Context for the following questions is discussed below the "8<" marker
> TL;DR Stable references to partitions for DT modification when "inheriting"
> ---
>
> Partition "label" Properties
> 
>
> Some of the "label" properties seem obviously named, like "firmware"
> and "art" and I assume that the kernel and drivers key off of these.
>
> * Is there a list of "reserved" and/or "preferred" values for the
>label property of the partitions?
OpenWrt kernel will try to automatically split "firmware“ into
kernel/rootfs, and it'll auto-attach "ubi" partition as a ubi device.
Besides these two the other names doesn't have any strict
requirements. People usually follow what the manufacturer defined in
their stock firmware.
"art" stands for "Atheros Radio Test" and it's widely used for
calibration data on QCA routers by the manufacturers. There are some
devices using other names for calibration data partition.
We tell the driver where to load calibration data in dts or load it
for drivers using firmware hotplug scripts.
>
>
>
> Labels for Partition Nodes
> ==
>
> I've noticed that there are some common labels for partition nodes in
> use. A quick check of the ath79 platform shows
>
>  addr, art, ART, caldata, eeprom, firmware, info, mac, mtdparts,
>  nvram, partitions, uboot, ubootenv
>
> * Is there a list of any of these that are "reserved" by general DTS
>files under OpenWrt?
As I said above, "firmware" and "ubi" are reserved for special purposes.
Other labels are usually just copied from manufacturers' firmware.
>
> At least as I understand DTS definition, these labels are not passed
> to the kernel, but only during compilation.
No. These labels will be saved in the compiled dtb files and can be
used by drivers.
e.g. mtd partition node labels will be used as mtd partition name.
>
> * Assuming this is the case, is there any guidance for adding
>"commonly used" labels or "device-specific" labels?
>
>
> 8<
>
> The questions above around the "label" property and labels arise
> mainly because I'm working with devices that have both NOR and NAND
> flash.  With the goal of easier maintainability and potential utility,
> I'd like to define the partitioning *once* for a physical device and,
> if needed, modify it for the NOR and NAND instances.
>
> These devices that I'm working with can, once the boot loader is
> running off NOR, boot either from NOR or from NAND (with fall-back if
> the preferred one fails). Flashing both variants simultaneously has
> benefits, but how to accomplish that may need to be the subject of
> another thread.
>
> At least as I (weakly) understand the use of
>
>  label = "firmware"
>  compatible = "denx,uimage"
>
> from https://openwrt.org/docs/guide-developer/defining-firmware-partitions
> there is some magic in the boot loader to know that the kernel is in the
> "firmware" partition and that the kernel, once running, can split the
> firmware partition into kernel and filesystem partitions, on the
> fly.
Incorrect. They are used by the kernel to properly split firmware
partition into kernel/rootfs.
OpenWrt dynamically determine the sizes of these two partitions to
avoid space wasted in a fixed kernel partition.
This compatible string was introduced upstream and OpenWrt folks wants
to use it to get rid of the current hack for firmware partition.
Currently OpenWrt patched the mtd framework so that when registering a
partition named 'firmware' it tries to apply every available mtdsplit

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

[Rosen Penev]

On Tue, Jan 22, 2019 at 2:34 PM Hauke Mehrtens  wrote:
>
> On 1/19/19 2:56 PM, Dave Taht wrote:
> > Hauke Mehrtens  writes:
> >
> >> On 12/18/18 12:46 PM, Hauke Mehrtens wrote:
> >>> On 12/17/18 1:54 AM, 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.
> >>>
> >>> In the second paper "Build Safety of Software in 28 Popular Home Router"
> >>> [0] they checked the "security" of multiple popular devices, by checking
> >>> if they activate ASLR, Non stack Exec, Relro and stack guards. The best
> >>> device was the Linksys wrt32x and this is based on OpenWrt with not so
> >>> many modifications. ;-) Just something like Samba downgrade to 3.0.37.
> >>> The paper also wonders why the other Linksys devices like the wrt1900ac
> >>> are much worse, but they probably do not use OpenWrt or a much older
> >>> version. The GPL source code tar.gz of the Linksys wrt32x, begins with
> >>> cloning from https://github.com/openwrt/openwrt.git
> >>>
> >>>
> >>> It is also interesting how different this approve to security checking
> >>> is to what the German BSI published in the "BSI TR-03148: Secure
> >>> Broadband Router:" [1].
> >>> You can build a device which scores 100% in the one and 0% in the other,
> >>> there is no overlap. ;-)
> >>>
> >>> Hauke
> >>>
> >>>
> >>> [0]:
> >>> https://cyber-itl.org/assets/papers/2018/build_safety_of_software_in_28_popular_home_routers.pdf
> >>> [1]:
> >>> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03148/TR03148.pdf?__blob=publicationFile=2
> >>
> >> It looks like they ran checksec from
> >> http://github.com/slimm609/checksec.sh on the root file system of the
> >> devices and came up with these results. The numbers for the Linksys
> >> wrt32x look very similar to current OpenWrt master, even for MIPS
> >> CPUs.
> >>
> >> I attached two outputs of checksec to this mail from the lantiq target
> >> with a MIP24Kc CPU. One with master and the current default
> >> configuration and one with master + activated ASLR configuration
> >> option.
> >>
> >> You can generate these yourself like this:
> >> ../checksec.sh/checksec -d build_dir/target-mips_24kc_musl/root-lantiq/
> >
> > This might be a useful tool to make more obvious security issues to
> > future builders of openwrt.
>
> Yes it is really helpful to check the compiler security settings used to
> compile a binary, it would be nice if someone could check a bigger build
> of OpenWrt if we use the correct compiler settings everywhere.
There's still a fair amount of work to be done there.

One of my annoyances is that checksec.sh requires bash and a few other
utilities. It's useful to run on the router as some binaries are
symlinks to local /bin locations.

binutils for example, does not have any OpenWrt settings. It also
seems to be relatively unmaintained (old version).:

RELRO   STACK CANARY  NXPIE RPATH
RUNPATHSymbolsFORTIFYFortifiedFortifiable
FILE
Full RELRO  No canary found   NX enabledNo PIE  No
RPATH   No RUNPATH   No Symbols  No00/bin/strings

PKG_ASLR_PIE is enabled btw.

My current list of binaries with such issues are:

/bin/strings
/sbin/askfirst
/usr/bin/bon_csv2html
/usr/bin/bonnie++
/usr/bin/buddy-ng
/usr/bin/dbus-uuidgen
/usr/bin/ldd
/usr/bin/resolveip
/usr/bin/file
/usr/sbin/fw_printenv
/lib/libatomic.so.
/lib/libsetlbf.so
/usr/lib/libbz2.so.1.0
/usr/lib/libcmdline-contexts-samba4.so
/usr/lib/libcrypto.so.1.0.0 - NX...
/usr/lib/libgthread-2.0.so
/usr/lib/libnatpmp.so.1 - relro
/usr/lib/libpanelw.so - relro
/usr/lib/libstdc++.so.6 - relro
/usr/lib/libopcodes-2.27.so
/usr/lib/libmagic.so.1

on an mvebu device (Turris Omnia)
>
> >> ASLR increases the image size by about 2.8%:
> >> Without ASLR:5.386.965 bytes
> >> With ASLR:   5.540.565 bytes
> >
> > To me this seems worth it on the larger flash sizes.
>
> The problem is that this would even be a toolchain option, but we can
> probably activate it at least for all modern arm CPUs and x86, they all
> have bigger flashes as far as I know.
I actually disagree with this. Some packages have a --with-pic
parameter in their configure script. I think packages should be fixed
on an individual basis. Not all packages need or require PIE
(/sbin/askfirst for example).
>
> >> This is caused by increased user space binary size, see for example
> >> busybox binary which is 7% bigger:
> >> Without ASLR:425.532 bytes
> >> With ASLR:   457.336 bytes
> >>
> >> The fortified function count does not work with fortify-headers, but
> >> only with glibc. With glibc some function calls are getting replaced
> >> with calls to *_chk 

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

[Hauke Mehrtens]

On 1/19/19 2:56 PM, Dave Taht wrote:
> Hauke Mehrtens  writes:
> 
>> On 12/18/18 12:46 PM, Hauke Mehrtens wrote:
>>> On 12/17/18 1:54 AM, 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.
>>>
>>> In the second paper "Build Safety of Software in 28 Popular Home Router"
>>> [0] they checked the "security" of multiple popular devices, by checking
>>> if they activate ASLR, Non stack Exec, Relro and stack guards. The best
>>> device was the Linksys wrt32x and this is based on OpenWrt with not so
>>> many modifications. ;-) Just something like Samba downgrade to 3.0.37.
>>> The paper also wonders why the other Linksys devices like the wrt1900ac
>>> are much worse, but they probably do not use OpenWrt or a much older
>>> version. The GPL source code tar.gz of the Linksys wrt32x, begins with
>>> cloning from https://github.com/openwrt/openwrt.git
>>>
>>>
>>> It is also interesting how different this approve to security checking
>>> is to what the German BSI published in the "BSI TR-03148: Secure
>>> Broadband Router:" [1].
>>> You can build a device which scores 100% in the one and 0% in the other,
>>> there is no overlap. ;-)
>>>
>>> Hauke
>>>
>>>
>>> [0]:
>>> https://cyber-itl.org/assets/papers/2018/build_safety_of_software_in_28_popular_home_routers.pdf
>>> [1]:
>>> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03148/TR03148.pdf?__blob=publicationFile=2
>>
>> It looks like they ran checksec from
>> http://github.com/slimm609/checksec.sh on the root file system of the
>> devices and came up with these results. The numbers for the Linksys
>> wrt32x look very similar to current OpenWrt master, even for MIPS
>> CPUs.
>>
>> I attached two outputs of checksec to this mail from the lantiq target
>> with a MIP24Kc CPU. One with master and the current default
>> configuration and one with master + activated ASLR configuration
>> option.
>>
>> You can generate these yourself like this:
>> ../checksec.sh/checksec -d build_dir/target-mips_24kc_musl/root-lantiq/
> 
> This might be a useful tool to make more obvious security issues to
> future builders of openwrt.

Yes it is really helpful to check the compiler security settings used to
compile a binary, it would be nice if someone could check a bigger build
of OpenWrt if we use the correct compiler settings everywhere.

>> ASLR increases the image size by about 2.8%:
>> Without ASLR:5.386.965 bytes
>> With ASLR:   5.540.565 bytes
> 
> To me this seems worth it on the larger flash sizes.

The problem is that this would even be a toolchain option, but we can
probably activate it at least for all modern arm CPUs and x86, they all
have bigger flashes as far as I know.

>> This is caused by increased user space binary size, see for example
>> busybox binary which is 7% bigger:
>> Without ASLR:425.532 bytes
>> With ASLR:   457.336 bytes
>>
>> The fortified function count does not work with fortify-headers, but
>> only with glibc. With glibc some function calls are getting replaced
>> with calls to *_chk functions which are taking extra arguments, this
>> is done by some glibc header magic. For musl libc OpenWrt uses
>> fortify-headers which overwrites the original functions and inlined
>> some extra security checks into the calling application. The result
>> should be similar, so I assume that we have at least in most places
>> similar security for the glibc fortified functions.
>> I checked this by compiling an test application and checked the
>> assembler code, it contained some extra size checks.
>>
>> It looks like the detection does not work correctly for kernel modules.
>>
>> Currently RELRO is not activated for the following libraries:
>>  root-lantiq/usr/lib/libbz2.so.1.0
>>  root-lantiq/usr/lib/libbz2.so.1.0.6
>>  root-lantiq/lib/libgcc_s.so.1
>> this looks like a bug.
>>
>> For libgcc_s.so.1 also NX is disabled, which is not good.
> 
> Hmm. Does gcc still actually contain executable code in this segment?

When I compile this for x86 NX is set, I do not know why it is not set
for MIPS, I would like to investigate this further.

>> Some binaries do not use a stack canary, I assume that these binaries
>> just do not have an array on the stack which could be exploited. The
>> compiler adds stack canaries only to functions which the compiler
>> thinks need it.
>>
>> ASLR is deactivated for root-lantiq/sbin/vdsl_cpe_control, because
>> this application does not link any more when ASLR is activated, this
>> is a bug in the package build system.
>>
>> Hauke

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

Re: [OpenWrt-Devel] Current "OpenWrt Style Guide for DTS"?

[Jeff Kletsky]

On 1/21/19 9:26 PM, Rafał Miłecki wrote:

> On Mon, 21 Jan 2019 at 20:06, Jeff Kletsky  wrote:

>> but I still have a few unanswered questions
>> [around DTS "best practices" for OpenWrt].

>
> Ask?
>


Style Questions
===


Choice of Node Naming for Partitions


In some DTS files, the partitions are named using sequential integers.
In others, the offset of the partition is used.

* Which of the two is preferred?

    uboot: u-boot@0 {
    firmware@2 {
    art: art@ff {

vs.

    partition@0 {
    partition@1 {
    partition@2 {
    art: partition@3 {



Use of CPP #include vs. Device Tree /include/
=

* It appears that the CPP #include is preferred. Is this correct?



TAB vs. SPACE Indentation
=

* It appears that TAB indentation is being used. Is this correct?



Structure Questions
===


read-only Partitions


* Is it appropriate to mark the boot-loader partition as read-only?

* What about the art partition?

Doing so would seem to be able help prevent users following outdated
or ill-advised suggestions to write to their file systems using
low-level access.

Advanced users that, for some reason, want to overwrite these critical
partitions could always compile their own kernel with the restriction
removed.



---
Context for the following questions is discussed below the "8<" marker
TL;DR Stable references to partitions for DT modification when "inheriting"
---

Partition "label" Properties


Some of the "label" properties seem obviously named, like "firmware"
and "art" and I assume that the kernel and drivers key off of these.

* Is there a list of "reserved" and/or "preferred" values for the
  label property of the partitions?



Labels for Partition Nodes
==

I've noticed that there are some common labels for partition nodes in
use. A quick check of the ath79 platform shows

    addr, art, ART, caldata, eeprom, firmware, info, mac, mtdparts,
    nvram, partitions, uboot, ubootenv

* Is there a list of any of these that are "reserved" by general DTS
  files under OpenWrt?

At least as I understand DTS definition, these labels are not passed
to the kernel, but only during compilation.

* Assuming this is the case, is there any guidance for adding
  "commonly used" labels or "device-specific" labels?


8<

The questions above around the "label" property and labels arise
mainly because I'm working with devices that have both NOR and NAND
flash.  With the goal of easier maintainability and potential utility,
I'd like to define the partitioning *once* for a physical device and,
if needed, modify it for the NOR and NAND instances.

These devices that I'm working with can, once the boot loader is
running off NOR, boot either from NOR or from NAND (with fall-back if
the preferred one fails). Flashing both variants simultaneously has
benefits, but how to accomplish that may need to be the subject of
another thread.

At least as I (weakly) understand the use of

    label = "firmware"
    compatible = "denx,uimage"

from https://openwrt.org/docs/guide-developer/defining-firmware-partitions
there is some magic in the boot loader to know that the kernel is in the
"firmware" partition and that the kernel, once running, can split the
firmware partition into kernel and filesystem partitions, on the
fly. This would suggest to me that "it would be bad" to have two
partitions with the "firmware" label, and likely with the
"denx,uimage" compatible (or whatever the boot loader and kernel are
expecting for that device).

This line of thinking suggests to me that if one or both flash storage
partitions are defined in a common place, "the other" flash storage
needs to be "de-fanged" at least as a start.

Ideally, I'd like to be able to define the NOR partitioning in a
common .dsti for the device, then modify it for the NAND variant,
along the lines of:

    partition@0 {
    label = "u-boot";
    reg = <0x00 0x04>;
    read-only;
    };

    partition@4 {
    label = "u-boot-env";
    reg = <0x04 0x01>;
    };

    art: partition@5 {
    label = "art";
    reg = <0x05 0x01>;
    read-only;
    };

    firmware_nor: partition@6 {
    compatible = "denx,uimage";
    label = "firmware";
    reg = <0x06 0xfa>;
    };

then, for the NAND variant

_nor {
    /delete-property/ 

Re: [OpenWrt-Devel] [PATCH 0/4] Update Gemini to kernel v4.19

[Hauke Mehrtens]

On 1/22/19 7:26 AM, Petr Štetiar wrote:
> Linus Walleij  [2019-01-21 23:17:50]:
> 
> Hi,
> 
>> I pushed it to the branch "gemini-v4.19" (with some more patches,
>> but shouldn't make a difference) here:
>> https://github.com/linusw/openwrt
> 
> thanks, so I've just tried following build config:
> 
>  CONFIG_TARGET_gemini=y
>  CONFIG_TARGET_MULTI_PROFILE=y
>  CONFIG_TARGET_ALL_PROFILES=y
>  CONFIG_TARGET_DEVICE_gemini_DEVICE_dlink-dir-685=y
>  CONFIG_TARGET_DEVICE_gemini_DEVICE_dlink-dns-313=y
>  CONFIG_TARGET_DEVICE_gemini_DEVICE_sq201=y
>  CONFIG_TARGET_DEVICE_gemini_DEVICE_nas4220b=y
>  CONFIG_TARGET_DEVICE_gemini_DEVICE_sl93512r=y
>  CONFIG_TARGET_DEVICE_gemini_DEVICE_rut1xx=y
>  CONFIG_TARGET_DEVICE_gemini_DEVICE_wbd111=y
>  CONFIG_TARGET_DEVICE_gemini_DEVICE_wbd222=y
>  CONFIG_ALL_KMODS=y
>  CONFIG_ALL_NONSHARED=y
> 
> And running:
> 
>  make V=s -j$(nproc)
> 
> Ends with following:
> 
>  make[5]: Entering directory 
> '/openwrt/build_dir/target-arm_fa526_musl_eabi/linux-gemini/linux-4.19.16'
>  Makefile:600: include/config/auto.conf: No such file or directory
>YACCscripts/kconfig/zconf.tab.c
>HOSTCC  scripts/kconfig/conf.o
>LEX scripts/kconfig/zconf.lex.c
>HOSTCC  scripts/kconfig/zconf.tab.o
>HOSTLD  scripts/kconfig/conf
>  scripts/kconfig/conf  --syncconfig Kconfig
>  net/sched/Kconfig:44: warning: menuconfig statement without prompt
>  .config:3930:warning: symbol value 'm' invalid for NF_NAT_REDIRECT
>  *
>  * Restart config...
>  *
>  *
>  * PCI controller drivers
>  *
>  Faraday Technology FTPCI100 PCI controller (PCI_FTPCI100) [Y/n/?] y
>  Generic PCI host controller (PCI_HOST_GENERIC) [N/y/?] n
>  Xilinx AXI PCIe host bridge support (PCIE_XILINX) [N/y/?] n
>  V3 Semiconductor PCI controller (PCI_V3_SEMI) [N/y/?] (NEW)
> 
> So I'm guessing, that you're probably missing some kernel config symbols
> (either in generic or in gemini config) when CONFIG_ALL_KMODS=y is enabled.

This should be added to target/linux/generic/config-4.19

Hauke

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

[OpenWrt-Devel] [PATCH] lantiq: make AVM FRITZ!Box naming consistent

[David Bauer]

This commit changes the model string and device title of all AVM boards
to fit the naming of the manufacturer.

Drop all provider-specific titles as they are re-used for every device
generation by 1&1. The original AVM model name is printed on the bottom
of every devices.

Exception applies for boards which are only supported by a specific
sub-revision.

Signed-off-by: David Bauer 
---
 .../arch/mips/boot/dts/FRITZ3370-REV2-HYNIX.dts  |  2 +-
 .../arch/mips/boot/dts/FRITZ3370-REV2-MICRON.dts |  2 +-
 .../arch/mips/boot/dts/FRITZ3370-REV2.dtsi   |  2 +-
 .../files-4.14/arch/mips/boot/dts/FRITZ7312.dts  |  2 +-
 .../files-4.14/arch/mips/boot/dts/FRITZ7320.dts  |  2 +-
 .../files-4.14/arch/mips/boot/dts/FRITZ7360SL.dts|  2 +-
 target/linux/lantiq/image/Makefile   | 12 ++--
 7 files changed, 12 insertions(+), 12 deletions(-)

diff --git 
a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ3370-REV2-HYNIX.dts 
b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ3370-REV2-HYNIX.dts
index 3cb7d7d723..ebd6f6e4c8 100644
--- a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ3370-REV2-HYNIX.dts
+++ b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ3370-REV2-HYNIX.dts
@@ -4,7 +4,7 @@
 
 / {
compatible = "avm,fritz3370-rev2-hynix", "avm,fritz3370-rev2", 
"lantiq,xway", "lantiq,vr9";
-   model = "AVM Fritz!Box WLAN 3370 Rev. 2 (Hynix NAND)";
+   model = "AVM FRITZ!Box 3370 Rev. 2 (Hynix NAND)";
 };
 
  {
diff --git 
a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ3370-REV2-MICRON.dts 
b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ3370-REV2-MICRON.dts
index 1a1be6fd37..dcc97d2808 100644
--- 
a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ3370-REV2-MICRON.dts
+++ 
b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ3370-REV2-MICRON.dts
@@ -4,7 +4,7 @@
 
 / {
compatible = "avm,fritz3370-rev2-micron", "avm,fritz3370-rev2", 
"lantiq,xway", "lantiq,vr9";
-   model = "AVM Fritz!Box WLAN 3370 Rev. 2 (Micron NAND)";
+   model = "AVM FRITZ!Box 3370 Rev. 2 (Micron NAND)";
 };
 
  {
diff --git 
a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ3370-REV2.dtsi 
b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ3370-REV2.dtsi
index a7e0c71915..9a0359d1cc 100644
--- a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ3370-REV2.dtsi
+++ b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ3370-REV2.dtsi
@@ -5,7 +5,7 @@
 
 / {
compatible = "avm,fritz3370-rev2", "lantiq,xway", "lantiq,vr9";
-   model = "AVM Fritz!Box WLAN 3370 Rev. 2";
+   model = "AVM FRITZ!Box 3370 Rev. 2";
 
chosen {
bootargs = "console=ttyLTQ0,115200";
diff --git a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7312.dts 
b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7312.dts
index c14695413e..796b941ede 100644
--- a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7312.dts
+++ b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7312.dts
@@ -6,7 +6,7 @@
 
 / {
compatible = "avm,fritz7312", "lantiq,xway", "lantiq,ar9";
-   model = "FritzBox 7312 (1&1 WLAN-MODEM)";
+   model = "AVM FRITZ!Box 7312";
 
chosen {
bootargs = "console=ttyLTQ0,115200";
diff --git a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7320.dts 
b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7320.dts
index 45a59c012d..cd274277d1 100644
--- a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7320.dts
+++ b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7320.dts
@@ -6,7 +6,7 @@
 
 / {
compatible = "avm,fritz7320", "lantiq,xway", "lantiq,ar9";
-   model = "1&1 HomeServer";
+   model = "AVM FRITZ!Box 7320";
 
chosen {
bootargs = "console=ttyLTQ0,115200";
diff --git a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7360SL.dts 
b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7360SL.dts
index 91520c8137..53623ab56c 100644
--- a/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7360SL.dts
+++ b/target/linux/lantiq/files-4.14/arch/mips/boot/dts/FRITZ7360SL.dts
@@ -7,7 +7,7 @@
 
 / {
compatible = "avm,fritz7360sl", "lantiq,xway", "lantiq,vr9";
-   model = "1&1 HomeServer";
+   model = "AVM FRITZ!Box 7360 SL";
 
chosen {
bootargs = "console=ttyLTQ0,115200";
diff --git a/target/linux/lantiq/image/Makefile 
b/target/linux/lantiq/image/Makefile
index e9d9e42027..b59acf4ddc 100644
--- a/target/linux/lantiq/image/Makefile
+++ b/target/linux/lantiq/image/Makefile
@@ -489,7 +489,7 @@ define Device/avm_fritz7312
   $(Device/AVM)
   DEVICE_DTS := FRITZ7312
   IMAGE_SIZE := 15744k
-  DEVICE_TITLE := 1&1 WLAN-MODEM - FRITZ7312
+  DEVICE_TITLE := AVM FRITZ!Box 7312
   DEVICE_PACKAGES := kmod-ath9k kmod-owl-loader wpad-mini \
kmod-ltq-adsl-ar9-mei kmod-ltq-adsl-ar9 \
kmod-ltq-adsl-ar9-fw-b kmod-ltq-atm-ar9 \

Re: [OpenWrt-Devel] [PATCH] treewide: dts: Unify naming of gpio-keys nodes

[Petr Štetiar]

Christian Lamparter  [2019-01-22 17:54:13]:

Hi,

> The at91, apm821xx, ipq40xx, ipq806x, layerscape and oxnas are probably
> ready to be merged.

a lot of additional work, thanks!

> The situation with ramips, ath79 and lantiq is a bit more complicated:
> 
> 
> 
> because some of these devices also have a separated ath9k-leds 
> and in theory these nodes "could be merged". However, this is
> going to be a bad idea and so I left the "gpio-leds" in these cases
> as is. Maybe "soc-leds" could be a better name, but I don't think
> upstream will care much about that.

I've noticed those during my sed session as well, but checked those manualy
and it looked fine, but maybe I've overlooked something, sorry for that.

> Feedback for merging patches upstream or into openwrt? For upstream:
> Have you talked to Rob or Mark? Usually, they do review device-tree
> changes related to drivers and suchs relatively quickly. 

Nope, the patch was sent just a few days ago (December 16th), so for me it's
still too early trying to ping someone about it.

> However, something must have caused them to ignore the default-state = off
> patch. I can't even find it in the devicetree patchwork. maybe it was too
> big?

It's hidden here https://patchwork.kernel.org/patch/10732469/ even with 'To:
devicet...@vger.kernel.org' header, so maybe the patchwork/mail pipeline
hickup?

> Why not start there? Upstream has a accumulated a vast library of semantic
> patches (http://coccinelle.lip6.fr/) and from what I can tell, these have 
> a pretty good track record to get accepted. (I guess the main difficulty here
> will be to check whenever spatch already supports dts/dtsi files or not).

Nice tool, but still without DT support.

-- ynezz

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

Re: [OpenWrt-Devel] [PATCH] treewide: dts: Unify naming of gpio-keys nodes

[Christian Lamparter]

On Thursday, January 3, 2019 10:39:08 PM CET Petr Štetiar wrote:
> Christian Lamparter  [2019-01-03 18:27:40]:
> 
> > I would try to split up the patch into multiple patches so that
> > each maintainer has the chance to act on just his own turf. 
> 
> I don't want to waste more of my time on such noop stuff, I've tried it so
> let's see how it pans out :-)

Well, I've split both patches (this and gpio-leds) up and put them into my
staging tree.



The at91, apm821xx, ipq40xx, ipq806x, layerscape and oxnas are probably
ready to be merged.

The situation with ramips, ath79 and lantiq is a bit more complicated:



because some of these devices also have a separated ath9k-leds 
and in theory these nodes "could be merged". However, this is
going to be a bad idea and so I left the "gpio-leds" in these cases
as is. Maybe "soc-leds" could be a better name, but I don't think
upstream will care much about that.

> 
> > Keep in mind that linux-kernel is heavily compartmentalized. The device-tree
> > maintainers mainly just ack/review patches for the subsystem maintainers.
> 
> Yea, just give me some feedback and I'm more then happy to do what is
> necessary to finish this crusade, but until then I'll just put it on ice.
Feedback for merging patches upstream or into openwrt? For upstream:
Have you talked to Rob or Mark? Usually, they do review device-tree
changes related to drivers and suchs relatively quickly. However, something
must have caused them to ignore the default-state = off patch. I can't
even find it in the devicetree patchwork. maybe it was too big?

> > While looking at the checklist, I noticed that one of the "SPDX license tag"
> > check is already automated in the upstream scripts/checkpatch.pl... And now,
> > I wish that the script could also act on default-state = "off", the
> > "gpio-keys-polled" and "gpio-leds" node names, etc.
> 
> Indeed, it would be nice to automate this and other checks and integrate it
> into GitHub's PR pipeline via some CI system. Well, one day :-)
Why not start there? Upstream has a accumulated a vast library of semantic
patches (http://coccinelle.lip6.fr/) and from what I can tell, these have 
a pretty good track record to get accepted. (I guess the main difficulty here
will be to check whenever spatch already supports dts/dtsi files or not).

Regards,
Christian



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

Re: [OpenWrt-Devel] INSTALL_SUID macro

[Jeff Kletsky]

On 1/22/19 3:26 AM, Daniel Golle wrote:

Hi Jo,
Hi everyone,

I was happy to see the addition of the INSTALL_SUID macro and now
wonder if it'd make sense to use fakeroot in order to allow installing
files for different users as well. For now, all files in rootfs are
always owned by root:root, and sometimes this is not what we want.


The ability to easily have services running with reduced privileges 
would be a welcome change. While I have also written some rather ugly 
scripts to change ownership at first boot, such a change would allow 
OpenWrt to ship and packages to install in an arguably more secure 
configuration.


For packages, it would seem that some changes in opkg might be needed to 
manage the proper additions to users/groups, as well as setting 
ownership and access during install. Personally, it wouldn't bother me 
if the added users/groups were not removed if the package was removed.



Jeff



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

Re: [OpenWrt-Devel] [PATCH] ath79: ag71xx: Fix tx queue timeouts during ifup

[Chuanhong Guo]

Hi!

On Thu, Jan 3, 2019 at 10:25 AM Petr Štetiar  wrote:
>
> On ath79 and UBNT Bullet M XW (ar9342) I was experiencing weird issues during
> network setup[1] which I was able to reproduce easily with following commands:
>
>  uci set network.lan.ipaddr='192.168.1.20'
>  uci commit network
>  ifup lan
>
> Which resulted after some time in:
>
>  ...
>  WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:461 
> dev_watchdog+0x16c/0x280
>  NETDEV WATCHDOG: eth0 (ag71xx): transmit queue 0 timed out
>  ...
> So I've looked at ag71xx_stop() in ar71xx, added the missing bits to ath79 and
> fixed this issue.
I ran into the same issue today on QCA9558 and this commit fixed the
problem for me, too :)
>
> 1. https://github.com/openwrt/openwrt/pull/1635#issuecomment-448638246
>
> Signed-off-by: Petr Štetiar 
> ...

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

[OpenWrt-Devel] [RFT] toolchain/musl: update to version 1.1.21

[Christian Lamparter]

"This release makes improvements with respect to default thread stack
size, including increasing the default from 80k to 128k, increasing
the default guard size from 4k to 8k, and allowing the default to be
increased via ELF headers so that programs that need larger stacks can
be build without source-level changes, using just LDFLAGS.
Insufficient stack size for AIO threads on kernels that don't honor
the constant MINSIGSTKSZ is also fixed.

The glob core has been rewritten to fix inability to see past
searchable-but-unreadable path components, and to avoid excessive
stack usage and unnecessary syscalls. The tsearch AVL tree
implementation has also been rewritten for better size and
performance. The math library adds more native single-instruction
implementations for arm, s390x, powerpc, and x86_64.

Various bugs are fixed, including several possible deadlocks, one of
which was a new regression in 1.1.20."

Signed-off-by: Christian Lamparter 
---
 toolchain/musl/common.mk  | 8 
 toolchain/musl/patches/200-add_libssp_nonshared.patch | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/toolchain/musl/common.mk b/toolchain/musl/common.mk
index 40c6273e63..b52263c43b 100644
--- a/toolchain/musl/common.mk
+++ b/toolchain/musl/common.mk
@@ -8,13 +8,13 @@ include $(TOPDIR)/rules.mk
 include $(INCLUDE_DIR)/target.mk
 
 PKG_NAME:=musl
-PKG_VERSION:=1.1.20
-PKG_RELEASE:=2
+PKG_VERSION:=1.1.21
+PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_VERSION:=0fa1e638e87cf257e9f96b4019b2076afd674a19
-PKG_MIRROR_HASH:=0a49559e845f51aaf006539176a36d6527957affd2838e71fd43275b737e90fe
+PKG_SOURCE_VERSION:=1691b23955590d1eb66a11158fdd91c86337e886
+PKG_MIRROR_HASH:=4fa312d0ca020d31603ced84a7103fb328c6ae9508239491a228be17e7807147
 PKG_SOURCE_URL:=git://git.musl-libc.org/musl
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz
 
diff --git a/toolchain/musl/patches/200-add_libssp_nonshared.patch 
b/toolchain/musl/patches/200-add_libssp_nonshared.patch
index b8fa7b4b4f..05bd2fe54a 100644
--- a/toolchain/musl/patches/200-add_libssp_nonshared.patch
+++ b/toolchain/musl/patches/200-add_libssp_nonshared.patch
@@ -24,7 +24,7 @@ Signed-off-by: Steven Barth 
 +OBJ_DIRS = $(sort $(patsubst %/,%,$(dir $(ALL_LIBS) $(ALL_TOOLS) $(ALL_OBJS) 
$(GENH) $(GENH_INT))) obj/include obj/libssp_nonshared)
  
  $(ALL_LIBS) $(ALL_TOOLS) $(ALL_OBJS) $(ALL_OBJS:%.o=%.lo) $(GENH) 
$(GENH_INT): | $(OBJ_DIRS)
-
+ 
 @@ -113,6 +113,8 @@ obj/crt/rcrt1.o: $(srcdir)/ldso/dlstart.
  
  obj/crt/Scrt1.o obj/crt/rcrt1.o: CFLAGS_ALL += -fPIC
@@ -34,7 +34,7 @@ Signed-off-by: Steven Barth 
  OPTIMIZE_SRCS = $(wildcard $(OPTIMIZE_GLOBS:%=$(srcdir)/src/%))
  $(OPTIMIZE_SRCS:$(srcdir)/%.c=obj/%.o) 
$(OPTIMIZE_SRCS:$(srcdir)/%.c=obj/%.lo): CFLAGS += -O3
  
-@@ -165,6 +166,11 @@ lib/libc.a: $(AOBJS)
+@@ -165,6 +167,11 @@ lib/libc.a: $(AOBJS)
$(AR) rc $@ $(AOBJS)
$(RANLIB) $@
  
-- 
2.20.1


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

Re: [OpenWrt-Devel] [PATCH 1/2] mpc85xx: use generic diag.sh

[Christian Lamparter]

On Thursday, January 17, 2019 12:43:12 AM CET David Bauer wrote:
> This commit removes the target-specific diag.sh script. This way, the
> generic one is used for the target, which uses DT-aliases to specify the
> LEDs used.
> 
> This way, we are also able to use different LEDs to indicate different
> states. We use green status LEDs for indicating boot and a running
> system. Where possible, the red status LED is used to indicate failsafe
> mode and a running upgrade.
> 
> Signed-off-by: David Bauer 
> ---
>  target/linux/mpc85xx/base-files/etc/diag.sh   | 41 ---
>  .../arch/powerpc/boot/dts/hiveap-330.dts  | 11 -
>  .../arch/powerpc/boot/dts/red-15w-rev1.dts| 11 -
>  .../arch/powerpc/boot/dts/tl-wdr4900-v1.dts   |  6 ++-
>  4 files changed, 23 insertions(+), 46 deletions(-)
>  delete mode 100644 target/linux/mpc85xx/base-files/etc/diag.sh
> 
> diff --git a/target/linux/mpc85xx/base-files/etc/diag.sh 
> b/target/linux/mpc85xx/base-files/etc/diag.sh
> deleted file mode 100644
> index e344d4b756..00
> --- a/target/linux/mpc85xx/base-files/etc/diag.sh
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -#!/bin/sh
> -# Copyright (C) 2013 OpenWrt.org
> -
> -. /lib/functions.sh
> -. /lib/functions/leds.sh
> -
> -get_status_led() {
> - case $(board_name) in
> - aerohive,hiveap-330)
> - status_led="hiveap-330:green:tricolor0"
> - ;;
> - sophos,red-15w-rev1)
> - status_led="red-15w-rev1:green:system"
> - ;;
> - tplink,tl-wdr4900-v1)
> - status_led="tp-link:blue:system"
> - ;;
> - esac
> -}
> -
> -set_state() {
> - get_status_led
> -
> - case "$1" in
> - preinit)
> - status_led_blink_preinit
> - ;;
> -
> - failsafe)
> - status_led_blink_failsafe
> - ;;
> -
> - preinit_regular)
> - status_led_blink_preinit_regular
> - ;;
> -
> - done)
> - status_led_on
> - ;;
> - esac
> -}
> diff --git a/target/linux/mpc85xx/files/arch/powerpc/boot/dts/hiveap-330.dts 
> b/target/linux/mpc85xx/files/arch/powerpc/boot/dts/hiveap-330.dts
> index 5e732664aa..c4abc905e9 100644
> --- a/target/linux/mpc85xx/files/arch/powerpc/boot/dts/hiveap-330.dts
> +++ b/target/linux/mpc85xx/files/arch/powerpc/boot/dts/hiveap-330.dts
> @@ -14,6 +14,13 @@
>   model = "Aerohive HiveAP-330";
>   compatible = "aerohive,hiveap-330";
>  
> + aliases {
> + led-boot = _green;
> + led-failsafe = _red;
> + led-running = _green;
> + led-upgrade = _red;
> + };
The Hive AP330/AP350 manual

states in the "Status Indicator" section that the boot color
should probably be "solid blue". The "operating normal"/led-running
color is "white", wheras "purple" is the "new upgrade".

However, getting "white" and "purple" to work will be tricky. I think
it's possible to do that with the led-pattern trigger in the future,
once it can be setup through DT. 

@Chris: do you still have the AP or do you have any comments?

Regards,
Christian



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

Re: [OpenWrt-Devel] lantiq: Netgear DM200 kernel too large

[Bjørn Mork]

Thomas Nixon  writes:
> On 1/21/19, Bjørn Mork  wrote:
>
>> I wonder about those better options...  What are they?
>
> In the UK at least BT OpenReach modems are available very cheaply second hand
> and are in theory a bit better, for a few reasons.

I only found this when googling: https://openwrt.org/toh/bt/vg3503j

And that looks like similar hardware, only with less RAM.  What am I missing?

> I'm not sure if all of them can run openwrt, but after some reflection I'm not
> that concerned by this. They will do PPPoE so you don't really need to touch
> them, and you can consider them to be outside your network.

I am sorry, but I do not buy this argument.  Sure, I can (and do) run
OpenWrt on more capable routers in my network.  But I still want to run
OpenWrt on the standalone VDSL2 modem too. And the DM200 looks like the
best option for the forseeable future.

Yes, I know proprietary solutions exist.  I am using one of those right
now (broadcom based).  Of course it does sort of work. But the
management sucks.  The configuration is a mess.  There is no snmp
support.  And the kernel is from the stone age.  Sure, I can close my
eyes and consider it outside my network.  But if I have a choice, then I
prefer replacing it with a proper OpenWrt device with sane management,
less bugs, and the possiblity of actually having more bugs fixed than
added.


FWIW, PPP support is irrelevant to me. My IP sessions are terminated on
more capable routers anyway.  And only one of the sessions is PPPoE.



Bjørn

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

Re: [OpenWrt-Devel] lantiq: Netgear DM200 kernel too large

[Bjørn Mork]

I thought this was implied around here, but just to make it absolutely
clear: OpenWrt support is required.


Bjørn

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

Re: [OpenWrt-Devel] lantiq: Netgear DM200 kernel too large

[Alberto Bursi]

On 22/01/19 01:11, Thomas Nixon wrote:

On 1/21/19, Bjørn Mork  wrote:

Paul Oranje  writes:

Op 20 jan. 2019, om 17:52 heeft Thomas Nixon  het
volgende geschreven:

I could add a new subtarget like xrx200 but with small_flash enabled, but
this
seems a bit excessive for a single board. The DM200 has generally been a
pain
to support, and there are better options out there, so I wonder if it
makes
more sense to just drop it.

Some people use this modem, so dropping its support will not please
everybody.
Supporting it as a small flash device seems the right approach.

I wonder about those better options...  What are they?

In the UK at least BT OpenReach modems are available very cheaply second hand
and are in theory a bit better, for a few reasons.

I'm not sure if all of them can run openwrt, but after some reflection I'm not
that concerned by this. They will do PPPoE so you don't really need to touch
them, and you can consider them to be outside your network. There therefore
isn't a huge security advantage to replacing the OS, especially when they're
running plenty of proprietary firmware in either case.

Hopefully we can keep supporting them anyway.

Thanks,

Tom



If the need was doing a true PPPoA-PPPoE bridge,  (i.e. if your line is 
PPPoA)

I've used a Draytech Vigor 120 (with stock firmware).

That's this device's main selling point.

I didn't find any other consumer device that can do it.

https://www.draytek.co.uk/products/business/vigor-120


I also agree on the statement that modems in bridging aren't 
particularly unsafe given the level in the stack they are working at.



-Alberto



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

Re: [OpenWrt-Devel] [PATCH 0/4] Update Gemini to kernel v4.19

[Linus Walleij]

On Tue, Jan 22, 2019 at 12:15 PM Petr Štetiar  wrote:

> Ends with following:
>
>  make[5]: Entering directory 
> '/openwrt/build_dir/target-arm_fa526_musl_eabi/linux-gemini/linux-4.19.16'
>  Makefile:600: include/config/auto.conf: No such file or directory
>YACCscripts/kconfig/zconf.tab.c
>HOSTCC  scripts/kconfig/conf.o
>LEX scripts/kconfig/zconf.lex.c
>HOSTCC  scripts/kconfig/zconf.tab.o
>HOSTLD  scripts/kconfig/conf
>  scripts/kconfig/conf  --syncconfig Kconfig
>  net/sched/Kconfig:44: warning: menuconfig statement without prompt
>  .config:3930:warning: symbol value 'm' invalid for NF_NAT_REDIRECT
>  *
>  * Restart config...
()
> So I'm guessing, that you're probably missing some kernel config symbols
> (either in generic or in gemini config) when CONFIG_ALL_KMODS=y is enabled.

Yeah interesting, hm there is that make target for OpenWrt that cleans
up the defconfig now that I remember it, I'll try running that.

Yours,
Linus Walleij

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

Re: [OpenWrt-Devel] Invalid revision range

[R. Diez via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---



If Git fails with a "fatal" error inside getver.sh, how come the build does not 
stop at that point?


Failed to calculate current revision isn't a "fatal error". As you can
see in getver.sh it falls back to reporting an "unknown" version and
the rest of the buildroot works just fine. A exact revision isn't a
must during the entire building procedure.

> [...]

Seeing a fatal error on the build log is not exactly reassuring. I did 
not want to set any OpenWrt revision, so I was not expecting anything 
like this.


What's the impact of building an "unknown" version? Is that part of the 
OpenWrt version string or version information in the end? In that case, 
an "unknown" version is indeed undesirable.


If the user wants to set a particular version, that's fine. But if he 
does not, and determining the current version from Git fails, the script 
should not just ignore it.


The script is too brittle. Ignoring errors is usually a bad idea. Maybe 
next time it will be something else that fails and goes unnoticed. From 
the reactions I got, I suspect other such scripts in OpenWrt are also 
like this. Such brittle scripts have given me grief in the past.


If there is interest, I can make getver.sh and maybe others more robust, 
and fix any ShellCheck warnings along the way.


About getver.sh, I do not like the idea that you try Git first, and then 
Mercurial. This is rather nondeterministic. Either you are using one, or 
the other. Something like GET_VERSION_FROM=git (as default) or 
GET_VERSION_FROM=mercurial would probably be better.


Best regards,
  rdiez

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

Re: [OpenWrt-Devel] Invalid revision range

[Chuanhong Guo]

Hi!
On Tue, Jan 22, 2019 at 3:16 AM R. Diez via openwrt-devel
 wrote:
...
> If Git fails with a "fatal" error inside getver.sh, how come the build does 
> not stop at that point?

Failed to calculate current revision isn't a "fatal error". As you can
see in getver.sh it falls back to reporting an "unknown" version and
the rest of the buildroot works just fine. A exact revision isn't a
must during the entire building procedure.

> For example: do we still need support for "version" and "hg" (Mercurial) in 
> that script?

The version file is for people to easily set their custom version if
they want. (e.g. if a manufacturer wants to pack their own OpenWrt
buildroot for their customers, this feature is useful)
As for hg OpenWrt never officially uses this as a version controlling
tool. I think it's there so that it's convenient when people want to
use this in their custom branch. It was added 10 years ago in svn
r17432.

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

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

Re: [OpenWrt-Devel] INSTALL_SUID macro

[Jo-Philipp Wich]

Hi Daniel,

I am fine with adding a fakeroot solution.


~ Jo



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

[OpenWrt-Devel] INSTALL_SUID macro

[Daniel Golle]

Hi Jo,
Hi everyone,

I was happy to see the addition of the INSTALL_SUID macro and now
wonder if it'd make sense to use fakeroot in order to allow installing
files for different users as well. For now, all files in rootfs are
always owned by root:root, and sometimes this is not what we want.
I'm currently working around this by fixing permissions at run-time on
the target, which is a bit ugly. Other distributions use fakeroot for
having the option of packaging files to be owned by different users.
See [1] for my current ugly work-around this missing packaging feature.

Let me know what you are thinking and if it would be feasible to add
fakeroot (or another way) to have non-root:root owned files installed
or packaged.

Cheers

Daniel


[1]: 
https://github.com/openwrt/packages/blob/master/net/gnunet/files/gnunet.init#L15

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

Re: [OpenWrt-Devel] [PATCH 0/4] Update Gemini to kernel v4.19

[Petr Štetiar]

Linus Walleij  [2019-01-21 23:17:50]:

Hi,

> I pushed it to the branch "gemini-v4.19" (with some more patches,
> but shouldn't make a difference) here:
> https://github.com/linusw/openwrt

thanks, so I've just tried following build config:

 CONFIG_TARGET_gemini=y
 CONFIG_TARGET_MULTI_PROFILE=y
 CONFIG_TARGET_ALL_PROFILES=y
 CONFIG_TARGET_DEVICE_gemini_DEVICE_dlink-dir-685=y
 CONFIG_TARGET_DEVICE_gemini_DEVICE_dlink-dns-313=y
 CONFIG_TARGET_DEVICE_gemini_DEVICE_sq201=y
 CONFIG_TARGET_DEVICE_gemini_DEVICE_nas4220b=y
 CONFIG_TARGET_DEVICE_gemini_DEVICE_sl93512r=y
 CONFIG_TARGET_DEVICE_gemini_DEVICE_rut1xx=y
 CONFIG_TARGET_DEVICE_gemini_DEVICE_wbd111=y
 CONFIG_TARGET_DEVICE_gemini_DEVICE_wbd222=y
 CONFIG_ALL_KMODS=y
 CONFIG_ALL_NONSHARED=y

And running:

 make V=s -j$(nproc)

Ends with following:

 make[5]: Entering directory 
'/openwrt/build_dir/target-arm_fa526_musl_eabi/linux-gemini/linux-4.19.16'
 Makefile:600: include/config/auto.conf: No such file or directory
   YACCscripts/kconfig/zconf.tab.c
   HOSTCC  scripts/kconfig/conf.o
   LEX scripts/kconfig/zconf.lex.c
   HOSTCC  scripts/kconfig/zconf.tab.o
   HOSTLD  scripts/kconfig/conf
 scripts/kconfig/conf  --syncconfig Kconfig
 net/sched/Kconfig:44: warning: menuconfig statement without prompt
 .config:3930:warning: symbol value 'm' invalid for NF_NAT_REDIRECT
 *
 * Restart config...
 *
 *
 * PCI controller drivers
 *
 Faraday Technology FTPCI100 PCI controller (PCI_FTPCI100) [Y/n/?] y
 Generic PCI host controller (PCI_HOST_GENERIC) [N/y/?] n
 Xilinx AXI PCIe host bridge support (PCIE_XILINX) [N/y/?] n
 V3 Semiconductor PCI controller (PCI_V3_SEMI) [N/y/?] (NEW)

So I'm guessing, that you're probably missing some kernel config symbols
(either in generic or in gemini config) when CONFIG_ALL_KMODS=y is enabled.

-- ynezz

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