Closed Bug 799825 Opened 12 years ago Closed 12 years ago

[wifi] Unable to connect to WPA Network

Categories

(Firefox OS Graveyard :: General, defect, P1)

Product:
Firefox OS Graveyard
Component:
General
Platform:
x86
Gonk (Firefox OS)
Type:
defect

Tracking

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed)

Status:
RESOLVED FIXED
Project Flags:
blocking-basecamp +
Tracking Flags:
Tracking Status
firefox18 --- fixed
firefox19 --- fixed

People

(Reporter: marcia, Assigned: vchang)

References

Details

(Keywords: dogfood, unagi)

Attachments

(2 files)

Patch, wait driver ready before starting wpa_supplicant
(deleted), patch
mrbkap
: review+
Details | Diff | Splinter Review
Patch, remove unused code related to device
(deleted), patch
mrbkap
: review+
Details | Diff | Splinter Review 
unagi device running 20121009 build

STR:
1. Settings | Wifi
2. Attempt to connect to Home Network
3. Enter passcode into password field

Actual: Receive a connection failed error
Expected: It should connect

This works using the latest Otoro build 20120912 connecting to the same network. At the office I have been connecting the device to the Guest network successfully, but
Per hallway conversation with akeybl, updating severity and marking blocking.
Severity: normal → critical
blocking-basecamp: --- → ?
Blocking and critical.
blocking-basecamp: ? → +
Priority: -- → P1
Mounir, can you take a look?
Assignee: nobody → mounir
I just retested this when I got home again today, and it still doesn't work with the Unagi device using today's build.

remote="b2g" revision="ca1f327d5acc198bb4be62fa51db2c039032c9ce"
gaia" remote="b2g" revision="58e2582ba479e4334fddfc2e759b474e74b7f52d"
releases-mozilla-central" path="gecko" remote="mozilla" revision="e0fb02b979b3109057ceeedd2011516522d4ad29"
gonk-misc" path=gonk-misc" remote="b2g" revision="8c3562dbbc63813fbb2c433a8714904d6cb17ae8"

Using today's build on Otoro, it connects fine. I leave the first field blank, and enter my numerical password in the second field.
Hm, I just tested on my unagi and entering just the password worked. This is with a custom build though (today's inbound).
I tried it today at home with my otoro and my WPA network is working fine (using yesterday a build from yesterday).

I'm not running the latest kernel yet. I think I'm still running version 8.
According to comment 5 and comment 6, connecting to a WPA Network is working. I tried with a fresh build (based on mozilla-aurora) and connecting to Mozilla-G works. If the issue is specific to a certain device (I have an Otoro, not an Unagi), a certain type of network (Mozilla-G isn't a basic WPA network) or a specific kernel, please reopen and give more information.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Mounir: This bug is specific to the Unagi Device as I noted in the initial comment. I was finally able to connect to the network, but doing so requires restarting the phone. Chris Lee has the same issue with his home network so it would great if he could include his information.

I am using one of the daily builds which is I believe has the latest kernel.

The network is configured as WPA/WPA2 Personal.

Otoro: Enter password and connect automatically
Unagi: Enter password and get connection failed. Restart phone and it works
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
If it is Unagi specific, I have no idea why it has been assigned to me. I never even saw a Unagi...
Assignee: mounir → nobody
(In reply to Mounir Lamouri (:mounir) from comment #9)
> If it is Unagi specific, I have no idea why it has been assigned to me. I
> never even saw a Unagi...

You can file a ServiceNow request for a developer Unagi device and Desktop will ship one too you. In the meantime, who can work on this that does have access to the Unagi hardware?
Vincent, can you take a look at this?  Fabrice said he thinks it's a regression.  Fabrice or Marcia can get you device logs if it is Unagi-specific (as it seems it is).
Assignee: nobody → vchang
Keywords: dogfood
I tried connecting again last night to my home router and ran into the same failure issue.  I will double check the encryption type tonight and report back.
(In reply to Andrew Overholt [:overholt] from comment #11)
> Vincent, can you take a look at this?  Fabrice said he thinks it's a
> regression.  Fabrice or Marcia can get you device logs if it is
> Unagi-specific (as it seems it is).

Sure, I can help to check it. 
Not sure if the problem is related to different wpa_supplicant version because 
it is platform dependent bug.

Hi Marcia, 

I don't have Unagi phone on hand.  
Can you help me to get logcat which turns on DEBUG=true in dom/WifiWorker.js ?  

BTW, does wpa-eap work on Unagi ? Or we only have problem on wpa-psk ?
Marcia - did you password have spaces in it? I believe mrz hit an issue where spaces in a password didn't work but ones without did.
No spaces in my password, so that is not the issue.

Chris Lee reports that my workaround of rebooting the phone works.

Since the network is at home I will have to wait until tonight to try to get what Vincent requests in Comment 13.
Keywords: qawanted
QA Contact: mozillamarcia.knous
Bug 801045 is blocking me from testing this ATM.
Using:

Gecko-143419e
Gaia- ff83f82 

I am not seeing this bug now that I updated the phone to the latest build. I will leave it open for Chris or others that have home networks to verify that they can connect without rebooting the phone.

There are a few other wifi bugs that I am seeing but I will file those separately or check to see whether bugs are already on file.
I see this on my home WiFi too with my new dogfooding phone, WPA2-Personal with AES encryption. Restarting the phone makes it work. Anything else I can provide?
I was able to connect with the latest build 10-17-stable with no issues at home (WPA2-Personal).  

Marcia, feel free to close this bug.  We can re-open if additional reports come in.
Finally got one unagi phone. 
I could reproduce this bug when burned unagi image from ICS to B2G in the first time. 
But reboot the device help to fix this issue. Not sure the root cause, need the way to burn image back to ICS. Can I get ICS image for unagi ? Where can I download it ?
(In reply to Vincent Chang from comment #20)
> Finally got one unagi phone. 
> I could reproduce this bug when burned unagi image from ICS to B2G in the
> first time. 
> But reboot the device help to fix this issue. Not sure the root cause, need
> the way to burn image back to ICS. Can I get ICS image for unagi ? Where can
> I download it ?

We can ask it from unagi phone partner.  I'll write e-mail to ask and adding you in cc list.
Marcia, I still don't get the ICS image from partner, can we close this bug first ? We can re-open if additional report comes in.
I reproduced this on unagi.

## Environment :
Unagi phone, build 20121031073004
2012-10-31 10:23:10
  
## Repro :
1. go to settings -> wifi 
2. connect to a WPA network (EAP, PSK it doesn't matter) w/ valid username/password
3. verify by going to a website in browser
4. reboot the device
5. go back to the settings -> wifi

Expected: connected to the WPA network
Actual: it's trying to find the network, selecting it will still fail to connect to it, until you shut the wifi off and back on.

You can connect the first time around... connecting the second time around doesn't work.  It seems unagi specific.  I didn't have a problem on the otoro.
Removing QA wanted, since there's an additional report now, there's no need to close this bug.
Keywords: qawanted
I found that this issue is related to the timing to start wpa_supplicant. We found similar bugs on "otoro" device. Add two seconds delay works for me on unagi device. 

nhirata, can you help to double check if this patch works for you, too.
Attachment #677306 - Flags: review?(mrbkap)
marking qawanted: for me to test the patch.
Keywords: qawanted
Comment on attachment 677306 [details] [diff] [review]
Patch, wait driver ready before starting wpa_supplicant

With this patch, I don't think we use "device" anymore. Want to post a second patch to remove it?
Attachment #677306 - Flags: review?(mrbkap) → review+
?  I thought the patch removes the if statement and just forces us to wait a little bit regardless of the device?
(In reply to Naoki Hirata :nhirata from comment #28)
> ?  I thought the patch removes the if statement and just forces us to wait a
> little bit regardless of the device?

I was referring to the variable |device|.
Oh my bad.  Sorry.  I was looking at the patch and wasn't sure what you were referring to... Just trying to learn as I go along.  :)

Anyways, patch seems to fix the issue for me.  \o/
(In reply to Blake Kaplan (:mrbkap) from comment #27)
> Comment on attachment 677306 [details] [diff] [review]
> Patch, wait driver ready before starting wpa_supplicant
> 
> With this patch, I don't think we use "device" anymore. Want to post a
> second patch to remove it?

ok, I will post a second patch to remove it.

  

  



        Attachment #677643 -
        Flags: review?(mrbkap)

        Attachment #677643 -
        Flags: review?(mrbkap) → review+
Keywords: checkin-needed

    
    

    
  
https://hg.mozilla.org/integration/mozilla-inbound/rev/5fb995072031
https://hg.mozilla.org/integration/mozilla-inbound/rev/12a1b70b2a5a

I just noticed that the commit messages on these two patches were identical. Remember, a patch's commit message should be describing what it's *doing*.

  

  


Flags: in-testsuite-
Keywords: checkin-needed

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/5fb995072031
https://hg.mozilla.org/mozilla-central/rev/12a1b70b2a5a

  

  


Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: