Wicd woes...Intel 3945...assistance requested

thayer · 2007-11-20 19:07:25

I have tried to use Wicd in the past without success and now that it's coming to the [extra] repository I thought for sure it'd be working by now, but I'm not having any luck at all. It doesn't even manage my DHCP wired connection, and half the time the gui doesn't even appear when I launch it.

As the title states, I'm running an intel wireless 3945 (iwlwifi drivers) and I've installed the wicd from [testing]

My rc.conf:

MODULES=(vboxdrv coretemp i8k acpi-cpufreq cpufreq_ondemand fglrx b44 mii iwl3945 snd-mixer-oss snd-pcm-oss snd-hwdep snd-page-alloc snd-pcm snd-timer snd snd-hda-intel soundcore)

HOSTNAME="dublin"
lo="lo 127.0.0.1"
eth0="dhcp"
wlan0="dhcp"
INTERFACES=(lo !eth0 !wlan0)
gateway="default gw 192.168.0.1"
ROUTES=(!gateway)

DAEMONS=(syslog-ng hal cpufreq wicd network !dhcdbd !networkmanager !@netfs @alsa @crond @cups @ntpd @sensors @sshd @transmissiond)

I've tried running it with and without the standard network daemon enabled--both have the same non-working result.

The console output when I run the tray and try to open the gui:

[thayer@dublin ~]$ /usr/lib/wicd/tray.py
attempting to connect daemon...
success
ERROR:dbus.proxies:Introspect error on :1.3:/org/wicd/daemon: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Traceback (most recent call last):
  File "/usr/lib/wicd/edgy.py", line 85, in set_signal_image
    config.DisableLogging()
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 64, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 136, in __call__
    **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 603, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
attempting to connect daemon...
success
starting...
refreshing...
ERROR:dbus.proxies:Introspect error on :1.3:/org/wicd/daemon: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Traceback (most recent call last):
  File "./gui.py", line 956, in <module>
    app = appGui()
  File "./gui.py", line 695, in __init__
    self.refresh_networks(fresh=False)
  File "./gui.py", line 855, in refresh_networks
    if wired.CheckPluggedIn() or wired.GetAlwaysShowWiredInterface():
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 64, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 136, in __call__
    **keywords)
  File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 603, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Traceback (most recent call last):
  File "/usr/lib/wicd/tray.py", line 7, in <module>
    import edgy
  File "/usr/lib/wicd/edgy.py", line 214, in <module>
    gtk.main()
KeyboardInterrupt
[thayer@dublin ~]$

schivmeister · 2007-11-21 07:55:01

I've worked around this issue by restarting the dbus daemon. Somehow the socket needs a refresh, or it can't connect; I'm blank on the details really. I'd patched my own build with a restart of dbus included in the rc script & many other changes to make things simpler, but it didn't reach the AUR package due to time constraints before it got adopted by the official repos. I will contact varun (maintainer) on this matter and hopefully he will do something about it.

As for the gui, only one click is needed. If you double-click, it won't appear For DHCP i presume you had pulled in dhcclient/dhcpcd, but sometimes configuring the IP takes a long time? This may be a DNS issue, and I suggest you try opendns.

But first, Network daemon should be enabled before wicd, the interfaces must not be disabled either. Also, 1.3.4 is definitely better than 1.3.1

slemKaffe · 2007-11-21 12:35:18

schivmeister wrote:

But first, Network daemon should be enabled before wicd, the interfaces must not be disabled either. Also, 1.3.4 is definitely better than 1.3.1

In the example in the wiki they are in oposite order.
http://wiki.archlinux.org/index.php/Wicd

Last edited by slemKaffe (2007-11-21 12:35:30)

schivmeister · 2007-11-21 13:58:36

Hmm that's tricky..I say that according to my experience. Try this with wired first, set it as default connection, whether DHCP or static it doesn't matter I think, but i can only test this w/ static at home as I'm connected to a server:

1) stop network daemon
2) restart dbus daemon
3) start wicd daemon
4) Run wicd

Now, stop network daemon. If it stops, it means starting wicd had started it too (& if this is the case, i don't think there is a need to place network as a daemon to start at boot). If it fails, try to ping an external address. If that goes well, then this means network daemon isn't needed as wicd probably takes care of the basic networking functionality of Linux. In my case however, network is started once wicd tries to connect.

Now for wireless, it's strange. When I use the kernel driver for my bcm chip, network needs to start before it can be activated. However, when I use ndiswrapper, it activates when ndiswrapper is loaded. So try the above method, this time with a wireless profile. I'm not too sure about the relation between the network script & wicd (it may very well be a front-end to the basics), so someone qualified would have to provide his/her input. Threadstarter should carry out these tests to see if it does solve the problem.

thayer · 2007-11-21 15:56:10

Thanks you two for the advice, I've had some limited success with your tips...

schivmeister wrote:

As for the gui, only one click is needed. If you double-click, it won't appear For DHCP i presume you had pulled in dhcclient/dhcpcd, but sometimes configuring the IP takes a long time? This may be a DNS issue, and I suggest you try opendns.
But first, Network daemon should be enabled before wicd, the interfaces must not be disabled either. Also, 1.3.4 is definitely better than 1.3.1

The funny thing is, I already use opendns at the router level. You are correct that dhclient and dhcpcd was already installed and for the record I tried both clicking and running the gui in standalone mode.

Reversing the order of wicd and network in the daemons array appears to be what fixed the bigger issues. Uncommenting the interfaces might have helped too, but I'm going to try removing the wlan0 device because currently Arch hangs during boot while trying to find wlan0.

So anyway, I rebooted with these changes and was happy to see my wireless had connected flawlessly. However, I normally use the wired connection when I'm sitting in my office and when I tried to connect to it, it just defaults back to the wireless after a few seconds. I created a profile as directed, so it must be something else going on.

At any rate, I've got SOMETHING working with wicd, so thanks again...

UPDATE1:

I disabled (!) wlan0 from the interfaces array and Wicd still picks it up okay, so at least the network daemon doesn't hang at boot while trying to associate with wlan0.

Last edited by thayer (2007-11-21 16:23:29)

schivmeister · 2007-11-21 17:35:34

No problem mate. An ammendment there, wicd just needs dhclient as that's what it contains in its code. I thought since both are clients either will work

Disabling interfaces & network daemon is only needed for networkmanager, if i'm not wrong. So the next wisest thing to do is revert to how it was before networkmanager (if u at anytime had it installed & running). network will try to scan & connect to what is defined in /etc/conf.d/wireless, & I myself roam a lot so that's not a good idea if it can't connect (takes a long time). I'm sure it can be solved by editing some lines in /etc/rc.d/network Have you tried to set the wired as default when in office? Do that & see if it still reverts.

@update: wow, i think that just confirms wicd being independent of any Arch configuration files, including rc.conf! I'm getting the hint it may just be like networkmanager in that you can (not must) disable network & the interfaces. Once you get back to your office, ensure you're able to ping a local address. If you can't, you know there needs to be more messing around with configuration of eth* both in rc.conf & wicd.

Last edited by schivmeister (2007-11-21 17:39:18)

Arch Linux

#1 2007-11-20 19:07:25

Wicd woes...Intel 3945...assistance requested

#2 2007-11-21 07:55:01

Re: Wicd woes...Intel 3945...assistance requested

#3 2007-11-21 12:35:18

Re: Wicd woes...Intel 3945...assistance requested

#4 2007-11-21 13:58:36

Re: Wicd woes...Intel 3945...assistance requested

#5 2007-11-21 15:56:10

Re: Wicd woes...Intel 3945...assistance requested

#6 2007-11-21 17:35:34

Re: Wicd woes...Intel 3945...assistance requested

Board footer