major wicd issues
 

Running (was) wicd-1.6.2 on slack current and I having nothing but problem since going to 1.6.x. I use wicd strictly for monitoring purposes due to its ui. Wpa_supplicant is used for all network configuration.

1. First problem I had was kde would boot to a black screen occasionally or upon unlocking my desktop, the screen would remain black. Thought this was the NVIDIA driver acting up again. I narrowed it down to wicd because it only occurs when wifi is not available.

2. wicd sometimes prevent my nic from scanning for wifi networks. Killing wicd and wpa_supplicant do not help. I have to unload the wifi module and reload it.

3. And the most frequent problem is the inability to receive data over wifi. Network connection would be active with packets being sent but none being received. Restarting the wlan would restore the connection, however connection would last only for a few minutes at best.

This took a lot a hair pulling to figure out. I narrowed it down to wicd completely by accident when I hooked up my ethernet after loosing wifi. My system has been running smoothly after remove wicd.

Anyone else had any of these symptoms? Slack is running on Lenovo T61 (centrino) with Intel iwlwifi-4965-ucode-228.61.2.24.

Nope, all is well here, and I've seen nothing similar in the wicd IRC channel.

It sounds like a driver problem. Does wifi work fine if you don't use wicd?

Brian

i had the same problem when i first installed my wireless card..... as it turns out wicd and inetd were butting heads. when i set inetd to default (set the inetd.conf to out-of-box defaults) wicd took over and works very nicely. basically you can't have both inetd and wicd trying to configure your network devices at the same time. choose one or the other. i think wicd has better functionality.

Hi,

Why not just configure the '/etc/inetd.conf' if you think there is a conflict.

Your 'inetd' provides the 'super-server' for a reason to inet communication with other daemons. I'm not saying your wrong with stopping the service, it's your machine. But what about 'time' or 'authentication' ? 'inetd' provides other configurable means for useful service to other daemons.

inetd and wicd are unrelated - I think "rc.inet1.conf" is what the poster meant.
That's also mentioned in the README.SLACKWARE file for wicd.

Hi,

I should have 'quoted' unclejed613 as my post was directed to him. Sorry about the mix up. I really couldn't see the relationship but if there are conflicts then try to configure than remove something as important as 'inetd'.

Edit: I re-read 'unclejed613' post and if you do apply the thought of 'inet1.conf' then probably where the confusion came for me. I just could not see disabling 'inetd'.

sorry for the mix-up. when i described the problem i was having with wicd a few months back, the developers of wicd told me in an email it was conflicting with the settings in inet1.conf, and to set inet1.conf back to the default configuration. after that wicd has worked fine...
inetd is still running, but it's not handling the wireless or wired cards directly, as that's what wicd is doing.

Hi,

That's OK!

It just didn't make sense to stop 'inetd' to me. I just couldn't see how that would be a problem with 'wicd'. If so then possible config changes but to what I wasn't sure.

robby, pointed out that he thought the 'inet1.conf' was the intent. I read your post thinking about using 'inet1.conf' and the light brightened. :)

I think the confusion stems from the missing rc. from rc.inet1.conf =)

I tried going back to stock rc.inet1.conf and used wicd fully but I found it took forever to boot. Plus, it kept messing up my resolv.conf file whenever decides to connect to my neighbor's wifi. Seeing the wifi strength on the taskbar is nice. If only I had an app (that worked) just for that.

I no longer have the above problems now that wicd has been removed, but I am getting more frequent wifi disconnects than usual. Could be the wifi driver. I might have some time to troubleshoot over the weekend. Will let you know my findings.

Looks like BCarey was right on this one. iwlwifi-4965-ucode-228.61.2.24 would stop transmitting after 10-15 sec when transferring large files over wifi. Wicd would lock up when this happens. Guess it was trying to poll the wifi or something. Disconnecting/reconnecting with wpa_sup_gui or a rc.inet1 restart would restore wicd. If this happened before logging into kde, kde desktop would not load. In this case I can log into kde by killing wicd or restarting the wifi. I went back to iwlwifi-4965-ucode-228.57.2.23 which resolved the issue. Didn't find anything on the kernel bug tracker related to this driver so I'll be submitting one.

One thing that came up while I had this issue, where are the old packages from previous revision of current kept? Had to build my own package using the slackbuild script.

Ewww, that's just wonderful. The reason for the upgrade was because my hardware craps out on large transfers with the previous firmware -- I mailed the wireless guys a stack trace and dmesg, and they referred me to the new firmware with a fix for it.

They're not :) The build script is the solution :)

That's interesting, similar issue with different driver versions. I don't recall anything unusual in dmesg and I didn't do a stack trace. I will upgrade and check again.

Just as I thought. Was checking to see if there was a public repository somewhere.

The "stack trace" was actually just the information printed in the kernel OOPS, fwiw.