anderbytes 139 Posted August 18, 2016 Share Posted August 18, 2016 (edited) Hello Again. When trying to use the BIND TO IP feature I'm having trouble connecting to it via external networks. - Internal connections seem fine. - If I disable the bind, both internal ad external work fine. The message that appears in browser is only: "Bad Request (Invalid host)" Nothing shows up in logs.. even with debugging mode ON. Funny fact: My laptop (used only as client) has in it's HOST files an entry telling my local emby server IP when looking for the external address. I do that to avoid NAT loopback here at home. "What's so fun?" - When I use the local IP in browser and https port... it lets me connect (with just a ssl warning). If I write the external domin name (that should do the same result), it throws me that error, too. It's almost as if when Emby has IP BIND, it won't like being connected via domain name UPDATE: Using http port with domain name also throws that error. Really not related to HTTP/HTTPS, but instead connecting via domain name. Edited August 18, 2016 by anderbytes Link to comment Share on other sites More sharing options...
Luke 37994 Posted August 18, 2016 Share Posted August 18, 2016 probably due to port forwarding with the docker container. does the port forwarding address in your router match the address you configured for internal binding? Link to comment Share on other sites More sharing options...
anderbytes 139 Posted August 18, 2016 Author Share Posted August 18, 2016 Exactly the same. not 8920... but the same. Link to comment Share on other sites More sharing options...
anderbytes 139 Posted August 18, 2016 Author Share Posted August 18, 2016 Resuming so far: - http://192.168.0.4:8096 - OK - https://192.168.0.4:8920 - OK - https://server.domain.com:8920 - ERROR - https://external.server.ip:8920 - ERROR Link to comment Share on other sites More sharing options...
anderbytes 139 Posted August 18, 2016 Author Share Posted August 18, 2016 If you Windows folks don't have this kind of problems and can't reproduce it..... once again Mono may be the reason :-( Link to comment Share on other sites More sharing options...
Luke 37994 Posted August 18, 2016 Share Posted August 18, 2016 If you Windows folks don't have this kind of problems and can't reproduce it..... once again Mono may be the reason :-( No, not mono related. Probably more likely related to the networking virtualization in the container. Link to comment Share on other sites More sharing options...
anderbytes 139 Posted August 18, 2016 Author Share Posted August 18, 2016 Actually I just moved from Bridge and am trying Host. In Host networking mode... there are really no network-related config to do. Just "Host". Not even ports like in bridge mode Link to comment Share on other sites More sharing options...
anderbytes 139 Posted August 18, 2016 Author Share Posted August 18, 2016 (edited) That's how my config is: Port forwarded in router: 8920 -> 192.168.0.4:8920 (TCP/UDP) Host Server IP: 192.168.0.4 Emby Container Network Mode: HOST Emby HTTPS Port: 8920 Tried bind to 192.168.0.4 only, because Docker creates several other interfaces... Edited August 18, 2016 by anderbytes Link to comment Share on other sites More sharing options...
Luke 37994 Posted August 18, 2016 Share Posted August 18, 2016 Actually I can reproduce, thanks. 1 Link to comment Share on other sites More sharing options...
anderbytes 139 Posted August 18, 2016 Author Share Posted August 18, 2016 Actually I can reproduce, thanks. Easy one? Hard one? Anything I can do to help? Link to comment Share on other sites More sharing options...
Luke 37994 Posted August 18, 2016 Share Posted August 18, 2016 Fixed, thanks. Link to comment Share on other sites More sharing options...
anderbytes 139 Posted August 19, 2016 Author Share Posted August 19, 2016 (edited) Fixed, thanks. Luke, now I set a BIND IP and the error doesn't come back. Thanks! but... I still see the lines below in log: 2016-08-19 11:27:10.2535 Info IDeviceDiscovery: Creating SSDP listener on 192.168.0.4 2016-08-19 11:27:10.2536 Info IDeviceDiscovery: Creating SSDP listener on 127.0.0.1 2016-08-19 11:27:10.2535 Info IDeviceDiscovery: Creating SSDP listener on 172.17.0.1 2016-08-19 11:27:10.3742 Debug HttpServer: Validating host 192.168.0.4 2016-08-19 11:27:10.4534 Debug HttpServer: Validating host 172.17.0.1 Questions: - How can I really be sure the Bind happened correctly? - Why does he creates a ssdp listener to all interfaces? Edited August 19, 2016 by anderbytes Link to comment Share on other sites More sharing options...
Luke 37994 Posted August 19, 2016 Share Posted August 19, 2016 It does bind correctly, but the feature is limited right now to the http server, not upnp socket communications. Link to comment Share on other sites More sharing options...
anderbytes 139 Posted August 19, 2016 Author Share Posted August 19, 2016 (edited) It does bind correctly, but the feature is limited right now to the http server, not upnp socket communications. Ok, got it! If possible... please throw to log (Normal or Debug, don't care) something like: "HTTP Server bound to IP XXX.XXX.XXX.XXX", so you and we users can confirm it's working as expected. If no IP BIND is specified at configuration, X lines (1 for each interface) will be thrown. If one IP is specified, 1 line would be thrown Edited August 19, 2016 by anderbytes Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now