Can't change bound IP

[rhodges 49]

I am attempting to change the bound ip address in the advanced hosting settings. Right now it is 1.5 and I am trying to change it to 1.14 and I'm trying to change the ports. When I change them (I even tried the ip by itself) and hit OK, I get a dialog that warns me about instability and I press OK. I then get a prompt about SSL and I press OK on it.

 

Nothing changes. If I restart the server, I see 1.5 there and the ports are unchanged.

 

Version 3.2.26.0

 

Edit: I'm attempting to bind to a second IP address added to the network card. Not the primary ip address. Maybe that is it? 1 NIC with multiple ip addresses assigned to it.

Edited August 7, 2017 by rhodges

[Luke 42081]

Hi, try unchecking the box report https as remote address.

[rhodges 49]

Hi, try unchecking the box report https as remote address.

That allowed it to save, but it isn't picking up the port number change. I tried changing it to port 80 but it doesn't respond on port 80, but it does on the 8096 port.

 

Edit: I also tried setting the exe to run as an administrator because I know there is some things about running ports under 1024 requires administrator access. I attached the logs. Maybe I didn't get the administrator permission to stick.

 

Edit 2: Nope, even right click, run as adminstrator MediaBrowser.ServerApplication.exe and I still get the "An attempt was made to access a socket in a way forbidden by its access permissions" error.

server-63637727916.txt

Edited August 7, 2017 by rhodges

[Luke 42081]

@@rhodges, what you're saying is not correct.

It isn't picking up the port number change.

This is not true. We are trying to bind to port 80, but something on your system is denying access.

	System.Net.Sockets.SocketException: An attempt was made to access a socket in a way forbidden by its access permissions
 

You'll need to figure out what that is, but generally this could be user permissions in Windows, and/or any security software or anti-virus you have installed. Additionally, any virus or malware on your system could cause a problem too.

 

My suggestion would be to stick with the default port. 

 

We will have to improve the error messaging so that you don't fall into the trap of assuming "Emby problem". Thanks.

[rhodges 49]

Correct. The error is the socket exception, which might not be Emby at all.

 

One thing I do notice. According to the log, I see it binding Adding HttpListener prefix http://+:80/ Is it really binding all ip addresses and the only responding to the one configured?

 

Not sure what it could be. I ran it, right click run as adminstrator. Same error. I did a netstat -o and found nothing on port 80. There is no virus scan software and windows firewall is disabled. It is a Windows 2016 server.

 

I'll keep looking. Is anyone else running it on port 80?

 

I might have to play with netsh.exe tool to see if I can fix it with that.

 

Side issue: Why did I have to uncheck "Report https as external address?" I still want that. I have reverse proxy that is terminating SSL for outside connections. Don't I need that setting to tell the apps they need to use SSL?

[Luke 42081]

Yes we still bind the socket to ip address any and then filter traffic based on the filter you entered in the emby config. It's much easier that way.

 

As for SSL, most devices are going to reject the self signed cert provided by Emby, so we're not going to allow you to check that box anymore unless you provide your own cert. What's happening is too many people are turning it on and then reporting that they can't connect because their devices are rejecting the cert.

[rhodges 49]

Well, that might be the problem. Something on another ip address might be using port 80 (still investigating). That is fairly limiting. I was expecting it to work more like IIS bindings. I don't really see the point on listening to all then just not responding.  The entire point is to bind to an ip. That way you can use a different port.

 

For SSL, that is very limiting. I have to put in a SSL cert on the server even though it will never be used?

 

These are Expert->Advanced settings. I don't expect there to be so much hand holding here. These 2 limitations are very frustrating, to say the least.

[Luke 42081]

Because if we bind to the specific IP that you enter, we also need additional sockets to bind to localhost addresses so that you can access via localhost, 127.0.0.1, etc. So it just gets a little messy having to manage multiple sockets and that is why it is easier to just use a single one.

 

For SSL, if you're using a reverse proxy, wouldn't you be handling SSL on that level and having all traffic be routed to Emby over http?

[rhodges 49]

Because if we bind to the specific IP that you enter, we also need additional sockets to bind to localhost addresses so that you can access via localhost, 127.0.0.1, etc. So it just gets a little messy having to manage multiple sockets and that is why it is easier to just use a single one.

 

For SSL, if you're using a reverse proxy, wouldn't you be handling SSL on that level and having all traffic be routed to Emby over http?

I can see that with localhost. What would be nice, but probably an extremely low priority, would be to have an interface like IIS where you can choose as many protocol/ip/port combinations as you want.

http 127.0.0.1 8096

http 192.168.1.14 80

https 192.168.1.14 443 etc

 

For SSL, yeah, I am doing that. I guess maybe I really don't understand what the checkbox means then. I expected that at some point, the url that gets advertised has the http if not checked and https if it is checked. I would expect it to advertise the https url to the apps. I don't have any http to https redirect. Maybe I am misunderstanding the purpose of the checkbox?

 

Edit: I'm about 90% sure my port 80 problem was the Web Deployment Agent Service. I am working that out. Apologies for blaming Emby. Once I figure out if that is the case, I'll update. A simple telnet port 80 before I changed things around would have alerted me that something else was hogging the port. Since I didn't configure anything in IIS to use it, I made a bad assumption. Never realized the web deployment service gobbles it up on every interface. *grrrrr*

 

Edit 2: Yup, it was the web deployment agent service. The fact it uses port 80 on every interface is short of amazing. And there is no configuration for it. Luckily someone wrote some scripting to do everything to get it over on a different port. This is the type of thing I was to see Emby avoid.

 

If you are open to it, I might look into making the change to give more control over the bindings. I'll need to see how difficult it is getting Emby to compile and run from source and have to figure out the UI piece.

Edited August 8, 2017 by rhodges

[pir8radio 1312]

For SSL, yeah, I am doing that. I guess maybe I really don't understand what the checkbox means then. I expected that at some point, the url that gets advertised has the http if not checked and https if it is checked. I would expect it to advertise the https url to the apps. I don't have any http to https redirect. Maybe I am misunderstanding the purpose of the checkbox?

 

If you have a reverse proxy, you will leave that unchecked.   Your link between the reverse proxy and emby will be plain http the RP will do the SSL termination.  Checking that box in emby will tell your RP "hey I'm emby talk to me using https" and report https urls to the RP.   Let the RP handle the translations automatically.   Think of the reverse proxy as a client to the backend server.  That client then makes minor changes on the fly before spiting out the new code to the real client.  I'm sure you know this, I'm just painting a picture.   

[rhodges 49]

Thanks. I was thinking about way back when I was working on a web application that was behind a load balancer that terminated SSL. That web application had to, for whatever reason, generate HTML with absolute urls, including the schema. (This was like 14 years ago). Of course, once the SSL was terminated, in .NET we didn't know that, so if we built a url, it would be http. We had to add a special host header on the load balance to indicate the original request came in as SSL. The we had a function that would use that header when we make a fully qualified url.

 

What I was thinking, was that checkbox did something similar. When urls are advertised either in the HTML or whatever, it would look at that checkbox and generate a url with a schema of http or https. I was afraid that, if it was unchecked, it would generate fully qualified urls with http://. If that url went out to a client outside the network, then the request would fail because the RP is not listening on port 80 and doesn't have a redirect.  Thus my question and concern.

 

Clear as mud?

Edited August 8, 2017 by rhodges

[pir8radio 1312]

@@rhodges

Yes clear as mud.. lol   Emby doesn't use the url that you see in the dashboard for anything other than a display for you to see how your server is setup..  As far as I have seen all urls in emby are not hard coded with the info you supply in the advanced tab.. I would venture to guess that the wan url IS used for emby connect though.  For example in my advanced tab i have something like emby.mydomain.com for the wan url  yet guest.mydomain.com and kfldjlfdsj.domain.com (if setup in the reverse proxy) will still bring up my emby server with no issues. If I use emby connect, it would connect the client to my server using the address I have in the wan url field which is emby.mydomain.com. The original request header is sent to emby but it doesn't really do anything with it, emby doesn't care what requested url hits its interface as long as its on the bound interface and destine for the monitored port #.   

 

Back to your question, the checkbox  (someone correct me if I'm wrong) if checked will send https urls to your client, in your case your RP, but your RP will continue to request http versions from emby, because that's how you probably have the RP setup. At the same time your RP will change the https to whatever your clients hit the RP with either http or https, that is one of the first things the RP will do strip http or https and change it to what the client was actually requesting with. So basically with a RP that checkbox will not do anything, but change requests to your RP which it will just strip anyway.   If that makes any sense........ 

Edited August 8, 2017 by pir8radio