Bug 118157

Summary: Error in ifup-wireless if special character in WPA-PSK Passphrase
Product: [openSUSE] SUSE LINUX 10.0 Reporter: Christoph Weidmann <c_weidmann>
Component: NetworkAssignee: Joachim Gleissner <joachim.gleissner>
Status: VERIFIED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: heiko.rommel, mjp-novell, mvidner
Version: RC 1   
Target Milestone: ---   
Hardware: i686   
OS: All   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: output of rcnetwork start

Description Christoph Weidmann 2005-09-20 23:06:07 UTC
When I'm trying to connect to a WPA-secured WLAN using a chemical formula as  
Passphrase (because of the mix of digits and characters ;)) I get the  
following error if this formula contains the "(" sign. First, Ithought this 
isn't an allowed character, but I'm quite sure that it worked in 9.3.
Comment 1 Christoph Weidmann 2005-09-20 23:10:01 UTC
Created attachment 50485 [details]
output of rcnetwork start

Hope it helps... The displayed password "(NH4)2SO4" (Ammonium sulphate) is not
x'ed out, because it was for testing purposes only
Comment 2 Christian Zoz 2005-09-23 13:11:29 UTC
Please edit /etc/sysconfig/network/scripts/ifup-wireless in line 515 and replace
the '/' with '//'. Now it should work.
Comment 4 Christoph Weidmann 2005-09-25 11:33:39 UTC
Works! Thanks a lot for caring about. Will this be included in final or does 
it break anything? 
 
Christoph 
Comment 5 Christoph Weidmann 2005-09-25 11:35:40 UTC
One questtion again: Should or can I change bug-status to "fixed" or should 
this only be done by novell employees?  
Comment 6 Joachim Gleissner 2005-10-17 13:39:57 UTC
Usually the assignee sets the bug to "resolved". There are exceptions but in this case please do not set it to "fixed", as it is simply not fixed in our product yet.
Comment 8 Andreas Jaeger 2005-10-27 17:14:51 UTC
Please provide an update: Maintenance-Tracker-2700
Comment 9 John Martin 2005-11-03 00:23:28 UTC
There is a similar problem that should be mentioned here with SSID names. I noticed when I named my wireless network "Elliott's place" the value in my ifcfg file was:
WIRELESS_ESSID='Elliott's place'

This should be fixed so that any valid character can be used here. I wish I could have a link here to a web page that explained what characters were valid, but I can't find one.
Comment 10 Joachim Gleissner 2005-11-07 14:51:42 UTC
Yes, using apostrophes here will not work. Martin, could you prevent YaST from accepting these?
Comment 12 Martin Vidner 2005-11-24 18:19:37 UTC
I can prohibit apostrophes when entering the ESSID.
That would avoid the problem that ini-agent does not escape the values: bug 72164.
Comment 13 Joachim Gleissner 2005-12-05 13:08:21 UTC
*** Bug 136876 has been marked as a duplicate of this bug. ***
Comment 14 Anja Stock 2006-01-16 14:20:22 UTC
What is the status here?
Comment 15 Martin Vidner 2006-01-16 14:46:55 UTC
I have disabled entering the apostrophe to ESSID in yast2-network-2.13.15.
Comment 16 Joachim Gleissner 2006-01-18 15:34:45 UTC
So can we close this bug?
Comment 17 Christoph Weidmann 2006-01-19 08:03:39 UTC
What about my initial problem with the ( and ) characters? (Klammer in german, don't know how its called in english). Did the fix from comment #2 made his way into comming product?
Comment 18 Heiko Rommel 2006-01-27 15:18:43 UTC
The fix for 136876 is not complete (tested with 0a4ee38a8b35449ab7bbe9e42bd380b6).


But when entering " 'L#(UIIII) L " as a WPA_PSK in the YaST2 configuration frontend, the "'" is silently dropped from the input.

This should not happen. The user should get some feedback about which characters are not allowed in that situation.
Comment 19 Anja Stock 2006-02-01 09:49:54 UTC
This Bugfix is included in SWAMP 2965. Because of the fact that this one includes a bunch of fixes I will wait until this one is fixed. Joachim? Can you give me an update?
Comment 20 Anja Stock 2006-02-20 13:41:28 UTC
released
Comment 21 Joachim Gleissner 2006-02-22 14:44:43 UTC
*** Bug 145224 has been marked as a duplicate of this bug. ***