 |
WiFi Radar |
| version 1.9.8 |
| About WiFi Radar |
WiFi Radar is a utility for managing, scanning, and auto-connecting to WiFi profiles.
It enables you to scan for available networks and create profiles for your preferred networks. At boot time, running WiFi Radar will automatically scan for an available preferred network and connect to it.
You can drag and drop your preferred networks to arrange the profile priority.
Requirements
This application requires GTK+ version 2.4.x.
Other dependencies include:
Python, PyGTK2
|
| Latest Version: 1.9.8 |
------------------------------------------------------------------------
r94 | finley | 2007-02-08 09:32:09 -0600 (Thu, 08 Feb 2007) | 2 lines
* Add comments on usage within Debian/Ubuntu based distros.
------------------------------------------------------------------------
r93 | finley | 2007-01-11 09:35:29 -0600 (Thu, 11 Jan 2007) | 8 lines
* Remove changelog from svn. Instead, use "svn log" to create changelog
when doing a "make tarball". Let's make sure our commit messages are
useful. ;-)
* Do an "svn up" (with a warning) prior to making a release tarball, to
ensure that we're working with the most recent updates to the desired
code branch.
* Update VERSION to 1.9.8. Ready for release, I believe.
------------------------------------------------------------------------
r92 | finley | 2007-01-11 09:21:29 -0600 (Thu, 11 Jan 2007) | 3 lines
Fix daemon mode (-d) with regard to threading. Thanks to David
Decotigny for the suggested fix.
------------------------------------------------------------------------
r91 | finley | 2007-01-08 10:12:25 -0600 (Mon, 08 Jan 2007) | 1 line
update todo
------------------------------------------------------------------------
r90 | finley | 2007-01-08 10:09:38 -0600 (Mon, 08 Jan 2007) | 1 line
More debug output.
------------------------------------------------------------------------
r89 | finley | 2007-01-01 11:47:42 -0600 (Mon, 01 Jan 2007) | 1 line
------------------------------------------------------------------------
r88 | finley | 2006-12-12 11:10:31 -0600 (Tue, 12 Dec 2006) | 1 line
------------------------------------------------------------------------
r87 | finley | 2006-12-12 10:40:49 -0600 (Tue, 12 Dec 2006) | 1 line
gtk.threads_* is deprecated (python told me so). change to gtk.gdk.threads_*
------------------------------------------------------------------------
r86 | finley | 2006-12-12 10:37:11 -0600 (Tue, 12 Dec 2006) | 7 lines
* Include interface name with dhcpcd kill command.
* This fixes an issue where an attempt to disconnect fails to kill
off the dhcpd daemon. Subsequent attempts to connect cause an
immediate failure because the first instantiation of the daemon is
still running. It now behaves as desired and expected.
------------------------------------------------------------------------
r85 | finley | 2006-12-12 10:22:02 -0600 (Tue, 12 Dec 2006) | 1 line
------------------------------------------------------------------------
r84 | finley | 2006-12-12 10:20:19 -0600 (Tue, 12 Dec 2006) | 51 lines
Patch by David. Comments below:
---
Hi,
I have a Dell D620 equipped with an IPW3945. When I clicked "connect" in
wifi-radar, it always refused to... connect. I noticed that, strangely,
if I executed by hand the exact same commands that wifi-radar executes,
it worked. So I tried to disable the iwlist scanning while the dhclient
is running and... now it works perfectly.
Attached is the patch, in 2 flavors: one against the current svn (83),
the other against edgy's current wifi-radar. You should easily guess
which is which from their name. I Cc to Patrick, he might also be
interested for Debian.
Basically, what this patch does is take the lock during the dhclient
invocation, the scanning thread is then blocked, preventing it from
issueing iwlist commands in the meantime.
However, the fix does not imply a simple acquire/release around the
dhclient invocation... I had to change the global locking model
slightly, to make use of a recursive lock instead of a simple one. This,
BTW, must have been needed for some time already, because some functions
are sometimes called while the lock is already taken, and some other
time they have to take it by themselves. I saw some "if not
locked.locked(): lock.acquire()" to solve this, but this is the wrong
way to go... because we should also ensure that in case the lock is
already taken, it was actually taken by the CURRENT thread, not by
someone else (otherwise... this is not a lock anymore). That is exactly
the job of the recursive locks.
Instead of implementing yet another recursive lock class, I used
threading.RLock. This is why I changed the thread package used: now we
use "threading" instead of "thread", and the thread-starting procedure
for scanning_thread has been updated accordingly.
Hope this might help some people. Note : I am not sure I tested all the
execution paths where "lock" might be None (eg I did not launch
wifi-radar as a daemon). For these cases, a simple "if (None != lock):"
before the lock.acquire()/lock.release() should be added. But, looking
quickly at the patch, anytime there was a "try:" before lock.acquire(),
there is now a "if (None != lock):", so this should be all right.
Thank you for wifi-radar, it is of *great* use (I'll have to change my
"iwlist scan" habit now ;). Best regards,
- --
David Decotigny -- http://decotigny.fr
Fingerprint: 54A6 7EC5 868D 98C8 8C8C 1BD1 95DE EF86 EB15 AC21
------------------------------------------------------------------------
r83 | jhurst | 2006-11-13 22:12:59 -0600 (Mon, 13 Nov 2006) | 6 lines
When an unconfigured network is selected, clicking on the 'Configure' button creates a new profile for that network, but does not connect to it afterwards.
Fixed WPA_SUPPLICANT_ARGS weirdness.
Updated Joey Hurst's email address in the credits.
------------------------------------------------------------------------
r82 | finley | 2006-10-30 09:16:06 -0600 (Mon, 30 Oct 2006) | 1 line
* Don't use explicit path to binary, since we're specifying a PATH variable.
------------------------------------------------------------------------
r81 | finley | 2006-10-17 14:37:31 -0500 (Tue, 17 Oct 2006) | 1 line
updated CREDITS
------------------------------------------------------------------------
r80 | finley | 2006-10-17 13:06:10 -0500 (Tue, 17 Oct 2006) | 1 line
Fixed SEE ALSO; updated CREDITS
------------------------------------------------------------------------
r79 | jhurst | 2006-10-16 01:08:00 -0500 (Mon, 16 Oct 2006) | 18 lines
Added some features from TODO:
- Center 'connected to X' text below network listing
- Set LC_MESSAGES=C in environment when wifi-radar is started, rather
than prefixing commands with this variable.
- auto-detect wireless interfaces if no interface specified, or if
specified interface is not wifi capable, and offer to set it
- have drop-down box for selecting from available wifi devices, and
remember last one selected (write to conf)
- Add a preferences dialog so there won't be a need to edit
wifi-radar.conf by hand.
Regarding the "auto-detecting wireless devices", I set it up so that, by
default, the network device setting in wifi_radar and wifi-radar.conf
are set to "auto_detect". This indicates that wifi-radar should select
the first wireless enabled network device it detects.
Joey Hurst
------------------------------------------------------------------------
r78 | finley | 2006-10-15 22:07:47 -0500 (Sun, 15 Oct 2006) | 1 line
Just testing post-commit hook.
------------------------------------------------------------------------
r77 | finley | 2006-10-15 22:06:19 -0500 (Sun, 15 Oct 2006) | 1 line
Just testing post-commit hook.
------------------------------------------------------------------------
r76 | finley | 2006-09-28 09:51:28 -0500 (Thu, 28 Sep 2006) | 1 line
* Update homepage URL
|
|
|
Report a Bug
Listed at 
