Closed Bug 807242 Opened 8 years ago Closed 8 years ago

[Wifi]: onconnected() function is not called when receiving CTRL-EVENT-CONNECTED event

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

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

RESOLVED FIXED
blocking-basecamp +
Tracking Status
firefox18 --- fixed
firefox19 --- fixed

People

(Reporter: vchang, Assigned: vchang)

Details

Attachments

(1 file, 1 obsolete file)

If we receive CTRL-EVENT-CONNECTED when manager.state is equal to COMPLETE, the onconnected() function will not be called. The reason is that  notifyStateChange() returns false in this case. So runDhcp() function will not have a chance to be called. This is the case reported from one of our partner. To get wider support of our framework, we should make it works in this case, too.
This is a great report. Please thank the partner. mrbkap, can you take this?
blocking-basecamp: --- → ?
blocking-basecamp: ? → +
Hi Blake, I would like to take this.
Assignee: nobody → vchang
Comment on attachment 677315 [details] [diff] [review]
Patch, call onconnected() function when receiving CONNECTED event.

Won't this let the manager's state end up in the "CONNECTED" state, meaning that we'll be kicked off and confused by reauth events later?

It seems like we should be tracking whether or not we've started DHCP separately. Either that, or we should ignore the CONNECTED state entirely and rely only on the COMPLETED message to start DHCP and friends. What do you think?
Attachment #677315 - Flags: review?(mrbkap)
(In reply to Blake Kaplan (:mrbkap) from comment #4)
> Comment on attachment 677315 [details] [diff] [review]
> Patch, call onconnected() function when receiving CONNECTED event.
> 
> Won't this let the manager's state end up in the "CONNECTED" state, meaning
> that we'll be kicked off and confused by reauth events later?

Yeah, you are right. 

> It seems like we should be tracking whether or not we've started DHCP
> separately. Either that, or we should ignore the CONNECTED state entirely
> and rely only on the COMPLETED message to start DHCP and friends. What do
> you think?

Wpa_supplicant sends us CONNECTED event when wpa_state is "COMPLETED" and new_connection flag is 1. The new_connection flag is set to 1 when wpa_state is in one of (WPA_DISCONNECTED, WPA_ASSOCIATING, WPA_ASSOCIATED) state. So we receive CONNECTED event for a new connection once, but may receive COMPLETED event several times for a CONNECTION(Not sure if we really have this case, maybe renew key make it happen ?). 
So the question becomes that should we run dhcp whenever we receive a COMPLETED event, or we just need to run dhcp once for a new connection ? Any comments ?
(In reply to Vincent Chang[:vchang] from comment #5)
> So the question becomes that should we run dhcp whenever we receive a
> COMPLETED event, or we just need to run dhcp once for a new connection ? Any
> comments ?

Well, we might receive multiple COMPLETED events due to reauth, but that's taken care of by notifyStateChange, right? So we should be able to say (in CTRL-EVENT-STATE-CHANGE):

if (fields.state === "COMPLETED" && notifyStateChange(fields))
  onconnected();

and then we can safely ignore CTRL-EVENT-CONNECTED.

Am I missing anything?
Attached patch Patch v1.1Splinter Review
This patch addresses the comment 6.
Attachment #677315 - Attachment is obsolete: true
Attachment #679054 - Flags: review?(mrbkap)
Attachment #679054 - Flags: review?(mrbkap) → review+
https://hg.mozilla.org/mozilla-central/rev/7c695905792e
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.