Failed to connect to binary FirefoxBinary

[Armand]

Hello,

I've faced a problem trying to run webdriver-firefox test under
OpenSuse 11.1 (under windows XP everything is OK).

I downloaded all the binaries from latest release and try to use
sample provided by GettingStart page. As I stated above everything is
OK under Windows XP both FireFox and IE. But under linux I receive the
following errors when I try to execute sample:
____________________________________________________________________
Exception in thread "main" org.openqa.selenium.WebDriverException:
org.openqa.selenium.WebDriverException: Failed to connect to binary
FirefoxBinary(/usr/bin/firefox) on port 7055; process output follows:

System info: os.name: 'Linux', os.arch: 'i386', os.version:
'2.6.27.19-3.2-default', java.version: '1.6.0_0'
Driver info: driver.version: firefox
System info: os.name: 'Linux', os.arch: 'i386', os.version:
'2.6.27.19-3.2-default', java.version: '1.6.0_0'
Driver info: driver.version: firefox
at
org.openqa.selenium.firefox.internal.ExtensionConnectionFactory.connectTo
(ExtensionConnectionFactory.java:46)
at org.openqa.selenium.firefox.FirefoxDriver.connectTo
(FirefoxDriver.java:119)
at org.openqa.selenium.firefox.FirefoxDriver.<init>
(FirefoxDriver.java:109)
at org.openqa.selenium.firefox.FirefoxDriver.<init>
(FirefoxDriver.java:82)
at test.main(test.java:12)
Caused by: org.openqa.selenium.WebDriverException: Failed to connect
to binary FirefoxBinary(/usr/bin/firefox) on port 7055; process output
follows:

System info: os.name: 'Linux', os.arch: 'i386', os.version:
'2.6.27.19-3.2-default', java.version: '1.6.0_0'
Driver info: driver.version: firefox
at
org.openqa.selenium.firefox.internal.NewProfileExtensionConnection.connectToBrowser
(NewProfileExtensionConnection.java:61)
at
org.openqa.selenium.firefox.internal.NewProfileExtensionConnection.<init>
(NewProfileExtensionConnection.java:50)
at
org.openqa.selenium.firefox.internal.ExtensionConnectionFactory.connectTo
(ExtensionConnectionFactory.java:44)
... 4 more
Caused by: org.openqa.selenium.firefox.NotConnectedException: Failed
to start up socket within 45000
at
org.openqa.selenium.firefox.internal.AbstractExtensionConnection.connectToBrowser
(AbstractExtensionConnection.java:130)
at
org.openqa.selenium.firefox.internal.NewProfileExtensionConnection.connectToBrowser
(NewProfileExtensionConnection.java:59)
... 6 more
________________________________________________

While running Firefox starts and it seems that everything is OK with
profile and extension.

How can this be solved?


-Gleb

[Simon Stewart]

Hi Gleb,

That error message occurs when webdriver finds the "firefox" binary,
but for some reason can't start it. There's a number of possible
causes:

* On a heavily loaded machine, it may just take too long to start. Did
firefox open eventually?

* We only work with Firefox 2 and 3. I have no idea what happens with
firefox 1.5 and 1.

* It's possible that the there's a wrapper around the normal firefox
binaries that's not passing the command line flags we need through. If
you quit all open Firefox instances before running the test, does that
work?

Please let us know if you're still experiencing problems!

Regards,

Simon

[Gleb Schukin]

Hello Simon,

I'm running latest version of Firefox (3.0.7) and machine isn't heavy loaded. Firefox starts and everything OK with its window. It takes about 15 seconds after firefox starts for errors to appear. There are no other instances of firefox running.

I've tried three different ways of invoking firefox

* using webdriver.firefox.bin property to specify starting script
* default one (without specifying binary) seems to be the same as first one
* using webdriver.firefox.bin property to specify firefox executable without any shell script

but all of them gives error message.

-Gleb

[Mirko Nasato]

Hi Gleb,

If you do a netstat after Firefox starts can you see it listening on port 7055? Do you have anything that may prevent Firefox from opening a port (e.g. SELinux policy)?

Cheers

Mirko

2009/3/16 Gleb Schukin <gs1...@gmail.com>

[Gleb Schukin]

Hi Mirko,

After WebDriver starts Firefox I can see it's process listening on port 7055.

-Gleb

[Simon Stewart]

Hi Gleb,

Can you telnet to that port? And is there a local firewall connection
running that might prevent the Java process from accessing that port?

Regards,

Simon

[Gleb Schukin]

Hi Simon,

I have successfully connected via telnet to that port.
There is no firewall running.


I'm also doesn't experience any problems running selenium tests (Java, ruby) on this machine, either locally or remotely.

-Gleb

[Simon Stewart]

Hi Gleb,

So the next debugging query is whether or not you have a "WebDriver"
profile set up for Firefox. The easiest way is to use:

firefox -ProfileManager

when no instances of firefox are running. You sometimes see the
behaviour you're seeing when a newer version of the java code talks to
an older version of the firefox extension (or vice versa) Since the
firefox driver now unpacks its copy of the extension, you no longer
need to have it installed into its own profile.

Regards,

Simon

[Gleb Schukin]

Hi Simon,

I've tried both variants, with WebDriver profile created by profile manager and without, in second case I checked that there wasn't any redundant profiles except default one. In both cases I can see that Firefox profile changed to WebDriver profile and WebDriver Firefox extension is installed. When I create WebDriver profile manually I do NOT copy WebDriver extension.
Extension version is 0.6.680. I'm using latest WebDriver version available at downloads section.

I also had the same behavior with one of the previous WebDriver builds. When it was necessary to install Firefox extension manually.

-Gleb

[Julian Harty]

Perhaps a network sniffer like wireshark might help capture where the communications is failing. It is free and available for most operating systems. Configure it to capture traffic for the loopback or local newtork interface (the name depends on the OS). Make sure it's capturing some local traffic eg if you open a web browser to localhost and/or your local telnet to port 7055. Then quit any existing firefox instances before trying to run your code. Do a telnet connection and then type some unique junk so you can easily find the telnet query later. Stop the capture once you think you have enough evidence. Then see if you can isolate the webdriver traffic eg using a filter of tcp port 7055.

If you wish you should be able to extract the text of the traffic and post it here.

I've probably given you about half the info needed for someone new to wireshark so tell me if you'd like more stuff explained and I'll try to fill in the gaps.

Julian

On Mar 23, 2009 10:46 AM, "Gleb Schukin" <gs1...@gmail.com> wrote:

Hi Simon,

I've tried both variants, with WebDriver profile created by profile manager and without, in second case I checked that there wasn't any redundant profiles except default one. In both cases I can see that Firefox profile changed to WebDriver profile and WebDriver Firefox extension is installed. When I create WebDriver profile manually I do NOT copy WebDriver extension.
Extension version is 0.6.680. I'm using latest WebDriver version available at downloads section.

I also had the same behavior with one of the previous WebDriver builds. When it was necessary to install Firefox extension manually.

-Gleb

On Mon, Mar 23, 2009 at 12:53 PM, Simon Stewart <simon.m...@gmail.com> wrote: > > > Hi Gleb, ...

[Gleb Schukin]

Hello,

Thank you Julian, I've googled the rest :) It's not so difficult.

I have successfully capture traffic. I'm attaching wireshark log.

Frame 1 - Frame 2 - trying to connect to localhost:7055 via telnet before test suite
Frame 9 - Frame 368 - running test suite
Frame 369 - Frame 371 - trying to connect to localhost:7055 via telnet after test suite aborted but Firefox is still running

It seems that while test suite is running it tries to connect to 127.0.0.2:7055 instead of 127.0.0.1:7055, but maybe I'm wrong and it's OK.

-Gleb

[Mirko Nasato]

What does your /etc/hosts file look like?

2009/3/24 Gleb Schukin <gs1...@gmail.com>:

[Gleb Schukin]

Nothing special I think:
/etc/hosts
127.0.0.1      localhost
127.0.0.1      schukin-laptop.office.asoft.ru schukin-laptop

# special IPv6 addresses
::1             localhost ipv6-localhost ipv6-loopback

fe00::0         ipv6-localnet

ff00::0         ipv6-mcastprefix
ff02::1         ipv6-allnodes
ff02::2         ipv6-allrouters
ff02::3         ipv6-allhosts


netstat -l -p | grep firefox while firefox is running:
tcp        0      0 localhost:7055          *:*                     LISTEN      19904/firefox      
unix  2      [ ACC ]     STREAM     LISTENING     429288 19904/firefox       /tmp/orbit-gschukin/linc-4dc0-0-75b7b497baa4d


I also noted that I can access ssh via 127.0.0.2 without a glitch and the output for netstat -l -p | grep ssh is:
tcp        0      0 *:ssh                   *:*                     LISTEN      -                  
tcp        0      0 *:ssh                   *:*                     LISTEN      -                  
unix  2      [ ACC ]     STREAM     LISTENING     11210  3686/gnome-keyring- /tmp/keyring-Gq4Haq/ssh

A bit confused why it is listed two times and why it is *.ssh while Firefox is localhost:7055

-Gleb

[Mirko Nasato]

So there's no 127.0.0.2 in /etc/hosts... weird. Not sure what's going
on, but I'd try replacing "localhost" with "127.0.0.1" in the
WebDriver code and see if that makes any difference.

2009/3/24 Gleb Schukin <gs1...@gmail.com>:

[Julian Harty]

Any chance you can send the file in the original format (as saved by Wireshark) which will make it easier to analyze :)

PS: FYI I'm based in the UK so will work on this in my waking hours (GMT).

2009/3/24 Gleb Schukin <gs1...@gmail.com>

[Julian Harty]

Also, try your machine's name schukin-laptop

PS: I assume you're based in Russia (in terms of timezones, etc).

2009/3/24 Mirko Nasato <mirko....@gmail.com>

[Gleb Schukin]

Hello Julian,

Here is the log saved in wireshark format.

Frame 1 - Frame 2 - telnet to localhost:7055
Frame 3 - Frame 4 - telnet to schukinlaptop:7055

both without Firefox running

Frame 5 - Frame 10 - don't know what it is but it seems that this happed after test is started
Frame 11 - Frame 370 - trying to connect to Firefox binary
Frame 371 - Frame 380 - telnet to localhost:7055
Frame 381 - Frame 390 - telnet to schukin-laptop:7055

Yes, I'm from Russia - home for snow, vodka, balalaikas and bears going circle on the Red Square =))

-Gleb

[Gleb Schukin]

I have managed to successfully start the test under ArchLinux under Virtualbox with minimum packages, only Gnome, JDK and Eclipse.
So the problem is with my configs in OpenSUSE :(

-Gleb

[Mirko Nasato]

No surprise there... you're certainly not the first person to try WebDriver on Linux. ;)

Another guess: in your /etc/hosts file try not defining localhost as ipv6, i.e. change

::1             localhost ipv6-localhost ipv6-loopback

to

::1             ipv6-localhost ipv6-loopback

Cheers

Mirko

2009/3/25 Gleb Schukin <gs1...@gmail.com>

[Julian Harty]

FYI I and others e.g. Simon use WebDriver extensively on linux (Ubuntu mainly) and it generally behaves well. I've discovered a post that might give a clue https://www.linuxquestions.org/questions/susenovell-60/hosts-file-ip-127.0.0.2-273340/ - do you happen to have 2 network adapters in the machine? If so you might try removing or disabling one (the one that maps to 127.0.0.2 if you have a choice) and retry WebDriver. The wireshark trace confirms the webdriver test script is trying to connect using 127.0.0.2 (frames 11 to 370) while your manual telnet sessions are using 127.0.0.1 which accounts for the difference.

We may need to find a smarter way to support multiple network cards in WebDriver - let me know whether having a single network card (NIC) works for you. And if anyone on the list has suggestions on how to control the source IP address in this situation programatically please shout :) 

2009/3/25 Mirko Nasato <mirko....@gmail.com>

[Gleb Schukin]

Hello,

My notebook has only one NIC and according to ifconfig it's true:
schukin-laptop:/home/gschukin # ifconfig
eth0      Link encap:Ethernet  HWaddr 00:17:31:AE:C4:7D 
          inet addr:192.168.2.62  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::217:31ff:feae:c47d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:85000 errors:0 dropped:0 overruns:0 frame:0
          TX packets:71516 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:53398817 (50.9 Mb)  TX bytes:6845448 (6.5 Mb)
          Interrupt:20 Base address:0x4400

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:402 errors:0 dropped:0 overruns:0 frame:0
          TX packets:402 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:11824 (11.5 Kb)  TX bytes:11824 (11.5 Kb)

I'm also attaching wireshark logs trying to connect to 127.0.0.1:ssh, 127.0.0.2:ssh and 127.0.0.3:ssh, as you can see I have successfully connected to localhost via all of that addresses.

-Gleb

PS I'll try to make a new clean SUSE install on a virtual machine and see what will happen then.

[Gleb Schukin]

I've just talk to our admins, it seems that they find where the problem is or maybe just explain it to me :):
Firefox listens to 127.0.0.1:7055 not 0.0.0.0:7055 so any connections to 127.0.0.2:7055 will fail
They recommend either start Firefox listening to 0.0.0.0:7055 or to force client part to connect to 127.0.0.1:7055 not 127.0.0.2:7055

So their question is: Why does client part tries to connect to 127.0.0.2?

[Julian Harty]

Thanks for the update. The 127.0.0.2 address is unusual and probably exposing a problem in the underlying WebDriver code. We're going to take a look at the code and see if we can fix the problem. Good luck meanwhile with creating a clean virtual image.

2009/3/26 Gleb Schukin <gs1...@gmail.com>

[Mirko Nasato]

2009/3/26 Gleb Schukin <gs1...@gmail.com>:

> I've just talk to our admins, it seems that they find where the problem is
> or maybe just explain it to me :):
> Firefox listens to 127.0.0.1:7055 not 0.0.0.0:7055 so any connections to
> 127.0.0.2:7055 will fail
> They recommend either start Firefox listening to 0.0.0.0:7055 or to force
> client part to connect to 127.0.0.1:7055 not 127.0.0.2:7055
>
> So their question is: Why does client part tries to connect to 127.0.0.2?
>

That's why I was suggesting to try and modify the WebDriver code to
use "127.0.0.1" rather than "localhost"...

I'm not sure WebDriver should listen on all interfaces by default,
that could be a security risk.

Cheers

Mirko

[Gleb Schukin]

Well I have just created openSUSE 11.1 Gnome virtual machine, not modifying any configuration files and the result is the same as on the real machine :( So I'll create a ticket for that.

2Mirko
As far as I understand FirefoxDriver code, the problem lies somewhere in optainLoopbackAddress method returning incorrect IP for localhost so forcing is just a workaround, but i'll try it.

2All
What should I change to force FirefoxDriver explicitly use 127.0.0.1 instead of localhost? Should I modify FirefoxDriver constructor?

-Gleb

[Mirko Nasato]

2009/3/26 Gleb Schukin <gs1...@gmail.com>:

>
> 2Mirko
> As far as I understand FirefoxDriver code, the problem lies somewhere in
> optainLoopbackAddress method returning incorrect IP for localhost so forcing
> is just a workaround, but i'll try it.
>

If you just replace "localhost" with "127.0.0.1" in FirefoxDriver -
just as a quick try - that won't call obtainLoopbackAddress() any
more.

Cheers

Mirko

[Simon Stewart]

On Thu, Mar 26, 2009 at 9:56 AM, Mirko Nasato <mirko....@gmail.com> wrote:

> I'm not sure WebDriver should listen on all interfaces by default,
> that could be a security risk.

Agreed. That's why I didn't enable it to start with, and just made it
listen on the loopback device. We could add a preference to allow
users to specify the address to bind to, but we should probably
(also?) do a better job of scanning the interfaces and identifying
loopback devices by the sound of it.

Thanks to everyone who's contributed on this thread: I know that it's
terribly frustrating when things like this don't work.

Regards,

Simon

[Gleb Schukin]

After a little change in code, I've successfully managed to perform the test :)

In FirefoxDriver constructor public FirefoxDriver(FirefoxBinary binary, FirefoxProfile profile) {...}
I switched host from "localhost" to "127.0.0.1"
And everything works fine.

-Gleb

[Mirko Nasato]

That makes me think: would hard-coding "127.0.0.1" as the default be
such a bad hack? Are there any machines out there that don't actually
use 127.0.0.1 for loopback?

Cheers

Mirko

2009/3/27 Gleb Schukin <gs1...@gmail.com>:

[Simon Stewart]

*sigh* You'd be surprised.

Simon