On 26/9/18 7:21 pm, Ed Greshko wrote:
On 9/26/18 4:34 PM, Stephen Morris wrote:
> On 14/9/18 12:29 am, Ed Greshko wrote:
>> On 9/13/18 7:39 PM, Stephen Morris wrote:
>>> After the last system update in F28 Network Manager is not retaining the
>>> password entered into its security tab. When I enter the password and select
>>> then 'OK' to exit network manager, when I get back in the password is
>>> anyone else seeing this issue or have any tips on how to rectify this issue?
>> Can we assume you're using GNOME?
>> If so, when you have the security tab open there is what looks like 2 people on
>> right hand side in the password box.
>> If you click on that there should be 3 choices. What is yours set to?
> Thanks Ed, sorry its taken me a while to response, I haven't been on much
> I'm actually using KDE. As well as the situation mentioned above, when I get
> KDE I get prompted for my password to supply to Kwallet, and then I get prompted to
> enter my Wifi password, at which point the wifi gets activated and then the
> firewall get started for the network adapter. I was using the option 'Store this
> password for this user only (encrypted)' which was not retaining it on exit, as
> test I switched to 'Store this password for all users (Unencrypted)' which
> be retaining it from the perspective of when I exit and get back in the password is
> still there. If the 2nd option has indeed retained the password, could there be a
> slight logic error in networkmanager where 'Store this password for this user
> (encrypted)' seems to be functioning like the option of 'Ask for this
> every time'?
I see. I am a KDE user as well.
I have my WiFi security set to "Store password for this user only
I activate the connection I am prompted for my kwallet password and the
connection is made without asking for the WiFi password. So, in my case there is no
issue. The WiFi password is being retained.
If you bring up kwalletmanager5 you should see an entry for "Network
This is where WiFi and VPN "secrets" are kept in the Maps area.
Your WiFi connection should have a name. And that name should (in most cases) match
a name in /etc/sysconfig/network-scripts.
For example, one of my WiFi connections is "asus2" and in the network-scripts
directory I have a ifcfg-asus2. Looking at that file there is a UUID line.
UUID=8eef1e08-095e-4fb2-8dab-50ef1c19a114. This line matches a line in the Maps area
and there exists a "psk" Key.
Do you have something similar?
Thanks Ed. I didn't have kwalletmanager of any sort installed, so I have
now installed kwalletmanager5.
My wifi connection is dlink-4A42 and there is an ifcfg-dlink-4A42 script
in /etc/sysconfig/network-scripts as well as a keys-dlink-4A42 that
contained my password. Looking at the UUID line under Maps and it was a
vpn entry, there was no 802.11 wireless security entry at all, and the
uuid did not match that in the ifcfg file. While kwalletmanager5 was
active I switched my wife definition in networkmanager back to "Store
password for this user only (encrypted)" and that put a uuid entry into
the maps area, while I was watching, that matched the uuid in the ifcfg
file with my wifi password. Having rebooted the issue has now been resolved.
The only thing I can think of that would have caused this is that having
changed the router I am using I encountered an issue under Windows 10
that looked like there was an incompatibility between the Dlink DWA192
AC1900 adapter I was using and the Dlink router (I could access the
internet through a browser, and applications like games could access the
internet over the 2.4GHz channel but not over either of the 5GHz
channels) so I changed my wireless adapter to a Netgear Nighthawk AC1900
adapter but that made no difference, and it turned out the issue was and
"Anti ARP-spoofing" option I had active in my windows firewall, which as
far as I can determine in not active/available in the Fedora firewall.
Unfortunately the Nighthawk adapter uses the same chipset as the DWA192
which is not supported in the kernel, hence uses the same kernel driver
the DWA adapter does. The unfortunate thing was I had changed the
dkms.conf file for the driver to use the same make command syntax that
was specified in the dkms.conf file supplied by the vendor for the Razor
gaming mouse I was using (before I changed the mouse and keyboard both
over to logitech gaming devices) to compile their mouse utilities to
identify how to find the kernel headers to compile for, which for some
reason produced a compiled driver that the kernel could not load because
of some sort of "Exec" errors. Changing the make command back to what I
was originally using rectified this issue (according to the dkms
documentation the razor methodology and the methodology I am using both
do the same thing). While I had these issues I was using ethernet
through networkmanager to get internet access and the wifi definition
was left at specifying to limit the wifi definition to the DWA adapters
mac address. Having rectified the driver compile issue, and still using
ethernet, I modified the wifi config to not limit the definition to a
specific device, deactivated the ethernet connection and connected via
wifi which then prompted for the kwallet password and then prompted for
the wireless password, which exhibited the issue raised in this thread
above. The only thing I can think of is that with the required password
changes from changing routers, and changing adapters, and dynamically
changing from ethernet to wireless, that it was too many changes at once
for networkmanager to cope with.
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: