Closed Bug 1163089 Opened 9 years ago Closed 6 years ago

[Wifi] Marionette tests for Wifi WPA-EAP associate start to fail

Categories

(Firefox OS Graveyard :: Wifi, defect)

All
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: chucklee, Assigned: chucklee)

References

Details

I have observed Marionette test in inbound for Wifi WPA-EAP associate start to failed since revision 01e6faa051bd.
The WAP-EAP connection might also fail on real devices.

The related patch involves change in UnixSocket, bug 1162524 and bug 1162585, which is used as certification backend of Wifi WPA-EAP function.
I suspect the issue might be caused by bug 1162585, because as I can remember, I tried to solve access issue of keystore socket in bug 928223, and it turns out I have to use chmod on the socket every time it is closed and listen again.

This is just my first guess, and bug 1161020 seems to be the final piece of tdz's refactory work.

I would wait for bug 1161020 to land and check if the test still fails.
If so, then I will start to investigate.

If this becomes an urgent issue, then I suggest Vincent assign it to others for faster response.

[1] https://treeherder.mozilla.org/#/jobs?repo=b2g-inbound&filter-searchStr=MNW&exclusion_profile=false
Did you find out why |listen| requires the permissions of the socket to be changed afterwards?

I'm asking because with the current |UnixSocket|, the key store should only open the listening socket once and keep it open.
In the older days the listen fd will be closed after accept, and somehow(I can't remember) I have to delete unix socket path so I can listen again.
I am tracing current behavior of unix socket to find out if it's necessary and how to adjust keystore.
Hi

(In reply to Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests] from comment #2)
> In the older days the listen fd will be closed after accept, and somehow(I
> can't remember) I have to delete unix socket path so I can listen again.

AF_UNIX requires |unlink|'ing the socket's file path after closing it. Maybe the connector should also offer a |CloseSocket| method that could implement such operations.

However, since KeyStore only opens a listening socket once, (?) unlinking shouldn't be necessary. And for reliability, |KeyStoreConnector::CreateSocket| will call |unlink| unconditionally before creating a new socket.

Let's see if bug 1161020 fixes the problem.

> I am tracing current behavior of unix socket to find out if it's necessary
> and how to adjust keystore.

Is there a simple way of reproducing the problem locally?
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #3)
> Hi
> 
> (In reply to Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback
> requests] from comment #2)
> > In the older days the listen fd will be closed after accept, and somehow(I
> > can't remember) I have to delete unix socket path so I can listen again.
> 
> AF_UNIX requires |unlink|'ing the socket's file path after closing it. Maybe
> the connector should also offer a |CloseSocket| method that could implement
> such operations.
> 
> However, since KeyStore only opens a listening socket once, (?) unlinking
> shouldn't be necessary. And for reliability,
> |KeyStoreConnector::CreateSocket| will call |unlink| unconditionally before
> creating a new socket.
> 
> Let's see if bug 1161020 fixes the problem.
> 

It seems the issue still exists.
I have tested the keystore and unix socket seems works well.

> > I am tracing current behavior of unix socket to find out if it's necessary
> > and how to adjust keystore.
> 
> Is there a simple way of reproducing the problem locally?

There's a command line tool called "keystore_cli" can communicate with keystore through socket, as wpa_supplicant does.
So how i test it is import a certificate through settings, then try to read it using keystore_cli.
But after JB, the keystore_cli doesn't show read result anymore, although the read operation is success.
So I have to put debug message in keystore now and check if the command reaches keystore.

Another way might be run marionette tests in dom/wifi/test/marionette/test_wifi_associate_WPA*, but as I can remember, only ICS emulatr can run marionette test.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.