Bug 442925

Summary: Wireless edit form is ignoring changes for "Connect autom" option
Product: [Fedora] Fedora Reporter: Gerwin Krist <gerwinkrist>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: christoph.wickert, dcbw, tellis, wtogami
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-19 17:02:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
screenshot none

Description Gerwin Krist 2008-04-17 16:17:57 UTC
Description of problem:

After enable/disable "Connect automaticly" option the OK button is not enabled
when editing a wireless connection and thus cannot save.

Version-Release number of selected component (if applicable):
NetworkManager-gnome-0.7.0-0.9.2.svn3566.fc9.i386

How reproducible:
Always

Steps to Reproduce:
1. Edit a wireless connections
2. check the "Connect automaticly" option and try to save it.
3.
  
Actual results:


Expected results:


Additional info:
I'm running in KDE ...

Comment 1 Dan Williams 2008-04-22 14:16:53 UTC
Fixed with latest koji builds, can you please test?

http://koji.fedoraproject.org/koji/buildinfo?buildID=46621


Comment 2 Gerwin Krist 2008-04-23 19:00:21 UTC
Created attachment 303536 [details]
screenshot

Comment 3 Gerwin Krist 2008-04-23 19:02:00 UTC
Problem not solved yet..
It seems this problem only occurs when there is "Auto" (dunno why it's there)
prepended to the networkname as you can see on the screenshot. 


Comment 4 Dan Williams 2008-04-30 23:17:29 UTC
I cannot reproduce with latest koji builds.  Editing an "auto" connection brings
up the editor window with an enabled OK button, and clicking the checkbox keeps
the OK button enabled.  Can you verify with the latest koji build?

http://koji.fedoraproject.org/koji/buildinfo?buildID=47742



Comment 5 Thomas Ellis 2008-05-01 09:44:03 UTC
I can confirm bug in latest rawhide:
[root@boomer ~]# rpm -q NetowrkManager-gnome
NetworkManager-gnome-0.7.0-0.9.2.svn3566.fc9.i386

After applying build 47742 from koji, behaviour is back to expected and you can
click 'OK'. I tried changing an 'AUTO <bssid>' access point from DHCP to static
IP addressing, 'OK' is shaded until you finish entering the gateway address then
you are able to successfully save entry.

[root@boomer ~]# rpm -q NetworkManager-gnome
NetworkManager-gnome-0.7.0-0.9.3.svn3623.fc9.i386

Thanks!

Comment 6 Dan Williams 2008-05-01 10:17:54 UTC
no problem

Comment 7 Gerwin Krist 2008-05-02 18:08:13 UTC
Nice to see it fixed for you :) It's somehow fixed here, in other words the OK
button can be pressed now. But it seems the setting is NOT being saved. And I
see:

ERROR:(page-wireless-security.c:407):update_connection: assertion failed:
(sec)

Adding a new connection is also not being saved ...

Comment 8 Thomas Ellis 2008-05-06 18:09:26 UTC
Hmmmmm very weird, as build svn3623 as fixed this for me.
I stumbled upon this because I had an issue setting up a static IP address for
my home wireless setup. Now, I've installed those latest packages it seems to
save all the data fine and connect perfectly with a static address set.

Sorry to state the obvious :-) but did you update?

On my system:
[root@boomer ~]# rpm -qa | grep NetworkManager
NetworkManager-gnome-0.7.0-0.9.3.svn3623.fc9.i386
NetworkManager-glib-0.7.0-0.9.3.svn3623.fc9.i386
NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386

You may want to reopen this bug or open a new one with the new bug you are
experiencing.

Thanks,

Tom


Comment 9 Gerwin Krist 2008-05-11 12:18:53 UTC
I tried to remove/install the rpm's but the problem still exists ...

[root@localhost ~]# rpm -qa | grep NetworkManager
NetworkManager-gnome-0.7.0-0.9.3.svn3623.fc9.i386
NetworkManager-glib-0.7.0-0.9.3.svn3623.fc9.i386
NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386

Anyways I found something out, this only occurs when security is set to
"None". I don't know if it's supposed to be act this way ....

Comment 10 Bug Zapper 2008-05-14 09:35:26 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Christoph Wickert 2008-05-19 15:32:38 UTC
rpm -qa | grep NetworkManager | sort
NetworkManager-0.7.0-0.9.3.svn3623.fc9.i386
NetworkManager-glib-0.7.0-0.9.3.svn3623.fc9.i386
NetworkManager-gnome-0.7.0-0.9.3.svn3623.fc9.i386

and I'm still seeing this behavior on fresh Fedora 9 install with Intel 3945. No
matter what I try to change the OK button is inactive. I have to close the
window and when I open it for the second time the OK button is active right from
the start, even if I did not change anything. Now if I change something I can
save it, but hitting the OK button results in a crash of nm-connection-editor,
at least in 9 out of 10 attempts.

Please tell me what you need to debug this.

Comment 12 Dan Williams 2008-05-19 15:59:03 UTC
Christoph: can you try:

http://koji.fedoraproject.org/koji/taskinfo?taskID=608593

which has just been submitted as an F9 testing update.

Comment 13 Christoph Wickert 2008-05-19 16:18:44 UTC
Unfortunately I can't reproduce the issue I described in the comment above any
longer. After I managed to change the connection for the first time it now seems
to work reliably. Changes are correctly saved and applied.

Nevertheless I will try your updates because NM works really bad here. It looses
the connection after 5-10 minutes, but this is a different issue. I will try
your packages and then file another bug if necessary. This one seems fixed for me.

Comment 14 Dan Williams 2008-05-19 17:02:18 UTC
Ok; thanks.  If your connection keeps dropping, that is more likely a kernel
driver issue than an NM issue.  We can try to get some logs from wpa_supplicant
to determine what events the driver is sending that would cause the disconnect.
 But as you say, that's a different bug entirely.  I'll close this one.