GeckoDriver should work in IPv6-only environment

RESOLVED FIXED in Firefox 65

Status

defect
P1
normal
RESOLVED FIXED
10 months ago
6 months ago

People

(Reporter: fisherii, Assigned: fisherii)

Tracking

(Depends on 1 bug)

unspecified
mozilla65
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox65 fixed)

Details

Attachments

(1 attachment)

Assignee

Description

10 months ago
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36

Steps to reproduce:

We use GeckoDriver in a Linux environment that has no IPv4 network stack. To get Firefox working in this environment we use a hack that uses an LD_PRELOAD library to make it use IPv6 connections when IPv4 connections are requested. In this environment, we need GeckoDriver to fallback to using IPv6 when IPv4 is not available (we tried using the same LD_PRELOAD with GeckoDriver as we use with Firefox and it did not work).


Actual results:

GeckoDriver returns "other os error" when trying to provision a browser.


Expected results:

GeckoDriver should fall back to using IPv6 when IPv4 is not available.
Assignee

Comment 1

10 months ago
This worked before the 0.21.0 release of GeckoDriver.
This was changed by bug 1462040 due to connection problems for users using a dual-stack.

It's interesting that you can get Firefox and specifically Marionette to use IPv6 with that LD_PRELOAD library. Do you have more details? For which platforms does this work?
Depends on: 1462040
Assignee

Comment 3

10 months ago
We use this on Linux only. The library we use is internal to Google but here is a description of what it does:

// Changes:
// - socket(AF_INET) instead creates an AF_INET6 socket.
// - connect() and bind() treat 127.0.0.1 as ::1, and 0.0.0.0 as ::.
// - setsockopt(IPV6_V6ONLY=0) ignores failures.
//
// These are all gross violations of the API standards, so use of this library
// will potentially create as many bugs as it fixes.  It should not be used with
// code that we can trivially fix, but it may serve a temporary crutch while the
// correct fixes are underway.
//
// The most obvious caveats are:
// - If an app properly binds to both 127.0.0.1 and ::1, the two listeners will
//   conflict with each other.
// - Apps which were not designed to interpret AF_INET6 addresses could see
//   them as IPv4 with garbage data.
// - IPv4 addresses which are not rewritten will typically be rejected by the
//   kernel for for not matching the socket family.
//
// This library will deactivate itself if the underlying environment supports
// AF_INET sockets, which helps to mitigate some of the problems.
The way we set up nsIServerSocket binds to the IPv4 layer by default.
If the client (geckodriver in this case) connects to "localhost",
which layer is chosen depends on the system configuration (/etc/hosts).
We found that whether the default layer is IPv4 or IPv6 is different
from system to system, and indeed Linux distro to distro.

This led us to change geckodriver 0.21.0 to always prefer "127.0.0.1",
since this forces the IPv4 stack to be used.  This fixed the problem
that system independent configuration caused users not to be able
to connect to Marionette.

I notice from
https://searchfox.org/mozilla-central/source/netwerk/base/nsIServerSocket.idl
that there are other ways of configuring it that may allow it to
prefer another IP layer.

However I note with some interest that there is a initWithFilename
constructor implemented that lets you create Unix domain sockets.
I wonder if not we should try to solve
https://bugzilla.mozilla.org/show_bug.cgi?id=1240830 as part of
this.

Unfortunately for the time being this means you’ll have to use an
IPv4 stack with Firefox and geckodriver to get access to Marionette.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Assignee

Comment 5

9 months ago
If I created a patch to allow the host name used to connect to be configured by a flag, would you be likely to accept it?
Assignee

Comment 6

9 months ago
Patch to add --marionette-host option to GeckoDriver.
Assignee

Comment 7

9 months ago
ato: Can you take a look at this patch, and let me know what you think?
Flags: needinfo?(ato)
Depends on: 1257719
Flags: needinfo?(ato)
Flags: needinfo?(ato)
Sorry that it has taken me a long time to get around to this, but
the background is that we have had several conversations about what
to do looking farther into the feature.

The way I see it, this patch doesn’t conflict with the future and
it solves an immeidate problem for people forcing the use of an
IPv6 stack.

In retrospect we should’ve applied this patch sooner, and I’m sorry
for that.
Flags: needinfo?(ato)
Assignee: nobody → fisherii
Blocks: 1495062
Status: NEW → ASSIGNED
Priority: P3 → P1
Assignee

Comment 9

6 months ago
Thank you. Is there anything you need me to do?
I have rebased and fixed up your patch, but it looks like the trees
are closed at the moment.  I will push them as soon as they open
again.

No action from you needed.

Comment 11

6 months ago
Pushed by ato@sny.no:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b2eb9000daed
geckodriver: add --marionette-host flag; r=ato
Marc, again please accept my apologies for the lateness in landing
your patch.  I have now done so, under your name.

You should be aware that we are likely looking towards a future
where initialising a TCP connection to Firefox will not be necessary.
This should not impact any Google infrastructure as it will be
handled transparently in geckodriver.

Comment 13

6 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/b2eb9000daed
Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
You need to log in before you can comment on or make changes to this bug.