**** BEGIN LOGGING AT Wed Aug 07 03:02:32 2019 Aug 07 09:01:48 My doods I need y'all experties Aug 07 09:53:34 hi guys.. we are running an application that manages wireless interfaces (i.e without /etc/config/wireless & netifd) and it's been working fine so long. All of a sudden netifd takes control and disables all interfaces without network reload or such commands. Aug 07 09:54:04 Is there any other reason why this could happen? I have all wireless interfaces disabled in /etc/config/wireless Aug 07 09:55:04 Any pointers would be much appreicated. Aug 07 09:56:17 I'd start with ubus monitor to see if any related event came in that woke up netifd Aug 07 09:57:48 also whats netif'd view on the system when checking "ubus call network.interface dump", "ubus call network.device status" and "ubus call network.wireless wireless" ? Does it exclude your externally managed interfaces? Aug 07 09:59:38 thanks. will try ubus montior and also see if the ubus has excluded my own wireless interfaces.. Aug 07 10:03:37 running ubus commands doesn't show my interfaces (i.e externally configured wireless interfaces) and I believe it is excluded. Aug 07 10:04:44 This issue doesn't happen every time and so far i have seen this only twice and couldn't reproduce it. Aug 07 10:05:40 but you're 100% positive that it was netifd tearing down your interfaces? Aug 07 10:06:14 offhand I can't think of many scenarios which would cause that Aug 07 10:09:15 I am not 100% sure but I believe it is due to netifd. Is there a way to confirm this? We are not running any other applications in this build and so have to suspect netifd for now. Aug 07 10:11:15 if netifd is responsible I'd expect ubus chatter and hotplug events Aug 07 10:12:09 you can also edit the netifd init script and start netifd with "-d 0xff" to enable all debug messages (you might need procd_set_param stdout 1; procd_set_param stderr 1 to relay the debug messages to syslog) Aug 07 10:13:31 Hey guys, can I ask a few questions? Aug 07 10:13:48 If I annoy you just let me know! Aug 07 10:14:31 Is OpenWISP a framework to set up multiple routers? (How is this different than LUCI) Aug 07 10:14:45 @jow sure. let me try with more debug logs.. am pasting the logread output now. Aug 07 10:14:46 Do you guys rock 'sudo'? Aug 07 10:15:29 Sat Aug 3 21:02:15 2019 kern.info kernel: [ 2141.204741] br-lan: port 2(phy0-mesh1) entered disabled stateSat Aug 3 21:02:15 2019 kern.info kernel: [ 2141.269957] device phy0-mesh1 left promiscuous modeSat Aug 3 21:02:15 2019 kern.info kernel: [ 2141.270000] br-lan: port 2(phy0-mesh1) entered disabled stateSat Aug 3 21:02:15 2019 kern.warn kern Aug 07 10:15:30 el: [ 2141.323996] ath10k_pci 0001:01:00.0: peer-unmap-event: unknown peer id 1Sat Aug 3 21:02:15 2019 kern.info kernel: [ 2141.331991] br-lan: port 4(phy1-wlan0) entered disabled stateSat Aug 3 21:02:15 2019 kern.warn kernel: [ 2141.368516] ath10k_pci 0000:01:00.0: peer-unmap-event: unknown peer id 2Sat Aug 3 21:02:15 2019 kern.info kernel: [ 2 Aug 07 10:15:30 141.377465] br-lan: port 3(phy0-wlan0) entered disabled stateSat Aug 3 21:02:15 2019 kern.info kernel: [ 2141.430038] device phy1-wlan0 left promiscuous modeSat Aug 3 21:02:15 2019 kern.info kernel: [ 2141.430079] br-lan: port 4(phy1-wlan0) entered disabled stateSat Aug 3 21:02:15 2019 kern.info kernel: [ 2141.599239] device phy0-wlan0 left prom Aug 07 10:15:31 iscuous modeSat Aug 3 21:02:15 2019 kern.info kernel: [ 2141.599279] br-lan: port 3(phy0-wlan0) entered disabled stateSat Aug 3 21:02:15 2019 kern.warn kernel: [ 2141.666024] ath10k_pci 0001:01:00.0: peer-unmap-event: unknown peer id 2Sat Aug 3 21:02:15 2019 kern.info kernel: [ 2141.774909] br-lan: port 6(phy1-wlan101) entered disabled stateSat Aug 07 10:15:31 Aug 3 21:02:15 2019 kern.info kernel: [ 2141.819916] device phy1-wlan101 left promiscuous modeSat Aug 3 21:02:15 2019 kern.info kernel: [ 2141.819962] br-lan: port 6(phy1-wlan101) entered disabled stateSat Aug 3 21:02:15 2019 kern.info kernel: [ 2141.975187] br-lan: port 5(phy0-wlan101) entered disabled stateSat Aug 3 21:02:15 2019 kern.info ke Aug 07 10:15:32 rnel: [ 2142.010242] device phy0-wlan101 left promiscuous modeSat Aug 3 21:02:15 2019 kern.info kernel: [ 2142.010290] br-lan: port 5(phy0-wlan101) entered disabled stateSat Aug 3 21:02:16 2019 daemon.notice netifd: radio1 (1181): command failed: Not supported (-95)Sat Aug 3 21:02:16 2019 daemon.notice netifd: radio0 (1180): command failed: Not Aug 07 10:15:32 supported (-95)Sat Aug 3 21:02:16 2019 daemon.err hostapd: Configuration file: /var/run/hostapd-phy1.confSat Aug 3 21:02:22 2019 kern.info kernel: [ 2148.481769] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not readySat Aug 3 21:02:22 2019 kern.info kernel: [ 2148.491520] br-lan: port 2(wlan1) entered blocking stateSat Aug 3 21:02:22 2019 kern.inf Aug 07 10:15:33 o kernel: [ 2148.491548] br-lan: port 2(wlan1) entered disabled stateSat Aug 3 21:02:22 2019 kern.info kernel: [ 2148.496436] device wlan1 entered promiscuous modeSat Aug 3 21:02:22 2019 daemon.err hostapd: Configuration file: /var/run/hostapd-phy0.confSat Aug 3 21:02:22 2019 daemon.err hostapd: Using interface wlan1 with hwaddr b0:39:56:89:36:8 Aug 07 10:15:33 3 and ssid "OpenWrt"Sat Aug 3 21:02:29 2019 kern.info kernel: [ 2155.937354] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not readySat Aug 3 21:02:29 2019 kern.info kernel: [ 2155.940174] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes readySat Aug 3 21:02:29 2019 kern.info kernel: [ 2155.946015] br-lan: port 2(wlan1) entered blocking stateSat A Aug 07 10:15:34 ug 3 21:02:29 2019 kern.info kernel: [ 2155.952452] br-lan: port 2(wlan1) entered forwarding stateSat Aug 3 21:02:29 2019 kern.warn kernel: [ 2155.959618] ath10k_warn: 2 callbacks suppressedSat Aug 3 21:02:29 2019 kern.warn kernel: [ 2155.959628] ath10k_pci 0001:01:00.0: peer-unmap-event: unknown peer id 1Sat Aug 3 21:02:29 2019 kern.info kerne Aug 07 10:15:34 l: [ 2156.054627] br-lan: port 2(wlan1) entered disabled stateSat Aug 3 21:02:29 2019 daemon.notice hostapd: wlan1: interface state UNINITIALIZED->ENABLEDSat Aug 3 21:02:29 2019 daemon.notice hostapd: wlan1: AP-ENABLEDSat Aug 3 21:02:29 2019 daemon.notice hostapd: wlan1: INTERFACE-DISABLEDSat Aug 3 21:02:30 2019 kern.warn kernel: [ 2156.148959] Aug 07 10:15:35 ath10k_pci 0000:01:00.0: peer-unmap-event: unknown peer id 1Sat Aug 3 21:02:30 2019 daemon.notice hostapd: handle_probe_req: send failedSat Aug 3 21:02:30 2019 kern.info kernel: [ 2156.360211] device wlan1 left promiscuous modeSat Aug 3 21:02:30 2019 kern.info kernel: [ 2156.360257] br-lan: port 2(wlan1) entered disabled stateSat Aug 3 21:02:3 Aug 07 10:15:35 0 2019 daemon.err hostapd: nl80211: Failed to add interface wlan0 into bridge br-lan: No such device Aug 07 10:15:46 Under Kernel Monitoring support - > does the 3200ACM have any of the options? I2C Support? Aug 07 10:16:21 kir: pastebin maybe? Aug 07 10:16:22 Input modules -> I remember for the original 1900acv1 it had gpios? Does the 3200acm have these? Aug 07 10:16:33 LED Modules ? Aug 07 10:17:04 @russell-- oops sorry! will send a pastebin link Aug 07 10:17:10 Native Language Support -> any reason to rock anything other than nls-utf8 if im from the USA? Aug 07 10:17:36 Network Devices-> Has Marvell DSA been tried out? Aug 07 10:18:07 Network Support -> what is kmod-bonding? Is this only for wifi AD? Aug 07 10:18:16 what about kmod-dnsresolver Aug 07 10:18:36 What is kmod-tun and would it be useful for a home network/. Aug 07 10:18:41 @jow https://pastebin.com/QsrNkGBn Aug 07 10:20:49 attached the failure messages we have got so far and let me enable additional debugging and come back to you. Aug 07 12:26:43 new kernel bumps pushed to staging Aug 07 13:03:45 * gch981213 wants suggestions or an ACK for this device support commit, especially on the factory image generating part: https://git.openwrt.org/?p=openwrt/staging/981213.git;a=commit;h=8f76e3fe38fff0d6f9cfaec18b2889bdf88247fb Aug 07 14:15:46 jow: ping Aug 07 14:16:06 jow: during a full rebuild of ar71xx rb922 target, i'm seeing this: Aug 07 14:16:10 make[3] -C target/imagebuilder install Aug 07 14:16:11 make[2] package/index Aug 07 14:16:12 WARNING: Applying padding in /mnt/ramdisk/koen/firmware/builds/generic_rb922/bin/packages/mips_24kc/base/Packages to workaround usign SHA-512 bug! Aug 07 14:16:14 make[2] checksum Aug 07 14:20:15 xback: details in e1f588e446c7ceb696b644b37aeab9b3476e2a57 Aug 07 14:20:47 the 110 fixed val? Aug 07 14:28:59 I didn't looked further then at the forum Aug 07 15:54:36 Hello OpenWrt devs, I sent a v2 of my RFC to disable the "EAP local hack", I don't know if /nbd is around, I'm pretty sure we said his name more than 3 times but he didn't appeared yet :P Aug 07 15:54:43 https://patchwork.ozlabs.org/patch/1143363/ Aug 07 15:57:13 champtar: you also need to rub the lamp 3 times ;-) Aug 07 16:57:27 Hauke: I think a PKG_RELEASE bump was needed for mdadm. The buildbots don't seem to be picking up the patch. Aug 07 16:57:55 actually...my mistake. It needs to be backported to 19.07 Aug 07 17:28:52 bleh, gotta fix a local hacky fix to be py2/3 compat now :) Aug 07 17:29:11 got a build failure ina package I haven't touched in a few years, had even forgotten it ran python :) Aug 07 18:55:19 do we have some data to decode this stack trace from openwrt 18.06.4: https://bugs.openwrt.org/index.php?do=details&task_id=2410&order=dateopened&sort=desc ? Aug 07 19:03:27 Hauke: (only partially related) that reminds me: is there any progress on a redistributable, vectoring-capable VDSL firmware? Aug 07 19:07:19 gch981213: if you haven't sent it to the mailing list yet then I would do that (maybe even flag it as "RFC" - request for comments) because it's easy to miss requests like this on IRC Aug 07 19:14:52 xdarklight: no, there is no progress I am aware of Aug 07 19:15:33 could be that this will be included in the prpl releases, butthen probably only for more recent chips Aug 07 19:17:25 but I also didn't really follow up on this topic Aug 07 19:31:35 Hauke: I've implemented a small subset of the 'openssl verify' command in px5g, that should be enough to handle certificate renewals. Aug 07 19:32:02 It's at https://github.com/cotequeiroz/openwrt/blob/px5g/package/utils/px5g/px5g.c Aug 07 19:33:37 To do renewals, you call 'px5g/openssl verify -no_check_time -CAfile cert.pem cert.pem' to ensure the cert is a valid, self-signed cert. Aug 07 19:33:49 Hauke: it would be awesome if you could ping "someone" (legal or firmware department?) again. with a supported vectoring capable VDSL firmware we can avoid more of these bugs Aug 07 19:34:54 Then run 'px5g verify d=30 pk5g verify -CAfile cert.crt -attime $(($(date +%s) + $d * 86400)) cert.crt', and it should fail if not valid 30 days from now. Aug 07 19:35:31 * 'd=30 pk5g verify -CAfile cert.crt -attime $(($(date +%s) + $d * 86400)) cert.crt' Aug 07 19:46:19 Package size for WRT3200ACM (mvebu/arm) went from 4,627 to 6,272 for the mbedtls variant, and from 52,305 to 68,446 in standalone. Aug 07 20:01:10 cotequeiroz: what advanatge does the real cert renewal bring? as along as it is self singed the browser has to approve each certificate Aug 07 20:05:03 The only advantage is to promote the renew of the actual key. As for the warning, I don't know any standard key rollover procedure to avoid it. **** ENDING LOGGING AT Thu Aug 08 02:59:57 2019