LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   major wicd issues (http://www.linuxquestions.org/questions/slackware-14/major-wicd-issues-747696/)

tux_dude 08-15-2009 01:00 AM

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.

rworkman 08-15-2009 01:29 AM

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

BCarey 08-15-2009 11:36 AM

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

Brian

unclejed613 08-18-2009 07:00 AM

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.

onebuck 08-18-2009 09:39 AM

Hi,

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

Quote:

excerpt from 'man inetd';

inetd -- internet ``super-server''

SYNOPSIS
inetd [-d] [-R rate] [configuration file]

DESCRIPTION
inetd should be run at boot time by /etc/rc (see rc(8)). It then listens
for connections on certain internet sockets. When a connection is found
on one of its sockets, it decides what service the socket corresponds to,
and invokes a program to service the request. After the program is fin-
ished, it continues to listen on the socket (except in some cases which
will be described below). Essentially, inetd allows running one daemon
to invoke several others, reducing load on the system.
...
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.

rworkman 08-18-2009 03:35 PM

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.

onebuck 08-18-2009 06:40 PM

Hi,

Quote:

Originally Posted by rworkman (Post 3648484)
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.

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'.

unclejed613 08-18-2009 08:31 PM

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.

onebuck 08-18-2009 10:31 PM

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. :)

mRgOBLIN 08-18-2009 11:36 PM

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

tux_dude 08-20-2009 09:06 AM

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.

tux_dude 08-25-2009 11:35 AM

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.

rworkman 08-25-2009 12:33 PM

Quote:

Originally Posted by tux_dude (Post 3656987)
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.

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.

Quote:

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.
They're not :) The build script is the solution :)

tux_dude 08-25-2009 01:46 PM

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.

Quote:

Originally Posted by rworkman (Post 3657038)
They're not :) The build script is the solution :)

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

rworkman 08-25-2009 03:14 PM

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


All times are GMT -5. The time now is 06:38 PM.