wifi-radar daemon (-d) ends

Bug #64051 reported by أحمد المحمودي (Ahmed El-Mahmoudy)
4
This bug affects 1 person
Affects Status Importance Assigned to Milestone
wifi-radar (Ubuntu)
Confirmed
Wishlist
Unassigned

Bug Description

The systems starts wifi-radar daemon from /etc/init.d/wifi-radar , but it shortly ends. Don't understand why. It didn't do so in Dapper.
Note: I am running on Edgy.
I also got whereami, ifplugd & waproamd running.

Revision history for this message
Ante Karamatić (ivoks) wrote :

Does wifi-radar starts if you run it like client?

Changed in wifi-radar:
importance: Undecided → Medium
status: Unconfirmed → Needs Info
Revision history for this message
أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy) wrote :

Yes, running "sudo wifi-radar" does start wifi-radar, and it doesn't end like the daemon does.

Revision history for this message
Ante Karamatić (ivoks) wrote :

Well, does wifi-radar -d starts dhclient and creates a connection?

Revision history for this message
أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy) wrote :

I tried it once in existance of AP. It reported that it found the AP, and reported an error about running dhclient, and then it ends.

When an AP does NOT exist, it also ends after a very short period.

Revision history for this message
أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy) wrote :

Here are some logs:
no-ap: is in the absence of AP.
ap: is in the presence of an AP. (note that the essid of the AP is "AP_ESSID")

The wifi interface is eth1.

In both cases dhclient is not running (I mean after the wifi-radar stopped, dhclient is not running). But I noticed that dhcdbd is running. Not sure what that is.
In both cases, I don't see the IP of eth1 being set. It should be set when the interface sees the AP.

Revision history for this message
أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy) wrote :
Revision history for this message
Ante Karamatić (ivoks) wrote :

Your network card doesn't support scaning? What card is that? If your card doesn't support scaning, wifi-radar can't autodetect which AP is available.

Revision history for this message
أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy) wrote :

My network card is ipw2200, it does support scanning, because when I enter this command: iwlist eth1 scan, I get a list of APs that are found. Besides, if I run the GUI, it does show me the APs that are available in the area, and signal strength of them.

Revision history for this message
Ante Karamatić (ivoks) wrote :

Please attach your /etc/wifi-radar.conf. I just noticed that your logs don't show eth1 (I guess eth0 is wired interface). syslog would be nice also, when wifi-radar fails to connect to AP. This:

down: error fetching interface information: Device not found
SIOCSIFNETMASK: No such device
SIOCADDRT: Network is unreachable

looks like problems with driver or configuration.

Revision history for this message
أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy) wrote :

Yes, eth0 is wired interface.
I just found that there is an paramater called "interface" in wifi-radar.conf, I set it to eth1 and tried wifi-radar -d, and same thing it also ends, the only difference is that it doesn't give any messages about lo,sit0,eth0 interfaces being not wireless interfaces. ie. setting that parameter makes wifi-radar not try to probe other interfaces for wireless extensions.

Revision history for this message
أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy) wrote :
Revision history for this message
أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy) wrote :

There's nothing in /var/log/messages regarding wireless when I run wifi-radar.

I don't think that there is a problem with driver because I can configure it manually.

Revision history for this message
أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy) wrote :

I tried today to run : sudo wifi-radar -d
AFTER the wifi connection is established manually (ie. I set the ESSID & key of the AP using iwconfig, and configured the andIP addresses using ifconfig & route), so I got this:

dhclient3 --version 2>&1
Error for wireless request "Set Frequency" (8B04) :
SET failed on device eth1 ; Invalid argument.

and I found this in dmesg:
[17181655.212000] eth1: no IPv6 routers present

Revision history for this message
أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy) wrote :

I removed those lines:
mode = Managed
security = restricted

Now I don't get any errors when running "wifi-radar -d", except for that it does end, which makes me wonder: is "wifi-radar -d" designed to end after the "scan_timeout" period ?

Revision history for this message
Ante Karamatić (ivoks) wrote : Re: [Bug 64051] Re: wifi-radar daemon (-d) ends

U Sub, 14. {$Month}. 2006., u 19:39 +0000, Ahmed El-Mahmoudy je
napisao/la:

> Now I don't get any errors when running "wifi-radar -d", except for that
> it does end, which makes me wonder: is "wifi-radar -d" designed to end
> after the "scan_timeout" period ?

Yes, it ends after discovering wifi network(s) and successful end of
dhclient. If there is no know network, it will end very fast. It's not
'classic' daemon where program stays in background and waits for change.

Revision history for this message
Juan Sebastián Echeverry (sebaxtian) wrote :

I have had similar problems, but I solved it when I identified the interface in wifi-radar.conf. I put interface = eth1 and it works again.

Revision history for this message
Ante Karamatić (ivoks) wrote :

Is this still an issue?

Revision history for this message
أحمد المحمودي (Ahmed El-Mahmoudy) (aelmahmoudy) wrote :

> Yes, it ends after discovering wifi network(s) and successful end of
> dhclient. If there is no know network, it will end very fast. It's not
> 'classic' daemon where program stays in background and waits for change.

Well, I think this means that this is how wifi-radar was designed to work, ie.
it is not a bug.

So either this could be some sort of feature request or maybe there are other
utilities in Ubuntu that can do the job (whereami/waproamd for example).

Ante Karamatić (ivoks)
Changed in wifi-radar:
importance: Medium → Wishlist
status: Needs Info → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.