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

Can't connect to WSL with post 400 error about connection refused - emulator doesn't connect to localhost #2433

Open
JeremyKPark opened this issue Jun 22, 2023 · 9 comments
Labels
Bug Your classic code defect Enhancement New feature or request to evolve an additional feature

Comments

@JeremyKPark
Copy link

Github issues should be used for bugs and feature requests. Use Stack Overflow for general "how-to" questions.

Version

4.14.1

Describe the bug

Can't connect to local WSL2 ubuntu bot from windows emulator because its trying to connect to 127.0.0.1 not localhost. I can view my bots json running in WSL on localhost:3978 from a windows edge browser but if I try the same url with 127.0.0.1:3978 it doesn't work. unfortunately the emulator stubbornly will not let me use localhost, and converts it to 127.0.0.1 so I can't seem to get around this.

Expected behavior

It should be able to connect to a local bot on localhost:3978 not 127.0.0.1:3978

I have tried putting the no_proxy environment variable in and it still doesn't seem to work. Run out of options.

[bug]

@JeremyKPark JeremyKPark added the Bug Your classic code defect label Jun 22, 2023
@OEvgeny
Copy link
Collaborator

OEvgeny commented Jun 22, 2023

Technically WSL is a virtual machine, so it doesn't bind to the host OS localhost, instead the port is opened on the virtual machine ip.

To get the WSL instance address you could use:

From windows shell:

wsl hostname -i

From linux shell:

ip addr show eth0

Then use the ip address provided for bot configuration.

There are probably some extra steps required to get this working. Can't test it myself at the moment.

@JeremyKPark
Copy link
Author

ok so windows shell shows 127.0.1.1 .. linux shell shows 172.29.23.230/20

from my windows browser, I can access localhost:3978 making a connection to wsl but bot emulator doesn't allow me to use that .. 127.0.1.1:3978 and 172.29.23.230:3978 do not work.

I'm going to try some ngrok stuff later today but it seems like a situation where I shouldn't need to tunnel into my own machine when the port is exposed already

Another bug I see is that the 'local override' field allows only one character at a time, before pushing the text selection back to 'path to ngrok' which makes it difficult to add the localhost override but not impossible.

Thanks for your help.

@JeremyKPark
Copy link
Author

Ok the 172.29.23.230:3978 suddenly started to go through for some reason, but now I get POST 500 error ECONNREFUSED. But I do see the error as well in the wsl terminal so at least there's a connection. Its also still complaining about ngrok not spawning even though I told it to override.

@JeremyKPark
Copy link
Author

Ok I got it to work. The key was I had to edit the bot's restify sever.listen function in the index.js. I'm using one of the botbuilder samples, and it doesn't define the server in the server.listen command, it leaves it open for interpretation. If anyone else having issues, I was able to get it to work by finding this line below and adding the 'localhost' part. I was using the nodejs echo bot sample.

server.listen(process.env.port || process.env.PORT || 3978, 'localhost', () => {

I assume I will have to change this back if I later want to put this live anywhere, but at least I can test it locally for now with WSL ubuntu on my PC

@OEvgeny
Copy link
Collaborator

OEvgeny commented Jun 22, 2023

Another bug I see is that the 'local override' field allows only one character at a time, before pushing the text selection back to 'path to ngrok' which makes it difficult to add the localhost override but not impossible.

This is a known issue and should be fixed after #2426 gets in

Its also still complaining about ngrok not spawning even though I told it to override.

I did a quick test and saw the same issue. Probably there is a bug related to local overrides

Glad it worked for you and thanks for details! Will pin this issue for anyone having issues with WSL.

@OEvgeny OEvgeny pinned this issue Jun 22, 2023
@ethanabrooks
Copy link

Hi before we close this, I was hoping I could get some clarification on @JeremyKPark's solution. I am currently doing this:

  1. I have:
server.listen(process.env.port || process.env.PORT || 3978, "localhost", () => {
  console.log(`\nBot Started, ${server.name} listening to ${server.url}`);
});

in index.js, as recommended.
2. I run node lib/index.js in WSL.
3. In the Bot Framework Emulator, I use "http://localhost:3978/api/messages" for Bot URL. In the output section I get:

[15:34:27]Connecting to bot on http://localhost:3978/api/messages
[15:34:27]Emulator listening on http://[::]:63262
[15:34:27]ngrok not configured (only needed when connecting to remotely hosted bots)
[15:34:27]Connecting to bots hosted remotely
[15:34:27]Edit ngrok settings
[15:34:27]-> conversationUpdate
[15:34:27]POST200directline/conversations/<conversationId>/activities
  1. I send the message "hello" and the server displays activity in the WSL terminal, but then displays:
[onTurnError] unhandled error: FetchError: request to http://localhost:63262/v3/conversations/c62ae350-153a-11ee-aac3-bfb73ba3e6de%7Clivechat/activities/de4a6cd0-153a-11ee-aac3-bfb73ba3e6de failed, reason: connect ECONNREFUSED 127.0.0.1:63262

Appreciate your help with this error!

@JeremyKPark
Copy link
Author

Yeah its not a perfect solution. It was working for me both ways back and forth originally when I wrote this last message with 'npm start' but then stopped working the next day when I got up and I'm not 100% sure why but I made a few changes before I shut down my computer that might have changed something.

One this I did note is that, I had upgraded to node 18 from 16 in WSL and noticed after that 'localhost' was no good anymore, and using '0.0.0.0' instead seemed to allow messages in from windows -> WSL, so I can at least trigger the bot and view error messages in the terminal.. with this setting the bot says its listening to 127.0.0.1 when it starts.. but the messages do not want to come back from WSL -> windows bot emulator.. haven't figured that out yet, and I spent the rest of the weekend testing my bots functionality by outputting error messages in terminal, which was not the the most fun way to code, but it did at least give me output.

I think because you can't define which port the bot emulator is running on in windows, ie. http://[::]:XXXX, because you can't change this to localhost or 0.0.0.0 as well, I'm not sure it will ever work. Or maybe its because I need to forward a port in WSL or something back to windows, but the port is always random on the windows side so its tricky.

Overall, emulator needs to run some bug fixes here or some additional options to define which local port to be set for listening. This is my feedback. I will only ever use npm/node in WSL so its important for people like me that this is working smoothly, if we are to use the bot framework effectively. Also some documentation on how to set it up with WSL would probably be helpful for future users.

@ethanabrooks
Copy link

Hi Jeremy, thanks for the update. I did ultimately switch to windows for development, but I definitely miss the features that I have in WSL. Hope the developers can weight in.

@OEvgeny
Copy link
Collaborator

OEvgeny commented Jul 3, 2023

Overall, emulator needs to run some bug fixes here or some additional options to define which local port to be set for listening. This is my feedback. I will only ever use npm/node in WSL so its important for people like me that this is working smoothly, if we are to use the bot framework effectively. Also some documentation on how to set it up with WSL would probably be helpful for future users.

Thanks for the feedback. I'll keep this open to track these improvements

@OEvgeny OEvgeny added the Enhancement New feature or request to evolve an additional feature label Jul 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Your classic code defect Enhancement New feature or request to evolve an additional feature
Projects
None yet
Development

No branches or pull requests

3 participants