Hello, everyone!

I've installed Slackware 13.0 today, and everything is OK except WICD.
I can find my Netgear Router but its ssid is <hidden>. Actually, I didn't config it like that. But everything is just fine in Slackware 13.0 RC2.
When I use "iwlist wlan0 scanning", I can still get the correct ssid.
So the problem is my configuration, or just the WICD bug?

Thanks!

Try the new 1.6.2.2. You can use the same SlackBuild provided with Slackware sources (/extra/source/wicd). Don't forget to change VERSION=${VERSION:-1.6.2.1} to VERSION=${VERSION:-1.6.2.2}.

Thanks BrZ.
I tried to upgrade my wicd from 1.6.2.1 to 1.6.2.2, but the problem is still there... And I don't think it's a configuration mistake, because I can use iwlist and wpa_supplicant to connect to my wireless network. What's funny is that wicd can recognize my neighbour's ssid, but leave <hidden> for mine... That's confused me...

same thing here: my network is described as hidden,
while the others in the neighborhood are displaying the proper name....

To erickFis:

Have you tried to using wpa_supplicant to connect to your wireless network? I've tried. And it succeeded.

I'm also looking forward for a solution to this problem. And that's precisely what happens: using wpa_supplicant from the command line works fine; iwlist lists all networks with correct ESSIDs. Somehow, wicd interprets some of them as "hidden", including my own network which I know is broadcasting the ESSID. While most of the networks around appear in the list, some that I know of are also tagged as "hidden" (their ESSIDs appear in the iwlist command). I'm not sure if wicd uses iwlist directly or any other interface to scan for networks... maybe it is a python parsing problem? I have to investigate...

Searching in the wicd forums I didn't find anything relevant... the only posts about this particular issue were precisely in this forum. Maybe we should post this also in the wicd forums.

Note: This happens in a EEE-PC 901 with an RT2860STA wifi card; Slackware 13; Router is an (old) Linksys WAG354G V2; stock wicd 1.6.2.1

I'm now convinced that this is a mixture of "python parsing"/"driver capability" problems. Upgrading wicd for version 1.6.2.2, I'm now able to see other formerly detected "hidden" networks. Those had spaces in their ESSIDs, and are now displayed correctly. That's precisely what they fixed in version 1.6.2.2. But my network still appears tagged as "hidden". I suspect that this is a driver problem, since the output from iwlist in the eee-pc (using a ra2860sta module for ralink 2860sta) is much simpler than, for example, the output from an asus a8js with a ipw3945 module (intel 3945)... I mean, the relevant information is all there but not in the same order. Some info (e.g., the frequency) is missing from the ralink output. This may confuse the python parser, I guess.


This is the iwlist for ralink

ra0 Scan completed :
Cell 01 - Address: xx:xx:xx:xx:xx:xx
Protocol:802.11b/g
ESSID:"CASA-NET"
Mode:Managed
Channel:1
Quality:100/100 Signal level:-33 dBm Noise level:-97 dBm
Encryption keyn
Bit Rates:22 Mb/s
IE: WPA Version 1
Group Cipher : TKIP
Pairwise Ciphers (1) : TKIP
Authentication Suites (1) : PSK

And for the intel 3945

wlan0 Scan completed :
Cell 01 - Address: xx:xx:xx:xx:xx:xx
Channel:1
Frequency:2.412 GHz (Channel 1)
Quality=31/70
Signal level=-79 dBm
Encryption keyn
ESSID:"CASA-NET"
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 22 Mb/s
Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s
36 Mb/s; 48 Mb/s; 54 Mb/s
Mode:Master
Extra:tsf=0000000081c451b8
Extra: Last beacon: 44ms ago
IE: Unknown: 0008484F4D452D4E4554
IE: Unknown: 010582848B962C
IE: Unknown: 030101
IE: Unknown: 2A0100
IE: Unknown: 32080C1218243048606C
IE: WPA Version 1
Group Cipher : TKIP
Pairwise Ciphers (1) : TKIP
Authentication Suites (1) : PSK

Thus, if your problem is just a ESSID with spaces, the 1.6.2.2 version of wicd fixes it! If it is a driver problem (as in my case) one must patch the code or send the relevant information to wicd developers...

To sairum:

I don't understand. If it's a driver problem, why wpa_supplicant works fine? It's also use wext driver. If it's wicd problem, OK, I've tried to upgrade to 1.6.2.2 which is just same...

I may not have explained it in the right way. In my case (as in yours) the drivers work fine if used with wpa_supplicant, because you provide the ESSID of your network directly with iwpriv or in the wpa_supplicant.conf. However, wicd uses the output of iwlist to grab information about the available networks and their ESSIDs, and that's precisely where it fails. Why it fails still puzzles me (to be honest I didn't find the time to inspect the source code in python) but my guess is that it has to do with the output format of iwlist. This, in turn, depends on the specific driver you are using.

So, I have two computers with different wifi cards and drivers, and when using wicd one "sees" my network and the other does not. In my case the ralink driver is the least supported (there is a module in kernels 2.29-> in the stagging section that is quite different from the most recent driver provided by ralink, but dating from 2008) and the iwlist output is much less informative than the one coming from an intel driver (see my post above with the two examples). It might be the order by which the fields are listed (in ralink, after the MAC address, the first field is the "Protocol" whilst in the intel this field doesn't even appear). A more promising route is the fact that iwlist lists what I think are three important parameters for wicd in one line (Quality:100/100 Signal level:-33 dBm Noise level:-97 dBm), while in the intel case they are listed separately in their own lines. So this will be the first thing that I'll test: find out in the ralink driver where this lines of output are and split the output in three different lines. I'll let you know if it worked for me. Meanwhile, it would be useful if you list the output of "iwlist <iface> scan" of your particular cell (network) and also specify the wifi driver you are using.

Oops! My guesses about iwlist format were wrong... Stupid me! All the other networks in the surrounding are detected and iwlist outputs them in the same format. The difference is that they do appear in wicd. It's only mine that doesn't show up... So the answer is somewhere else.

I'm having the same problem with my wirless connection since upgrading to 13. Using the above method I upgraded wicd to most recent version. It only partially helped. We have two wireless access points where I work. Both were showing up as <hidden> when neither are. After upgrading wicd one is now showing up correctly but the closest one to my work station is still hidden.

Compaq V5305
BCM 4318 Air Force 1
wireless access points both Dlink DWL-2100AP
Both access points configured the same (except name and channel)

I used b43fwcutter and b43 drivers from SlackBuilds.org

same thing when using Slack 12.2, everthing worked flawlessly.

The up side is I can connect now to one of our wireless access points, but would be nice to connect to the closer one.

Thanks
Dan

Removed wicd, nuked all related files and made a clean install. 1.6.2.2 is working 100% here. Just needed to create a template (/etc/wicd/encryption/templates), added it to the 'active' list and wicd does the job:

When messing with the test 2.6.30.5 (now .6), I was greeted by ath5k working and also my wireless led, my so desired wireless led. There goes my last taint =]

It would be nice if someone could figure out what changed between Slack 12.2 and 13. This all worked fine (at least for me). I'm thinking of going back to 12.2. I don't like KDE 4?? anyway. I'm not saying the problem is Slack 13, but something changed between versions.

Downgrading wicd first will be my first approach. Can you connect to open/free/unsecured networks and get ip?
Try to assign fixed settings to your missed hidden router. If wpa_supplicant is working, chances are you can 'force' the connection and enjoy your system.

Thanks BrZ!
My problem is solved. I reinstalled my system without wicd. Then got the newest 1.6.2.2 and built it with the script in the source directory. And the problem disappeared...
I think maybe the problem is the related files, although I don't know what and where they are...