Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows: "dial tcp 127.0.0.1:2828: connectex: No connection could be made" #32

Closed
tombh opened this issue Jun 12, 2018 · 20 comments
Closed

Windows: "dial tcp 127.0.0.1:2828: connectex: No connection could be made" #32

tombh opened this issue Jun 12, 2018 · 20 comments
Labels

Comments

@tombh
Copy link
Member

@tombh tombh commented Jun 12, 2018

I don't how popular running Browsh on Windows is? But we might as well have it working if it's possible. At the moment Firefox crashes during boot, I don't know why.

Of course Windows users, as I suspect most users, will use Browsh over Mosh/SSH, where Browsh runs on a Linux VM.

@tombh tombh added the bug label Jun 12, 2018
@tombh
Copy link
Member Author

@tombh tombh commented Jul 9, 2018

As a user on Twitter reports, the issue seems to be;

dial tcp 127.0.0.1:2828: connectex: No connection could be made because the target machine actively refused it.

Which is Firefox's Marionette RPC. So this could be a port permissions error on Windows?

@dertuxmalwieder
Copy link

@dertuxmalwieder dertuxmalwieder commented Jul 9, 2018

For me, browsh starts fine but crashes instantly after Firefox has been started:

panic: runtime error: invalid memory address or nil pointer dereference◙[signal 0xc0000005 code=0x0 addr=0x8 pc=0x4b4cdd]◙◙goroutine 19 [running]:◙os.(*Process).signal(0x0, 0x7cd560, 0x91c3c8, 0xc0422b4070, 0x0)◙    .go:58 +0x2d◙(0x0, , :◙
C:\>

Sometimes it manages to display the "waiting for Firefox to connect" screen, at least.

Windows 10, Firefox 64 Bit.

@tombh
Copy link
Member Author

@tombh tombh commented Jul 10, 2018

Thanks for extra info

@janmechtel
Copy link

@janmechtel janmechtel commented Jul 10, 2018

Same herein Windows 10, Firefox 64 Bit.

  1. I kill all firefox processes
  2. Run browsh_1.2.3_windows_amd64

dial tcp 127.0.0.1:2828: connectex: No connection could be made because the target machine actively refused it.

  1. Run browsh_1.2.3_windows_amd64 again:
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x8 pc=0x4b4cdd]

goroutine 19 [running]:
os.(*Process).signal(0x0, 0x7d2540, 0x9233c8, 0xc042354070, 0x0)
	/home/travis/.gimme/versions/go1.10.3.linux.amd64/src/os/exec_windows.go:58 +


@jamespeace
Copy link

@jamespeace jamespeace commented Jul 10, 2018

I have the same problem like @janmechtel on Windows7

@parasdsingh
Copy link

@parasdsingh parasdsingh commented Jul 10, 2018

Same here! And as a windows user I'd prefer running it natively than wrapped in mosh tbh

@Structed
Copy link

@Structed Structed commented Jul 10, 2018

Same here. I was using the -firefox option to specify the path for the x64 firefox executable.

When starting browsh via powershell, it opens a new Firefox window, spits out above panic message and the powershell process hangs. See screenshot
image

@tombh tombh changed the title Windows build doesn't seem to start Firefox very well Windows: "dial tcp 127.0.0.1:2828: connectex: No connection could be made" Jul 13, 2018
@tombh
Copy link
Member Author

@tombh tombh commented Jul 13, 2018

@janmechtel Thanks for clarifying. (1) is really the main problem, (2) is just the fact that Browsh was unable to close Firefox in the first attempt.

I'm afraid this isn't a top priority for me to fix. Mainly as Browsh's main target is to be run on a remote server (in order to get the bandwidth savings for people on slow/expensive bandwidth locally). Also I haven't used windows in nearly 20 years now, so I'm not at all familiar with how to start debugging this.

But I'll certainly leave this issue open. I'd love to see this fixed. Maybe there's someone else that has more Windows experience that can help?

@tombh
Copy link
Member Author

@tombh tombh commented Jul 13, 2018

We may have found a fix! @morrah discovered that after seeing the "dial tcp" error Firefox was indeed running in the background. So he tried running Browsh again but this time with the -use-existing-ff.

In which we have a workaround. The idea being that you need to have headless Firefox running before starting Browsh. You can do this in 1 of 2 ways:

  1. Manually start your Firefox from the CLI with these arguments --marionette --headless.
  2. Run Browsh as you normally would so it starts Firefox, then wait for it crash.

You should now be able to run Browsh with the -use-existing-ff argument.

@tombh tombh mentioned this issue Jul 13, 2018
@tombh
Copy link
Member Author

@tombh tombh commented Jul 20, 2018

This should be formally fixed with a non-hacked solution as of v1.4.0. I'll reopen if this exact problem is reported again.

@tombh tombh closed this Jul 20, 2018
@Some-T
Copy link

@Some-T Some-T commented Jul 28, 2018

Was having a look at this on Windows to see if I could get it working, noticed on virustotal.com it indicates the following:

https://i.gyazo.com/b2510770f2475e95af63c30a41e8fd64.png

Can anyone confirm if this is a false positive, please?

@tobimensch
Copy link
Collaborator

@tobimensch tobimensch commented Jul 28, 2018

@Some-T
It definitely is a false positive. Please post in #67 about this and not here though.

@ghost
Copy link

@ghost ghost commented Oct 1, 2018

  1. Opened CLI as Admin
  2. Run browsh_1.4.13_windows_amd64.exe

I got this error:

Error reading Windows registry: The system cannot find the file specified.

@tobimensch
Copy link
Collaborator

@tobimensch tobimensch commented Oct 2, 2018

@MarioColuzzi
Looks more like issue #217 than this one! Please post there.

@sergeevabc
Copy link

@sergeevabc sergeevabc commented Dec 16, 2018

So sad it does not work on Windows 7.

@tonybengue
Copy link

@tonybengue tonybengue commented Feb 12, 2019

It seems to not work on Windows even with some flags added in the CLI

@AgentConDier
Copy link

@AgentConDier AgentConDier commented May 12, 2019

Windows 10 Pro 1803; Firefox x64 66.0.6; browsh 1.5.0
Did anyone get this to work the way it is supposed to? I somewhat did, but it feels like a hack or random discovery. My thoughts were as follows:
As far as I know the problem is that when browsh tries to connect to firefox after starting it, firefox is not yet listening on port 2828 and windows refuses the connection, because if I try to connect to the same port after firefox has started, it works:

>curl localhost:2828
50:{"applicationType":"gecko","marionetteProtocol":3}

So the solution is supposed to be running browsh.exe --firefox.use-existing, but this just prints the Waiting for a user-initiated Firefox instance to connect... message and nothing happens. If I understood this right, this means that browsh is waiting for firefox to start, load the browsh addon and connect to the browsh process. But this will never happen, since the addon is not installed. As far as I know, there is no version of the addon available for manual install.
So is there any way to tell browsh to connect to a running firefox marionette so the addon can be installed? Or am I missing something?
Furthermore, you can not run browsh without --firefox.use-existing while firefox is running because this results in a

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x8 pc=0x4cc60d]

goroutine 35 [running]:
os.(*Process).signal(0x0, 0x9c18a0, 0xbe6470, 0xc0420fa020, 0x0)
	/home/travis/.gimme/versions/go1.10.5.linux.amd64/src/os/exec_windows.go:58 +0x2d
os.(*Process).Signal(0x0, 0x9c18a0, 0xbe6470, 0xc042057e80, 0x18)
	/home/travis/.gimme/versions/go1.10.5.linux.amd64/src/os/exec.go:129 +0x46
os.(*Process).kill(0x0, 0xc042045228, 0xc042057e80)
	/home/travis/.gimme/versions/go1.10.5.linux.amd64/src/os/exec_posix.go:54 +0x4a
os.(*Process).Kill(0x0, 0x3, 0x3)
	/home/travis/.gimme/versions/go1.10.5.linux.amd64/src/os/exec.go:114 +0x32
browsh/interfacer/src/browsh.startHeadlessFirefox()
	/home/travis/gopath/src/browsh/interfacer/src/browsh/firefox.go:85 +0x3b9
created by browsh/interfacer/src/browsh.setupFirefox
	/home/travis/gopath/src/browsh/interfacer/src/browsh/firefox.go:288 +0x3c

Incidentally, doing this managed to install the addon despite crashing. The addon then promptly connected to the waiting instance started with --firefox.use-existing which worked like a charm, so I guess I did get browsh to work. But this is tedious and hacky.
UPDATE: Silly me, the addon is available as browsh-version-an.fx.xpi, see releases

@jspraul
Copy link

@jspraul jspraul commented Aug 14, 2019

Windows HOWTO, circa August 2019

Windows 10, Firefox 68, Brow.sh 1.64

  1. Download the add-on from the bottom of the releases list (currently browsh-1.6.4-an.fx.xpi)
  2. Open Firefox and install the add-on from the file
  3. Run "\Program Files\Mozilla Firefox\firefox.exe" --marionette --headless
  4. Run browsh_1.6.4_windows_amd64.exe --firefox.use-existing

Posted here because this issue is linked from the main website. I can add more details if necessary.

@MeetPing
Copy link

@MeetPing MeetPing commented May 25, 2020

It's annoying to see a unfixed bug being closed all the time. The error I'm getting is concerning the registry and i want direct help into how this can be fixed.

@agent255
Copy link

@agent255 agent255 commented Feb 11, 2021

same here @MeetPing Its realllly annoying

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet