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

Status: RESOLVED WONTFIX

(Core :: Networking, defect, P1)

Description

[[e-mail] [:onecyrenus]]

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.

Comment 1

[[e-mail] [:onecyrenus]]

This problem may be related to mochitests running out of process, wheras before they were being run in process.

Comment 2

[Jonathan Griffin (:jgriffin)]

To be clear, this bug only affects the ability to manually run mochitests on the otoro, and does not impact CI.

Comment 3

[Andrew Overholt [:overholt]]

Geo says while this is a nice to have, we shouldn't block on it.

Comment 4

[Jonathan Griffin (:jgriffin)]

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}

Comment 5

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

Any chance that the framework breakage is indicative of a greater problem with more impact?

Comment 6

[Jonathan Griffin (:jgriffin)]

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.

Comment 7

[[e-mail] [:onecyrenus]]

Any movement here ?

Comment 8

[Jason Smith [:jsmith]]

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.

Comment 9

[Dietrich Ayala (:dietrich)]

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?

Comment 10

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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?

Comment 11

[[e-mail] [:onecyrenus]]

Could you list the bug here ? 

Thanks

Comment 12

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Was thinking of bug 777145, but it's been backed out.

Comment 13

[Jonathan Griffin (:jgriffin)]

The code that sets up proxy configuration for mochitest is here:

http://mxr.mozilla.org/mozilla-central/source/build/automation.py.in#454

Comment 14

[Andrew Overholt [:overholt]]

Blocking since it's stopping test runs on the devices.

Comment 15

[Andrew Overholt [:overholt]]

Jason, this looks like it may be in the network layer.  Can you take a look?

Comment 16

[Jason Duell]

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.

Comment 17

[Jason Duell]

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)?

Comment 18

[Jason Duell]

I'm hoping this is something simple but it's hard to tell yet.

Comment 19

[Jason Duell]

I've got an Otero phone set up and will investigate this after the feature freeze.

Comment 20

[Jason Duell]

Do we know if this is happening on Unagi phones too?

Comment 21

[[e-mail] [:onecyrenus]]

Overholt need a bit more explanation as to what needs to happen here ?

Comment 22

[Andrew Overholt [:overholt]]

Sorry, David.  Was just wondering if you could answer Jason's question in comment #20.  Thanks.

Comment 23

[[e-mail] [:onecyrenus]]

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

Comment 24

[Jonathan Griffin (:jgriffin)]

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.

Comment 25

[Andrew Overholt [:overholt]]

Setting needinfo to Jonathan to know if this happens on the panda boards.

Comment 26

[Alex Keybl [:akeybl]]

Milestoning for C2 (deadline of 12/10), as this meets the criteria of "known bugs with LOE:M".

Comment 27

[Dietrich Ayala (:dietrich)]

No update since October. Does this really block the release?

Comment 28

[Jonathan Griffin (:jgriffin)]

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.

Comment 29

[Dietrich Ayala (:dietrich)]

Blocking- per comment #28.

Comment 30

[Jason Duell]

not working on this ATM

Comment 31

[Martijn Wargers (dead)]

David, I think you figured this out, right?