Closed Bug 1483996 Opened 3 years ago Closed 2 years ago
Driver should work in IPv6-only environment
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.
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
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
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?
Patch to add --marionette-host option to GeckoDriver.
ato: Can you take a look at this patch, and let me know what you think?
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.
Assignee: nobody → fisherii
Status: NEW → ASSIGNED
Priority: P3 → P1
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.
Pushed by email@example.com: 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.
You need to log in before you can comment on or make changes to this bug.