Open tam481 opened 5 months ago
Hi @tam481 , could you provide some details about what is not working?
At the moment the UI is not built by me, but provided by the matterbridge project. This project uses two ports. The first is the http port 8283, which should not be a problem to be used with a reverse proxy. The second port 8284 is used for a websocket connection. Unfortunately this port is hardcoded and cannot be changed. It is needed for the frontend to be usable.
I use Traefik and have tried to get matterbridge to work behind it and it just does not work.
labels:
- "traefik.enable=true"
- "traefik.docker.network=backend-network"
## HTTP Configuration
- "traefik.http.routers.matterbridge-rtr.entrypoints=websec-ep"
- "traefik.http.routers.matterbridge-rtr.tls=true"
- "traefik.http.routers.matterbridge-rtr.rule=Host(`bridge.${DOMAIN}`)"
- "traefik.http.routers.matterbridge-rtr.tls.certresolver=tlsconn"
- "traefik.http.routers.matterbridge-rtr.service=matterbridge-svc"
- "traefik.http.services.matterbridge-svc.loadbalancer.server.port=8283"
## WebSocket Configuration
- "traefik.http.routers.matterbridge-ws-rtr.entrypoints=websec-ep"
- "traefik.http.routers.matterbridge-ws-rtr.tls=true"
- "traefik.http.routers.matterbridge-ws-rtr.rule=Host(`bridge.${DOMAIN}`) && Path(`/ws`)"
- "traefki.http.middlewares.matterbridge-ws.headers.customRequestHeaders.X-Forwarded-Proto=ws"
- "traefik.http.middlewares.matterbridge-ws.headers.customResponseHeaders.X-Forwarded-Proto=ws"
- "traefik.http.middlewares.websocket-ws.headers.customRequestHeaders.Upgrade=websocket"
- "traefik.http.middlewares.websocket-ws.headers.customRequestHeaders.Connection=Upgrade"
- "traefik.http.middlewares.websocket-ws.headers.customRequestHeaders.X-Forwarded-Proto=https,wss"
- "traefik.http.routers.matterbridge-ws-rtr.middlewares=matterbridge-ws"
- "traefik.http.routers.matterbridge-ws-rtr.service=matterbridge-ws-svc"
- "traefik.http.services.matterbridge-ws-svc.loadbalancer.server.port=8284"
## TCP Routers/Service
- "traefik.tcp.routers.matterbridge-tcp-rtr.entrypoints=matter-ep"
- "traefik.tcp.routers.matterbridge-tcp-rtr.rule=HostSNI(`*`)"
- "traefik.tcp.routers.matterbridge-tcp-rtr.tls=true"
- "traefik.tcp.routers.matterbridge-tcp-rtr.service=matterbridge-tcp-svc"
- "traefik.tcp.services.matterbridge-tcp-svc.loadbalancer.server.port=5540"
## UDP Routers/Service
- "traefik.udp.routers.matterbridge-udp-rtr.entrypoints=matter-ep-udp"
- "traefik.udp.routers.matterbridge-udp-rtr.service=matterbridge-udp-svc"
- "traefik.udp.services.matterbridge-udp-svc.loadbalancer.server.port=5540"```
Why not run the bridge in host network mode and have treafik use the host local ip as it's target for this service? I do this with matterbride/homeassistant/etc. I did need to add to my traefik container:
extra_hosts:
- "host.docker.internal:10.0.3.1"
Your ip will likely be different.
I'm running into the same issue with ingress-nginx.
Also, is port 8284 still needed? When version 1.6.0 comes up it looks like both HTTP and ws are listening on the same port
[16:41:50.191] [Matterbridge] Created Matterbridge Plugin Directory: /root/Matterbridge
[16:41:50.194] [Matterbridge] Matterbridge version 1.3.9 mode running on Linux 6.6.32-talos linux x64
[16:41:50.196] [Matterbridge] Plugin /usr/local/lib/node_modules/matterbridge-home-assistant/package.json already added to matterbridge
[16:41:50.849] [Matterbridge] Matterbridge version 1.3.9 mode bridge restart mode docker running on Linux 6.6.32-talos linux x64
[16:41:50.981] [Matterbridge] The frontend http server is listening on http://172.22.1.44:8283
[16:41:50.981] [Matterbridge] The WebSocketServer is listening on ws://172.22.1.44:8283
[16:41:50.995] [Matterbridge] Loading plugin matterbridge-home-assistant type DynamicPlatform
[16:41:51.044] [Matterbridge] Loaded plugin matterbridge-home-assistant type DynamicPlatform (entrypoint /usr/local/lib/node_modules/matterbridge-home-assistant/lib/index.js)
[16:41:51.044] [Matterbridge] Starting plugin matterbridge-home-assistant type DynamicPlatform
[16:41:51.044] [HomeAssistantPlatform] onStart called with reason: Matterbridge is starting
[16:41:51.060] [Matterbridge] Started plugin matterbridge-home-assistant type DynamicPlatform
I'm running the docker image through a helm deploy on talos linux.
Why not run the bridge in host network mode and have treafik use the host local ip as it's target for this service? I do this with matterbride/homeassistant/etc. I did need to add to my traefik container:
extra_hosts: - "host.docker.internal:10.0.3.1"
Your ip will likely be different.
As matterbridge requires to run with host network enabled, docker bridge networks do not work with it. I don’t know traefik in detail and I don’t know your docker deployment config, but did you actually try to use the host‘s external ip address as a target of traefik?
As long as matterbridge runs in host network mode, there will be no container ip to connect with.
I run this @ home on qnap nas. That ip is the ip of my docker-host network's gateway - which is also capable of accessing host machine services (aka matterbridge). This might be qnap specific ip-masquerading/routing, but I suspect something similar will work for others. By supplying docker an extra_hosts: on the target container - it tells traefik where to attach to docker containers running in host mode - even though traefik is usually used for routing to and protecting usually un-authed internal containers, you can keep your routing tidy with the above (it's also possible to make admin UIs when on separate ports look something like ports: -localhost:8080:8080, so that the admin port even when running in host. Not super pertinent to matterbridge-homeassisting-plugin, or even matterbridge for that matter (heh).
Any updates here @tam481 ? Did any of the hints of @rexhoffman work? Just make sure to enable websocket support for the proxy-target.
@dmfrey the extra port for the websocket is not needed anymore. I removed it from the documentation.
@t0bst4r what version is that in? I'll make sure it's updated and see if I see the logs and such coming through the web interface
@t0bst4r nevermind. I see the details on the breaking change from v1 to v2. I need to refactor my helm release and push it back out there. I'll report back later.
The web socket port is not a thing I changed. It’s part of matterbridge itself. Anyway it seems to be like that (http and websocket on the same port) since 1.6.x, but it’s never bad to have someone testing the newest version 😄
Hi all, Sorry. I have tried a couple of days ago since the ports have been merged and I could not get it to work. Also the 4045 port does not work at all. Alexa cannot see Matterbridge. As regards the interface, it just doesn't work. I get blank page.
I am not very keen on using it the way @rexhoffman suggested. Sorry.
I’ll give it a try tomorrow with nginx-proxy-manager, to see if it’s not working in general, or if it’s a traefik thing.
Could you also please provide some details about your deployment? Maybe the whole Part of the compose file where Matterbridge is defined.
@t0bst4r A fix is in for 1.4.1
Version 1.4.1 is not yet released, since Matterbridge is currently going through a refactoring and we‘ll probably need to wait for it to be done.
Just upgraded to 1.4.1. Please upgrade and test.
Just tried it. No change in the behaviour. It flashes the screen and I can just about see a little box saying "Welcome to Matterbridge" that looks like it's asking for a password before the page goes completely white
Here are my labels for the service:
labels:
- "traefik.enable=true"
- "traefik.docker.network=backend"
## HTTP Configuration
- "traefik.http.routers.matterbridge-rtr.entrypoints=websec-ep"
- "traefik.http.routers.matterbridge-rtr.tls=true"
- "traefik.http.routers.matterbridge-rtr.rule=Host(`matterbridge.${EXT_DOMAIN}`) || Host(`matterbridge.${INT_DOMAIN}`)"
- "traefik.http.routers.matterbridge-rtr.tls.certresolver=freemyip"
- "traefik.http.routers.matterbridge-rtr.service=matterbridge-svc"
- "traefik.http.services.matterbridge-svc.loadbalancer.server.port=8283"
## WebSocket Configuration
- "traefik.http.routers.matterbridge-ws-rtr.entrypoints=websec-ep"
- "traefik.http.routers.matterbridge-ws-rtr.tls=true"
- "traefik.http.routers.matterbridge-ws-rtr.rule=Host(`matterbridge.${EXT_DOMAIN}`) || Host(`matterbridge.${INT_DOMAIN}`) && Path(`/ws`)"
- "traefki.http.middlewares.matterbridge-ws.headers.customRequestHeaders.X-Forwarded-Proto=ws"
- "traefik.http.middlewares.matterbridge-ws.headers.customResponseHeaders.X-Forwarded-Proto=ws"
- "traefik.http.middlewares.websocket-ws.headers.customRequestHeaders.Upgrade=websocket"
- "traefik.http.middlewares.websocket-ws.headers.customRequestHeaders.Connection=Upgrade"
- "traefik.http.middlewares.websocket-ws.headers.customRequestHeaders.X-Forwarded-Proto=https,wss"
- "traefik.http.routers.matterbridge-ws-rtr.middlewares=matterbridge-ws"
- "traefik.http.routers.matterbridge-ws-rtr.service=matterbridge-ws-svc"
- "traefik.http.services.matterbridge-ws-svc.loadbalancer.server.port=8283"
## TCP Routers/Service
- "traefik.tcp.routers.matterbridge-tcp-rtr.entrypoints=matter-ep"
- "traefik.tcp.routers.matterbridge-tcp-rtr.rule=HostSNI(`*`)"
- "traefik.tcp.routers.matterbridge-tcp-rtr.tls=true"
- "traefik.tcp.routers.matterbridge-tcp-rtr.service=matterbridge-tcp-svc"
- "traefik.tcp.services.matterbridge-tcp-svc.loadbalancer.server.port=5540"
## UDP Routers/Service
- "traefik.udp.routers.matterbridge-udp-rtr.entrypoints=matter-ep-udp"
- "traefik.udp.routers.matterbridge-udp-rtr.service=matterbridge-udp-svc"
- "traefik.udp.services.matterbridge-udp-svc.loadbalancer.server.port=5540"
This is my Traefik config yaml for the Entry Points:
websec-ep:
address: ":443"
matter-ep:
address: ":5540"
transport:
respondingTimeouts:
readTimeout: 0
matter-ep-udp:
address: ":5540/udp"
Hmm since it seems to load something, i have some hope that we’ll get it working somehow 😆
I still think it is a combination of your traefik settings and a bug in matterbridge… but let’s try to figure that out…
Could you open the developer tools of your browser (shortcut: most probably F12), go to the network tab and then reload the page once. You should see several requests loading the files of the webpage and probably some API calls and the websocket. Could you please share which ones are failing and why (status codes and responses and suspicious headers if any) ?
a bit off topic:
Are you deploying the container in a docker bridge network? Do you try to proxy the matter port 5540 tcp & udp to connect your matter controller like Alexa? Did you get THAT working already?
because project-chip/matter.js states that it must run on host network for matter to work properly. I would be very interested if you tell me it’s working with bridge & proxy.
It's pretty close for me. If I set a load balancer IP address, I can load the whole UI and it connects to the websocket. If i attempt to go through my ingress with a host name, it doesn't. However, what you mentioned above in is probably the issue. That's exposing it on 443. So it can't find 5540. I'll see if I can adjust my ingress to expose 5540 instead of 443.
Hmm since it seems to load something, i have some hope that we’ll get it working somehow 😆
I still think it is a combination of your traefik settings and a bug in matterbridge… but let’s try to figure that out…
Could you open the developer tools of your browser (shortcut: most probably F12), go to the network tab and then reload the page once. You should see several requests loading the files of the webpage and probably some API calls and the websocket. Could you please share which ones are failing and why (status codes and responses and suspicious headers if any) ?
a bit off topic:
Are you deploying the container in a docker bridge network? Do you try to proxy the matter port 5540 tcp & udp to connect your matter controller like Alexa? Did you get THAT working already?
because project-chip/matter.js states that it must run on host network for matter to work properly. I would be very interested if you tell me it’s working with bridge & proxy.
Sorry. I've been away.
No. I run it attached to the host network. I've set up entry points for TCP and UDP for 5540 but Alexa could not connect to Matterbridge.
I'm exposing 443 on TCP and TCP+UDP 5540. The reverse-proxy is reverse proxying the connections to the Matterbridge container on port 8283
I believe that this stems from the fact that the the app tries to open an insecure websocket connection even when accessed over SSL and the browser blocks the connection.
I have raised an issue for this here: https://github.com/Luligu/matterbridge/issues/96
Did you configure the reverse proxy to route 'http://127.0.0.1:8283' to 'https://domain.com'? It works fine when it's set to 'http://domain.com/'.
The SSL option is not configured in matterbridge for this Docker project. Once my PR is approved, please update the configuration to route 'https://127.0.0.1:8283' to 'https://domain.com'.
Your PR is merged and released as 2.7.1
.
Since most people want the reverse proxy to manage SSL, I still don’t think that solves it for everyone.
Working
Domain
No response
What is actually missing?
Hi @t0bst4r Please support running Matterbridge behind Reverse Proxy. I use Traefik and I run all my containers behind it including Home Assistant.