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

[Philip Prindeville]

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


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

-Philip



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

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

[Syrone Wong]

It seems security is ignored completely. getrandom() makes sure it
gets initialized before reading any random numbers.

The correct way is to backport new random facilities to old kernels or
just switch all old kernels to the new one.

Prevent getrandom() is a dangerous workaround to bypass the real problem.

PS: I have a partially backported one located at [0] if anyone has interest

[0]: 
https://github.com/wongsyrone/lede-1/blob/master/target/linux/generic/pending-4.4/999-02-backport-random.patch


Best Regards,
Syrone Wong


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

 I will prepare a patch that forces util-linux to stick to /dev/urandom
 instead - that should hopefully fix this for good.
>>> Pushed the fix, please test.
>>>
>>> - Felix
>>
>>
>> Tested on x86_64.  Seems to work.
>
> To avoid patching mored packages in the future, would it make sense to
> LD_PRELOAD a library which overrides the SYS_getrandom() with a non
> blocking version/early return at appropriate times during system
> boot/upgrades which would suffer from low entropy?
> --
> Florian
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

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

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

[Florian Fainelli]

On 09/29/2017 06:01 PM, Philip Prindeville wrote:
> 
>> On Sep 29, 2017, at 4:39 AM, Felix Fietkau  wrote:
>>
>> On 2017-09-29 12:20, Felix Fietkau wrote:
>>> On 2017-09-11 02:33, Philip Prindeville wrote:
 Changing the subject from the previous thread as it turned out to not have 
 to do with sysupgrade at all.

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

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

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

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

 What would cause this to hang rather than return an error?
>>> I've used sysrq to trace this and found out that it's hanging in the
>>> getrandom system call, which could be used through util-linux library
>>> code. That also explains why the update broke it.
>>>
>>> I will prepare a patch that forces util-linux to stick to /dev/urandom
>>> instead - that should hopefully fix this for good.
>> Pushed the fix, please test.
>>
>> - Felix
> 
> 
> Tested on x86_64.  Seems to work.

To avoid patching mored packages in the future, would it make sense to
LD_PRELOAD a library which overrides the SYS_getrandom() with a non
blocking version/early return at appropriate times during system
boot/upgrades which would suffer from low entropy?
-- 
Florian

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

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

[Philip Prindeville]

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


Not actually my quote.

I think it was Christian.



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

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

[Philip Prindeville]

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


Tested on x86_64.  Seems to work.

Thanks!


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

[LEDE-DEV] [PATCH] hostapd: escape double quoutes in wpad CFLAGS

[Stijn Tintel]

A recent commit in hostapd added a build option to specify the default
TLS ciphers. This build option is passed via CFLAGS. Due to the way
CFLAGS are handled when building wpad, the compiler tries to expand
TLS_DEFAULT_CIPHERS, resulting in the following error:

../src/crypto/tls_openssl.c: In function 'tls_init':
:0:21: error: 'DEFAULT' undeclared (first use in this function)
../src/crypto/tls_openssl.c:1028:13: note: in expansion of macro 
'TLS_DEFAULT_CIPHERS'
   ciphers = TLS_DEFAULT_CIPHERS;
 ^

Escape double quotes in the .cflags file to avoid this.

Fixes: 3bcbf3d133f7 ("hostapd: update to version 2017-08-24")
Signed-off-by: Stijn Tintel 
---
 package/network/services/hostapd/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/network/services/hostapd/Makefile 
b/package/network/services/hostapd/Makefile
index 2558f2da0b..344896ca62 100644
--- a/package/network/services/hostapd/Makefile
+++ b/package/network/services/hostapd/Makefile
@@ -299,6 +299,7 @@ define Build/Compile/wpad
$(call Build/RunMake,wpa_supplicant,-s MULTICALL=1 dump_cflags) 
| \
sed -e 's,-n ,,g' -e 's^$(TARGET_CFLAGS)^^' \
` > $(PKG_BUILD_DIR)/.cflags
+   sed -i 's/"/\\"/g' $(PKG_BUILD_DIR)/.cflags
+$(call Build/RunMake,hostapd, \
CFLAGS="(cat $(PKG_BUILD_DIR)/.cflags)" \
MULTICALL=1 \
-- 
2.13.6


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

Re: [LEDE-DEV] clarifying how trivial it is to define a couple new IMX6QDL targets

[Florian Fainelli]

On 09/29/2017 10:33 AM, Robert P. J. Day wrote:
> 
>   i was just looking at using latest LEDE to define a couple new
> IMX6QDL targets, and after a few minutes, it looks as if, at least to
> get a minimal bootable system and as long as i'm not doing anything
> drastically weird, it should be wickedly simple and i just want to
> verify that.
> 
>   it's all based on the fact that, with the current kernel, the only
> selection you need to make is CONFIG_SOC_IMX6Q, which will build a
> suitable kernel, whereupon the file arch/arm/boot/dts/Makefile
> contains the directive:
> 
> dtb-$(CONFIG_SOC_IMX6Q) += \
>... over 100 target dtb files ...
> 
>   under the circumstances, given that that single kernel is compatible
> with that many targets, it would appear that, as long as i don't care
> that 100+ other dtb files will be compiled, i can just add, under the
> LEDE directory target/linux/imx6/files-4.9/arch/arm/boot/dts, a couple
> new .dts files, like:
> 
>   acme_coyote_1.dts
>   acme_coyote_2.dts
> 
> and that's it.
> 
>   of course, there might be enhancements down the road but, for now,
> just to get something bootable, it seems all i need to do is patch a
> couple entries into arch/arm/boot/dts/Makefile, and add the dts files.
> 
>   am i understanding this correctly?

As far as the kernel and DTS build is concerned that is pretty much all
that is needed, you will need a patch to arch/arm/boot/dts/Makefile to
make sure that your DTS get built into a DTB AFAICT.

You will probably need to pair the DTS file(s) with an appropriate
change under target/linux/imx6/image/Makefile that adds a new
Device/acme-coyote1 and has at least a DEVICE_DTS := acme_coyote_1.dts
to build a kernel with an appended DTB image.
-- 
Florian

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

Re: [LEDE-DEV] Is LOCALMIRROR for setting up a local mirror directory purely for tarballs?

[Florian Fainelli]

Hi,

On 09/29/2017 06:18 AM, rpj...@crashcourse.ca wrote:
> 
> I want the OE equivalent of a local source mirror, purely for tarballs
> that I
> don't want to have to download each time I do a new build (as in, I'm
> not trying
> to define a local feed, just a tarballs directory). Is that what
> LOCALMIRROR is
> for? The full pathname to a directory chock-full of nothing but tarballs?
> Thanks.

CONFIG_LOCALMIRROR is really for e.g: an HTTP/FTP server that is going
to host tarballs of the source packages (analogous to
downloads.openwrt.org for instance). I have not tried, but it might be
that doing something like file:///path/to/sources on your filesystem may
work just fine.

If you want to set up a local directory that contains tarballs, that's a
different option and it is CONFIG_DOWNLOAD_FOLDER that you may want to
use instead.
-- 
Florian

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

[LEDE-DEV] clarifying how trivial it is to define a couple new IMX6QDL targets

[Robert P. J. Day]

  i was just looking at using latest LEDE to define a couple new
IMX6QDL targets, and after a few minutes, it looks as if, at least to
get a minimal bootable system and as long as i'm not doing anything
drastically weird, it should be wickedly simple and i just want to
verify that.

  it's all based on the fact that, with the current kernel, the only
selection you need to make is CONFIG_SOC_IMX6Q, which will build a
suitable kernel, whereupon the file arch/arm/boot/dts/Makefile
contains the directive:

dtb-$(CONFIG_SOC_IMX6Q) += \
   ... over 100 target dtb files ...

  under the circumstances, given that that single kernel is compatible
with that many targets, it would appear that, as long as i don't care
that 100+ other dtb files will be compiled, i can just add, under the
LEDE directory target/linux/imx6/files-4.9/arch/arm/boot/dts, a couple
new .dts files, like:

  acme_coyote_1.dts
  acme_coyote_2.dts

and that's it.

  of course, there might be enhancements down the road but, for now,
just to get something bootable, it seems all i need to do is patch a
couple entries into arch/arm/boot/dts/Makefile, and add the dts files.

  am i understanding this correctly?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday



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

Re: [LEDE-DEV] [PATCH 1/3] sunxi: backport the stmmac driver from kernel 4.13

[Hauke Mehrtens]

On 09/29/2017 09:12 AM, Andrey Jr. Melnikov wrote:
> In article <20170928214945.13510-1-ha...@hauke-m.de> you wrote:
>> This adds support for the GMAC which is use in the A64 and other
>> Allwinner chips by backporting the changes from the kernel versions
>> 4.13.
> 
> Why this part only for sunxi? It's should land in generic, ipq8064 uses 
> stmmac too.

I added it only for sunxi, because this needs extra testing on the other
platforms like ipq806x, archs38, arc770, pistachio and oxnas. I do not
have devices for most of these targets so testing is hard for me and I
would not be surprised if I would break some of them.

I also think it does not bring a big advantage to these targets, I added
it to sunxi because the new version adds support for the controller used
in newer Allwinner SoCs, without this patch Ethernet is not working at all.

Hauke

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

Re: [LEDE-DEV] [OpenWrt-Devel] MV88E6060 switch

[Nerijus Baliunas via Lede-dev]

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 ---
On Fri, 8 Sep 2017 22:50:13 +0300 Sergey Ryazanov  
wrote:

> >> >> Did  you  see  the  "Marvell  88E6060  PHY  driver attached" in kernel
> >> >> messages   log?  If  not then the mwswitch driver did not attached and
> >> >> you  should  fix  this  first.  And  only  then  go  to  the interface
> >> >> configuration.
> >> >
> >> > No, dmesg|grep 6060 does not show anything. How do I fix it?
> >>
> >> Try   to check, which MDIO addresses PHY core (or Ethernet MAC driver)
> >> scans to detect connected PHYs.
> >
> > I enabled #define DEBUG_MDIO 1 in ixp4xx_eth.c and got this:
> > # dmesg|grep -i MII|grep -v took
> > ...
> > [0.976646] IXP4xx MII Bus #16: MII read [2] -> 0x141
> > [0.976747] IXP4xx MII Bus #16: MII read [3] -> 0xC87
> > [0.978682] IXP4xx MII Bus #24: MII read [3] -> 0x602
> 
> Looks like mvswitch driver tries to check chip here and got an
> expected value 0x060X from register 3. So on the one hand the driver
> is functioning, but on the other hand it can not detect switch IC.
> 
> Can you go to the /sys/class/mdio_bus/ and for each bus check driver
> and ID of the each detected device. E.g.:
> # cd /sys/class/mdio_bus
> # ls -l */*/driver

lrwxrwxrwx1 root root 0 Jul 22 21:31 
ixp4xx-eth-0/ixp4xx-eth-0:01/driver -> 
../../../../../bus/mdio_bus/drivers/Generic PHY
lrwxrwxrwx1 root root 0 Jul 22 21:31 
ixp4xx-eth-0/ixp4xx-eth-0:10/driver -> 
../../../../../bus/mdio_bus/drivers/Marvell 88E6060

> # ls -l */*/phy_id

-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:01/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:10/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:11/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:12/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:13/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:14/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:15/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:16/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:17/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:18/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:19/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1a/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1b/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1c/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1d/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1e/phy_id
-r--r--r--1 root root  4096 Jul 22 21:32 
ixp4xx-eth-0/ixp4xx-eth-0:1f/phy_id

> # cat */*/phy_id

0x8201
0x088e6060
0x01410c87
0x01410c87
0x01410c87
0x01410c87
0x
0x
0x
0x0602
0x0602
0x0602
0x0602
0x0602
0x0602
0x
0x

Regards,
Nerijus

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

[LEDE-DEV] Is LOCALMIRROR for setting up a local mirror directory purely for tarballs?

[rpjday]

I want the OE equivalent of a local source mirror, purely for tarballs that I
don't want to have to download each time I do a new build (as in, I'm  
not trying
to define a local feed, just a tarballs directory). Is that what  
LOCALMIRROR is

for? The full pathname to a directory chock-full of nothing but tarballs?
Thanks.

rday


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

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

[Bjørn Mork]

Matthias May  writes:

> While unfortunate that the actual patch which got merged didn't have the 
> explanation why the patch was done, if you look
> at the mailing list archive you will see that there was a thread discussing 
> this topic:
> http://lists.infradead.org/pipermail/lede-dev/2017-September/009004.html

This fails to discuss the reason that TTL restriction was there in the
first place, as well as any security implications of the change.

Please see
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-6520
https://www.kb.cert.org/vuls/id/550620
and more.  This is a well known can of worms.

As said before: You should disuss such issues with your proposed
patches.  Not doing so gives the impression that you either

 a) don't understand the implications, or
 b) don't care about security

I hope neither is true.  Please reassure me by fixing this up.


Bjørn

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

Re: [LEDE-DEV] [PATCH] uloop: make SIGCHLD signal handling optional

[Felix Fietkau]

On 2017-09-29 13:35, Petar Paradzik wrote:
> It is already present (in the master), but not used.
You're right. Will merge this patch.

Thanks,

- Felix

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

Re: [LEDE-DEV] [PATCH] uloop: make SIGCHLD signal handling optional

[Petar Paradzik]

It is already present (in the master), but not used.

Regards,
Petar

On Fri, Sep 29, 2017 at 12:41 PM, Felix Fietkau  wrote:
> On 2017-07-03 13:37, Petar Paradzik wrote:
>> Some programs want to manage their own child life cycle without using
>> SIGCHLD signal handler. In these cases, uloop is reaping children for
>> them because they don't have SIGCHLD handler set. This patch makes it
>> possible to disable reaping children through 'uloop_handle_sigchld'
>> variable.
>>
>> Signed-off-by: Petar Paradzik 
>> ---
>>  uloop.c | 5 -
> You also need to add 'extern bool uloop_handle_sigchld' to uloop.h
>
> - Felix

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

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

[Lucian Cristian]

On 29.09.2017 14:07, Felix Fietkau wrote:

On 2017-09-29 13:04, Daniel Golle wrote:

On Fri, Sep 29, 2017 at 12:20:08PM +0200, Felix Fietkau wrote:

On 2017-09-11 02:33, Philip Prindeville wrote:

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

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

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

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

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

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

I've used sysrq to trace this and found out that it's hanging in the
getrandom system call, which could be used through util-linux library
code. That also explains why the update broke it.

I will prepare a patch that forces util-linux to stick to /dev/urandom
instead - that should hopefully fix this for good.

mkfs.f2fs also uses getrandom(3) and hangs there for some minutes when
creating the initial snapshot...

I don't see any direct calls to getrandom from mkfs.f2fs, so I assume
they are issued through util-linux libuuid. That would explain why my
change fixes the issue (with f2fs as overlay fs) for me, and results in
the following new warning:

[8.756017] random: mkfs.f2fs: uninitialized urandom read (16 bytes read)

- Felix

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


tested on sun7i on 2.30.1 and 2.30.2 and seems to work

[    8.808332] mount_root: rootdisk overlay filesystem has not been 
formatted yet

[    8.957393] random: mkfs.f2fs: uninitialized urandom read (16 bytes read)
[    8.969056] random: fast init done
[    9.321046] random: crng init done


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

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

[Felix Fietkau]

On 2017-09-29 13:04, Daniel Golle wrote:
> On Fri, Sep 29, 2017 at 12:20:08PM +0200, Felix Fietkau wrote:
>> On 2017-09-11 02:33, Philip Prindeville wrote:
>> > Changing the subject from the previous thread as it turned out to not have 
>> > to do with sysupgrade at all.
>> > 
>> > What I can tell is this, having added some tracing to fstools.
>> > 
>> > We get to the call to system() in rootdisk_volume_init():
>> > 
>> > https://git.lede-project.org/?p=project/fstools.git;a=blob;f=libfstools/rootdisk.c;h=dd00c1b4e5b4aa9b748610fa3e93d301a67101a7;hb=HEAD#l269
>> > 
>> > and it never seems to return.  The value of “str” is “mkfs.f2fs -q -l 
>> > rootfs_data /dev/loop0”.
>> > 
>> > What would cause this to hang rather than return an error?
>> I've used sysrq to trace this and found out that it's hanging in the
>> getrandom system call, which could be used through util-linux library
>> code. That also explains why the update broke it.
>> 
>> I will prepare a patch that forces util-linux to stick to /dev/urandom
>> instead - that should hopefully fix this for good.
> 
> mkfs.f2fs also uses getrandom(3) and hangs there for some minutes when
> creating the initial snapshot...
I don't see any direct calls to getrandom from mkfs.f2fs, so I assume
they are issued through util-linux libuuid. That would explain why my
change fixes the issue (with f2fs as overlay fs) for me, and results in
the following new warning:

[8.756017] random: mkfs.f2fs: uninitialized urandom read (16 bytes read)

- Felix

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

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

[Daniel Golle]

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

mkfs.f2fs also uses getrandom(3) and hangs there for some minutes when
creating the initial snapshot...


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

Re: [LEDE-DEV] [PATCH] uloop: make SIGCHLD signal handling optional

[Felix Fietkau]

On 2017-07-03 13:37, Petar Paradzik wrote:
> Some programs want to manage their own child life cycle without using
> SIGCHLD signal handler. In these cases, uloop is reaping children for
> them because they don't have SIGCHLD handler set. This patch makes it
> possible to disable reaping children through 'uloop_handle_sigchld'
> variable.
> 
> Signed-off-by: Petar Paradzik 
> ---
>  uloop.c | 5 -
You also need to add 'extern bool uloop_handle_sigchld' to uloop.h

- Felix

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

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

[Felix Fietkau]

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

- Felix

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

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

[Felix Fietkau]

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

I will prepare a patch that forces util-linux to stick to /dev/urandom
instead - that should hopefully fix this for good.

- Felix

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

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

[Matthias May]

On 29/09/17 10:28, Syrone Wong wrote:
> The sad truth is it has been pushed via
> https://github.com/lede-project/source/commit/00e9a7aacb66b3f00df2002e8210bdb5086d2e0c
> 
> 
> Best Regards,
> Syrone Wong
> 
> 
> On Fri, Sep 29, 2017 at 3:52 PM, Bjørn Mork  wrote:
>> Note that security is the usual (only?) reason one would enforce TTL=255.
>> Requiring TTL=255 is the same as guaranteeing that the packet source is
>> in the same L2 domain.  This prevents any direct remote attack.
>>
>> Please do not propose any patches removing such a restriction without at
>> least explaining why this can be done without negative security
>> implications. Thanks
>>
>>
>>
>> Bjørn
>>
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

Why are you sad that this got merged?
It fixes compatibility with current implementations of mDNS.

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

Since most people update their distributions, thus have a "newer implementation 
of mDNS", umdns was kind of broken in
this regards.

While unfortunate that the actual patch which got merged didn't have the 
explanation why the patch was done, if you look
at the mailing list archive you will see that there was a thread discussing 
this topic:
http://lists.infradead.org/pipermail/lede-dev/2017-September/009004.html

The restriction of IP TTL == 255 applies to responses, but not to queries.
See RFC6762 chapter 11 for more.

BR
Matthias

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

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

[Syrone Wong]

The sad truth is it has been pushed via
https://github.com/lede-project/source/commit/00e9a7aacb66b3f00df2002e8210bdb5086d2e0c


Best Regards,
Syrone Wong


On Fri, Sep 29, 2017 at 3:52 PM, Bjørn Mork  wrote:
> Note that security is the usual (only?) reason one would enforce TTL=255.
> Requiring TTL=255 is the same as guaranteeing that the packet source is
> in the same L2 domain.  This prevents any direct remote attack.
>
> Please do not propose any patches removing such a restriction without at
> least explaining why this can be done without negative security
> implications. Thanks
>
>
>
> Bjørn
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

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

Re: [LEDE-DEV] Updating Perl to 5.26.1

[Daniel Engberg]

Hi,

Sorry for for not including the history (not subscribed).
Perhaps taking a peek at 
https://github.com/buildroot/buildroot/tree/master/package/perl might 
help as they seem to have it working?


Best regards,
Daniel


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

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

[Bjørn Mork]

Note that security is the usual (only?) reason one would enforce TTL=255.
Requiring TTL=255 is the same as guaranteeing that the packet source is
in the same L2 domain.  This prevents any direct remote attack.

Please do not propose any patches removing such a restriction without at
least explaining why this can be done without negative security
implications. Thanks



Bjørn

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

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

[Martin Schiller]

On 2017-09-29 00:36, Philip Prindeville wrote:

Inline…



On Sep 28, 2017, at 2:32 AM, Martin Schiller  wrote:

If you rename a network interface, there is a move uevent
invoked instead of remove/add.

This patch adds support for this kind of event.

Signed-off-by: Martin Schiller 
---
system-linux.c | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/system-linux.c b/system-linux.c
index 6d97a02..e2017d0 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -543,16 +543,20 @@ out:
static void
handle_hotplug_msg(char *data, int size)
{
-   const char *subsystem = NULL, *interface = NULL;
+	const char *subsystem = NULL, *interface = NULL, *interface_old = 
NULL;

char *cur, *end, *sep;
struct device *dev;
int skip;
-   bool add;
+   bool add, move = false;

if (!strncmp(data, "add@", 4))
add = true;
else if (!strncmp(data, "remove@", 7))
add = false;
+   else if (!strncmp(data, "move@", 5)) {
+   add = true;
+   move = true;
+   }
else
return;

@@ -574,11 +578,32 @@ handle_hotplug_msg(char *data, int size)
if (strcmp(subsystem, "net") != 0)
return;
}
-   if (subsystem && interface)
+   else if (!strcmp(cur, "DEVPATH_OLD")) {
+   interface_old = strrchr(sep + 1, '/');
+   if (interface_old)
+   interface_old++;
+   }
+   }
+
+   if (subsystem && interface) {
+   if (move && interface_old)
+   goto move;
+   else
goto found;
}
+
return;

+move:
+   dev = device_find(interface_old);
+   if (!dev)
+   goto found;
+
+   if (dev->type != _device_type)
+   goto found;
+
+   device_set_present(dev, false);
+
found:
dev = device_find(interface);
if (!dev)




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

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

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

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

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

Am I missing anything?


I can't see any reason why the logic would get confused here:

After the "ip link set eth0 name _eth0", the eth0 device would be set to 
"NOT-present".
And after "ip link set _eth7 name eth0", the eth0 device would be set to 
"present" again.


Martin.


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

[LEDE-DEV] [PATCH] iw: fix build on musl host

[Stijn Tintel]

The empty version.sh script causes a problem when run by make:
make[3]: /usr/bin/env bash: Shell program not found

Adding a shebang line in version.sh seems to solve it.

Fixes FS#977.

Signed-off-by: Stijn Tintel 
---
 package/network/utils/iw/Makefile | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/package/network/utils/iw/Makefile 
b/package/network/utils/iw/Makefile
index a578ddc98c..9b3c12beca 100644
--- a/package/network/utils/iw/Makefile
+++ b/package/network/utils/iw/Makefile
@@ -30,8 +30,7 @@ endef
 
 define Build/Configure
echo "const char iw_version[] = \"$(PKG_VERSION)\";" > 
$(PKG_BUILD_DIR)/version.c
-   rm -f $(PKG_BUILD_DIR)/version.sh
-   touch $(PKG_BUILD_DIR)/version.sh
+   echo "#!/bin/sh" > $(PKG_BUILD_DIR)/version.sh
chmod +x $(PKG_BUILD_DIR)/version.sh
 endef
 
-- 
2.13.6


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