Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050827 Fedora/1.1-0.2.8.deerpark.alpha2 Firefox/1.0+ Description of problem: Lack of 0x in the WEP key input is accepted by the python tool, and passed to the network scripts, which fails to activate the card, with a very uninformative message (passed back in raw form to the user). If the 0x is required, why not append it automatically? If it isn't, (can be specified on octal or something like that), a more informative message should be displayed when the card doesn't activate, because of incorrect WEP. Basically, as the user, I am confused by all of this - I just want my card to work. Version-Release number of selected component (if applicable): How reproducible: Didn't try Steps to Reproduce: Additional info:
if you want a hexadecimal key, then you have to prepend 0x... if you want a string to be set, then you don't need 0x... $ man iwconfig
I think you're missing the point - this is a UI bug. This is what I get when I forget to put 0x: Error for wireless request "Set Encode" (8B2A) : SET failed on device ath0:1 ; Invalid argument. ... how am I supposed to figure out what's wrong? If I wanted to read manpages on iwconfig, I wouldn't be using a graphical tool to configure my network. IOW, the bug is that unfriendly error messages from the underlying programs/libraries are relayed to the user.
some card accept a string, some not... s-c-network even notes, that you have to prepend a 0x, if you want a hex key in the gui dialog!!! those who can read, have an advantage :)
Well, I'm not going to keep resetting the bug back and forth, but I disagree with you. Relaying low-level errors to the end users seems like bad design to me. Please note, however, that when I removed and re-added the device like you suggested for the other bug, the WEP key was remembered (1) without the 0x, and (2) with dashes, both of which broke the network.