Brainstorm session :) - WiFi near

[Calvin]

Hi all,

every now and then the FAQ "Why does it take my Wifi Near state so
long to exit? comes along.
Most of the time as a question if it's a bug because new users
experience it as such.

From a developer/tweaker point of view the explanation from the FAQ-
page is clear and we kinda leave it at that.
But from a user point of view, it is a bit strange.

Example use:
- WiFi Near: WiFi On, Data Off
You want to connect WiFi at home/work and disable WiFi and enable Data
when not at home.

(Assuming default of 600 seconds for Display Off Timing)
When you enter home: it takes max 10 minutes to connect WiFi (When it
scans and the WiFi is near - done)
and you still have the Data connection in the mean time. No problems
whatsoever.
When you leave home: it takes max 20 minutes to disable WiFi
during this time you have no data connection.
For any user this feels strange the first time you experience this.
After all, "the connection to my WiFi is gone, why doesn't tasker see
that?"

I understand the idea behind it "avoid the context activating and
deactivating if the AP is briefly not visible".
But still, there has to be a better way IMHO.

Now the reason for this tread.... what would be a good 'solution' for
this?
Two ideas I can come up with:
- make it possible to manually force a re-check of WiFi near with
Tasker
- for WiFi near decrease the 2nd check period to 1 minute (or
something like that). So if currently "WiFi near" is active and AP not
visible: scan again in one minute instead of 10.


Any other creative ideas?

[UncleMike]

Along the lines of your idea, I would suggest that a Wifi scan
triggered by the "Display Off Timings", which fails to find the Wifi
signal for an active context, be followed by another Wifi scan at the
"Display On Timings" interval.

That said, the behavior of my Droid is that if Wifi is on and
connected to a network, mobile data is automatically disabled (who
needs two simultaneous data connections?), and when the Wifi
conneciton is lost (even if Wifi remains on), mobile data comes back
on automatically fairly quickly. Given this behavior, I see no need
to turn mobile data off in conjunction with turning Wifi on. I
thought this was normal Android behavior, but my Droid is the only
Android phone I've ever used, so I could easily be mistaken.

[Calvin]

You're right. In theory my HTC Desire does the same :)
I should retry this default behavior.
In Eclair I had some problems with it, ending in no longer being able
to connect mobile data after a while. Maybe Froyo fixed this...

besides that, your idea sounds like a good addition!
So far that has my vote... anybody else?

[short/y]

My Nexus One on Froyo (CM6 nightly) behaves the same way that
UncleMike describes. Worked that way on 2.1 and 1.6 and 1.5, too.

I don't know why WiFi is so important to me ... I fear I'm dancing a
one-note samba here in these forums. I suppose it's because something
like WiFi Near would be so dang useful if it didn't interrupt my
normal data connection to do the scan. Since you two have already
chimed in on WiFi, would you care to comment on how WiFi Near scanning
works for you? Maybe I'm the only one in these forums who's having
problems with it?
--
Tony

[UncleMike]

You're not the only one having the problem. In my case, I'm just not
doing anything that can't easily pick up where it left off. If I
recall correctly, in your situation a dropped connection causes you to
have to restart the session (or something to that effect).

According to a post here by Pent, in the latest beta Wifi should not
connect when scanning (at least that's how I interpreted what he
said). Unfortunately, the behavior on my Droid hasn't changed, and it
still connects when Wifi is turned on for scanning. I actually had a
profile that took advantage of this behavior; if Wifi came on and
happened to connect, it would remain on. But I think scanning without
connecting is a more desirable behavior.

[short/y]

That's pretty much the gist of my problem: depending on which app I'm
using I may or may not be able to pick up where I left off. But I'm
glad to head I'm not alone!

As far as Pent's remark, well, I interpreted it several different
ways. My first interpretation was that it was in the beta then, based
on some correction from a couple of people (Pent himself) I took it to
mean that it was in Tasker PRIOR to the beta. So, the long and short
of it is this: I'm not sure :) And I haven't had the wherewithall to
install the beta because I doubt that I'll be able to contribute
anything to the beta discussion since I'm still not really using
Tasker for too much besides changing my volumes at a particular time
of day and I think pretty much everyone else has got at least one
profile that does that. The rest of the changes are interesting but
aren't things that I can make use of (yet).
--
Tony

[SHADOW-XIII]

I am opting for timeout, repeats amount and scan frequncies per-task/
context instead of one setting for application.
Therefore settings up WiFi near would have 3 extra ticks (default off
like "If"):
- Custom timeout
- Custom "Scan every ..."
- Custom "Exit after X tries"
Selecting any tick box will show box to enter some data (seconds/
number)

[Calvin]

Good thinking, but I guess this would make it a lot harder to
understand for the average user.
I'd still go for UncleMike's idea..

[Calvin]

Did a few tests here.

Profile: Wifi Near (Toggle Wifi On)
Task: Wifi On
Responds to (example) SSIDHome

How I can NOT replicate your problem.
- I turn off the Wifi at home (so SSIDHome is not available)
- I start browsing using 3G
- no breaks in the connection, works perfectly

How I CAN replicate it (I think)
- Wifi network at home turned on (SSIDHome is available)
- I turn off Wifi /manually/ (using Android Power Control widget)
- I start browsing using 3G
- I can see the connection is dropped (every 2 mins probably), Wifi is
activated for a few seconds and after that 3G re-connects.

Just to make sure I also checked it with a different task for the same
profile, one that just showed a notification.
Same result.

So, the reason why I had never seen this problem is that I connect the
Wifi I'm searching for. So, as soon as it's found it connects. Thereby
avoiding the problem. My guess is that most people use Wifi near to
detect when to turn on Wifi and connect to that network.

If you are using a 3G data connection and you're near a network you're
searching for without connecting it (leaving wifi off)... your problem
is easy to reproduce.

This is what I can find here after a short test.

Does this in any way look familiar to you?

[Pent]

> According to a post here by Pent, in the latest beta Wifi should not
> connect when scanning (at least that's how I interpreted what he
> said).

Sorry I should've been clearer there.

It's been requesting 'just scan don't connect' for a fair few months
now.

Original point of thread: I guess it makes a lot of sense to run a
shorter
cycle when an active context depends on an AP that just went AWOL.
I'll put it on todo.

Boy I'm swamped ATM.

Pent

[UncleMike]

I can remember when you were worried that the beta testers would be
your only paying customers. It seems things have gone to the other
extreme. :)

[Calvin]

Thanks!

Keep up the good work!
I'm not trying to push you BTW, just trying to help you out with ideas
and reproducing of bugs.

[short/y]

Thanks for that, Calvin. I think that explains it -- I *don't* want to
connect so let WiFi toggle

And thank YOU, Pent, for that clarification. I guess I'm up against
either an Android bug or a Cyanogenmod ROM bug. I'll go check out the
respective bug trackers and see what I can find.
--
Tony

[Krac]

If you never connect to that Wifi, you shouldn't have a problem. Make
your phone "forget" the details, and it won't connect when it starts
up. If it is aware of it, it will connect. It's WAD (working as
designed.)

So your only solution is to forget that network, and never connect to
it. Then it will "see" it, but not connect to it.

[short/y]

No, I don't think it's WAD, at least not at the Android framework
layer. WIFI_MODE_SCAN_ONLY isn't described all that clearly in the
docs so it's open to interpretation. Until I find the time to get into
the code and see what it's really supposed to do, I'm hoping that it's
a bug.

I connect to my work WiFi but very infrequently. I've considered
saving a copy of my wpa_supplicant.conf and restoring it when I want
to connect and may go that route but I still have the problem here at
home. I have good 3G connectivity and speeds here so I only connect
when I want to control one of my other devices or grab some music from
my server. It's a couple times each week and I used to have to reboot
my phone every time I changed the config by moving files around (I've
got a 36 character random string for my WiFi key so it's not easy to
re-enter). Still, that may be the route I end up going.

[Dave Fisher]

Short/y <tsu...@gmail.com> wrote :

> No, I don't think it's WAD, at least not at the Android framework
> layer. WIFI_MODE_SCAN_ONLY isn't described all that clearly in the
> docs so it's open to interpretation. Until I find the time to get into
> the code and see what it's really supposed to do, I'm hoping that it's
> a bug.

Tasker maybe enabling WiFi in scan mode, ie. Tasker does not initiate a connection to a specific WiFi AP, but is Andoird itself connecting as soon as WiFi is enabled, if you see what I mean ?

For example, you have 2 APs, HOME1 and HOME2. HOME1 is known to the Android OS, and remembered. HOME2 isn't.

When Tasker enables WiFi to look for HOME2, it finds it, but doesn't connect as it was opened in scan only mode. But when the WiFi stack is enabled by Tasker, the OS notices HOME1 so connects to it.

Equally if you just have one AP called HOME, Tasker scans for HOME with no intention of connecting, but in the meantime the OS has connected.

I guess the only way to test that is to make the OS forget about all APs and see if it still does it.

Just a thought anyway!

--
Best Regards,
Dave Fisher

[short/y]

Yes, I think I understand your point. But I think (or maybe more
appropriately, I *hope*) that Android itself just hasn't implemented
WIFI_MODE_SCAN_ONLY correctly. See, it just doesn't make logical sense
to me to have a scan only mode if it's just going to go ahead and
connect. Again, though, I may be misinterpreting the Android docs on
this, which is why I need to get into the code.
--
Tony

On Aug 17, 8:11 am, Dave Fisher <d...@the-darkside.co.uk> wrote:
> Short/y <tsum...@gmail.com> wrote :

[short/y]

I found some decent documentation on what WIFI_MODE_SCAN_ONLY is
supposed to do from
http://www.kiwidoc.com/java/l/x/android/android/5/p/android.net.wifi/c/WifiManager


WIFI_MODE_SCAN_ONLY
public static final int WIFI_MODE_SCAN_ONLY = 2
In this Wi-Fi lock mode, Wi-Fi will be kept active, but the only
operation that will be supported is initiation of scans, and the
subsequent reporting of scan results. No attempts will be made to
automatically connect to remembered access points, nor will periodic
scans be automatically performed looking for remembered access points.
Scans must be explicitly requested by an application in this mode.

So, to me it *looks* like scan only mode should NOT connect. Now, I
have to dig a little deeper and look at the code itself.
--
Tony

[UncleMike]

This same info is also available here:

http://developer.android.com/reference/android/net/wifi/WifiManager.html#WIFI_MODE_SCAN_ONLY

I mention this only because (to my untrained eye) the source appears
to be more authoritative.

On Aug 18, 6:18 pm, "short/y" <tsum...@gmail.com> wrote:

> I found some decent documentation on what WIFI_MODE_SCAN_ONLY is

> supposed to do fromhttp://www.kiwidoc.com/java/l/x/android/android/5/p/android.net.wifi/...

[short/y]

Yeah, thanks, UncleMike, I appreciate it. I found it in several places
and grabbed the wrong URL. Right information, same information, but
from developer.android.com it's more official.
--
Tony

On Aug 18, 3:44 pm, UncleMike <njcable...@gmail.com> wrote:
> This same info is also available here:
>

> http://developer.android.com/reference/android/net/wifi/WifiManager.h...

[TomL]

I know this is a super old thread, but in case anyone is interested, I can reliably use Tasker on a rooted phone to forget all defined AP definitions by swapping in different /data/misc/wifi/wpa_supplicant.conf files (make sure you preserve the user/group ownership and permissions of the original file) and then issuing this shell command:

kill -HIP pid

... where pid is the process id of the wpa_supplicant process in order to force the wifi service to reread the conf file.

I mainly do it so that I can enable the wifi radio for better geolocation when I know I'm outside of the range of any of my known APs.

Tom