Con not connect to web server when run on a verdin

Technical Support
, ,
1

This is an odd one. I have a compose file:
docker_web.yml (424 Bytes)

it launches 2 containers. a Server and a Client. I’ve run this on 2 machines.

  1. a PC running Ubuntu WSL. and it works just fine.
  2. Ran it on Verdin SoM from you guys. and I get an error
    WebSocket connection to ‘ws://localhost:3001/ws’ failed:

What could be going on that one system works well, but the other can’t connect to the server.
The docker container were build for both platforms. Do I need something extra for the torizon OS?

2

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Based on the context provided, there are several potential reasons why the WebSocket connection is failing on the Verdin SoM but working on a PC running Ubuntu WSL:

  1. Network Configuration Differences: On the Verdin SoM, localhost refers to the container itself, not the host machine. This means that when the client tries to connect to ws://localhost:3001/ws, it may not be reaching the server container. You should try using the actual IP address of the server container or the host’s IP address in your WebSocket URL instead of localhost.

  2. Server Not Running or Misconfigured: Ensure that the WebSocket server is running and listening on port 3001 within the Verdin SoM environment. Check the server logs for any issues during startup that might prevent it from running correctly.

  3. Firewall or Security Settings: The Verdin SoM might have firewall settings or security configurations that block WebSocket connections. Make sure that the necessary ports are open and accessible.

  4. Docker Networking Mode: Verify that the Docker containers are correctly networked. If they are not on the same network or if the network mode is not set correctly, it may prevent the client from connecting to the server. Consider using the host network mode if necessary.

  5. Platform-Specific Dependencies: Ensure there are no architecture-specific dependencies or configurations affecting the WebSocket server’s operation on Torizon OS. Differences in service management or startup between Torizon OS and Ubuntu WSL could also contribute to the issue.

To resolve the issue, you should check these aspects and consider using the actual IP address instead of localhost in your WebSocket connection string. Additionally, reviewing the logs of both the server and client containers may provide further insights into the connection failure.

Please, also check if these links can help you solve your problem:

Page 44 - Toradex Community.

3

Hey @jeffbelz,

I believe this to be correct. I think you want to refer to the environment variable of the client as WS_URL=ws://api:3001/ws

-Eric

4

WS_URL=ws://api:3001/ws did not work.

I even tried to just put both on host, but that failed too

5

update:

working with my web dev.
WS_URL=ws://api:3001/ws was not being recognized on his end

6

update:

Still having trouble:
we hard coded the ws://webServer:3001/ws. I have to say we are both spinning our tires on this one.

I run it on my WSL ubuntu and it works, but when it’s on the Torizon OS SoM it gives us these errors

docker_web.yml (524 Bytes)

web error
web error776×180 13.1 KB

7

“webServer” is actually “webserver” if you want to try it out. I typed it in wrong. so we hardcoded “webserver” and in the compose I actually do have “webserver” so they match.

8

Hi Jeff,

Did the error log you showed in the previous post come from the web browser on your host?

I may be misunderstanding but this feels like confusion about container names vs domain names vs IP addresses.

Can you clarify what component is trying to connect to the web socket? And where the web socket is running?

Drew

9

Hi Jeff,

I was looking at this again and have some thoughts. Assuming that the websocket connection is only needed from your “client” service, then you can simplify your docker-compose. You don’t need to explicitly map a port in this case since docker-compose will automatically setup an internal network for your containers with DNS setup so that you can access them by the service name. ie the client container can access the api container using the domain name of “api”.

Mapping the port exposes it to the host so that the host can access it but if that is not needed I suggest removing it. Also, the way you have it specified (ie without a specific network IP address such as 127.0.0.1:3001) it is available on all network interfaces of your host. And if you happen to have a network firewall setup with iptables, docker will actually poke a hole in your firewall for that port.

Assuming you do not want that you can simplify your yml file as follows:

services:
  api:
    image: polardelight/p[olardelight_web-server:v1.0
    volumes:
      - /home/jbelz/toggle:/app/data
    environment:
      - DATA_FILE_PATH=/app/data
 
  client:
    image: polardelight/polardelight_web-client:v1
    stdin_open: true
    volumes:
      - /app/node_modules
    environment:
      - WS_URL=ws://api:3001/ws

Although I see you also forwarded port 3000 from the api container and I don’t know how the client container or external units are accessing that.

Drew

10

Hi Jeff,

Have you had a chance to review my posts above? Is this still an issue for you?

Drew