I have a configuration that used to work but now suddenly doesn't anymore. The router is supposed to connect to an access point that provides internet connectivity. While i don't have control over the access point i can confirm that all credentials are valid because my other devices can connect to it.
I've tried resetting the connection, rebooting the router, double checking connection settings but as far as i can tell it's no obvious cause. I did notice that it does seem to connect briefly and in a matter of seconds it disconnects. The log confirms this and i've posted a segment of it in the hopes that someone sees something i don't. This pattern repeats every 30 seconds or so, when a new connection attempt is done that fails in the same way.
The udcpc receiving SIGTERM sounds like a bad thing but maybe it's not the cause as this always happens AFTER the kernel decides to deauthenticate. Which it seems to me it shouldn't be doing. Also i'm not sure how to read the line about limiting TX power. Does 23 (23 - 0) dBm mean 23 dBm or is it something like "setting 23, which is 0 dBm"? I tried setting the transmit power to auto or different fixed settings but that doesn't fix the problem. I also tried killing wpa_supplicant as suggested by others posting about DEAUTH_LEAVING but this didn't fix it for me.
I'm using OpenWrt 18.06.2 r7676-cddd7b4c77 on a Linksys RE6500
Mon Apr 1 00:08:47 2019 kern.info kernel: [ 2574.059778] wlan1: authenticate with <BSSID>
Mon Apr 1 00:08:47 2019 kern.info kernel: [ 2574.634443] wlan1: send auth to <BSSID> (try 1/3)
Mon Apr 1 00:08:47 2019 kern.info kernel: [ 2574.647980] wlan1: authenticated
Mon Apr 1 00:08:47 2019 kern.info kernel: [ 2574.664850] wlan1: associate with <BSSID> (try 1/3)
Mon Apr 1 00:08:47 2019 kern.info kernel: [ 2574.697917] wlan1: RX AssocResp from <BSSID> (capab=0x1431 status=0 aid=1)
Mon Apr 1 00:08:47 2019 kern.info kernel: [ 2574.713609] wlan1: associated
Mon Apr 1 00:08:47 2019 daemon.notice netifd: Network device 'wlan1' link is up
Mon Apr 1 00:08:47 2019 daemon.notice netifd: Interface 'wwan' has link connectivity
Mon Apr 1 00:08:47 2019 daemon.notice netifd: Interface 'wwan' is setting up now
Mon Apr 1 00:08:47 2019 daemon.notice netifd: wwan (12265): udhcpc: started, v1.28.4
Mon Apr 1 00:08:48 2019 kern.debug kernel: [ 2574.871147] wlan1: Limiting TX power to 23 (23 - 0) dBm as advertised by <BSSID>
Mon Apr 1 00:08:48 2019 daemon.notice netifd: wwan (12265): udhcpc: sending discover
Mon Apr 1 00:08:51 2019 kern.info kernel: [ 2577.865065] wlan1: deauthenticating from <BSSID> by local choice (Reason: 3=DEAUTH_LEAVING)
Mon Apr 1 00:08:51 2019 daemon.notice netifd: Network device 'wlan1' link is down
Mon Apr 1 00:08:51 2019 daemon.notice netifd: Interface 'wwan' has link connectivity loss
Mon Apr 1 00:08:51 2019 daemon.notice netifd: wwan (12265): udhcpc: sending discover
Mon Apr 1 00:08:51 2019 daemon.notice netifd: wwan (12265): udhcpc: received SIGTERM
I tried rfkill via ssh but it says not found.
The order of things is always as in the log snippet, udhpc starts, tx power is limited, udhpc sends discover and two or three seconds later comes the DEAUTH_LEAVING and then udhcoc gets SIGTERM. So it could still mean that the deauth is somehow caused by udhcpc but starting and sending a discover seems normal business that should succeed.
Which part of the configuration would you like to see? Here is /tmp/run/wpa_supplicant-wlan1.conf
There are no logs at all about authorization? Are you using the full wpad? The default install is wpad-mini, which does not support "Enterprise" authorization.
I am indeed using the full wpad and i've removed wpad-mini because this network needs Enterprise authentication. I don't suspect any malfunctions there because it can connect to one other enterprise network that is also in the air. In addition as i said earlier other devices can connect using the same credentials and the log snippet i posted suggests that authentication succeeds. I don't suspect that the error is in authentication but i'll gladly show you any logs if you tell me where i can find them. I know about the kernel log and system log that you can get to through LuCI. Other than that i know how to ssh and read files but i don't know where any authorization logs are.
I am more interested in the wireless configuration you've set up.
You can get that by either typing cat /etc/config/wireless or 'uci show wireless'. It would also be useful if you could provide the configuration of other devices that are actually able to persistently connect to the AP.
You can try disabling power management as well. Though that might not be a very graceful fix.
As you can see i have a local lan configured on radio 0 and the problem network lives on radio 1, although the association/request udhcpc/deauth pattern is exactly the same if i connect to the upstream on radio 0. The local lan works as expected, also regardless of which radio i put it on and clients can connect to it but obviously receive no internet because the upstream network won't connect anymore.
I did see other people mention power management options but i haven't found any in LuCI. The closest thing i found was setting the the TX power to the highest setting instead of 'auto', or any other setting for that matter. I've fixed TX power for both networks as i have always done, so these power setting should suffice.
With the search terms i use i come across a lot of Archlinux posts, and i've tried some of the tips there. Most of the time the commands they mention are not available on my router. They also mention multiple network managers interfering and killing wpa_supplicant. I do have a wpa_supplicant process running but things just stop working when i kill it so i'm guessing i don't have multiple network mangers
