iprowifi7260 - no connection due to missing data in keystore_database

[vidrep]

Clean install to formatted HDD partition

hrev56164 and earlier working

hrev56168 and later not working

The "Application keyring access" notification (see attached keystore_server.png) is never invoked on hrev56168 and later.

Overwriting the keystore_database with one from hrev56164 allows the connection to be made. (see attached screenshot1.png)

[vidrep]

If updating to a current hrev from hrev56164 or earlier, you would probably not notice this issue existed.

[mbrumbelow]

When executing:

keystore list passwords
keystore list passwords wpa_supplicant

What do you get? Thinking there may be a bogus entry in the keystore database

[Starcrasher]

So I checked with a RT2573 (I had to deactivate then reactivate the dongle so it sees the AP but that's another story) anyway I guess that it is the same at this point.

As Vidrep says wpa_supplicant app didn't request access to the keyring. I didn't remember testing that dongle before but thought that it could be 'normal' if I did. After all, users don't want to have to answer that question every time. It could be interesting to see if that access was granted before already. How could I do?

keystore list passwords --> command returned nothing keystore list passwords wpa_supplicant --> command returned (from memory) Couldn't find next key with .

[oco]

Had the same problem here with this same driver on a new machine.

The workaround in the description was enough to establish a connection (copying keystore_database from another machine containing the required WIFI key).

Maybe there is a problem when adding a new key on a non existent or an empty database : before the workaround, i have tried numerous time to set a new WIFI key. Without success.

Before replacing the database, the content looks almost empty : only an header (see attached screenshot).

About the machine : not a very fast one, but it has an SSD drive. More details about the machine here : ​https://xdo.tech/

[oco]

Keystore_database after numerous attempts to add a WIFI key to connect to a WIFI endpoint

[madmax]

Not device driver specific. I've just had the same issue with realtekwifi while trying to connect to a new AP.

No need to overwrite the keystore database, you can add the new password with keystore add password to wpa_supplicant WIFI_AP_NAME THE_PASSWORD

@Starcrasher: to list the applications that have been granted access: keystore list applications wpa_supplicant

[pulkomandy]

I think I have the same issue with iaxwifi. I found that I can connect to a network by specifying the password from the ifconfig command line, but not from the GUI. Didn't confirm if I can manually add things to the keystore yet.

[waddlesplash]

Please upgrade your wpa_supplicant package (to at least version "2.10.haiku.2") and retest.

[Starcrasher]

Not really better.

It seems that wpa_supplicant is requesting access to a keyring that does not exists yet so keystore drops the request and you get no pop-up for granting access.

By manually adding a keyring wpa_supplicant to keystore db

keystore add keyring wpa_supplicant

then a password

keystore add password to wpa_supplicant WIFI_AP_NAME THE_PASSWORD

You are will force the pop-up for granting access to keyring wpa_supplicant for app wpa_supplicant.

Unfortunately, it doesn't seem to be enough. And there's something else. I'm surprised that wpa_supplicant is launched so late in the process. Is it only used to scan secured APs?

[HaikuBot]

Got same issue... downgraded to hrev56147 in my previous states. All other states higher than pointed hrev56164. In hrev56147 all works fine. All other revs higher than hrev56164 can't conntect to WiFi. On current hrev56410 (Updated via wired net) it alway says that password incorrect. I changed pass on my router to simple 12345678 and with this password Haiku too says password incorrect (hrev56410).

I tryed manually set password via cli 'keystore' - don't help. I tryed to copy keystore file from working state hrev56147 to current hrev56410 - don't help.

I compared via diff keystore files they identically on binary level.

[waddlesplash]

As noted in an above issue, make sure to upgrade your wpa_supplicant package before testing.

What WiFi driver do you use?

[HaikuBot]

Replying to waddlesplash:

As noted in an above issue, make sure to upgrade your wpa_supplicant package before testing.

What WiFi driver do you use?

I have wpa_supplicant-2.10.haiku-2-1-x86_64.hpkg

Driver idualwifi7260

Wifi card Intel 3160

[waddlesplash]

Your problem appears to be different than this one. Please open a new ticket and attach a syslog from both a working and a non-working version.

[bruno]

Why is this still a blocker?

[waddlesplash]

It seems that wpa_supplicant is requesting access to a keyring that does not exists yet

I think this is actually expected, if there's no keyring then it won't try to look for existing passwords, makes sense. It will then request access again (and create the keyring if it does not exist) when saving the password, only after the connection has been established

Unfortunately, it doesn't seem to be enough.

Well, that indicates the real problem may be something else, then.

I'm surprised that wpa_supplicant is launched so late in the process. Is it only used to scan secured APs?

Yes. Connecting to unsecured APs does not need wpa_supplicant.

Why is this still a blocker?

It may be that it has no need of being at this point. Vidrep has not yet reported back whether the new version of wpa_supplicant fixed his problems; if it did, we can close this and move on.

[vidrep]

Installing the new wpa_supplicant update fixes the connectivity issue. However, because it is not included yet in the nightly images, users who attempt a fresh install will still need a wired connection in order to download and install the update.

[bruno]

fixes the connectivity issue...

Does it work now or not?

[waddlesplash]

Yes, it is, I had talked to him on IRC about it. You still have to manually update the package for now, but the newer package will be shipped by default before the next beta.