I've noticed one other problem. samba4 is working for me with this build. I have a network share for Music that my Sonos system uses.
However, if I go to "Network Shares" in LuCI, under Services, the page shows no shares. In r10307, the share was shown on that page.
Not included in the build, so nothing to disable.
I have been trying to get WPA3 working on a WRT1900ACv1 running http://downloads.openwrt.org/releases/19.07-SNAPSHOT/ + WPAD-OPENSSL
I can get straight WPA2-PSK working (had to enable 802.11w first), but not WPA2/3 mixed, or straight WPA3-SAE.
Are their any tricks or known issues with WPA3 on WRT series?
Or known issues with macOS Catalina and iOS 13 betas, which both support WPA3?
Some 2.4GHz devices refuse to connect to WRT32X (running 18.06.4 w/mwlwifi 10.3.8.0-20181210-31d9386): Amazon Cloud Cam, Chromecast, Sonoff devices. There is the snippet of log file when a Sonoff device tried to connect to the router:
Sat Jul 27 22:43:10 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: associated (aid 5)
Sat Jul 27 22:43:10 2019 daemon.notice hostapd: wlan1-1: AP-STA-CONNECTED 06:05:04:03:02:01
Sat Jul 27 22:43:10 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 RADIUS: starting accounting session 8AB4CDD24062089B
Sat Jul 27 22:43:10 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 WPA: pairwise key handshake completed (RSN)
Sat Jul 27 22:43:12 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: authenticated
Sat Jul 27 22:43:33 2019 daemon.notice hostapd: wlan1-1: AP-STA-DISCONNECTED 06:05:04:03:02:01
Sat Jul 27 22:43:33 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: disassociated
Sat Jul 27 22:43:33 2019 kern.debug kernel: [51444.401845] ieee80211 phy1: staid 5 deleted
Sat Jul 27 22:43:34 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sat Jul 27 22:43:44 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: associated (aid 5)
Sat Jul 27 22:43:44 2019 daemon.notice hostapd: wlan1-1: AP-STA-CONNECTED 06:05:04:03:02:01
Sat Jul 27 22:43:44 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 RADIUS: starting accounting session AF0DD809F404E8F6
Sat Jul 27 22:43:44 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 WPA: pairwise key handshake completed (RSN)
Sat Jul 27 22:43:49 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: authenticated
Sat Jul 27 22:45:17 2019 kern.debug kernel: [51548.268348] ieee80211 phy1: staid 5 deleted
Sat Jul 27 22:45:17 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: associated (aid 5)
Sat Jul 27 22:45:17 2019 daemon.notice hostapd: wlan1-1: AP-STA-CONNECTED 06:05:04:03:02:01
Sat Jul 27 22:45:17 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 RADIUS: starting accounting session AF0DD809F404E8F6
Sat Jul 27 22:45:17 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 WPA: pairwise key handshake completed (RSN)
Sat Jul 27 22:45:21 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: authenticated
Sat Jul 27 22:45:39 2019 daemon.notice hostapd: wlan1-1: AP-STA-DISCONNECTED 06:05:04:03:02:01
Sat Jul 27 22:45:39 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: disassociated
Sat Jul 27 22:45:39 2019 kern.debug kernel: [51570.833787] ieee80211 phy1: staid 5 deleted
Sat Jul 27 22:45:40 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sat Jul 27 22:45:50 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: associated (aid 5)
Sat Jul 27 22:45:51 2019 daemon.notice hostapd: wlan1-1: AP-STA-CONNECTED 06:05:04:03:02:01
Sat Jul 27 22:45:51 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 RADIUS: starting accounting session 12D8FFFA141F491E
Sat Jul 27 22:45:51 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 WPA: pairwise key handshake completed (RSN)
Sat Jul 27 22:45:53 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: authenticated
Sat Jul 27 22:46:14 2019 daemon.notice hostapd: wlan1-1: AP-STA-DISCONNECTED 06:05:04:03:02:01
Sat Jul 27 22:46:14 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: disassociated
Sat Jul 27 22:46:14 2019 kern.debug kernel: [51605.609236] ieee80211 phy1: staid 5 deleted
Sat Jul 27 22:46:15 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sat Jul 27 22:46:16 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: associated (aid 5)
Sat Jul 27 22:46:16 2019 daemon.notice hostapd: wlan1-1: AP-STA-CONNECTED 06:05:04:03:02:01
Sat Jul 27 22:46:16 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 RADIUS: starting accounting session 968AEA8B560D111D
Sat Jul 27 22:46:16 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 WPA: pairwise key handshake completed (RSN)
Sat Jul 27 22:46:18 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: authenticated
Sat Jul 27 22:46:39 2019 daemon.notice hostapd: wlan1-1: AP-STA-DISCONNECTED 06:05:04:03:02:01
Sat Jul 27 22:46:39 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: disassociated
Sat Jul 27 22:46:39 2019 kern.debug kernel: [51630.602582] ieee80211 phy1: staid 5 deleted
Sat Jul 27 22:46:40 2019 daemon.info hostapd: wlan1-1: STA 06:05:04:03:02:01 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)One workaround is set wmm to 0. But my understanding is that setting wmm=0 is effectively disable N mode. Any solution to this problem?
Thanks!
The only other thing would be setting 2.5Ghz to Legacy, but you may be doing that already disabling N mode.
IOT's not connecting has been an issue for a long time (I have a printer that refuses to connect). My recommendation would be to buy one of those Netgear 2.5Ghz wifi extenders. They work great and are cheap.
Thanks the suggestion @davidc502. My current solution is putting an old router into AP mode and connecting it to wrt32x with wired port(only 100M). Is this a mwlwifi driver issue or firmware issue?
I've had two problems with r10618. First, when I try to install dnsmasq-full per the instructions for adding vpn-policy-routing (https://github.com/stangri/openwrt_packages/blob/master/vpn-policy-routing/files/README.md), I get "Failed to download" errors with wget returning 4, as described in my earlier posts. That occurs repeatedly. When I move to downloading the dnsmasq-full ipk and installing it, I end up with the same "Failed to download" errors as opkg installs the dependencies (libnfnetlink0 is the first one). I recognize I could likely solve this by downloading all the dependencies as ipks myself, but I shouldn't have to do this given it has always worked per the vpn-policy-routing instructions in the past. The behavior makes me suspect a larger issue.
Second, although samba4 works now that version 4.9 comes with the build, the "Network Shares" through LuCI shows no shares. This is mainly just an annoyance because samba is working and I can manage it all through the command line and config files. However, it isn't very user friendly.
So, my 2 cents, I suppose. I'm inclined to stay with r10307 for now.
If you get a chance, try this if you are on IPv4.
Add the following line to the bottom of 'WAN' in your /etc/config/network
option ipv6 0
Restart the router.
I have an IPv6 connection. If I understand what you've written properly, given that I have an IPv6 connection it isn't worth adding the option ipv6 0 line to my network config.
Correct... I noticed that option was missing in the latest build, and other people having the same issue put that option in to get wget working again.
Looks like you are an expert on upnp ... I'm using miniupnp's default config, and since some versions ago it's flooding my syslog with something like this:
Mon Jul 29 07:42:09 2019 daemon.err miniupnpd[9555]: sendto(udp_notify=8, [fd04:6713:20c1::1]): Permission denied
Mon Jul 29 07:42:09 2019 daemon.err miniupnpd[9555]: sendto(udp_notify=8, [fd04:6713:20c1::1]): Permission denied
Mon Jul 29 07:42:09 2019 daemon.err miniupnpd[9555]: try_sendto(sock=8, len=465, dest=[ff0e::c]:1900): sendto: Permission denied
Mon Jul 29 07:42:09 2019 daemon.err miniupnpd[9555]: try_sendto(sock=8, len=465, dest=[ff0e::c]:1900): sendto: Permission denied
Mon Jul 29 07:42:09
Mon Jul 29 07:42:09 2019 daemon.err miniupnpd[9555]: try_sendto(sock=7, len=463, dest=239.255.255.250:1900): sendto: No such device
Mon Jul 29 07:42:09 2019 daemon.err miniupnpd[9555]: try_sendto(sock=7, len=463, dest=239.255.255.250:1900): sendto: No such device
Mo
Mon Jul 29 07:41:39 2019 daemon.err miniupnpd[9555]: try_sendto(sock=7, len=471, dest=239.255.255.250:1900): sendto: No such device
Mon Jul 29 07:41:39 2019 daemon.err miniupnpd[9555]: try_sendto(sock=7, len=399, dest=239.255.255.250:1900): sendto: No such device
Mon Jul 29 07:41:39 2019 daemon.err miniupnpd[9555]: try_sendto failed to send 52 packets
Mon Jul 29 07:42:09 2019 daemon.err miniupnpd[9555]: sendto(udp_notify=7, 192.168.1.1): No such device
Mon Jul 29 07:42:09 2019 daemon.err miniupnpd[9555]: sendto(udp_notify=7, 192.168.1.1): No such device
Just to clarify: you just want to mute that error message?
That would be a solution, yes. The other would be to avoid the errors ( as they are reported as errors and not warnings)
I don't see those warnings in my syslog. Did you enabled the "additional logging" for UPNP?
The only thing that floods my syslog are ssdp m-search notifications (even for devices which aren't allowed to use UPNP) if additional logging is enabled.
Maybe the latest miniupnpd daemon will fix those entries. We are still using 2.1.20190408 instead of 2.1.20190630 (latest)....
It happened again. So it may not be DFS channel issue ( 5G use channel 40). Same behavior, The outage lasted about 3 minutes
Tue Jul 30 07:36:22 2019 daemon.notice hostapd: wlan1: CTRL-EVENT-EAP-STARTED aa:bb:cc:dd:ee:ff
Tue Jul 30 07:36:22 2019 daemon.notice hostapd: wlan1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
Tue Jul 30 07:36:23 2019 daemon.info hostapd: wlan1: STA aa:bb:cc:dd:ee:ff RADIUS: VLAN ID 1
Tue Jul 30 07:36:23 2019 daemon.notice hostapd: wlan1: CTRL-EVENT-EAP-SUCCESS2 aa:bb:cc:dd:ee:ff
Tue Jul 30 07:36:23 2019 daemon.info hostapd: wlan1: STA aa:bb:cc:dd:ee:ff RADIUS: starting accounting session 3D2B7B77D2F6A274
Tue Jul 30 07:36:23 2019 daemon.info hostapd: wlan1: STA aa:bb:cc:dd:ee:ff IEEE 802.1X: authenticated - EAP type: 25 (PEAP)
Tue Jul 30 07:36:23 2019 daemon.info hostapd: wlan1: STA aa:bb:cc:dd:ee:ff WPA: pairwise key handshake completed (RSN)
Tue Jul 30 07:40:03 2019 daemon.info hostapd: wlan0: STA aa:bb:cc:dd:ee:ff IEEE 802.11: associated (aid 3)
Tue Jul 30 07:40:03 2019 daemon.notice hostapd: wlan0: CTRL-EVENT-EAP-STARTED aa:bb:cc:dd:ee:ff
Tue Jul 30 07:40:03 2019 daemon.notice hostapd: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
Tue Jul 30 07:40:03 2019 daemon.info hostapd: wlan0: STA aa:bb:cc:dd:ee:ff RADIUS: VLAN ID 1
Tue Jul 30 07:40:03 2019 daemon.notice hostapd: wlan0: CTRL-EVENT-EAP-SUCCESS2 aa:bb:cc:dd:ee:ff
Tue Jul 30 07:40:03 2019 daemon.info hostapd: wlan0: STA aa:bb:cc:dd:ee:ff WPA: pairwise key handshake completed (RSN)
Tue Jul 30 07:40:03 2019 daemon.notice hostapd: wlan0: AP-STA-CONNECTED aa:bb:cc:dd:ee:ff
Tue Jul 30 07:40:03 2019 daemon.info hostapd: wlan0: STA aa:bb:cc:dd:ee:ff RADIUS: starting accounting session 533CD1DFE724F432
Tue Jul 30 07:40:03 2019 daemon.info hostapd: wlan0: STA aa:bb:cc:dd:ee:ff IEEE 802.1X: authenticated - EAP type: 25 (PEAP)
Tue Jul 30 07:40:03 2019 daemon.info hostapd: wlan0: STA aa:bb:cc:dd:ee:ff IEEE 802.11: authenticatedI didn't have debug enabled... but did enable it , then disabled it, and now the issue seems not to be happening ... but now, coincidentally, I'm getting flooded with this one:
Tue Jul 30 13:37:36 2019 kern.debug kernel: [814952.798152] ieee80211 phy0: Mac80211 start BA 1c:4d:70:0c:86:6d
Tue Jul 30 13:37:52 2019 kern.debug kernel: [814968.181727] ieee80211 phy1: Mac80211 start BA fc:2a:9c:71:f6:8a
Tue Jul 30 13:37:52 2019 kern.debug kernel: [814968.491427] ieee80211 phy1: Stop BA 74:8d:08:9f:95:4e
Tue Jul 30 13:38:03 2019 kern.debug kernel: [814979.457687] ieee80211 phy1: Mac80211 start BA 74:8d:08:9f:95:4e
Tue Jul 30 13:38:04 2019 kern.debug kernel: [814980.531188] ieee80211 phy1: Stop BA fc:2a:9c:71:f6:8a
Tue Jul 30 13:38:05 2019 kern.debug kernel: [814981.908418] ieee80211 phy1: Mac80211 start BA fc:2a:9c:71:f6:8a
@eduperez Yes, can I mute it?
Is there anything in the kernel logs during this time?
These look like normal 802.1x logs from what I can tell.
Only kernel log before is:
Tue Jul 30 07:32:11 2019 kern.debug kernel: [256035.261847] ieee80211 phy1: staid 6 deleted
Tue Jul 30 07:32:11 2019 kern.info kernel: [256035.306322] br-vlan4: port 2(wlan1.4) entered disabled state
Tue Jul 30 07:32:11 2019 kern.info kernel: [256035.314118] device wlan1.4 left promiscuous mode
Tue Jul 30 07:32:11 2019 kern.info kernel: [256035.318873] br-vlan4: port 2(wlan1.4) entered disabled state
Tue Jul 30 07:32:11 2019 daemon.err hostapd: VLAN: br_delif: Failure determining interface index for 'wlan1.4'And after
Tue Jul 30 07:41:34 2019 kern.debug kernel: [256598.220647] ieee80211 phy1: staid 5 deleted
Tue Jul 30 07:41:34 2019 kern.info kernel: [256598.266145] br-vlan1: port 3(wlan1.1) entered disabled state
Tue Jul 30 07:41:34 2019 kern.info kernel: [256598.273718] device wlan1.1 left promiscuous mode
Tue Jul 30 07:41:34 2019 kern.info kernel: [256598.278474] br-vlan1: port 3(wlan1.1) entered disabled state