browser icon indicating copy to clipboard operation
browser copied to clipboard

remote debug session not working

Open basz opened this issue 1 year ago • 4 comments

Hi

I'm am trying to get a remote debug session working and can only get it to work with network_mode: host. Unfortunatly that is not an option as the running SPA clients needs to resolve other services via the internal docker DNS service names.

What does work with network_mode: host

tunnel directly into the device with

ssh -i /Users/bas/.ssh/special-identity-rsa -L 0.0.0.0:9222:127.0.0.1:9222 [email protected] -p 22222

or with a balena tunnel (for real remote devices) and then a tunnel trhough that tunnel

balena tunnel e41e86a041857b8db2c75cb4956a32f3 -p 22222:127.0.0.1:4321
// other session
ssh -i /Users/bas/.ssh/special-identity-rsa -L 9222:127.0.0.1:9222 [email protected] -p 4321

The debug session shows up at chrome://inspect/devices#devices but the SPA is not loaded or not working correctly.

So this seems a configuration issue. What coudl it be...

My docker-compose.yaml


  browser:
    image: bh.cr/balenalabs/browser-aarch64/2.5.1
    depends_on:
      - controller
    restart: always
    # we can *not* use `network_mode: host` as the browser container needs to be able resolve hosts running
    # inside the docker compose context. In addition we *must* also use an explicit LAUNCH_URL as automatic
    # discovery of an exposed http service requires 'work_mode: host'.
    # network_mode: host
    ports:
      # - '5011' # management API (optional)
      - "9222:9222" # Chromium debugging port (optional) http://192.168.178.222:9222/
    environment:
      - LAUNCH_URL=http://controller:5051
      - REMOTE_DEBUG_PORT=9222
      - KIOSK=1
      - LOCAL_HTTP_DELAY=0
      - SHOW_CURSOR=0
      - PERSISTENT=0
      - ENABLE_GPU=1
ignore-gpu-blocklist --enable-gpu-rasterization)
      - FLAGS=--disable-extensions --no-sandbox --password-store=detect --kiosk --incognito --disable-translate --disable-ipv6 --bwsi --auto-launch-at-startup --console --disable-sync --enable-accelerated-2d-canvas --noerrdialogs --no-message-box --no-first-run --start-fullscreen --disable-hang-monitor --disable-infobars --disable-logging --disable-sync --disable-settings-window --disable-pinch --overscroll-history-navigation=0 --disable-session-crashed-bubble --content-shell-hide-toolbar --touchscreen-usable-while-screen-off --disable-features="OverscollHistoryNavigation" --ignore-gpu-blocklist --enable-gpu-rasterization --user-data-dir=remote-profile

basz avatar Dec 15 '23 16:12 basz

Hey @basz

Thanks for the report. I'll try and look into it, but up front I don't know when. I'll set myself a reminder for the first week of 2024, and see what I can figure out.

Phil

phil-d-wilson avatar Dec 21 '23 14:12 phil-d-wilson

Hi Phil,

That's more than I dare to ask. Would be great if you could figure this oh it. I'm sure it's a configuration detail but no luck here.

Also asked Omar various places (discord docker and balena forums)

Have a great holiday!

Bas

basz avatar Dec 21 '23 15:12 basz

Hello Phil, just a gentle reminder to this ticket.

basz avatar Jan 10 '24 08:01 basz

Hai Phil. Did you ever managed to have a look at this? I would love to be able to do remote debugging as a support capability.

basz avatar Feb 13 '24 12:02 basz

+1 on this issue. Similar to what was stated above, I exposed the port for remote debugging 9222 in my docker compose with - "9222:9222", added all the correct flags. Within my container I can curl the endpoint and get data, from http://localhost:9222/json. However, I can't get any response when done from the balena host.

If I add network_mode: host, then I can get a response from the balena host. But then when I try to do the same from my remote machine using the ip address of the balena device, I don't get anything back.

bopete1313 avatar Jul 04 '25 00:07 bopete1313

It seems that byy design, Chromium binds its remote debugging interface strictly to localhost (127.0.0.1)

I noticed there is a flag to change the address, namely --remote-debugging-address=0.0.0.0 but that didn't work. Seems to be limited to only when in headless mode. Also there has been further changes recently that further restricts this.

From trace-chrome: easy remote tracing of Chromium:

The Chromium remote debugging port is disabled by default, but it can be enabled using the command line switch --remote-debugging-port=PORT in the target Chromium instance. This will open an HTTP port in the localhost interface, that can be used to connect. Why localhost? Because this interface does not provide any authentication or encryption. So it is unsafe. It is user responsibility to provide some security (i.e. by using an setting an SSH tunnel between the host and the target device to connect to the remote debugging port).

I did a simple test:

  • installed socat in the container
  • I had 35173 port mapped in my docker-compose, so I changed REMOTE_DEBUG_PORT to 9222
  • I ran socat TCP-LISTEN:35173,fork,bind=0.0.0.0 TCP:127.0.0.1:9222 in the container
  • I added a remote target in chrome://inspect/#devices
Image - The device shows up: Image Image

rahul-thakoor avatar Dec 04 '25 02:12 rahul-thakoor