New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 137273 link

Starred by 7 users

Issue metadata

Status: Verified
Email to this user bounced
Closed: Aug 2012
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug-Regression

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Hidden network connection fails with spurious message

Project Member Reported by, Jun 7 2012

Issue description

Chrome Version     :  21.0.1166.0
OS Version         :  2404.0.0
Type of computer   :  x86
Network info       :  Hidden CrOS_WPA2_LinksysWRT54GL

Please specify Area-* of the system to which this bug/feature applies (add
the label below).

What steps will reproduce the problem?
1.On the login screen try connecting to a hidden network using the "Join WiFi Network" option in the ash tray(CrOS_WPA2_LinksysWRT54GL in logs)

What is the expected output?
On proving the correct passphrase connection should succeed

What do you see instead?
The first connection attempt always fails with "Incorrect passphrase" error. Subsequent "Connect" also fails. But a later attempt to connect to the same network from list(without changing passphrase) succeeds.

How frequently does this problem reproduce? (Always, sometimes, hard to

What is the impact to the user, and is there a workaround? If so, what is
Misleading errror messages

Please provide any additional information below.

Summary: Hidden network connection fails with spurious message
Logs @
Labels: -Type-Bug Type-Regression
Labels: Mstone-21 Connectivity-Wifi
Status: Assigned
Possibly the same as  bug 30112 .
See the same issue with 2590,0,0,R22.
Labels: ReleaseBlock-Stable
We have another scenario of the same bug. When in OOBE trying to connect to hidden network for the first time gives an "Unknown Network error" dialog even though the connection was successful.

Comment 6 by, Jul 13 2012

Looking through the logs, there are no services which are put in a "failure" state, so I believe the dialog box is a UI issue.  I do see the following message in the Chrome logs:

[] Unexpected signal for unobserved network: CrOS_WPA2_netgearwgr614

which might have something to do with it.  I don't know how to relate Chrome's stamp with wallclock time.  Here are all the service state changes reported (apart from the "Idle state") for services in all of /var/log/messages.*

2012-07-13T11:13:23.372101-07:00 Service CrOS_NONE_N300 state Idle -> Associating
2012-07-13T11:13:23.381081-07:00 Service CrOS_NONE_N300 state Associating -> Configuring
2012-07-13T11:13:24.243448-07:00 Service CrOS_NONE_N300 state Configuring -> Connected
2012-07-13T11:13:54.271892-07:00 Service CrOS_NONE_N300 state Connected -> Portal
2012-07-13T11:14:54.318511-07:00 Service CrOS_NONE_N300 state Portal -> Portal
2012-07-13T11:15:54.364441-07:00 Service CrOS_NONE_N300 state Portal -> Portal
2012-07-13T11:16:54.381341-07:00 Service CrOS_NONE_N300 state Portal -> Portal
2012-07-13T11:17:54.415093-07:00 Service CrOS_NONE_N300 state Portal -> Portal
2012-07-13T11:18:54.440436-07:00 Service CrOS_NONE_N300 state Portal -> Portal
2012-07-13T11:19:54.466550-07:00 Service CrOS_NONE_N300 state Portal -> Portal
2012-07-13T11:20:54.487881-07:00 Service CrOS_NONE_N300 state Portal -> Portal
2012-07-13T11:21:02.314272-07:00 Service CrOS_NONE_N300 state Portal -> Idle
2012-07-13T11:21:02.333123-07:00 Service CrOS_NONE_N300 state Idle -> Idle
2012-07-13T11:21:02.333322-07:00 Service CrOS_WPA2_netgearwgr614 state Idle -> Idle
2012-07-13T11:21:06.621910-07:00 Service CrOS_WPA2_netgearwgr614 state Idle -> Associating
2012-07-13T11:21:06.623484-07:00 Service CrOS_WPA2_netgearwgr614 state Associating -> Associating
2012-07-13T11:21:06.638930-07:00 Service CrOS_WPA2_netgearwgr614 state Associating -> Configuring
2012-07-13T11:21:07.358657-07:00 Service CrOS_WPA2_netgearwgr614 state Configuring -> Connected
2012-07-13T11:21:07.449224-07:00 Service CrOS_WPA2_netgearwgr614 state Connected -> Online
2012-07-13T11:31:06.932412-07:00 Service CrOS_WPA2_netgearwgr614 state Online -> Idle
2012-07-13T11:31:06.950677-07:00 Service CrOS_WPA2_netgearwgr614 state Idle -> Idle
2012-07-13T11:31:06.950778-07:00 Service GUESTGATE state Idle -> Idle
2012-07-13T11:31:11.114742-07:00 Service GUESTGATE state Idle -> Associating
2012-07-13T11:31:11.120509-07:00 Service GUESTGATE state Associating -> Configuring
2012-07-13T11:31:11.427051-07:00 Service GUESTGATE state Configuring -> Connected
2012-07-13T11:31:17.518512-07:00 Service GUESTGATE state Connected -> Portal
2012-07-13T11:31:53.557867-07:00 Service GUESTGATE state Portal -> Portal
2012-07-13T11:32:29.603542-07:00 Service GUESTGATE state Portal -> Portal
2012-07-13T11:33:05.735544-07:00 Service GUESTGATE state Portal -> Portal
2012-07-13T11:33:34.727089-07:00 Service Ethernet state Idle -> Configuring
2012-07-13T11:33:35.710728-07:00 Service Ethernet state Configuring -> Connected
2012-07-13T11:33:35.727145-07:00 Service Ethernet state Connected -> Online

Comment 7 by, Jul 16 2012

Labels: -Pri-2 Pri-1

Comment 8 by, Jul 16 2012

Labels: OS-Chrome
Labels: Iteration-61
Can someone provide me (via another channel) the password for the hidden network so I can attempt to reproduce?
gspencer: I've shared the password for CrOS_WPA2_netgearwgr614 (another hidden network) in valentine.
Status: Started
Labels: -Area-Network Area-UI

Comment 14 by, Jul 25 2012

Issue chromium-os:32920 has been merged into this issue.

Comment 15 by, Jul 25 2012

I'm still looking at this.  I've gotten as far as determining that the network connection has a status of "Connection Succeeded" but with an error status of "Failed", which seems kind of suspect.  I'm running now in the debugger to try and figure out where the mismatch occurs.
OK, so from what I can tell, the problem here is that shill is returning "PassphraseRequired: true" when we request a connection to this network, even though the passphrase has been provided, and ultimately works.  When the Chrome code requests a connect, it gets back the following dictionary from shill:

 WifiServiceUpdateAndConnect network properties:{
   "AutoConnect": false,
   "CheckPortal": "auto",
   "Connectable": false,
   "Device": "/device/wlan0",
   "EAP.AnonymousIdentity": "",
   "EAP.CACert": "",
   "EAP.CACertID": "",
   "EAP.CACertNSS": "",
   "EAP.CertID": "",
   "EAP.ClientCert": "",
   "EAP.EAP": "",
   "EAP.Identity": "",
   "EAP.InnerEAP": "",
   "EAP.KeyID": "",
   "EAP.KeyMgmt": "NONE",
   "EAP.PIN": "",
   "EAP.PrivateKey": "",
   "EAP.RemoteCertification": [  ],
   "EAP.SubjectMatch": "",
   "EAP.UseSystemCAs": true,
   "Error": "Unknown",
   "Favorite": false,
   "GUID": "",
   "HTTPProxyPort": 0,
   "IsActive": false,
   "Mode": "managed",
   "Name": "CrOS_WPA2_netgearwgr614",
   "PassphraseRequired": true,
   "Priority": 0,
   "ProxyConfig": "",
   "SaveCredentials": true,
   "Security": "wep",
   "State": "idle",
   "Strength": 0,
   "Type": "wifi",
   "UIData": "",
   "WiFi.AuthMode": "",
   "WiFi.BSSID": "",
   "WiFi.Frequency": 0,
   "WiFi.HiddenSSID": true,
   "WiFi.PhyMode": 0,
   "WiFi.VendorInformation": [  ]

And since PassphraseRequired is true, it attempts to display the passphrase entry dialog, and since the "Error" field is set to "Unknown", it also displays the error string for "Unknown network error" in that passphrase entry dialog.  It would not display this dialog if PassphraseRequired were false, as long as the error also wasn't indicating a bad passphrase or bad wep key.

I'm going to send this back to Paul and see if he can follow it from the shill side.  Paul, feel free to grab me and we can look at it together again.

Comment 18 by, Jul 30 2012

In R21, as of change ca8c4a74d78f50136f7898cc96af7d4960f5878a (Jul 13), the instant you call Connect() on a WiFi service, the service state should be "Associating".  What shill are you using?
Nevermind. :-)

Looks like that dictionary is from before the connection request, not after.
Labels: Merge-Requested
OK, I've committed a fix for this to ToT:

I'm requesting a merge to M21 for:

The change affects only ChromeOS, and the extent of it is to exclude hidden networks from the code that marks connection attempts as failed if the network ceases to appear in the scanned networks list (because hidden networks don't show up on scans in any case).  I've tested it locally several times, and the fix appears to work but hasn't had any soak time yet.

Possible impact could be that connections for hidden networks that fail to connect may not report that they have failed by opening a dialog (the status tray will still show them as failing).  Worst case (if I got my logic totally wrong) would be that network connection failures of any type would fail to appear as dialogs requesting more info.

Comment 21 by, Aug 2 2012

Labels: -Merge-Requested Merge-Approved
Labels: -Merge-Approved merge-merged-1180
Status: Fixed
Merge to M21 (1180) with change 149712.
Labels: VerifiedIn-R22
Verified in 2715.0.0 with Chrome 22.00.1228.0.
Status: Verified
Verified in 2465.116.0 with chrome 21.0.1180.78.
Project Member

Comment 25 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 26 by, Mar 9 2013

Labels: -Type-Regression -Area-UI -Mstone-21 Type-Bug-Regression Cr-UI M-21
Project Member

Comment 27 by, Mar 14 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment