Opened 4 months ago

Closed 2 months ago

#17855 closed bug (fixed)

iprowifi7260 - no connection due to missing data in keystore_database

Reported by: vidrep Owned by: waddlesplash
Priority: blocker Milestone: R1/beta4
Component: Network & Internet/Wireless Version: R1/beta3
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

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)

Attachments (3)

keystore_server.png (82.6 KB ) - added by vidrep 4 months ago.
screenshot1.png (120.8 KB ) - added by vidrep 4 months ago.
empty_keystore_database_2022-08-07_23-25.png (25.6 KB ) - added by oco 4 months ago.
Keystore_database after numerous attempts to add a WIFI key to connect to a WIFI endpoint

Download all attachments as: .zip

Change History (22)

by vidrep, 4 months ago

Attachment: keystore_server.png added

by vidrep, 4 months ago

Attachment: screenshot1.png added

comment:1 by vidrep, 4 months ago

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

comment:2 by waddlesplash, 4 months ago

Component: - GeneralNetwork & Internet/Wireless
Milestone: UnscheduledR1/beta4
Owner: changed from nobody to mmlr
Priority: normalblocker

comment:3 by waddlesplash, 4 months ago

Owner: changed from mmlr to waddlesplash
Status: newassigned

comment:4 by mbrumbelow, 4 months ago

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

comment:5 by Starcrasher, 4 months ago

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 .

comment:6 by oco, 4 months ago

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/

by oco, 4 months ago

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

comment:7 by madmax, 4 months ago

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

comment:8 by pulkomandy, 4 months ago

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.

comment:9 by waddlesplash, 4 months ago

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

comment:10 by Starcrasher, 4 months ago

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?

comment:11 by HaikuBot, 3 months ago

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.

Please Help! Can't without network...

Last edited 3 months ago by HaikuBot (previous) (diff)

comment:12 by waddlesplash, 3 months ago

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

What WiFi driver do you use?

in reply to:  12 comment:13 by HaikuBot, 3 months ago

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

Last edited 3 months ago by HaikuBot (previous) (diff)

comment:14 by waddlesplash, 3 months ago

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.

comment:15 by bruno, 2 months ago

Why is this still a blocker?

comment:16 by waddlesplash, 2 months ago

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.

comment:17 by vidrep, 2 months ago

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.

comment:18 by bruno, 2 months ago

fixes the connectivity issue...

Does it work now or not?

comment:19 by waddlesplash, 2 months ago

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.