I'm trying but unable to reproduce this issue.

using r5265, I attempt to connect to a WPA network with an incorrect password (WRTG54GL running Tomato, WPA Personal, AES encryption). After it failed I attempted to re-enter a passphrase. In all cases I was presented a keyboard to re-enter the passphrase. I tried this on two Fab4s both through setup and through advanced settings.

Erland, was there anything notably different about your setup? Were you doing this with r5265?

> Erland, was there anything notably different about your setup? Were you doing
> this with r5265?

I just tried it again, I did a factory reset and entered the incorrect password. It gave me the choice to "Re-enter password" or "Choose a different network", I selected to "Re-enter password" and it tried to connect directly without asking me for the new password.

I'm using a D-Link DIR-655 router with firmware 1.21EU, the SBT firmware is r5265.

what flavor of WPA and what type of encryption?

changed router to WPA2 + TKIP/AES, still not able to reproduce issue.

(In reply to comment #3)
> what flavor of WPA and what type of encryption?

I'm using WPA Personal and have the router in "Auto" mode which means that it will use WPA2 if available else it will use WPA. In the same way it will use AES when supported by client else it will use TKIP.

I think Philip Meyer mentioned that he had the same problem, so it at least isn't just my setup that behaves this way.

I could try to reconfigure the router in specific mode to see if it makes any difference, but that will have to wait until tomorrow.

I don't have an ethernet cable connected, I don't know if that matters.

thanks for the feedback Erland.

I switched my router to WPA/WPA2 TKIP+AES, which afiact in the Tomato firmware is the equivalent of what you have your D-Link router set to. I'm still not able to reproduce.

I had an ethernet cable on one of my two devices but pulled it with no effect.

I saw that Phil had also seen the same thing. Will ping via the forum and see if we can get some feedback from him.

Can you attempt to repro, Ross?

I'm unable to reproduce this.  I've also tried changing networks at the password failure screen, and going back and forth between networks with unsuccessful login attempts on all of them, but I always get the keyboard.

1. D-Link DWL-2100AP wireless access point, fw 2.10na
2. WPA-PSK
3. AES
4. SSID broadcast enabled
5. Super G without Turbo

Created attachment 5112 [details]
fab4 log during setup

I'm able to reproduce with WRT310N, this is a WPS router. After factory reset with r5250 I'm prompted Choose WPS Login Method(Use Push Button/PBC, PIN, or Enter WPA Password), I select Enter WPA Password and I enter the key incorrectly. It fails saying Can't Connect, shows me the key I entered and offers Re-enter password or Choose a different network. I select Re-enter password, again I'm prompted with Use Push Button/PBC, PIN, or Enter WPA Password. I select Enter WPA Password and immediatly it shows Connecting to [ssid], no prompt to change the password. SSID is WRT310N, WPA2 password.

(In reply to comment #9)
> Created an attachment (id=5112) [details]
> fab4 log during setup
> 
> I'm able to reproduce with WRT310N, this is a WPS router. 

Just to confirm this, I tried the same procedure towards my non WPS Belkin router and there it works correctly, so the problem seems to be related to WPS routers which show the extra WPS Login Method screen.

I do not see this behavior.

I tried r5265 combined with WPS and non WPS routers. Choosing 'Re-enter password' always led me to a keyboard where I was able to modify the password.

I've got a WPS router (Netgear WNR3500) here to test with. I'll set that up and see if I can reproduce as well. I thought we had this nailed as a WPS issue, but Felix's comment suggest that alone is not it.

Ben: Thanks. Please let me know your findings so we can either try to fix it or close the bug.

I'm able to reproduce this with r5299 with the Linksys WRT310N. Another WPS router, the Belkin F5D8231-4 v5000, it works. By it works I mean that enter wireless password brings up a keyboard where I can change the key. WRT310N I click enter password, and it immediatly goes to connecting to [ssid]. Need any other log or anything?

Felix, we can't close this bug as it is clearly affecting multiple people.

Ross, if possible I'd like to see the contents of /etc/wpa_supplicant.conf at the time of the bug being reproduced. Do you have a Fab4 hooked up with serial available?

However, I have tried and failed to reproduce this issue with my WPS-capable Netgear router. Works correctly every time.

I guess I'll dive into the code and see if there's anything obviously wrong, but my hunch is that's going to be a dead-end.

# cat wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
update_config=1

Ross's update shows that wpa_supplicant.conf is written to what we'd want after a failed connection. Which is to say no stored information about that network. So that part is not it.

this is the callback function for the "re-enter password" menu item.

callback = function()
            _networkScanAgain(self, iface, true) 
            _enterPassword(self, iface, ssid, "config")
end

one theory is that certain WPS routers either aren't sending the right flags or we are losing that information, thus we go the wrong logical route in the _enterPassword() method. 

Here is the _enterPassword() method. In the case of "re-enter password", we're sending the string "config" to the nocheck method argument:

-- wireless network choosen, we need the password
function _enterPassword(self, iface, ssid, nocheck)
        assert(iface and ssid, debug.traceback())

        -- check if we know about this ssid
        if self.scanResults[ssid] == nil then
                return _chooseEncryption(self, iface, ssid)
        end

        -- is the ssid already configured
        if nocheck ~= "config" and self.scanResults[ssid].id ~= nil then
                return _connect(self, iface, ssid, false)
        end

        local flags = self.scanResults[ssid].flags
        log:debug("ssid is: ", ssid, " flags are: ", flags)

        if flags == "" then
                self.encryption = "none"
                return _connect(self, iface, ssid, true)

        elseif string.find(flags, "ETH") then
                self.encryption = "none"
                return _connect(self, iface, ssid, true)

        elseif nocheck ~= "wps" and string.find(flags, "WPS") then
                self.encryption = "wpa2"
                return _chooseWPS(self, iface, ssid)

        elseif string.find(flags, "WPA2%-PSK") then
                self.encryption = "wpa2"
                return _enterPSK(self, iface, ssid)

        elseif string.find(flags, "WPA%-PSK") then
                self.encryption = "wpa"
                return _enterPSK(self, iface, ssid)

        elseif string.find(flags, "WEP") then
                return _chooseWEPLength(self, iface, ssid)

        elseif string.find(flags, "WPA%-EAP") or string.find(flags, "WPA2%-EAP") then
                return _enterEAP(self, iface, ssid)

        else
                return _chooseEncryption(self, iface, ssid)

        end
end

this clause I'm finding curious...if the flags show it to be a WPS router then it assumes wpa2 as the encryption type. I'm not sure that's a smoking gun to the problem, but it seems presumptive...


        elseif nocheck ~= "wps" and string.find(flags, "WPS") then
                self.encryption = "wpa2"
                return _chooseWPS(self, iface, ssid)

Created attachment 5119 [details]
Fab log with Ben's SetupNetworkingApplet.lua

For some reason using Ben's debug version of SetupNetworkingApplet.lua its far more difficult to reproduce this bug with WRT310N. I got it on about the 15th attempt. Should be right around 23:25.

nice work Ross

logging did its job I think:

Jan  6 23:24:56 SqueezeboxTouch user.warn jive: (SetupNetworkingApplet.lua:514) - ssid is: wrt310n flags are: [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS]
Jan  6 23:24:56 SqueezeboxTouch user.warn jive: (SetupNetworkingApplet.lua:532) - WPA2%-PSK

the first line of that log lists the flags
[WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS]

the second line indicates that it didn't hit true until the bottom clause of the two below, which is not intended. It should have hit true on the first--

     elseif nocheck ~= "wps" and string.find(flags, "WPS") then
                log:warn('WPS')
                self.encryption = "wpa2"
                return _chooseWPS(self, iface, ssid)

        elseif string.find(flags, "WPA2%-PSK") then
                log:warn('WPA2%-PSK')
                self.encryption = "wpa2"
                return _enterPSK(self, iface, ssid)

(nocheck should be equal to 'config' and the flags string contains WPS...unknown why that doesn't work in some situations)

I think this is the interesting part of the log:

Jan  6 23:25:34 SqueezeboxTouch user.warn jive: (SetupNetworkingApplet.lua:499) - _enterPassword()
Jan  6 23:25:34 SqueezeboxTouch user.warn jive: (SetupNetworkingApplet.lua:514) - ssid is: wrt310n flags are: [WPA-PSK-TKIP+CCMP][WPA2-PSK-TKIP+CCMP][WPS]
Jan  6 23:25:34 SqueezeboxTouch user.warn jive: (SetupNetworkingApplet.lua:527) - WPS
Jan  6 23:25:34 SqueezeboxTouch user.warn jive: (SetupNetworkingApplet.lua:499) - _enterPassword()
Jan  6 23:25:34 SqueezeboxTouch user.warn jive: (SetupNetworkingApplet.lua:509) - nocheck not equal to config and ssid is configured
Jan  6 23:25:34 SqueezeboxTouch user.info jive: (Networking.lua:871) - select network wrt310n


but I have no idea what going wrong. :(

The workaround is to reset or power-off-power-on and start over.

The general unreliability of wireless networking means many users will assume it's their network (either in general or something like insufficient signal strength/reception) and thus are less likely to think to power cycle the device.

Given that the primary consideration for the MP firmware is successfully getting the device on the network, this seems like an MP bug to me.

Seth: I am confused. I got a email from Mickey "Summary of Wednesday August 5th Status for Baby Boom MP Firmware" stating "The Baby Boom MP firmware is r6899".

It is my understanding that Baby MP firmware is done.

Also, what do you mean by "general unreliability of wireless networking"? Are you talking about setup or after setup? Do you know for sure it is the wireless connection that fails or do you see a symptom where mysqueezebox.com cannot be reached? Have you tried to connect your Baby to the ethernet?

And is your statement meant for MV (with the many many APs and routers) or in general, i.e. you see the same issues at home for instance.

I only have about 7 APs I can turn on to try to simulate wireless interference, but having them all running seems not to influence Babys wireless performance.

I only have a PB1 and PB2 unit to test, but I was told there should be no hardware difference regarding wireless.

My mistake Felix. I didn't mean _our_ wireless is generally unreliable. I meant that Wi-Fi as a whole is often unreliable for people (e.g., range/interference issues, etc.)

That compounds the problems of this bug, where a user who enters an incorrect wireless password is presented with options to "try again" but, even if they correct their typo, the device still won't connect. In this case, users are likely to think it's their network that is the problem when, in fact, the device seems to somehow be caching(?) the old/incorrect wireless password. As a result, they are unlikely to think of actually power-cycling their SB device.

I haven't tried this at home, but it does seem to have affected several other non-Mt. View based people.

Re MP firmware, it was my understanding that we had an MP _candidate_, but not necessarily that MP was done. I guess we could go out with this issue still present, but my point was that the primary focus of the MP firmware is network connectivity and this bug seems to fall squarely in that category...

Ok, thanks Seth for the clarification.

I did some more tests today, I even added the same debugging printouts as Ben did, and tried to reproduce. I don't have that particular router Ross was using, but I tried against all of my WPS routers and unfortunately I was unable to force the issue to happen.

Entering an incorrect passphrase always did let me correct it after choosing 'Try again' - 'Enter wireless password'.

The code in question temporarily adds the network credentials to the wpa_supplicant.conf file but then removes it again when the connection fails.

There was a change about how the configuration file is written due to some filesystem issues which sometimes corrupted a file, maybe that helped.

The only other way this could have happened I can see right now is that a knob bounce would skip over the already filled out 'Enter password' dialog, but I guess people would have seen that so that is quite unlikely.

Just to be clear, if I enter an incorrect wireless password, I get "try again - enter wireless password". However, if I edit the previously entered password to correct the mistake, it still does not connect.

Are you saying that if you correct the wireless password it connects successfully?

If so, then it would seem it is specific to one (or more) router(s). So, less of a problem, but still a problem with network setup which is unfortunate for MP f/w.

I deliberately enter an incorrect passphrase, go the "Try again" - "Enter Wireless password" - failed to connect route several times and as soon as I change the passphrase to the correct one Baby connects successfully.

Maybe some routers automatically put a device onto a blacklist for a while after several failed attempts? Just a wild guess, never heard of that.

Are you sure you really entered the correct passphrase? Also after a factory reset (maybe a router reboot) and with entering the correct passphrase the first time, does it connect then?

Felix: are you using MP firmware during your tests?  we are seeing this on the MP branch.

Please also try using WPA2 encryption keys

I tried with MP and the regular branch. I also used WPA2.

QA re-verified.  Looks like MP 6943 and 7.4 6950 no longer suffer from this problem.

Verified that I was able to go back 1 step and correct bad key entry:

WPA
WPA2

 == Auto-comment from SVN commit #6977 to the jive repo by felix ==
 == https://svn.slimdevices.com/jive?view=revision&revision=6977 ==

Bug: 11771 
Description: Allow correction of passphrase if network settings already exist in wpa_supplicant.conf 
- Allow correcton of passphrase if network settings for an SSID already exist in wpa_supplicant.conf
- Added comment explaining how _enterPassword() works in different situations
- Fix crasher in help text in case psk or key is nil
Hours Worked: 2.0

Hmm, I thought hours worked can be updated from svn checkins?

This appears to be happening in MP7022 again, a regression?

Hmm, that is very strange. From campfire:

James R. - I have verified that MP6943 works and MP7022 fail

According to my checkin notes nothing has changed in the MP branch in that regard so I would have expected that it fails (or is ok) in both revisions.

BTW: I think it only happens with WPS capable APs using WPA or WPA2 passphrase manually.

(In reply to comment #35)
> 
> BTW: I think it only happens with WPS capable APs using WPA or WPA2 passphrase
> manually.

You are correct here Felix, I saw this problem only with WPS capable routers.  Even though I tell the router to 'configure manually' WPS is still enabled.

Do we have an open bug on WPS routers that may cover this behavior?

Felix: The fix you did in 7.4 appears to function properly.

re-entering password on WPS capable routers with 7.4 r7062 firmware works
Using MP r7022 re-entering password fails
Using MP r6943 re-entering password works

Since we are going to be doing another MP firmware, I would suggest checking your fix into the MP branch, so it's there the next time we rev the MP builds

 == Auto-comment from SVN commit #7122 to the jive repo by felix ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7122 ==

Bug: 11771 
Description: 
- Do not allow breakout of connection spinny as that leaves it in an unknown state and makes further connction attempts fail
- Allow correcton of passphrase if network settings for an SSID already exist in wpa_supplicant.conf
- Added comment explaining how _enterPassword() works in different situations
- Fix crasher in help text in case psk or key is nil

Fix added to MP branch.