Ok.

So yesterday was the first that I'd heard of wicd, so I promptly dl'd the tarball, and installed from source, etc. Replaced the networking.py with the *proper* one for Slack. I stopped /etc/rc.d/rc.inet1; started the daemon, ran gui-py - entered the interface info, tried each wpa option (it's ralink, rt),...nothing. It simply doesn't find the interface. The wicd.log shows persistent attempts to find/start the interface, but no luck.

On a second box, I installed the package from slackbuilds.org, same results: nothing. Only difference is that this nic is Atheros.

Any advice/suggestions/direction?

Thanks,

Did you install the dbus-python and pyGTK packages too? When I first built wicd I forgot the dbus-python and I didn't get any errors when building.

Yes, I downloaded both of them from slackbuilds.org ran the scripts and then the installers. Then I ran the build and install scripts for wicd (also from slackbuilds.org)

Did you try the "Preferences" menu in the GUI? IIRC ralink's interfaces are named "ra?"

I've been happily running WICD (with an Intel card. I'm also running -current, tho') for a couple of months now.

As for modifying networking.py, using dhclient seems to work for me at several places *EXCEPT* when using my home AP (for some reason dhclient doesn't update /etc/resolv.conf as it should... but only with this AP so far).

Yes. The interface is wlan0, though when I used the nic in Fedora, it was rausb0. I'm going to do some serious playing around today to see if I can solve the issue.

I'm not overly concerned because both boxes work fine without wicd - my interest was piqued when this thread originated, and it's just a wee bit frustrating when what should be a fairly simple application doesn't behave as expected. I'll keep y'all posted...

cheers,

mrclisdue, what were you using before to connect to your wireless? Since this is a laptop I want to be able to see the networks availiable to me, I used wicd when Kubuntu was installed on this machine and it worked well.

On the box with the Atheros card, I installed madwifi. I *believe* that I then made the appropriate modifications to /etc/rc.d/rc.inet1.conf, restarted /etc/rc.d/rc.inet1, et voila!

On the second box, I retrieved and installed the appropriate driver from serialmonkey, made the modifications to /etc/rc.d/rc.inet1.conf, etc..

I like the idea of wicd, tho', especially the gui, because I believe it simplifies the scanning for available networks, connecting, etc. processes (this is the point where someone will jump in with the cli commands in an attempt to prove to me how much simpler it is to do it from the command line - I *already* know how to connect from the cli - it's *everyone* else I'm concerned with. If I wish to spread the Linux gospel, I must do so on the "educated by MS" terms, not on my terms....)

cheers,

I have been having trouble when I am at home then suspend to ram, take my laptop to school and try to connect using wicd. Before I leave I use the "Disconnect" button(but I get the same result whether I do or not). When I try connecting to my schools network it won't get an ip until I reboot. I have tried doing it manually as well with dhcpcd and dhclient but I get the same result, no ip until I reboot then everything works fine. I am using a modified networking.py that uses dhcpcd. I have the same result if I then suspend to ram and return home, no ip until I reboot. I started using wicd hoping a tool such as this would be able to connect to different networks without the reboot but I can't seem to get it to work. It would seem that one should be able to connect to different networks without a reboot. My home network uses wpa2 and the school network is unencrypted.

I finally have it working. Since Slackware was a recent install I decided to go back to square 1 and reinstall Slack12.

Step1:

I setup my wireless adapter (broadcom). There are a lot of substeps to this, and it varies by wireless manufacturer. There are lots of posts and tutorials availiable.

Step2:

Install dbus-python
Install pygobject
Install pycairo
Install pygtk

Step3:

Install wicd

Step4:

start daemon (/etc/rc.d/rc/wicd start)
start wicd (sucess!)

Step5:

make it automatic, add:

into /etc/rc.d/rc.local

No, actually so long as he didn't elect not to install the dhcp package, dhclient will work just fine.

The behaviours of dhclient and dhcpcd are also different enough that just replacing "dhclient" with "dhcpcd" in the script is not very likely to be a good (or working) solution.

Actually in this case as long as you only replace the *word* "\<dhclient\>" with dhcpcd in daemon.py and networking.py it does appear to work fine. I've been using it this way for a few weeks with no issues.

Did the trick for me

Either way it's not necessary. dhclient works fine.

dhclient doesn't update resolv.conf without modifying the dhclient-script. slackware is set up to have dhcpcd deal with resolv.conf updates initially. thats why replacing dhclient with dhcpcd and the dhclient route commands with dhcpcd equivalent works. you can use dhclient just fine - you just wont be able to update your resolv.conf automatically with it without some changes in inet1.

I talked to the wicd developer; he plans on making the next major update to include support for what it has so far, plus dhcpcd and pump, along with others.

if you got dhclient to update the resolv.conf in slackware evilDagmar, that's great. It's just that if there is an easier route to solving the problem without making any changes, that's the best way to go. dhcpcd has resolv.conf control in slackware. which is why its better to use dhcpcd with wicd. make 2 line changes in networking.py - wallah. problem solved.

here is an updated package that will take care of the dirty work for you:
http://nawcom.com/files/slack/wicd-1.4.2-i486-3bpn.tgz

direct link to the wicd forum relating to this topic:
http://wicd.sourceforge.net/phpbb/vi...e1bbf7415070db

wicd bug report about this topic: https://bugs.launchpad.net/wicd/+bug/191091

if there are problems with it email me at nawcom@nawcom.com; I seem to focus on the linuxquestions.org forums less and less these days.