Comment 1 Eric Warnke (reporter) 2008-07-04 16:36:14 UTC

WPA network is TTLS/MSCHAPv2 ( Cisco )

Comment 2 Kalle Valo 2008-07-05 09:26:37 UTC

This is a feature. WPA-Enterprise networks are excluded from automatic
connections because with some configurations user action might be required.

Comment 3 Eric Warnke (reporter) 2008-07-05 14:01:42 UTC

With that line of thinking *any* network might require user interaction.  Why
not base this decision on if the user has saved the credentials or not?  If the
user is required to interact, why save the password at all?

This is a horrible inconsistency with the rest of the system and I have wasted
hours trying to get this to work.  Either this inconsistency should be removed
or there should be some feedback to the user when saving the network.

Comment 4 Kalle Valo 2008-07-06 08:53:54 UTC

(In reply to comment #3)
> With that line of thinking *any* network might require user interaction.

Nope, not all connections need input from the user. For example, a saved
WPA-PSK connection will not need to ask anything from the user. But, for
example, EAP-PEAP with EAP-GTC will need to ask input from the user before the
connection is established.

>  Why not base this decision on if the user has saved the credentials or not?

I don't remember the details behind the decision, but I'm quite sure that the
lack of time for the implemantion was a major reason, as usual :)

> If the user is required to interact, why save the password at all?

Good question. 

> This is a horrible inconsistency with the rest of the system and I have wasted
> hours trying to get this to work.

I'm sorry to hear that. I agree with you that this is a really annoying
feature.

> Either this inconsistency should be removed
> or there should be some feedback to the user when saving the network.

Yes, some feedback should be definitely shown. Better yet, the EAP connections
which have saved credentials should be used as candidates for automatic
connections. 

I'll forward this bug report to the relevant people. Let's hope for the best.

Comment 5 Andre Klapper 2008-07-07 16:53:39 UTC

Kalle, have you internally forwarded this as a feature request (I assume), or
do you consider this as a bug so there is an internal report number to track
(please only post the number, not the URL)?

Comment 6 Kalle Valo 2008-07-08 09:36:45 UTC

(In reply to comment #5)
> Kalle, have you internally forwarded this as a feature request (I assume), or
> do you consider this as a bug so there is an internal report number to track
> (please only post the number, not the URL)?

I forwarded this as a feature request.

Comment 7 Ryan Abel 2008-07-14 05:34:17 UTC

*** Bug 3448 has been marked as a duplicate of this bug. ***

Also, we get the error "Saved connections not found" followed by the list of
saved connections that were found.

I consider this a bug, not a feature request. It looks like the thing's
supposed to automatically connect to wifi when needed, using one of the
previously set up networks, which is pretty slick... except for this
inconsistency where it doesn't connect to certain networks automatically even
though it can.

Or, to put it another way, I've been using my N800 for a month now, frowning
every time I have to manually connect to my work network while it connects just
fine everywhere else. If it's not a bug operationally, then it's certainly a
bug in terms of usability.

Comment 9 Alan Bruce 2009-09-30 23:05:47 UTC

This bug remains open in Fremantle.

Comment 10 Jukka Rissanen 2009-10-19 10:08:53 UTC

This bug is basically the same as bug #2503
Perhaps #2503 could be marked as duplicate as this one has better comments.

Comment 11 Andre Klapper 2009-10-19 12:13:17 UTC

*** Bug 2503 has been marked as a duplicate of this bug. ***

Bug still exists with the release firmware for the N900. It is very annoying to
have to keep manually reconnecting when moving around campus on a WPA EAP
MSCHAPv2 network even though all the credentials are already saved.

Comment 13 Andre Klapper 2009-12-08 16:22:54 UTC

Yes, that's why it is "NEW" instead of "FIXED". No real need for comments in
this case. :-)

*** Bug 6779 has been marked as a duplicate of this bug. ***

Please fix this!

The handset won't autoconnect to networks with saved credentials, which require
no user interaction.  Perhaps a reasonable solution is to have a per-network
checkbox for "automatically connect to this network"?  That's how desktops
work.

Please fix ... I only use WPA-Enterprise setups besides my GPRS connection. So
the auto connect feature is basically worthless at the moment.

Comment 17 Andre Klapper 2010-01-06 13:06:16 UTC

Please do not add "Please fix" or "me too" comments, instead just vote. Thanks.

Why it is marked like enhancement?

If wifi completely useless it is BUG!!!!
If i connect to our wifi i usually disconnected from it in 2-3 min...
How many times per day should i manually reconnect for BUG and for Enhancement?
I think enhancement - 1-3 times per day.
Bug more than 10 (in my case 160 times for 8 working ours)...

Comment 19 Andre Klapper 2010-01-06 17:45:13 UTC

(In reply to comment #18)
> Why it is marked like enhancement?
> If wifi completely useless it is BUG!!!!

Please read the bug report before adding non-helpful comments.
Comment 2 explains why this currently is severity "enhancement".
Also, your exclamation mark key seems to be broken. Thanks.

You misunderstand, Andre.

Comment #2 explains why Kalle Valo considers this to be a feature, but it's
perfectly reasonable to comment explaining why Kalle Valo is wrong.

For Max this "feature" makes wifi unusable. That's a pretty strong argument as
to why this is a bug and not an enhancement request... in short, it means that
this "feature" needs to be reconsidered and done a different way.

As Kalle said in a following comment, this "feature" was implemented this way
because of lack of resources for a proper solution. That just screams bug.

Is it really such a terrible thing to mark one more bug in the system when it
leads to such broken user experience?

Comment 21 Kalle Valo 2010-01-07 09:30:16 UTC

(In reply to comment #20)
> Comment #2 explains why Kalle Valo considers this to be a feature, but it's
> perfectly reasonable to comment explaining why Kalle Valo is wrong.

Just to make it clear because my name seems to come up:

I was just the messenger here, I wasn't involved with the decision of not to
implement this feature (or "fix this bug", whichever is preferred). So it's
useless to blame me here.

No blame intended, Kalle.

The point was, "comment number two" is not some sort of proclamation from
on-high that's unquestionable. It was an opinion of a person or some people,
and additional comments can rightfully challenge it, as max did and I would.
There's nothing mean or personal in that, it's just the discussion that these
bug trackers are supposed to allow.

We feel that labeling this as an enhancement request shortchanges the
seriousness of the problem (it's one major reason I retired my N800), and
referring to "comment number two" adds an additional slap in the face in a way.

Such basic functionality should exist in a phone like the n900. Without it, the
wifi is severely impaired.

All those who are reading this, make sure you sign up and vote. It won't get
fixed otherwise!

(In reply to comment #2)
> This is a feature. WPA-Enterprise networks are excluded from automatic
> connections because with some configurations user action might be required.

I have several non WPA-Enterprise networks in my list of IAPs that actually
*DO* require user interaction, so this argumentation is wrong. Just consider
the "insecure" campus network someone anonymous mentioned here as initial
comment #23 (unfortunately that comment got deleted or was lost during
bugtrack-server migration but it's still in my inbox), or e.g. one of the
insecure Hotspot providers - who else has a saved connection named "tmobile",
"attwifi" or similar?

All these have one thing in common ... the current framework considers them to
not need any user interaction, connects to them but they will actually prompt
the user for username/password on a website before enabling any communication.

Possible solution: See comment #15 - add a field [X] Automatically connect to
this network to every IAP.

The assumption that WPA-Enterprise networks always require user interaction and
that WPA-Personal, WEP or even unencrypted networks never require interaction
is just plain wrong.

My campus has a WPA TTLS/MSCHAPv2 network too. Besides providing a
username/password during the first login, no interaction is required to connect
to the network. Automatically assuming that _every_ WPA TTLS/MSCHAPv2 network
_ever_ will require user interaction to connect every time is just plain wrong. 

I got fed up with manually switching to the campus wifi every time I moved
access points that I gave up and just let my phone use the 3g.

Comment 26 Alan Bruce 2010-01-19 21:29:23 UTC

(Yes, my comment was lost during the server move. This is probably for the
best; I have a chance to write it again with a less confrontational approach)

When I come to work, my N900 drops my GPRS connection and silently and
automatically connects to the "insecure" campus network, which requires a web
page login, instead of the "secure" WPA Enterprise network, which requires no
interaction. The phone thinks it is connected, but it isn't really connected at
all.

As a result, the phone is effectively offline until I notice the problem and
manually switch to the correct network.

This behaviour was merely annoying on the N800, because there was no GPRS
networking capability. With the introduction of GPRS in Maemo 5, however, this
should be moved from "enhancement" to "bug" because it improperly causes the
phone to go offline in cases such as mine.

My current workaround is to not have the "insecure" network listed in my
connections, so that my phone will not attempt to connect to it. This isn't a
good permanent solution, however.

So any official comments on that reasoning? Maybe we should file another bug -
"No internet connectivity because phone silently drops cellular connection in
favor of authentication-needing hotspot"?

Michael and Alan, yes, I think you should file a new bug for that behavior.

This bug is mainly about WPA not autoconnecting even when it can, I think,
while you're describing a different bad behavior, dropping cell when it can't
connect to wifi.

Spent a couple of minutes hacking some code together that will force your
device to be connected to WPA-Enterprise networks, if available. I understand
this as a (binary only) proof of concept and it is way too ugly. Enjoy!

http://scriptkiller.de/en/a49/computer_electronics/maemo/icd_autoconnection_hack_(bug__3399)/

My N900 running 2009.51-1 attempts to connect to the corporate network via
MSCHAPv2, but it hangs waiting for me to dismiss a "Done" popup button whenever
I move from one access point to the next.  This makes Mail for Exchange
synchronization relatively useless.

To fully support automatic connections as suggested by this bug, it is also
necessary to reconnect without a user response to the message:

"Certificate not currently valid. Check date and time settings.
servername.example.net               [Done]"

as was reported here:

https://bugs.maemo.org/show_bug.cgi?id=2051#c33

I would be glad to supply detailed configuration information or diagnostic data
if needed.

(In reply to comment #30)
> To fully support automatic connections as suggested by this bug, it is also
> necessary to reconnect without a user response to the message:
> 
> "Certificate not currently valid. Check date and time settings.
> servername.example.net               [Done]"

God no. Silently ignoring bad certificates is definitely _NOT_ within your
interests, unless you don't really value your data. You should try to fix the
underlying cause for that error message instead (thus not the scope of this
bug).


As for this bug, I'd personally be happy with a gconf setting that
prevents/forces libicd-network-wlan to consider IAPs when autoconnecting.

(In reply to comment #31)
> 
> God no. Silently ignoring bad certificates is definitely _NOT_ within your
> interests, unless you don't really value your data. You should try to fix the
> underlying cause for that error message instead (thus not the scope of this
> bug).

That isn't what I am asking.  I just want it to stop displaying a spurious
error message when no certificate is required to reconnect to our Cisco
MSCHAPV2 network.  The quoted message is just another symptom that requires
even more frequent manual intervention in what should be an automated process,
which is the subject of this enhancement request.  The quoted dialog appears
whenever the N900 has a momentary signal loss or a handoff to another access
point and unless it is dismissed quickly, it puts the connection back into the
manual "off" state.

The only reason that I commented on this bug is because it is the more recent
of the two open bugs that mention this specific error message.  I would be glad
to open a new bug that is more specific and supply any requested information if
someone in development belives that it would be useful.

as with PR1.2 this is not 'featured' (sounds odd in this case) I was wondering
why it is "Severity: enhancement" after looking in here again. "It does not do
what is expected" keeps a bug flying around bulbs in my head. Any other device
I use is able to auto connect, Windows or Linux. It should check if in the
specific network setup user action is required and if not it should be able to
auto connect, or am I wrong? As other setups are able to auto connect this
should be filed as bug again and get a higher priority as this is an always
online device and system.

I agree. Maemo should at least give the user a true option whether or not they
want to autoconnect. The option is given, but doesn't follow through. Since
ttls/pap is being fixed in 1.2, this is still going to make walking around
campus (what you should be able to do with a phone) while being connected
totally unfeasible.

Who can we contact to get this fixed?

(In reply to comment #33)
> as with PR1.2 this is not 'featured' (sounds odd in this case) I was wondering
> why it is "Severity: enhancement" after looking in here again. "It does not do
> what is expected" keeps a bug flying around bulbs in my head. Any other device
> I use is able to auto connect, Windows or Linux. It should check if in the
> specific network setup user action is required and if not it should be able to
> auto connect, or am I wrong? As other setups are able to auto connect this
> should be filed as bug again and get a higher priority as this is an always
> online device and system.
>

Seems like no-one cares about this bug at all, sad story. Someone at Nokia
willing to leak the wlancond-sources?

Comment 36 Andre Klapper 2010-04-13 19:39:23 UTC

(In reply to comment #35)
> Someone at Nokia willing to leak the wlancond-sources?

Instead maybe willing to share the code of icd_autoconnection_hack_(bug__3399)
from your comment 29?

(In reply to comment #35)
> Seems like no-one cares about this bug at all, sad story. Someone at Nokia
> willing to leak the wlancond-sources?

Wlancond is open.

(In reply to comment #37)

Oh sorry .. I think I meant icd2, which should be source of this bug, but I'd
have to double-check later ..

(In reply to comment #38)
> (In reply to comment #37)
> 
> Oh sorry .. I think I meant icd2, which should be source of this bug, but I'd
> have to double-check later ..
> 
You mean libicd-network-wlan.

I developed an alternative that was more or less working on the N8x0
(libicd-network-wpa, http://libicd-wpa.garage.maemo.org/) but requires cleanup
to work on the N900 (and probably an entire new design while we're at it to try
and remove the dependency on a patched wlancond, which should be doable on the
N900) . I no longer have the need of it so development has greatly slowed...

N900 won't reconnect when on WPA enterprise wireless networks.

Also keeps refusing to accept certificate but if you transfer the certificate
on to the phone and install it, it doesn't complain any more...even if you
don't select it on the settings.

Since nothing is happening with this bug anyway, I might as well share the
following:

I long ago left my N800 behind, moving on to Android. Well, lately I've been
annoyed at my G1 and have been thinking about buying a N900 as soon as I can
afford it.

But seeing dtakias's report that this bug exists on the N900 as well, well, so
much for that idea. 

And yes, this is a bug since the software does not do what it says it's going
to do. That's not clumsy usability; that's a departure from software
specifications. Eric, if you're still watching, would you go ahead and set
severity to normal again?

Comment 42 Andre Klapper 2010-05-03 19:30:18 UTC

(In reply to comment #41)
> Eric, if you're still watching, would you go ahead and set
> severity to normal again?

No, as per comment 2.

(In reply to comment #42)
> (In reply to comment #41)
> > Eric, if you're still watching, would you go ahead and set
> > severity to normal again?
> 
> No, as per comment 2.

A workaround that introduces a bug is still a bug whether you call it a feature
or not.

This is absolutely a bug as the software doesn't do what it says it will do.

I would think it classifies as a bug. In my case it ate up a fair bit of my 3G
data plan, because I wasn't ware of this behaviour. I moved from WLAN at home
where the auto-connect works to the WLAN at work (WPA-Enterprise), assuming
that it would behave the same. I now know better but it caused me a loss of
quota.

Any chances of getting this one fixed? PR1.2 actually made the device way more
usable, but Wifi is still just unusable for me (and many others).

Comment 46 Andre Klapper 2010-05-27 16:26:14 UTC

Unlikely I'd say. (Feel free to contact Nokia Customer Care.)

>> This is a feature. WPA-Enterprise networks are excluded from automatic
>> connections because with some configurations user action might be required.

Then make a check box that says "no user interaction required"   (or call it
"connect automatically")...

Seriously, I was really hoping PR1.2 would have fixed this.  This missing
feature makes the phone a pain.  That some networks would behave different than
others.

At least put up a warning that "this connection isn't available for auto
connect".   Right now it's just frustrating...

It's not a feature, it's a bug.

And by the way ... is it SO painful to add an "automagically connect"-flag to
gconf? The GUI to set this option could be FOSS then.

Well, I got frustrated with always needing to connect manually, so I've written
a program to connect automatically, like comment #29, but using the new Qt
Mobility Bearer API.

It scans for networks periodically when there is no current connection. If the
requested network becomes available, it tries to connect.

Source here:
http://simon-butler.com/software/autoconnect.tar.gz

Simon,

Thank you immensely for the Qt code. It works wonderfully for me but I had one
tiny quibble. Your documentation says that the timer value should be entered in
units of seconds but I believe it is really in milliseconds. I tried entering:

.../autoconnect MySSID 60

and it would retry very rapidly while trying to connect and then seg fault.

As soon as I entered:

.../autoconnect MySSID 60000

It worked beautifully. My mistake was obvious when I examined the code but in
my initial rush to try it out, I didn't check too closely.

Thanks again!

*** Bug 11570 has been marked as a duplicate of this bug. ***

Created an attachment (id=3391) [details]
SHell script

I have modified the shell script by Flynx
(http://talk.maemo.org/showpost.php?p=967981&postcount=8) to make something
simple I can schedule via Alarmd during working hours. Takes a single parameter
of SSID but may not work if you have renamed the connection to be different
from the SSID.

This is just silly.

No, I won't just 'vote', but instead post this 'me too' comment. This is a bug,
for all the reasons stated previously. It is in the TOP 15 voted-for bugs and
Nokia classifies this as 'low enhancement'? Are you kidding me?

https://bugs.maemo.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&query_format=advanced&votes=50&order=votes%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_based_on=

Laughable as always. Good look with WP, at least you won't get any bug reports
like these anymore because nobody will even care to report bugs.

Comment 54 Andre Klapper 2011-10-25 15:31:38 UTC

(In reply to comment #53)
> No, I won't just 'vote', but instead post this 'me too' comment. This is a bug,
> for all the reasons stated previously. It is in the TOP 15 voted-for bugs and
> Nokia classifies this as 'low enhancement'? Are you kidding me?

Please read https://bugs.maemo.org/ to understand what this bugtracker is (and
what it is not), plus note that the Maemo 5 User Interface and Maemo 5 platform
components (e.g. libraries) are considered stable by Nokia. Only critical
issues have a chance of being addressed by Nokia.

Comment 55 Andre Klapper 2012-03-24 11:43:58 UTC

The Maemo 5 User Interface and Maemo 5 platform components (e.g. libraries)
used for the N900 are considered stable by Nokia and it seems that there are no
plans for official updates currently, hence nobody plans to work on this
enhancement/wishlist request. 
(And in case you feel like discussing this situation: Nokia Customer Care or
http://talk.maemo.org would be the place to do so as you will not reach Nokia
officials in this community bugtracker - though all of this is really no news.)

Reflecting this status by setting RESOLVED WONTFIX for this
enhancement/wishlist request (see
https://bugs.maemo.org/page.cgi?id=fields.html#status for status explanations).

There is a small chance for issues in those Maemo components that are open
source: Contributed patches could be included and made available in the Maemo 5
Community CSSU updates. 
The Maemo CSSU project is run by a small team of volunteers; see
http://wiki.maemo.org/CSSU for more information.
So in case that you can provide a patch that fixes the reported problem, please
feel encouraged to file a request under
https://bugs.maemo.org/enter_bug.cgi?product=Maemo%205%20Community%20SSU .
Please note: The Maemo CSSU project is not related in any way to Nokia.


( Tag for mass-deleting bugmail: [cleanup20120324] )