Flyspray:: https://bugs.openwrt.org/ Flyspray::OpenWrt/LEDE Project: Recently edited tasks 2019-03-25T13:11:57Z FS#2204: odhcpd: dhcpv6 preffered lifetime halved on renew of static lease https://bugs.openwrt.org/index.php?do=details&task_id=2204 2019-03-25T13:11:57Z rogerjames99 Model Linksys WRT1900ACSArchitecture ARMv7 Processor rev 1 (v7l)Firmware Version Lede SNAPSHOT r9506-42f2e07ba0 / LuCI Master (git-19.061.64392-718fb97)Kernel Version 4.14.103odhcpd 2019-02-27-16c5b6c9-3 When using systemd-networkd to request a static ipv6 address from from an openwrt router. I run into the problem illustrated by the following trace. The address to follow is IA_ADDR 2001:8b0:1418:4c2f::9 pltime:2372 vltime:2372 34 dhcp6 renew (xid=1c3ff1 (server-ID hwaddr type 1 c25627d4a752) (IA_NA IAID:9 T1:1186 T2:1897 (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295) (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:2372 vltime:2372)) (option-request DNS-server DNS-search-list NTP-server SNTP-servers) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (elapsed-time 0))35 dhcp6 reply (xid=1c3ff1 (server-ID hwaddr type 1 c25627d4a752) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (opt_82) (DNS-server fda0:4d7f:afbb:4c2f::1) (IA_NA IAID:9 T1:580 T2:928 (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:1161 vltime:1161) (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295))) Note that the pltime has been halved in the routers reply! 42 dhcp6 renew (xid=973c61 (server-ID hwaddr type 1 c25627d4a752) (IA_NA IAID:9 T1:580 T2:928 (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295) (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:1161 vltime:1161)) (option-request DNS-server DNS-search-list NTP-server SNTP-servers) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (elapsed-time 0))43 dhcp6 reply (xid=973c61 (server-ID hwaddr type 1 c25627d4a752) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (opt_82) (DNS-server fda0:4d7f:afbb:4c2f::1) (IA_NA IAID:9 T1:285 T2:456 (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:571 vltime:571) (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295))) 52 dhcp6 renew (xid=4f072e (server-ID hwaddr type 1 c25627d4a752) (IA_NA IAID:9 T1:285 T2:456 (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295) (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:571 vltime:571)) (option-request DNS-server DNS-search-list NTP-server SNTP-servers) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (elapsed-time 0))53 dhcp6 reply (xid=4f072e (server-ID hwaddr type 1 c25627d4a752) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (opt_82) (DNS-server fda0:4d7f:afbb:4c2f::1) (IA_NA IAID:9 T1:130 T2:208 (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:261 vltime:261) (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295))) and so on until 274: 106 01:45:01.745699 c2:56:27:d4:a7:52 > b8:27:eb:d4:eb:54, ethertype IPv6 (0x86dd), length 198: (flowlabel 0xc541e, hlim 64, next-header UDP (17) payload length: 144) fe80::c056:27ff:fed4:a752.547 > fe80::ba27:ebff:fed4:eb54.546: [udp sum ok] dhcp6 reply (xid=3eeea5 (server-ID hwaddr type 1 c25627d4a752) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (opt_82) (DNS-server fda0:4d7f:afbb:4c2f::1) (IA_NA IAID:9 T1:4294967295 T2:4294967295 (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295) (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:0 vltime:0) At which point the client gives up and removes the address from the interface and does not attempt to reaccquire it. I can get round this by having the client request an infinite lease. But I would prefer not to. This does not look like the correct behaviour to me. Leasetime half life is a matter for the client not the server. Steps to reproduce 1. Configure a network to request a static ipv6 lease. :/etc/systemd/network $ cat 10-peglegpete.network[Match]Name=peglegpete [Network]DHCP=yesIPv6AcceptRA=yes [Address]Address=2001:1111:2222:3333::9/64 [DHCP]DUIDType=link-layer-timeDUIDRawData=00:01:21:44:28:4a:b8:27:eb:71:99:03IAID=9 2. Set up a static lease in odhcpd using matching DUID and IAID data. Remember to prefix the DUID with the DUID-LLT type code 0001. Model Linksys WRT1900ACS
Architecture ARMv7 Processor rev 1 (v7l)
Firmware Version Lede SNAPSHOT r9506-42f2e07ba0 / LuCI Master (git-19.061.64392-718fb97)
Kernel Version 4.14.103
odhcpd 2019-02-27-16c5b6c9-3

When using systemd-networkd to request a static ipv6 address from from an openwrt router. I run into the problem illustrated by the following trace. The address to follow is IA_ADDR 2001:8b0:1418:4c2f::9 pltime:2372 vltime:2372

34 dhcp6 renew (xid=1c3ff1 (server-ID hwaddr type 1 c25627d4a752) (IA_NA IAID:9 T1:1186 T2:1897 (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295) (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:2372 vltime:2372)) (option-request DNS-server DNS-search-list NTP-server SNTP-servers) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (elapsed-time 0))
35 dhcp6 reply (xid=1c3ff1 (server-ID hwaddr type 1 c25627d4a752) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (opt_82) (DNS-server fda0:4d7f:afbb:4c2f::1) (IA_NA IAID:9 T1:580 T2:928 (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:1161 vltime:1161) (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295)))

Note that the pltime has been halved in the routers reply!

42 dhcp6 renew (xid=973c61 (server-ID hwaddr type 1 c25627d4a752) (IA_NA IAID:9 T1:580 T2:928 (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295) (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:1161 vltime:1161)) (option-request DNS-server DNS-search-list NTP-server SNTP-servers) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (elapsed-time 0))
43 dhcp6 reply (xid=973c61 (server-ID hwaddr type 1 c25627d4a752) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (opt_82) (DNS-server fda0:4d7f:afbb:4c2f::1) (IA_NA IAID:9 T1:285 T2:456 (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:571 vltime:571) (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295)))

52 dhcp6 renew (xid=4f072e (server-ID hwaddr type 1 c25627d4a752) (IA_NA IAID:9 T1:285 T2:456 (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295) (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:571 vltime:571)) (option-request DNS-server DNS-search-list NTP-server SNTP-servers) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (elapsed-time 0))
53 dhcp6 reply (xid=4f072e (server-ID hwaddr type 1 c25627d4a752) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (opt_82) (DNS-server fda0:4d7f:afbb:4c2f::1) (IA_NA IAID:9 T1:130 T2:208 (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:261 vltime:261) (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295)))

and so on until

274: 106 01:45:01.745699 c2:56:27:d4:a7:52 > b8:27:eb:d4:eb:54, ethertype IPv6 (0x86dd), length 198: (flowlabel 0xc541e, hlim 64, next-header UDP (17) payload length: 144) fe80::c056:27ff:fed4:a752.547 > fe80::ba27:ebff:fed4:eb54.546: [udp sum ok] dhcp6 reply (xid=3eeea5 (server-ID hwaddr type 1 c25627d4a752) (client-ID hwaddr/time type 1 time 558114890 b827eb719903) (opt_82) (DNS-server fda0:4d7f:afbb:4c2f::1) (IA_NA IAID:9 T1:4294967295 T2:4294967295 (IA_ADDR fda0:4d7f:afbb:4c2f::9 pltime:4294967295 vltime:4294967295) (IA_ADDR 2001:8b0:1418:4c2f::9 pltime:0 vltime:0)

At which point the client gives up and removes the address from the interface and does not attempt to reaccquire it.

I can get round this by having the client request an infinite lease. But I would prefer not to.

This does not look like the correct behaviour to me. Leasetime half life is a matter for the client not the server.

Steps to reproduce

1. Configure a network to request a static ipv6 lease.

:/etc/systemd/network $ cat 10-peglegpete.network
[Match]
Name=peglegpete

[Network]
DHCP=yes
IPv6AcceptRA=yes

[Address]
Address=2001:1111:2222:3333::9/64

[DHCP]
DUIDType=link-layer-time
DUIDRawData=00:01:21:44:28:4a:b8:27:eb:71:99:03
IAID=9

2. Set up a static lease in odhcpd using matching DUID and IAID data. Remember to prefix the DUID with the DUID-LLT type code 0001.

]]>
FS#2203: mtk_eth_soc: cannot build without nf_conntrack https://bugs.openwrt.org/index.php?do=details&task_id=2203 2019-03-25T09:53:19Z LGA1150 CC drivers/net/ethernet/mediatek/mtk_eth_soc.o In file included from drivers/net/ethernet/mediatek/mtk_eth_soc.c:34:0: ./include/net/netfilter/nf_flow_table.h:19:2: error: unknown type name 'nf_hookfn' nf_hookfn *hook; ^~~~~~~~~ ./include/net/netfilter/nf_flow_table.h:149:23: warning: 'struct nf_hook_state' declared inside parameter list will not be visible outside of this definition or declaration const struct nf_hook_state *state); ^~~~~~~~~~~~~ ./include/net/netfilter/nf_flow_table.h:151:25: warning: 'struct nf_hook_state' declared inside parameter list will not be visible outside of this definition or declaration const struct nf_hook_state *state); ^~~~~~~~~~~~~ scripts/Makefile.build:326: recipe for target 'drivers/net/ethernet/mediatek/mtk_eth_soc.o' failed CC drivers/net/ethernet/mediatek/mtk_eth_soc.o In file included from drivers/net/ethernet/mediatek/mtk_eth_soc.c:34:0: ./include/net/netfilter/nf_flow_table.h:19:2: error: unknown type name 'nf_hookfn' nf_hookfn *hook; ^~~~~~~~~ ./include/net/netfilter/nf_flow_table.h:149:23: warning: 'struct nf_hook_state' declared inside parameter list will not be visible outside of this definition or declaration const struct nf_hook_state *state); ^~~~~~~~~~~~~ ./include/net/netfilter/nf_flow_table.h:151:25: warning: 'struct nf_hook_state' declared inside parameter list will not be visible outside of this definition or declaration const struct nf_hook_state *state); ^~~~~~~~~~~~~ scripts/Makefile.build:326: recipe for target 'drivers/net/ethernet/mediatek/mtk_eth_soc.o' failed ]]> FS#1763: 18.06 doesn't obtain IPv6 address on mt76 https://bugs.openwrt.org/index.php?do=details&task_id=1763 2019-03-24T11:16:01Z Henry Gebhardt OpenWRT-18.06 doesn’t obtain an IPv6 address on the wan6 interface since commit 424a9ae128bd2045cd4bfd6e3229f2529d150a25. IPv6 works before that commit. The git bisect output is $ git bisect good There are only 'skip'ped commits left to test. The first bad commit could be any of: 424a9ae128bd2045cd4bfd6e3229f2529d150a25 bfed38254076d576914251689a2e1f85d514783d We cannot bisect more! The WAN6 interface status when not working is root@OpenWrt:~# ifstatus wan6 { "up": false, "pending": true, "available": true, "autostart": true, "dynamic": false, "proto": "dhcpv6", "device": "eth0.2", "data": { } } The device is a Netgear R6220, and my ISP is Comcast in Pennsylvania. I attach dmesg when running the last working commit. Other users also have this problem, see this forum thread. (I’m the OP of that thread.) Would be great to have IPv6 working again. Thank you! Steps to reproduce:0. Delete .config file, in “make menuconfig” select appropriate target (MediaTek Ralink MIPS), subtarget (MT7621), and target profile (Netgear R6220).1a. Compile image prior to above commits, upload to router1b. Run “sysupgrade -v -n /tmp/*.tar” 1c. Confirm that IPv6 is working, e.g. by pointing browser to ipv6-test.com, or “ifstatus wan6” on the router2a. Compile image from source after above mentioned commits, e.g. tag “v18.06.0”, upload to router2b. Run “sysupgrade -v -n /tmp/*.tar” 2c. Confirm that IPv6 is not working OpenWRT-18.06 doesn’t obtain an IPv6 address on the wan6 interface since commit 424a9ae128bd2045cd4bfd6e3229f2529d150a25. IPv6 works before that commit. The git bisect output is

$ git bisect good
There are only 'skip'ped commits left to test.
The first bad commit could be any of:
424a9ae128bd2045cd4bfd6e3229f2529d150a25
bfed38254076d576914251689a2e1f85d514783d
We cannot bisect more!

The WAN6 interface status when not working is

root@OpenWrt:~# ifstatus wan6
{
	"up": false,
	"pending": true,
	"available": true,
	"autostart": true,
	"dynamic": false,
	"proto": "dhcpv6",
	"device": "eth0.2",
	"data": {		
	}
}

The device is a Netgear R6220, and my ISP is Comcast in Pennsylvania.

I attach dmesg when running the last working commit.

Other users also have this problem, see this forum thread. (I’m the OP of that thread.)

Would be great to have IPv6 working again. Thank you!

Steps to reproduce:
0. Delete .config file, in “make menuconfig” select appropriate target (MediaTek Ralink MIPS), subtarget (MT7621), and target profile (Netgear R6220).
1a. Compile image prior to above commits, upload to router
1b. Run “sysupgrade -v -n /tmp/*.tar” 1c. Confirm that IPv6 is working, e.g. by pointing browser to ipv6-test.com, or “ifstatus wan6” on the router
2a. Compile image from source after above mentioned commits, e.g. tag “v18.06.0”, upload to router
2b. Run “sysupgrade -v -n /tmp/*.tar” 2c. Confirm that IPv6 is not working

]]>
FS#1978: syscall getrandom() hangs on Turris Omnia https://bugs.openwrt.org/index.php?do=details&task_id=1978 2019-03-23T13:07:42Z Andrew McConachie Supply the following if possible: - Device problem occurs on - Software versions of OpenWrt/LEDE release, packages, etc. - Steps to reproduce root@OpenWrt:/~# uname -aLinux OpenWrt 4.14.63 #0 SMP Wed Aug 15 20:42:39 2018 armv7l GNU/Linux root@OpenWrt:~# cat /proc/version Linux version 4.14.63 (buildbot@builds-03.infra.lede-project.org) (gcc version 7.3.0 (OpenWrt GCC 7.3.0 r7101-a63e38b)) #0 SMP Wed Aug 15 20:42:39 2018 root@OpenWrt:~# uptime 14:40:46 up 1:14, load average: 0.00, 0.00, 0.00 root@OpenWrt:~# cat /proc/device-tree/model Turris Omniaroot@OpenWrt:~# root@OpenWrt:~# ps |grep rand 2228 root 1128 S /bin/sh /sbin/urandom_seed 2247 root 748 S getrandom 512 3114 root 1056 R grep rand root@OpenWrt:~# cat /proc/cpuinfo processor : 0model name : ARMv7 Processor rev 1 (v7l)BogoMIPS : 1600.00Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 CPU implementer : 0×41 CPU architecture: 7CPU variant : 0×4 CPU part : 0xc09CPU revision : 1 processor : 1model name : ARMv7 Processor rev 1 (v7l)BogoMIPS : 1600.00Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 CPU implementer : 0×41 CPU architecture: 7CPU variant : 0×4 CPU part : 0xc09CPU revision : 1 Hardware : Marvell Armada 380/385 (Device Tree)Revision : 0000Serial : 0000000000000000 root@OpenWrt:~# cat /proc/devices Character devices: 1 mem 4 ttyS 5 /dev/tty 5 /dev/console 5 /dev/ptmx 10 misc 89 i2c 90 mtd108 ppp128 ptm136 pts180 usb189 usb_device251 watchdog252 rtc253 ttyMV254 gpiochip Block devices: 7 loop 8 sd 31 mtdblock 65 sd 66 sd 67 sd 68 sd 69 sd 70 sd 71 sd128 sd129 sd130 sd131 sd132 sd133 sd134 sd135 sd179 mmc254 ubiblock259 blkext root@OpenWrt:~# ls -l /dev/|grep randcrw-rw-rw- 1 root root 1, 8 Nov 30 13:26 randomcrw-rw-rw- 1 root root 1, 9 Nov 30 13:26 urandom I am using the stock images from here:https://downloads.openwrt.org/releases/18.06.1/targets/mvebu/cortexa9/openwrt-18.06.1-mvebu-cortexa9-turris-omnia-initramfs-kernel.bin https://downloads.openwrt.org/releases/18.06.1/targets/mvebu/cortexa9/openwrt-18.06.1-mvebu-cortexa9-turris-omnia-kernel.bin https://downloads.openwrt.org/releases/18.06.1/targets/mvebu/cortexa9/openwrt-18.06.1-mvebu-cortexa9-turris-omnia-sysupgrade.img.gz I discovered this when troubleshooting why unbound would not start. I could see with strace that unbound was getting stuck at the getrandom() syscall, and at first I thought it was a problem with unbound. But then I saw that /usr/bin/getrandom 512 had been stuck since boot. The syscall just blocks forever. root@OpenWrt:~# which getrandom/usr/bin/getrandomroot@OpenWrt:~# strace /usr/bin/getrandom 512 >/tmp/derp.txtexecve(”/usr/bin/getrandom”, [”/usr/bin/getrandom”, “512”], 0xbead7df4 /* 13 vars */) = 0set_tls(0xb6f31544, 0xbe8aec28, 0x490ceab4, 0, 0xb6f314a0) = 0set_tid_address(0xb6f314bc) = 3132open(”/etc/ld-musl-armhf.path”, O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)open(”/lib/libgcc_s.so.1”, O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3fcntl64(3, F_SETFD, FD_CLOEXEC) = 0fstat64(3, {st_mode=S_IFREG|0644, st_size=41251, ...}) = 0read(3, “\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\20<\0\0004\0\0\0”..., 936) = 936mmap2(NULL, 110592, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb6ea0000mmap2(0xb6eb9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0×9000) = 0xb6eb9000close(3) = 0mprotect(0xb6eb9000, 4096, PROT_READ) = 0mprotect(0×20000, 4096, PROT_READ) = 0ioctl(1, TIOCGWINSZ, 0xbe8aec80) = -1 ENOTTY (Not a tty)getrandom( ‘/usr/bin/head /dev/urandom’ returns random data like you expect. ‘/usr/bin/head /dev/random’ just hangs. Supply the following if possible:
- Device problem occurs on
- Software versions of OpenWrt/LEDE release, packages, etc.
- Steps to reproduce

root@OpenWrt:/~# uname -a
Linux OpenWrt 4.14.63 #0 SMP Wed Aug 15 20:42:39 2018 armv7l GNU/Linux

root@OpenWrt:~# cat /proc/version
Linux version 4.14.63 (buildbot@builds-03.infra.lede-project.org) (gcc version 7.3.0 (OpenWrt GCC 7.3.0 r7101-a63e38b)) #0 SMP Wed Aug 15 20:42:39 2018

root@OpenWrt:~# uptime
14:40:46 up 1:14, load average: 0.00, 0.00, 0.00

root@OpenWrt:~# cat /proc/device-tree/model
Turris Omniaroot@OpenWrt:~#

root@OpenWrt:~# ps |grep rand
2228 root 1128 S /bin/sh /sbin/urandom_seed
2247 root 748 S getrandom 512
3114 root 1056 R grep rand

root@OpenWrt:~# cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 1 (v7l)
BogoMIPS : 1600.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0×41 CPU architecture: 7
CPU variant : 0×4 CPU part : 0xc09
CPU revision : 1

processor : 1
model name : ARMv7 Processor rev 1 (v7l)
BogoMIPS : 1600.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32
CPU implementer : 0×41 CPU architecture: 7
CPU variant : 0×4 CPU part : 0xc09
CPU revision : 1

Hardware : Marvell Armada 380/385 (Device Tree)
Revision : 0000
Serial : 0000000000000000

root@OpenWrt:~# cat /proc/devices
Character devices:

1 mem
4 ttyS
5 /dev/tty
5 /dev/console
5 /dev/ptmx

10 misc
89 i2c
90 mtd
108 ppp
128 ptm
136 pts
180 usb
189 usb_device
251 watchdog
252 rtc
253 ttyMV
254 gpiochip

Block devices:

7 loop
8 sd

31 mtdblock
65 sd
66 sd
67 sd
68 sd
69 sd
70 sd
71 sd
128 sd
129 sd
130 sd
131 sd
132 sd
133 sd
134 sd
135 sd
179 mmc
254 ubiblock
259 blkext

root@OpenWrt:~# ls -l /dev/|grep rand
crw-rw-rw- 1 root root 1, 8 Nov 30 13:26 random
crw-rw-rw- 1 root root 1, 9 Nov 30 13:26 urandom

 

I am using the stock images from here:
https://downloads.openwrt.org/releases/18.06.1/targets/mvebu/cortexa9/openwrt-18.06.1-mvebu-cortexa9-turris-omnia-initramfs-kernel.bin https://downloads.openwrt.org/releases/18.06.1/targets/mvebu/cortexa9/openwrt-18.06.1-mvebu-cortexa9-turris-omnia-kernel.bin https://downloads.openwrt.org/releases/18.06.1/targets/mvebu/cortexa9/openwrt-18.06.1-mvebu-cortexa9-turris-omnia-sysupgrade.img.gz

I discovered this when troubleshooting why unbound would not start. I could see with strace that unbound was getting stuck at the getrandom() syscall, and at first I thought it was a problem with unbound. But then I saw that /usr/bin/getrandom 512 had been stuck since boot. The syscall just blocks forever.

root@OpenWrt:~# which getrandom
/usr/bin/getrandom
root@OpenWrt:~# strace /usr/bin/getrandom 512 >/tmp/derp.txt
execve(”/usr/bin/getrandom”, [”/usr/bin/getrandom”, “512”], 0xbead7df4 /* 13 vars */) = 0
set_tls(0xb6f31544, 0xbe8aec28, 0x490ceab4, 0, 0xb6f314a0) = 0
set_tid_address(0xb6f314bc) = 3132
open(”/etc/ld-musl-armhf.path”, O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open(”/lib/libgcc_s.so.1”, O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=41251, ...}) = 0
read(3, “\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\20<\0\0004\0\0\0”..., 936) = 936
mmap2(NULL, 110592, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0xb6ea0000
mmap2(0xb6eb9000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0×9000) = 0xb6eb9000
close(3) = 0
mprotect(0xb6eb9000, 4096, PROT_READ) = 0
mprotect(0×20000, 4096, PROT_READ) = 0
ioctl(1, TIOCGWINSZ, 0xbe8aec80) = -1 ENOTTY (Not a tty)
getrandom(


‘/usr/bin/head /dev/urandom’ returns random data like you expect.
‘/usr/bin/head /dev/random’ just hangs.

]]>
FS#2202: brcm63xx: Hg556a: kernel boot stuck at "random: crng init done" https://bugs.openwrt.org/index.php?do=details&task_id=2202 2019-03-23T10:51:00Z Israel The kernel 4.14.107 is unable to boot on the Hg556a (BCM6358). Steps to reproduce: Intall the latest trunk version kernel 4.14.107 Sympthoms: No Boot It stucks at “random: fast init done”, and apparently no more kernel messages But after a minute it spits the last message random: crng init done Boot Log: *** Press any key to stop auto run (1 seconds) *** Auto run second count down: 0 boot kernel from be020100 Code Address: 0x80A00000, Entry Address: 0x80a00000 Decompression OK! Entry at 0x80a00000 Closing network. Starting program at 0x80a00000 [ 0.000000] Linux version 4.14.107 (hg556a@localhost.localdomain) (gcc version 7.4.0 (OpenWrt GCC 7.4.0 r9015-34696ce25e)) #0 Thu Mar 10 15:47:43 2019 [ 0.000000] Detected Broadcom 0x6358 CPU revision a1 [ 0.000000] CPU frequency is 300 MHz [ 0.000000] 64MB of RAM installed [ 0.000000] board_bcm963xx: Boot address 0xbe000000 [ 0.000000] board_bcm963xx: CFE version: d081.5003 [ 0.000000] bcm63xx_nvram: nvram checksum failed, contents may be invalid (expected 33313330, got 3c502ae7) [ 0.000000] bootconsole [early0] enabled [ 0.000000] CPU0 revision is: 0002a010 (Broadcom BMIPS4350) [ 0.000000] board: board name: HW556_B [ 0.000000] MIPS: machine is Huawei EchoLife HG556a (version B) [ 0.000000] Determined physical RAM map: [ 0.000000] memory: 04000000 @ 00000000 (usable) [ 0.000000] Initrd not found or empty - disabling initrd [ 0.000000] Primary instruction cache 16kB, VIPT, 2-way, linesize 16 bytes. [ 0.000000] Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 16 bytes [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000000000000-0x0000000003ffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x0000000003ffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000003ffffff] [ 0.000000] random: get_random_bytes called from start_kernel+0x80/0x488 with crng_init=0 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 16256 [ 0.000000] Kernel command line: rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200 [ 0.000000] PID hash table entries: 256 (order: -2, 1024 bytes) [ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) [ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Memory: 54392K/65536K available (6369K kernel code, 343K rwdata, 2132K rodata, 1324K init, 256K bss, 11144K reserved, 0K cma-reserved) [ 0.000000] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] NR_IRQS: 256 [ 0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 12741736309 ns [ 0.000026] sched_clock: 32 bits at 150MHz, resolution 6ns, wraps every 14316557820ns [ 1.034043] random: fast init done [ 53.820705] random: crng init done The kernel 4.14.107 is unable to boot on the Hg556a (BCM6358).

Steps to reproduce:

  Intall the latest trunk version kernel 4.14.107

Sympthoms:

  No Boot
  It stucks at “random: fast init done”, and apparently no more kernel messages
  But after a minute it spits the last message random: crng init done

Boot Log:

*** Press any key to stop auto run (1 seconds) ***
Auto run second count down: 0
boot kernel from be020100
Code Address: 0x80A00000, Entry Address: 0x80a00000
Decompression OK!
Entry at 0x80a00000
Closing network.
Starting program at 0x80a00000
[    0.000000] Linux version 4.14.107 (hg556a@localhost.localdomain) (gcc version 7.4.0 (OpenWrt GCC 7.4.0 r9015-34696ce25e)) #0 Thu Mar 10 15:47:43 2019
[    0.000000] Detected Broadcom 0x6358 CPU revision a1
[    0.000000] CPU frequency is 300 MHz
[    0.000000] 64MB of RAM installed
[    0.000000] board_bcm963xx: Boot address 0xbe000000
[    0.000000] board_bcm963xx: CFE version: d081.5003
[    0.000000] bcm63xx_nvram: nvram checksum failed, contents may be invalid (expected 33313330, got 3c502ae7)
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU0 revision is: 0002a010 (Broadcom BMIPS4350)
[    0.000000] board: board name: HW556_B
[    0.000000] MIPS: machine is Huawei EchoLife HG556a (version B)
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 04000000 @ 00000000 (usable)
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] Primary instruction cache 16kB, VIPT, 2-way, linesize 16 bytes.
[    0.000000] Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 16 bytes
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x0000000003ffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x0000000003ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000003ffffff]
[    0.000000] random: get_random_bytes called from start_kernel+0x80/0x488 with crng_init=0
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 16256
[    0.000000] Kernel command line: rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200
[    0.000000] PID hash table entries: 256 (order: -2, 1024 bytes)
[    0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Memory: 54392K/65536K available (6369K kernel code, 343K rwdata, 2132K rodata, 1324K init, 256K bss, 11144K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS: 256
[    0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 12741736309 ns
[    0.000026] sched_clock: 32 bits at 150MHz, resolution 6ns, wraps every 14316557820ns
[    1.034043] random: fast init done
[   53.820705] random: crng init done


]]>
FS#2201: kernel error: do_page_fault(): sending SIGSEGV to reader#1 for invalid read access from 77a87d90 https://bugs.openwrt.org/index.php?do=details&task_id=2201 2019-03-22T21:05:36Z camel current trunk from 22.3.2019git-19.079.18950-11e64f8) / OpenWrt SNAPSHOT r9672-d78e229903 i see in the logs that having more often kernel error: Fri Mar 22 15:14:27 2019 kern.info kernel: [11750.766284] do_page_fault(): sending SIGSEGV to reader#1 for invalid read access from 77a87d90Fri Mar 22 15:14:27 2019 kern.info kernel: [11750.774984] epc = 77f55944 in libc.so[77edb000+94000]Fri Mar 22 15:14:27 2019 kern.info kernel: [11750.780320] ra = 77f558e0 in libc.so[77edb000+94000] any idea about what can be the reason for it ? or how i can give you more infos ? current trunk from 22.3.2019
git-19.079.18950-11e64f8) / OpenWrt SNAPSHOT r9672-d78e229903

i see in the logs that having more often kernel error:

Fri Mar 22 15:14:27 2019 kern.info kernel: [11750.766284] do_page_fault(): sending SIGSEGV to reader#1 for invalid read access from 77a87d90
Fri Mar 22 15:14:27 2019 kern.info kernel: [11750.774984] epc = 77f55944 in libc.so[77edb000+94000]
Fri Mar 22 15:14:27 2019 kern.info kernel: [11750.780320] ra = 77f558e0 in libc.so[77edb000+94000]

any idea about what can be the reason for it ? or how i can give you more infos ?

]]>
FS#2200: Luci doesn't accept multiple IPv6 prefixes https://bugs.openwrt.org/index.php?do=details&task_id=2200 2019-03-22T14:25:45Z Trey Sis Under Luci &rarr; Network &rarr; Interfaces &rarr; interface-id you can define the routed IPv6 prefixes on an interface, but Luci only accepts one prefix in the &#8220;IPv6 routed prefix&#8221; field. This field should accept a space-separated list. You can still define multiple prefixes directly in the configuration at /etc/config/network, e.g.:option ip6prefix &#8216;prefix1::/64 prefix2::/64&#8217; Doing that will lead to Luci showing both prefixes on the configuration page, but deny changes due to the wrong format of this field. Under Luci → Network → Interfaces → interface-id you can define the routed IPv6 prefixes on an interface, but Luci only accepts one prefix in the “IPv6 routed prefix” field. This field should accept a space-separated list.

You can still define multiple prefixes directly in the configuration at /etc/config/network, e.g.:
option ip6prefix ‘prefix1::/64 prefix2::/64’ Doing that will lead to Luci showing both prefixes on the configuration page, but deny changes due to the wrong format of this field.

]]>
FS#2199: Bananapi R2, Kernel command line problem https://bugs.openwrt.org/index.php?do=details&task_id=2199 2019-03-22T08:07:23Z Ivan Can not configure root variable in kernel command line with U-Boot. Please cleanCONFIG_CMDLINE for linux kernel. thanks. Can not configure root variable in kernel command line with U-Boot. Please clean
CONFIG_CMDLINE for linux kernel.

thanks.

 


]]>
FS#2198: Tow entangled problems involving boost and package integration. https://bugs.openwrt.org/index.php?do=details&task_id=2198 2019-03-21T23:03:14Z reallyohwell This involves an x86 generic full build of 18.02.This seems less to be a problem directly involving packages, and more a problem involving the integration of packages. The builds were finishing up to this point.In make menuconfig, I added in a few packages to replace the weakerbinutils version of these utilities, e.g., the less package, because Iwanted the search capability.Apparently these additions got tangled up with boost, which was not atthis point selected: cp -fpR -v /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/boost_1_68_0/ipkg-install/lib/*.{a,so*} /home/stuff/code/openwrt/repo/tmp/stage-boost/usr/lib/&#8216;/home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/boost_1_68_0/ipkg-install/lib/libboost_exception.a&#8217; &rarr; &#8216;/home/stuff/code/openwrt/repo/tmp/stage-boost/usr/lib/libboost_exception.a&#8217; cp: cannot stat &#8216;/home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/boost_1_68_0/ipkg-install/lib/*.so*&#8217;: No such file or directory I searched for the unusual string {a,so*} and found it in feeds/packages/libs/boost/Makefile line 473.Apparently boost was being pulled in, but not creating any .so* files, even though boost was not yet selected. So I went into make menuconfig and selected boost. Same problem. Then I split line 473 to this form: $(CP) -v $(PKG_INSTALL_DIR)/lib/*.a $(1)/usr/lib/ -$(CP) -v $(PKG_INSTALL_DIR)/lib/*.so* $(1)/usr/lib/ (It had been {a,so*}).This (I think) will execute the same if boost is creating any .so files,but will otherwise get past this step if no .so files are being created. It seemed to work at first. But then (using make -j1) I started getting complaints about the newly selected packages overwriting busybox versions offiles.If you look more closely you will see that these errors wrote in the middleof the string &#8220;Configuring boost.&#8221; CoCollected errors: * check_data_file_clashes: Package logger wants to install file /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/root-x86/usr/bin/logger But that file is already provided by package * busybox * opkg_install_cmd: Cannot install package logger. * check_data_file_clashes: Package findutils-find wants to install file /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/root-x86/usr/bin/find But that file is already provided by package * busybox * opkg_install_cmd: Cannot install package findutils-find. * check_data_file_clashes: Package findutils-xargs wants to install file /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/root-x86/usr/bin/xargs But that file is already provided by package * busybox * opkg_install_cmd: Cannot install package findutils-xargs. * check_data_file_clashes: Package less-wide wants to install file /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/root-x86/bin/less But that file is already provided by package * less * opkg_install_cmd: Cannot install package less-wide.nfiguring boost. Note that busybox doesn&#8217;t like having logger, find, and xargs overwritten,but I also selected find and less, which should have overwritten busyboxversions of the files. But that didn&#8217;t generate any complaints. Here is where my memory gets a little hazy... I found out about this time thatmenuconfig/boost was set to not install any libraries, so I selected &#8216;alllibraries&#8217;, and that may have gotten rid of the boost .so problem, because theboost build was now creating .so files. But I was still getting the file overwrite problem, so I yanked out theoffending package selections. At that point the make process completed. Anyway, that&#8217;s what happened. This involves an x86 generic full build of 18.02.
This seems less to be a problem directly involving packages, and more a
problem involving the integration of packages.

The builds were finishing up to this point.
In make menuconfig, I added in a few packages to replace the weaker
binutils version of these utilities, e.g., the less package, because I
wanted the search capability.
Apparently these additions got tangled up with boost, which was not at
this point selected:

cp -fpR -v /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/boost_1_68_0/ipkg-install/lib/*.{a,so*} /home/stuff/code/openwrt/repo/tmp/stage-boost/usr/lib/
‘/home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/boost_1_68_0/ipkg-install/lib/libboost_exception.a’ → ‘/home/stuff/code/openwrt/repo/tmp/stage-boost/usr/lib/libboost_exception.a’ cp: cannot stat ‘/home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/boost_1_68_0/ipkg-install/lib/*.so*’: No such file or directory

I searched for the unusual string {a,so*} and found it in feeds/packages/libs/boost/Makefile
line 473.
Apparently boost was being pulled in, but not creating any .so* files, even though boost was not yet selected.

So I went into make menuconfig and selected boost. Same problem.

Then I split line 473 to this form:

$(CP) -v $(PKG_INSTALL_DIR)/lib/*.a $(1)/usr/lib/
-$(CP) -v $(PKG_INSTALL_DIR)/lib/*.so* $(1)/usr/lib/

(It had been {a,so*}).
This (I think) will execute the same if boost is creating any .so files,
but will otherwise get past this step if no .so files are being created.

It seemed to work at first. But then (using make -j1) I started getting
complaints about the newly selected packages overwriting busybox versions of
files.
If you look more closely you will see that these errors wrote in the middle
of the string “Configuring boost.”
CoCollected errors:
* check_data_file_clashes: Package logger wants to install file /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/root-x86/usr/bin/logger

      But that file is already provided by package  * busybox

* opkg_install_cmd: Cannot install package logger.
* check_data_file_clashes: Package findutils-find wants to install file /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/root-x86/usr/bin/find

      But that file is already provided by package  * busybox

* opkg_install_cmd: Cannot install package findutils-find.
* check_data_file_clashes: Package findutils-xargs wants to install file /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/root-x86/usr/bin/xargs

      But that file is already provided by package  * busybox

* opkg_install_cmd: Cannot install package findutils-xargs.
* check_data_file_clashes: Package less-wide wants to install file /home/stuff/code/openwrt/repo/build_dir/target-i386_pentium4_musl/root-x86/bin/less

      But that file is already provided by package  * less

* opkg_install_cmd: Cannot install package less-wide.
nfiguring boost.

Note that busybox doesn’t like having logger, find, and xargs overwritten,
but I also selected find and less, which should have overwritten busybox
versions of the files. But that didn’t generate any complaints.

Here is where my memory gets a little hazy... I found out about this time that
menuconfig/boost was set to not install any libraries, so I selected ‘all
libraries’, and that may have gotten rid of the boost .so problem, because the
boost build was now creating .so files.

But I was still getting the file overwrite problem, so I yanked out the
offending package selections. At that point the make process completed.

Anyway, that’s what happened.

 


]]>
FS#2170: WNDR3400 v2 needs gpio pin 21 high to enable USB https://bugs.openwrt.org/index.php?do=details&task_id=2170 2019-03-21T22:47:49Z Eric Bohlman The Netgear WNDR3400 v2, just like the v3, requires GPIO pin 21 to be set to high for the USB port to work, but the current software version doesn&#8217;t do it. Upon powerup, USB devices are not recognized. After executing echo &quot;21&quot; &gt; /sys/class/gpio/export echo &quot;out&quot; &gt; /sys/class/gpio/gpio21/direction echo &quot;1&quot; &gt; /sys/class/gpio/gpio21/value they are recognized. Because this comes after files have been mounted, it&#8217;s necessary to reboot to access, say, an extroot. The Netgear WNDR3400 v2, just like the v3, requires GPIO pin 21 to be set to high for the USB port to work, but the current software version doesn’t do it.

Upon powerup, USB devices are not recognized. After executing

echo "21" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio21/direction
echo "1" > /sys/class/gpio/gpio21/value

they are recognized. Because this comes after files have been mounted, it’s necessary to reboot to access, say, an extroot.

]]>