Something happened to my wifi after a hard reset & FSCK
 

Hey everyone, so, I'm having wifi issues again. My previous thread with wifi dongle issues was this thread: https://www.linuxquestions.org/quest...nt-4175672155/

Anyways, in trying to do some heavy Qemu-using, it turns out, you cannot dedicate 3/4ths of your RAM to a virtual machine and just casually browse the internet on your host at the same time.
web & browser standards these days, I tell you what...

So my Slackware-based host froze, and I hard-reset it which resulted in FSCK running it's shenanigans on sda3 (my /home partition) at startup.

Well, turns out, something is wrong with either the dongle driver I had installed a month earlier, or something else in the system that is causing me to not be able to connect to my wifi router. I am back onto tethering again for the time being. I can connect via wifi on other devices and systems, just not my Slackware machine.

iwconfig doesn't do anything but show my dongle exists, when I try to connect, nothing changes. At this point, I don't know what to do. How can I diagnose and fix this problem?

Can you provide the output of iwconfig and method you use to connect to the internet (rc.inet1.conf, networkmanager, wicd, etc)? And then can you provide any relevant output or error messages from trying to connect?

Basically, for your connection you need a driver (that you already got compiled & installed in the thread you mentioned) that iwconfig is reporting as working - wireless interface is up (that's according to your last lines). Note that iwconfig is just a configuration utility that won't do the actual connection.
Then you need a utility to make the connection, standard is wpa_supplicant, that uses /etc/wpa_supplicant.conf for configuration. If this standard method is used, check if /etc/wpa_supplicant.conf is OK. Here (end of the post) you have some manual instructions for bringing up the connection:
https://www.linuxquestions.org/quest...4/#post6061801

If you used some other connection managers, like wicd/NetworkManager, then check their configuration files. AFAIK NM stores its own stuff and doesn't make use of /etc/wpa_supplicant.conf
I'm not familiar with these graphic connection managers, but since you mentioned a potential filesystem corruption, I'd just wipe them out (uninstall), clean all their configuration crap and reinstall them again.

P.S. bassmadrigal was faster :)

I use Network Manager to connect to wifi. Sorry, I should've included that in the OP, my bad.

I select my router in the NM dropdown, it hangs for about seventy seconds, then goes back to a disconnected state, no error message, no further responses.

I don't know how else to find logs, errors or information about what's going on in Network Manager


Thank you for that, but I don't think network manager even touches rc.inet1.conf. I set it up using the driver specified, and nothing seems to have changed.

So you have a slackware host onto which you run multiple virtual machines, each accessing heavily the same unique host's network resources, the usb dongle ?

After the crash you had, maybe it is worth inspecting and looking at your router's configuration panel that you are not being denied an ip address for that dongle.

networkmanager logs to /var/log/messages

Indeed, it doesn't, nor does the manual connection method I presented in the post:
https://www.linuxquestions.org/quest...4/#post6061801
again: end of the post
It just needs a properly populated /etc/wpa_supplicant.conf and to not have any wpa_supplicant session running (NetworkManager (which uses by itself wpa_supplicant) / wicd).
A successful manual test will exclude any networking issues and you can then focus on NetworkManager.
You could even use two consoles and disable the "move to background" -B switch from wpa_supplicant and look after errors:
You'll need another console to call:
Or, enable debugging and/also create a debug log with:
For populating /etc/wpa_supplicant.conf, check bassmadrigal's post (towards the end):
https://www.linuxquestions.org/quest...4/#post6061656

@lawnm0wer

Before going for the manual test!
Some of the causes for the WiFi connection problems reported in this recent thread might be also relevant for your actual situation, in which you had to hard reset you Slackware. wpa_supplicant & dhcpcd have not exited clean and you might have some pid/lock files leftovers that you'll need to manually clean/delete. These are both executed (used) by NetworkManager.

- /var/run/wpa_supplicant/wlan0
https://www.linuxquestions.org/quest...ml#post6080130

- /run/dhcpcd/dhcpcd-wlan0.pid
https://www.linuxquestions.org/quest...ml#post6109167

@abga I just realized, I've been getting mad at people for not looking at my posts when I did the exact same thing to you... :foot:

Sorry about that, I will be looking at posts closer from here-on-out.

I checked, apparantly my system doesn't even have those folders.

I managed to get my network information & populated my /etc/wpa_supplicant.conf via bassmadrigal's post, these were the results:

Weird, I don't even know how a configuration named -dd would exist... I think my hard-reset may have corrupted some files... :(

@_peter
It wasn't even multiple qemu machines, just one. I've dialed that back to 50% ram instead of 75%

Anyways I checked that folder, all I see is 70-persistent-net.rules, the flash.rules I set up for qemu and I don't see anything out of the ordinary there.

- this is weird and related to the WiFi driver itself. Try using the older wext instead of nl80211
- more info on wext and why it is "old"
https://wireless.wiki.kernel.org/en/...ess-extensions
- well, there isn't any 8812au driver
- for some clarification, read the first answer from this post:
https://unix.stackexchange.com/quest...wpa-supplicant
- this is my fault, sorry - wrong syntax, added the -dd switch after -c
- the correct ones should be:
(also corrected in the original post)

OK, so no pids/locks related to WiFi appear to be available and nl80211 is not supported by the WiFi driver.
Please correct and retry the test(s).
If the manual test(s) gets you connected, then focus on NetworkManager. Again, I'd just uninstall it together with its conf files and reinstall & reconfigure it back clean.

few times on nasty hard reset, the file you identified 70-persistent-net.rules has been corrupted for me, hdds were most likely faulty, but i never understood the root cause.
no network connection while driver and interface looked ok, it puzzled me for days.

agree, it doesn't appear to be the scenario you are facing.
as others said, eventually you will make it work by focusing on network-manager once the manual tests passes, good luck.
another case of "it was working fine until it doesn't"

guessing, you have zero issue connecting to your router with the ethernet interface on that particular computer?
usb tethering works fine you said.

Zero issue with the ethernet interface, which is what network manager treats tethering to my router as.

I guess standards change? Or is it obsessiveness over semantics the reason they depreciated the driver?

Well, back on topic, wext seems to initialize, but nothing further came of anything other than what seemed to be an idle process.

Output:
Upon running the updated commands, I got the following output:
Also, the command that pipes to the debug log has a second, loose -dd. Removing it causes the command to output the same text as the non-debug command, so I presume that was user error. Well, happens to all of us. :P

Alright, how would I go and delete any conf files for the driver? I did make (uninstall / clean / install) in that order, but nothing seems to have changed. I couldn't find anything of interest in my user account's .conf folder so right now i'm out of options.

The line in bold - "Association request to the driver failed" bothers me a little.
EDIT:
________________________________
Looking after an explanation about this error I learned that it could be caused by an already running wpa_supplicant instance. Which in turn could have been launched by you, in your attempts, or by NetworkManager if it's still running.
First, check if NetworkManager is running and kill it:
Then check and kill any running wpa_supplicant instances - this is important every time you start a test!
________________________________

Next step you should have tried:
The updated commands were just corrected with respect to the -dd switch but still used nl80211, which we already knew it didn't work. You should have switched to wext for them too, here are again updated with wext
Let's still focus on the driver & manual test.

NetworkManager is just a package that you can uninstall with:
And then reinstall with:

The last line here states that you were connected. This is good. The next step is you would need to then request an address from the dhcp server. You would need to keep wpa_supplicant running and then run one of the following in a separate console (both basically do the same thing, just different programs):

If that works and you get an IP address, we can then try the automated version. Ctrl+C the wpa_supplicant window, make sure dhcpcd or dhclient is no longer running (it might require killing the process... I don't remember). Before we do that, we'll want to make sure /etc/rc.d/rc.inet1.conf is updated to use the correct wpa_supplicant driver, so make sure you uncomment the line WLAN_WPADRIVER[4] and change the "ndiswrapper" to "wext" like the following:

Then at that point, you can try running:

If that gets you internet access, you're done unless you need to set up NetworkManager or wicd.

Did you redo the steps in post 4 of the other thread? Whenever you have a kernel update you will have to rerun the commands in post 4 of your other thread.