Thanks for making the effort to submit an openSUSE bug report.
At the moment, I’m still trying to wrap my mind around why MAC randomization would make a WiFi connection faulty. If anything, it should fix problems in multi-boot situations by ensuring that the new install is recognized as a new and unique machine on the network, and not mis-identify the machine by MAC address.
In any case, although it’s true that the MATE Desktop pattern isn’t on the DVD, it’s incorrect you can’t use the DVD to install MATE as your first Desktop, you only have to “Enable Online Repositories” on the screen where you are asked to choose between KDE/Plasma, Gnome, Server and Custom. Once you have configured Online Repositories and then select “Custom,” you will be using the vastly larger online repos for your install similar to a NET install instead of using only the DVD (If the openSUSE version launched recently, I’d expect that many packages will still be installed from the DVD).
I describe this and a lot more in my Intro to openSUSE presentation slide deck which will be revised and updated for 15.1
https://slides.com/tonysu/opensuse#/
TSU
Still that bug report thread on Launchpad, though closed over a year ago, is quite long. Now many wouldn’t even know they are facing this exact issue, and alot many wouldn’t have commented on that thread.
Well, I have never said that, everyone will not be able to connect to online repos using WiFi. But I was not able to connect from Live-DVD, and still cannot connect to WiFi using Wicked from the installed OS (though now I have WiFi working through NetworkManager).
In my case I have tried 5+ times to add online repos. And none of settings/configuration, in wicked, in 4.3GB full Tumbleweed ISO, let me connect to WiFi, and hence I couldn’t add online repos.
Now I even went through these opensuse.org pages but it didn’t help me get Wicked working (*please see Redhat link I’ve mentioned below in this reference that, how the “Using/Troubleshooting guides” should be):
https://en.opensuse.org/Portal:Wicked/Using_Wicked
https://en.opensuse.org/Portal:Wicked/Troubleshooting
I even read these slides from LinuxCon 2013:
http://events.linuxfoundation.org/sites/events/files/slides/LinuxCon_2013_NA_Eckermann_Network_Wicked.pdf
It made me thinking that in year 2019, a shiny, polished GUI (Wicked) from openSUSE (among top three in Linux world, in my humble opinion) is not working the way it should (at least in my/some cases) but a CLI / text-based NET installer (which might have components that are 20-30 years old) gets the job done right away.
It would be great if you please describe in detail that, how to configure wireless in Wicked, in your slides, like this Redhat page (for NetwrokManager):
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-interacting_with_networkmanager
Because, though I am very far from being expert on Linux or NetworkManager in general, I still can, and am using various VPNs like NordVPN, VPN Gate, Siga VPN, Windscribe etc for a while in Ubuntu Mate. And the beauty is, I can change from one VPN to another on the fly. In case of Wicked, I don’t even know where to start.
I thank you for the reply.
It may not be obvious, and I haven’t done it in awhile because Wicked is not the recommended way to connect to WiFi (because only one connection is “remembered” at a time which means your machine has to remain stationary and not move between wireless Access Points), The easiest and almost automatic way to configure Wicked is to use the YaST Network Settings module (would be the case no matter whether you connect using wired or wireless).
If it’s not obvious to you, I’d agree that documentation should be created with screenshots describing the process even if it’s somewhat rarely done.
TSU
Ohh ok. Because as per my limited reading, and from screens during many installations, I was under impression that, Wicked = Wicked Service = YaST Network Service Module are all one and same, meaning the only way to use / configure Wicked / Wicked service is through YaST network service module.
https://i.imgur.com/uFdikh1.jpg
https://i.imgur.com/W3EDIKm.jpg
https://i.imgur.com/zupw4Ow.jpg
Just to be extra clear, in my case, I was not able to connect to WiFi using Wicked / Wicked service through YaST network service module either from Live-DVD or even after the net installation was completed (after the first boot).
Thank you.
After selecting Wicked Service in your screenshot, you may need to exit the YaST Network Settings Module (clicking OK each time), you want to see your network service restart. If it doesn’t say that, then you need to close out YaST completely which should activate your Wicked Service.
Then, you should not see the message in your screenshot that says that Network Manager is managing your networking and that YaST is unable to configure some options.
Once you can edit your network device without seeing that error, you should be able to go in and configure your networking without an issue.
I don’t know about installing from a LiveCD (That’s something I haven’t personally tested, I’ve only installed using the DVD and NET installs), if there is an issue using the DVD or NET installs, that’s something I’m not aware of, but then typically I’d recommend setting up NM anyway so that the machine can move from Access Point to Access Point without forgetting each configuration.
TSU
Oh yes, I do know this. I just posted screens to know if I was missing something or was there any other way for Wicked/Wicked service.
Previously, when WiFi wasn’t working because of MAC address randomization issue/bug, I’ve disabled NetworkManager option in YaST, and tried every possible configuration for Wicked service through YaST network service module to no avail.
Now that WiFi is working through NetworkManager, later tonight, once again I’m gonna try to configure Wicked service though YaST.
Thank you so much.
Cool.
I’m just still mystified how MAC randomization can cause and not solve problems in a new install.
I always randomize MAC addresses when cloning new virtual machines, nowadays it’s either done automatically (eg VMware) or you’re asked whether you want it done for you (Virtualbox). Before, I used do my own MAC randomization manually.
It’s too bad even the bugzillas I looked at don’t say why MAC randomization caused a problem and I really can’t imagine any downside for having it done and can think of at least a few scenarios where it’s desirable. Purely speculating, maybe your AP firewall has some kind of security policy that prevents DHCP leases from being handed out freely, but that’s usually seen only in high security networks… Wouldn’t be seen in SOHO or even typical networks.
TSU
By AP firewall, you mean my wireless source/router’s firewall, right? Because as mentioned in my first post, my WiFi source is a hotspot from either of my two Android phones with 802.11 AC (Qualcomm SD 821), both running latest LineageOS 16.0. Though over a month ago, when one of the phone was on Lineage 15.1 and other on 16.0, I had the same issue (couldn’t connect to WiFi after a net install).
And obviously, there’s no MAC filtering, and firewall running on my phones. So we can eliminate AP firewall in my case.
Actually, there could be MAC filtering,
How is your connection through your LineageOS set up?
Sounds like it’s not set up as a WiFi hotspot which would support MAC randomization without a problem, you’d only need your Hotspot password.
If it’s set up as a straight serial connection, then MAC randomization wouldn’t enter the picture because you wouldn’t be running ethernet at all.
So, whatever you’re running, it’s running some kind of Ethernet that either might not be compliant (ethernet over serial, maybe ethernet over bluetooth serial?) that’s not compliant with how your phone is set up (my guess most likely) or perhaps some odd case where your MAC address might be forwarded to your ISP.
So,
If you could give more details or a LineageOS reference for how you’re set up, that might be revealing.
TSU
Again as I have mentioned in my first post, it’s just a hotspot. Here’s a screenshot:
https://i.imgur.com/SyTVw1e.png
In LineageOS hotspot settings, I don’t see any settings/option for MAC filtering.
OK,
That narrows down possibilities considerably.
Is there any way to grab the AP logfile off your Android? I’d expect that on LineageOS, you won’t have the same permissions problems you’d have on a true Android.
And, however LineageOS is doling out DHCP addresses.
It might be running something like dnsmasq instead of a regular DHCP server.
Would be worth looking at that logfile, too.
TSU
Alright finally I was able to get the following through adb logcat.
04-09 11:24:09.809 23402 23402 I hostapd : wlan0: STA 98:de:d0:0b:03:a5 IEEE 802.11: associated
04-09 11:24:09.810 629 629 I wificond: New station 98:de:d0:0b:03:a5 associated with hotspot
04-09 11:24:09.812 1035 1610 I chatty : uid=1000(system) WifiStateMachin expire 16 lines
04-09 11:24:09.814 1697 1717 V WifiManager: SoftApCallbackProxy: onNumClientsChanged: numClients=1
04-09 11:24:09.816 1035 1285 I chatty : uid=1000(system) android.fg expire 5 lines
04-09 11:24:09.828 23402 23402 I hostapd : wlan0: AP-STA-CONNECTED 98:de:d0:0b:03:a5
04-09 11:24:09.828 23402 23402 I hostapd : wlan0: STA 98:de:d0:0b:03:a5 WPA: pairwise key handshake completed (RSN)
04-09 11:24:09.929 23405 23405 I dnsmasq : DHCPDISCOVER(wlan0) 192.168.43.29 98:de:d0:0b:03:a5
04-09 11:24:09.930 23405 23405 I dnsmasq : DHCPOFFER(wlan0) 192.168.43.29 98:de:d0:0b:03:a5
04-09 11:24:14.942 23405 23405 I dnsmasq : DHCPREQUEST(wlan0) 192.168.43.29 98:de:d0:0b:03:a5
04-09 11:24:14.943 23405 23405 I dnsmasq : DHCPACK(wlan0) 192.168.43.29 98:de:d0:0b:03:a5 tw
Note: tw = openSUSE hostname
This is when WiFi gets connected.
Now I couldn’t find a single entry or any mention when WiFi does not get connected (I’ve repeated this five separate times hoping to find something), meaning if I edit /etc/NetworkManager/NetworkManager.conf back to original state, without [device] wifi.scan-rand-mac-address=no.
To me it sounds like, when WiFi doesn’t get connected, it’s because of the PC side issues not because of router side.
If the following file exists on your LineageOS, retrieve it and view its contents
/var/lib/misc/dnsmasq.leases
I’m not sure if anything telling would be in it,
Ordinarily every new install should generate a new, unique hostname which is the other desirable attribute… besides a different MAC address.
On the other hand, when you <don’t> do MAC randomization, then your new machine would be mis-identified as the previous machine. It would pick up the previously allocated IP address but have a different hostname. That wouldn’t be a critical issue if hostnames aren’t used, but it could suggest a problem with the dnsmasq being unable to create additional leases. I generally avoid using dnsmasq in favor of separate DNS and DHCP servers but recognize why dnsmasq is used for its smaller footprint but also means integrated complexity.
TSU
/var doesn’t exit all. What I found is, it should be in either (1) /bin/dnsmasq, where I get “Permission denied” error, or (2) /usr/sbin/dnsmasq, where I’m getting “No such file or directory” error. Note: Both phone are obviously unlocked but not rooted (Because banking, and similar apps won’t work if they are rooted. And I don’t wanna go for Magisk etc route to hide rooting)
Though I found, and have gone through this extremely detailed page on dnsmasq in Andoind, I couldn’t find anything related to “wifi.scan-rand-mac-address=no”.
https://github.com/Android-Apps/dnsmasq/blob/master/dnsmasq.conf.example
Now what I gather from Ubuntu Launchpad bug report is, the issue lies with some **WiFi adapters, **not the wireless source/router.
Thank you.
Regardless what they might say in those bug reports, nothing much else would make sense except for what happens on the device running whatever doles out the dhcp leases, and the diff is what I described… almost certainly some issue with creating a new lease for the supplicant. If the supplicant (Your PC doesn’t broadcast a dhcp request, then it would be the client but that’s extremely rare.
Note that to replicate your test conditions, you have to randomize your MAC address again (replicating your problem). I’m assuming that the log snippets you posted that I requested were from your successful connection. If you can’t read your Android directly during an attempted new dhcp request, then you need to look far up the log to find the previous connection, not your current connection. Or, try to retrieve the entire log and post on a pastebin for all to inspect.
TSU
My point was all the people that reported or commented on the Launchpad bug report (most likely) would not be running Android phone as their router.
Anyway, I’ve got this new ASUS RT-AC68U router now.
https://i.imgur.com/ufFKL7r.jpg
https://i.imgur.com/zHHH2R1.jpg
https://i.imgur.com/DlZK0Ey.jpg
Also, I’ve made another totally clean, fresh installation with openSUSE-Tumbleweed-NET-x86_64-Snapshot20190420-Media, and though now I’m using RT-AC68U router as a source for WiFi on the PC, the issue still remains.
I was able to connect ONLY after I added (1) " **[device] wifi.scan-rand-mac-address=no **" to /etc/NetworkManager/NetworkManager.conf, (2) reboot the PC, and (3) remove the USB wireless adapter physically and reinserted. So I think the real issue is that some wireless adapters cannot connect to WiFi with MAC Address Randomization enabled.
Logs are in the following posts. I have to break this down in multiple posts, as I’ve got this error message: The text that you have entered is too long (18654 characters). Please shorten it to 15000 characters long.
Thank you so much.
dmesg | grep wlp0s26f7u1
14.403203] rtl8xxxu 1-1:1.0 wlp0s26f7u1: renamed from wlan0
59.421162] wlp0s26f7u1: authenticate with 38:2c:4a:97:7e:c0
59.445330] wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 1/3)
59.648612] wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 2/3)
59.852561] wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 3/3)
60.056553] wlp0s26f7u1: authentication with 38:2c:4a:97:7e:c0 timed out
61.361091] wlp0s26f7u1: authenticate with 38:2c:4a:97:7e:c0
61.383729] wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 1/3)
61.584567] wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 2/3)
61.788523] wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 3/3)
61.992518] wlp0s26f7u1: authentication with 38:2c:4a:97:7e:c0 timed out
63.729077] wlp0s26f7u1: authenticate with 38:2c:4a:97:7e:c0
63.751599] wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 1/3)
63.952472] wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 2/3)
64.156478] wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 3/3)
64.360436] wlp0s26f7u1: authentication with 38:2c:4a:97:7e:c0 timed out
66.548943] wlp0s26f7u1: authenticate with 38:2c:4a:97:7e:c0
66.572115] wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 1/3)
66.772461] wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 2/3)
66.976369] wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 3/3)
67.180407] wlp0s26f7u1: authentication with 38:2c:4a:97:7e:c0 timed out
77.403327] wlp0s26f7u1: authenticate with 38:2c:4a:97:7e:c0
77.415371] wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 1/3)
77.616154] wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 2/3)
77.820151] wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 3/3)
78.024177] wlp0s26f7u1: authentication with 38:2c:4a:97:7e:c0 timed out
107.937305] rtl8xxxu 1-1:1.0 wlp0s26f7u1: renamed from wlan0
133.761148] wlp0s26f7u1: authenticate with 38:2c:4a:97:7e:c0
133.785396] wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 1/3)
133.786927] wlp0s26f7u1: authenticated
133.788665] wlp0s26f7u1: associate with 38:2c:4a:97:7e:c0 (try 1/3)
133.792096] wlp0s26f7u1: RX AssocResp from 38:2c:4a:97:7e:c0 (capab=0x1411 status=0 aid=2)
133.795880] wlp0s26f7u1: associated
133.845118] IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s26f7u1: link becomes ready
journalctl | grep wlp0s26f7u1
Apr 22 07:38:58 tw kernel: rtl8xxxu 1-1:1.0 wlp0s26f7u1: renamed from wlan0
Apr 22 07:38:58 tw NetworkManager[1311]: <info> [1555943938.8280] device (wlan0): interface index 3 renamed iface from 'wlan0' to 'wlp0s26f7u1'
Apr 22 07:38:58 tw NetworkManager[1311]: <info> [1555943938.8622] device (wlp0s26f7u1): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
Apr 22 07:38:58 tw NetworkManager[1311]: <warn> [1555943938.8795] device (wlp0s26f7u1): connectivity: "/proc/sys/net/ipv4/conf/all/rp_filter" is set to "1". This might break connectivity checking for IPv4 on this device
Apr 22 07:38:58 tw NetworkManager[1311]: <info> [1555943938.9468] device (wlp0s26f7u1): supplicant interface state: init -> starting
Apr 22 07:38:59 tw NetworkManager[1311]: <info> [1555943939.0232] sup-iface[0x5596052bc0e0,wlp0s26f7u1]: supports 4 scan SSIDs
Apr 22 07:38:59 tw NetworkManager[1311]: <info> [1555943939.0238] device (wlp0s26f7u1): supplicant interface state: starting -> ready
Apr 22 07:38:59 tw NetworkManager[1311]: <info> [1555943939.0239] device (wlp0s26f7u1): state change: unavailable -> disconnected (reason 'supplicant-available', sys-iface-state: 'managed')
Apr 22 07:39:42 tw NetworkManager[1311]: <info> [1555943982.1815] device (wlp0s26f7u1): Activation: starting connection 'RTAC68U_2_4' (97e1acc3-400a-4fb2-8859-10e2fc110cf5)
Apr 22 07:39:42 tw NetworkManager[1311]: <info> [1555943982.1820] device (wlp0s26f7u1): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Apr 22 07:39:42 tw NetworkManager[1311]: <info> [1555943982.1832] device (wlp0s26f7u1): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Apr 22 07:39:42 tw NetworkManager[1311]: <info> [1555943982.1838] device (wlp0s26f7u1): Activation: (wifi) access point 'RTAC68U_2_4' has security, but secrets are required.
Apr 22 07:39:42 tw NetworkManager[1311]: <info> [1555943982.1839] device (wlp0s26f7u1): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
Apr 22 07:39:42 tw NetworkManager[1311]: <info> [1555943982.1858] device (wlp0s26f7u1): state change: need-auth -> prepare (reason 'none', sys-iface-state: 'managed')
Apr 22 07:39:42 tw NetworkManager[1311]: <info> [1555943982.1864] device (wlp0s26f7u1): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Apr 22 07:39:42 tw NetworkManager[1311]: <info> [1555943982.1868] device (wlp0s26f7u1): Activation: (wifi) connection 'RTAC68U_2_4' has security, and secrets exist. No new secrets needed.
Apr 22 07:39:42 tw NetworkManager[1311]: <info> [1555943982.2034] device (wlp0s26f7u1): supplicant interface state: ready -> scanning
Apr 22 07:39:43 tw kernel: wlp0s26f7u1: authenticate with 38:2c:4a:97:7e:c0
Apr 22 07:39:43 tw NetworkManager[1311]: <info> [1555943983.4251] device (wlp0s26f7u1): supplicant interface state: scanning -> authenticating
Apr 22 07:39:43 tw kernel: wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 1/3)
Apr 22 07:39:43 tw kernel: wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 2/3)
Apr 22 07:39:43 tw kernel: wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 3/3)
Apr 22 07:39:44 tw kernel: wlp0s26f7u1: authentication with 38:2c:4a:97:7e:c0 timed out
Apr 22 07:39:44 tw NetworkManager[1311]: <info> [1555943984.0777] device (wlp0s26f7u1): supplicant interface state: authenticating -> disconnected
Apr 22 07:39:44 tw NetworkManager[1311]: <info> [1555943984.1777] device (wlp0s26f7u1): supplicant interface state: disconnected -> scanning
Apr 22 07:39:45 tw kernel: wlp0s26f7u1: authenticate with 38:2c:4a:97:7e:c0
Apr 22 07:39:45 tw NetworkManager[1311]: <info> [1555943985.3635] device (wlp0s26f7u1): supplicant interface state: scanning -> authenticating
Apr 22 07:39:45 tw kernel: wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 1/3)
Apr 22 07:39:45 tw kernel: wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 2/3)
Apr 22 07:39:45 tw kernel: wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 3/3)
Apr 22 07:39:45 tw kernel: wlp0s26f7u1: authentication with 38:2c:4a:97:7e:c0 timed out
Apr 22 07:39:46 tw NetworkManager[1311]: <info> [1555943986.0055] device (wlp0s26f7u1): supplicant interface state: authenticating -> disconnected
Apr 22 07:39:46 tw NetworkManager[1311]: <info> [1555943986.5061] device (wlp0s26f7u1): supplicant interface state: disconnected -> scanning
Apr 22 07:39:47 tw kernel: wlp0s26f7u1: authenticate with 38:2c:4a:97:7e:c0
Apr 22 07:39:47 tw NetworkManager[1311]: <info> [1555943987.7314] device (wlp0s26f7u1): supplicant interface state: scanning -> authenticating
Apr 22 07:39:47 tw kernel: wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 1/3)
Apr 22 07:39:47 tw kernel: wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 2/3)
Apr 22 07:39:48 tw kernel: wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 3/3)
Apr 22 07:39:48 tw kernel: wlp0s26f7u1: authentication with 38:2c:4a:97:7e:c0 timed out
Apr 22 07:39:48 tw NetworkManager[1311]: <info> [1555943988.3732] device (wlp0s26f7u1): supplicant interface state: authenticating -> disconnected
Apr 22 07:39:49 tw NetworkManager[1311]: <info> [1555943989.3737] device (wlp0s26f7u1): supplicant interface state: disconnected -> scanning
Apr 22 07:39:50 tw kernel: wlp0s26f7u1: authenticate with 38:2c:4a:97:7e:c0
Apr 22 07:39:50 tw kernel: wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 1/3)
Apr 22 07:39:50 tw NetworkManager[1311]: <info> [1555943990.5520] device (wlp0s26f7u1): supplicant interface state: scanning -> authenticating
Apr 22 07:39:50 tw kernel: wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 2/3)
Apr 22 07:39:50 tw kernel: wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 3/3)
Apr 22 07:39:51 tw kernel: wlp0s26f7u1: authentication with 38:2c:4a:97:7e:c0 timed out
Apr 22 07:39:51 tw NetworkManager[1311]: <info> [1555943991.1939] device (wlp0s26f7u1): supplicant interface state: authenticating -> disconnected
Apr 22 07:39:56 tw NetworkManager[1311]: <info> [1555943996.1990] device (wlp0s26f7u1): supplicant interface state: disconnected -> scanning
Apr 22 07:40:01 tw kernel: wlp0s26f7u1: authenticate with 38:2c:4a:97:7e:c0
Apr 22 07:40:01 tw kernel: wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 1/3)
Apr 22 07:40:01 tw NetworkManager[1311]: <info> [1555944001.3954] device (wlp0s26f7u1): supplicant interface state: scanning -> authenticating
Apr 22 07:40:01 tw kernel: wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 2/3)
Apr 22 07:40:01 tw kernel: wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 3/3)
Apr 22 07:40:02 tw kernel: wlp0s26f7u1: authentication with 38:2c:4a:97:7e:c0 timed out
Apr 22 07:40:02 tw NetworkManager[1311]: <info> [1555944002.0450] device (wlp0s26f7u1): supplicant interface state: authenticating -> disconnected
Apr 22 07:40:07 tw NetworkManager[1311]: <warn> [1555944007.4073] device (wlp0s26f7u1): Activation: (wifi) association took too long, failing activation
Apr 22 07:40:07 tw NetworkManager[1311]: <info> [1555944007.4073] device (wlp0s26f7u1): state change: config -> failed (reason 'ssid-not-found', sys-iface-state: 'managed')
Apr 22 07:40:07 tw NetworkManager[1311]: <warn> [1555944007.4082] device (wlp0s26f7u1): Activation: failed for connection 'RTAC68U_2_4'
Apr 22 07:40:07 tw NetworkManager[1311]: <info> [1555944007.4086] device (wlp0s26f7u1): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')
Apr 22 07:40:11 tw NetworkManager[1311]: <info> [1555944011.3404] device (wlp0s26f7u1): state change: disconnected -> unmanaged (reason 'removed', sys-iface-state: 'removed')
Apr 22 07:40:31 tw kernel: rtl8xxxu 1-1:1.0 wlp0s26f7u1: renamed from wlan0
Apr 22 07:40:31 tw NetworkManager[1311]: <info> [1555944031.9523] device (wlan0): interface index 4 renamed iface from 'wlan0' to 'wlp0s26f7u1'
Apr 22 07:40:31 tw NetworkManager[1311]: <info> [1555944031.9945] device (wlp0s26f7u1): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
Apr 22 07:40:32 tw NetworkManager[1311]: <warn> [1555944032.0139] device (wlp0s26f7u1): connectivity: "/proc/sys/net/ipv4/conf/all/rp_filter" is set to "1". This might break connectivity checking for IPv4 on this device
Apr 22 07:40:32 tw NetworkManager[1311]: <info> [1555944032.0773] sup-iface[0x5596052bc1c0,wlp0s26f7u1]: supports 4 scan SSIDs
Apr 22 07:40:32 tw NetworkManager[1311]: <info> [1555944032.0785] device (wlp0s26f7u1): supplicant interface state: starting -> ready
Apr 22 07:40:32 tw NetworkManager[1311]: <info> [1555944032.0787] device (wlp0s26f7u1): state change: unavailable -> disconnected (reason 'supplicant-available', sys-iface-state: 'managed')
Apr 22 07:40:56 tw NetworkManager[1311]: <info> [1555944056.5424] device (wlp0s26f7u1): Activation: starting connection 'RTAC68U_2_4' (97e1acc3-400a-4fb2-8859-10e2fc110cf5)
Apr 22 07:40:56 tw NetworkManager[1311]: <info> [1555944056.5428] device (wlp0s26f7u1): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Apr 22 07:40:56 tw NetworkManager[1311]: <info> [1555944056.5444] device (wlp0s26f7u1): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Apr 22 07:40:56 tw NetworkManager[1311]: <info> [1555944056.5451] device (wlp0s26f7u1): Activation: (wifi) access point 'RTAC68U_2_4' has security, but secrets are required.
Apr 22 07:40:56 tw NetworkManager[1311]: <info> [1555944056.5451] device (wlp0s26f7u1): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
Apr 22 07:40:56 tw NetworkManager[1311]: <info> [1555944056.5478] device (wlp0s26f7u1): state change: need-auth -> prepare (reason 'none', sys-iface-state: 'managed')
Apr 22 07:40:56 tw NetworkManager[1311]: <info> [1555944056.5484] device (wlp0s26f7u1): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Apr 22 07:40:56 tw NetworkManager[1311]: <info> [1555944056.5489] device (wlp0s26f7u1): Activation: (wifi) connection 'RTAC68U_2_4' has security, and secrets exist. No new secrets needed.
Apr 22 07:40:56 tw NetworkManager[1311]: <info> [1555944056.5664] device (wlp0s26f7u1): supplicant interface state: ready -> scanning
Apr 22 07:40:57 tw kernel: wlp0s26f7u1: authenticate with 38:2c:4a:97:7e:c0
Apr 22 07:40:57 tw NetworkManager[1311]: <info> [1555944057.7651] device (wlp0s26f7u1): supplicant interface state: scanning -> authenticating
Apr 22 07:40:57 tw kernel: wlp0s26f7u1: send auth to 38:2c:4a:97:7e:c0 (try 1/3)
Apr 22 07:40:57 tw kernel: wlp0s26f7u1: authenticated
Apr 22 07:40:57 tw kernel: wlp0s26f7u1: associate with 38:2c:4a:97:7e:c0 (try 1/3)
Apr 22 07:40:57 tw kernel: wlp0s26f7u1: RX AssocResp from 38:2c:4a:97:7e:c0 (capab=0x1411 status=0 aid=2)
Apr 22 07:40:57 tw NetworkManager[1311]: <info> [1555944057.7719] device (wlp0s26f7u1): supplicant interface state: authenticating -> associating
Apr 22 07:40:57 tw kernel: wlp0s26f7u1: associated
Apr 22 07:40:57 tw NetworkManager[1311]: <info> [1555944057.7809] device (wlp0s26f7u1): supplicant interface state: associating -> 4-way handshake
Apr 22 07:40:57 tw kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s26f7u1: link becomes ready
Apr 22 07:40:57 tw NetworkManager[1311]: <info> [1555944057.8268] device (wlp0s26f7u1): supplicant interface state: 4-way handshake -> completed
Apr 22 07:40:57 tw NetworkManager[1311]: <info> [1555944057.8268] device (wlp0s26f7u1): Activation: (wifi) Stage 2 of 5 (Device Configure) successful. Connected to wireless network "RTAC68U_2_4"
Apr 22 07:40:57 tw NetworkManager[1311]: <info> [1555944057.8417] device (wlp0s26f7u1): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Apr 22 07:40:57 tw NetworkManager[1311]: <info> [1555944057.8423] dhcp4 (wlp0s26f7u1): activation: beginning transaction (timeout in 45 seconds)
Apr 22 07:40:57 tw NetworkManager[1311]: <info> [1555944057.8441] dhcp4 (wlp0s26f7u1): dhclient started with pid 2365
Apr 22 07:40:57 tw avahi-daemon[1044]: Joining mDNS multicast group on interface wlp0s26f7u1.IPv6 with address fe80::b742:d09e:9c6b:77de.
Apr 22 07:40:57 tw avahi-daemon[1044]: New relevant interface wlp0s26f7u1.IPv6 for mDNS.
Apr 22 07:40:57 tw avahi-daemon[1044]: Registering new address record for fe80::b742:d09e:9c6b:77de on wlp0s26f7u1.*.
Apr 22 07:41:02 tw NetworkManager[1311]: <info> [1555944062.9074] dhcp4 (wlp0s26f7u1): address 192.168.1.157
Apr 22 07:41:02 tw NetworkManager[1311]: <info> [1555944062.9074] dhcp4 (wlp0s26f7u1): plen 24 (255.255.255.0)
Apr 22 07:41:02 tw NetworkManager[1311]: <info> [1555944062.9074] dhcp4 (wlp0s26f7u1): gateway 192.168.1.1
Apr 22 07:41:02 tw NetworkManager[1311]: <info> [1555944062.9075] dhcp4 (wlp0s26f7u1): lease time 86400
Apr 22 07:41:02 tw NetworkManager[1311]: <info> [1555944062.9075] dhcp4 (wlp0s26f7u1): hostname 'tw'
Apr 22 07:41:02 tw NetworkManager[1311]: <info> [1555944062.9075] dhcp4 (wlp0s26f7u1): nameserver '192.168.1.1'
Apr 22 07:41:02 tw NetworkManager[1311]: <info> [1555944062.9075] dhcp4 (wlp0s26f7u1): state changed unknown -> bound
Apr 22 07:41:02 tw avahi-daemon[1044]: Joining mDNS multicast group on interface wlp0s26f7u1.IPv4 with address 192.168.1.157.
Apr 22 07:41:02 tw avahi-daemon[1044]: New relevant interface wlp0s26f7u1.IPv4 for mDNS.
Apr 22 07:41:02 tw avahi-daemon[1044]: Registering new address record for 192.168.1.157 on wlp0s26f7u1.IPv4.
Apr 22 07:41:02 tw NetworkManager[1311]: <info> [1555944062.9093] device (wlp0s26f7u1): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
Apr 22 07:41:02 tw NetworkManager[1311]: <info> [1555944062.9106] device (wlp0s26f7u1): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
Apr 22 07:41:02 tw NetworkManager[1311]: <info> [1555944062.9110] device (wlp0s26f7u1): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
Apr 22 07:41:03 tw NetworkManager[1311]: <info> [1555944063.2051] device (wlp0s26f7u1): Activation: successful, device activated.
Apr 22 07:41:03 tw nm-dispatcher[2472]: req:1 'up' [wlp0s26f7u1]: new request (3 scripts)
Apr 22 07:41:03 tw nm-dispatcher[2472]: req:1 'up' [wlp0s26f7u1]: start running ordered scripts...
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether e0:69:95:4d:7c:9c brd ff:ff:ff:ff:ff:ff
inet 192.168.1.230/24 brd 192.168.1.255 scope global dynamic noprefixroute enp0s25
valid_lft 85810sec preferred_lft 85810sec
inet6 fe80::26ab:9ffd:88d1:ebe2/64 scope link noprefixroute
valid_lft forever preferred_lft forever
4: wlp0s26f7u1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 98:de:d0:0b:03:a5 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.157/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp0s26f7u1
valid_lft 85931sec preferred_lft 85931sec
inet6 fe80::b742:d09e:9c6b:77de/64 scope link noprefixroute
valid_lft forever preferred_lft forever