[B2G] http://mochi.test is unreachable in mochitests when run OOP on the Otoro

RESOLVED WONTFIX

Status

()

Core
Networking
P1
normal
RESOLVED WONTFIX
6 years ago
2 years ago

People

(Reporter: onecyrenus, Unassigned)

Tracking

unspecified
B2G C2 (20nov-10dec)
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:-)

Details

(Whiteboard: [LOE:M])

(Reporter)

Description

6 years ago
Mochitests running on the device try to connect to http://mochi.test:8888/ 

and inside the user.js a pref creates a match between mochi.test and the actual mochitest server
......
user_pref("network.proxy.autoconfig_url", "data:text/plain,function FindProxyForURL(url, host){ 
....
return 'PROXY 192.168.2.10:8888';  if (isHttps || isWebSocket || isWebSocketSSL)    return 'PROXY 192.168.2.10:4443';  return 'DIRECT';}");

Now the problem is the web server is running but the device is unable to connect to 192.168.2.10:8888.   Now I believe that is because this pref is not being looked at on b2g and things have been diverted elsewhere.  

This needs to work or we cannot run mochitests on device.
(Reporter)

Comment 1

6 years ago
This problem may be related to mochitests running out of process, wheras before they were being run in process.
(Reporter)

Updated

6 years ago
blocking-basecamp: --- → ?
To be clear, this bug only affects the ability to manually run mochitests on the otoro, and does not impact CI.
Summary: http://mochi.test not able to be reached on mochitest run → [B2G] http://mochi.test not able to be reached on mochitest run on Otoro
(Reporter)

Updated

6 years ago
Blocks: 771725
Geo says while this is a nice to have, we shouldn't block on it.
blocking-basecamp: ? → -
A little more detail about this:

When mochitest runs (if you're not running just a single test), it loads the testrunner in the main document, and loads the tests themselves in an iframe.  Both are hosted at the http://mochi.test:8888 domain.

For some reason on the Otoro device, the main page (containing the testrunner) loads OK.  But the iframe containing the test does not, it shows "mochi.test could not be found".  This is odd since the parent frame successfully loaded the testrunner from the same domain.

This is the log output:

0 INFO Running tests 1-2/409
1 INFO SimpleTest START
2 INFO TEST-START | /tests/layout/base/tests/test_after_paint_pref.html
Network Worker: received message: {"cmd":"setDefaultRouteAndDNS","ifname":"wlan0","oldIfname":null}
Any chance that the framework breakage is indicative of a greater problem with more impact?
This has something to do with the fact that we're now running mochitests OOP.  If you remove all of the extra prefs here except the first one:

http://mxr.mozilla.org/mozilla-central/source/testing/mochitest/runtestsb2g.py#366

...then mochitest works OK on the otoro again.  This has the effect of making mochitest run in the parent process.
Summary: [B2G] http://mochi.test not able to be reached on mochitest run on Otoro → [B2G] http://mochi.test is unreachable in mochitests when run OOP on the Otoro
Blocks: 781696
(Reporter)

Comment 7

6 years ago
Any movement here ?
Renoming - https://bugzilla.mozilla.org/show_bug.cgi?id=771725#c8 indicates that this is the last bug blocking the mochitests on otoro device basecamp blocker.
blocking-basecamp: - → ?
Cc'ing OOP people. Chris and Dave, this bug is blocking our ability to run tests on the device. Any idea what the problem might be?
You want the folks who know the network stack.

How is the mochi.test host entry being configured?  Is this perhaps related to the offline/online bug we just fixed?
(Reporter)

Comment 11

6 years ago
Could you list the bug here ? 

Thanks
Was thinking of bug 777145, but it's been backed out.
The code that sets up proxy configuration for mochitest is here:

http://mxr.mozilla.org/mozilla-central/source/build/automation.py.in#454
Blocking since it's stopping test runs on the devices.
blocking-basecamp: ? → +
Whiteboard: [WebAPI:P1]
Jason, this looks like it may be in the network layer.  Can you take a look?
Assignee: nobody → jduell.mcbugs
mcmanus knows the PAC code, so may have insights here.

So this only happen on otero devices (B2G emulator works fine) on wifi.   From reading the rest of the comments I think we may need device in hand to debug this--there's not much to work with.
Can we get an NSPR log here with 

 https://developer.mozilla.org/en-US/docs/HTTP_Logging

Use 

  NSPR_LOG_MODULES=timestamp,nsHttp:5,nsSocketTransport:5,nsHostResolver:5,proxy:5

(i.e. add 'proxy' to the list on the web page).

Wireshark log couldn't hurt either, but if that's a fuss we can start with just NSPR log.

So do simple PAC files work ok on the phone (i.e. not in mochitest)?
I'm hoping this is something simple but it's hard to tell yet.
Whiteboard: [WebAPI:P1] → [WebAPI:P1][LOE:M]
I've got an Otero phone set up and will investigate this after the feature freeze.
Do we know if this is happening on Unagi phones too?
Keywords: qawanted
Priority: -- → P1
QA Contact: dclarke
Whiteboard: [WebAPI:P1][LOE:M] → [LOE:M]
(Reporter)

Comment 21

6 years ago
Overholt need a bit more explanation as to what needs to happen here ?
Sorry, David.  Was just wondering if you could answer Jason's question in comment #20.  Thanks.
(Reporter)

Comment 23

6 years ago
I think the same problem is seen on pandaboard, so this was not device specific from what we could tell. 

I'll need to get a unagi device before I get a chance to verify, is there a reason why we'd imagine that the new device would be have differently ? 

Both Jason / I should have environments up and ready to go which is probably where we are more blocked on at this point. 

I believe this is a candidate to reverify if we know the pandaboard issue has been fixed. 

@jgriffin ? any update on that front
Keywords: qawanted
We run tests on the panda without wifi, so whether or not it works on the panda doesn't necessarily tell us whether it will work on the otoro/unagi.

I'll try it on the panda, but it'll take me a day or two to get to it.
Setting needinfo to Jonathan to know if this happens on the panda boards.
Flags: needinfo?(jgriffin)
Milestoning for C2 (deadline of 12/10), as this meets the criteria of "known bugs with LOE:M".
Target Milestone: --- → B2G C2 (20nov-10dec)
No update since October. Does this really block the release?
Since we will not be running mochitests on either unagis or pandas by the release date, I'd argue it should not block the release.
Flags: needinfo?(jgriffin)
Blocking- per comment #28.
blocking-basecamp: + → -
not working on this ATM
Assignee: jduell.mcbugs → nobody
David, I think you figured this out, right?
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.