Difficulty accessing server

[crusher11 851]

My dad has a Telstra TV, which is essentially a Roku. He's got the Emby app on it, but whenever he tries to log in it tells him his user name or password is incorrect, even though this isn't true. Removing the password allows login with no issues.

 

He also has a Samsung UA55J6200, and has installed the Emby app on that. When entering the address of my server he gets an error saying it can't connect to that server, check to see if it's running. The web browser app on the Samsung TV also returns a 'server not found' error upon entering my server's address.

 

He's able to connect fine from his phone and PC.

 

I'm behind an NGINX reverse proxy and Cloudflare.

 

I've attached a log which is reasonably lengthy, but starts with a login attempt on the Telstra TV. I'm assuming the attempted Samsung connections aren't even getting through far enough to be logged at all.

embyserver.txt

[ebr 14904]

What app is he actually running?  Must be either our very old one or BNN.

 

Not sure if those will continue to work with the current server but check your proxy configuration to be sure it isn't stripping out post data from the requests.  We've seen this in the past causing this type of issue.

 

Compare your config to @@pir8radio.

[crusher11 851]

On which device? Not sure what BNN is.

 

I'm using the config @@Swynol posted, I believe.

[ebr 14904]

On which device? Not sure what BNN is.

 

On the Telestra TV.  There is no current Emby app available for that device but it was possible to side-load our (now very) old app or Speechles' old Blue Neon Night app.

[crusher11 851]

It's emby branded. Although it does look terrible.

 

Is there not a more recent version for Roku, or does that specifically not work with Telstra TV?

[ebr 14904]

Is there not a more recent version for Roku, or does that specifically not work with Telstra TV?

 

Specifically not the Telestra as it doesn't use the normal Roku store and they refused our request to be included in theirs.

[crusher11 851]

On what basis?

 

That aside, why would the newer Roku app be any more difficult to side load than the older one?

[crusher11 851]

My NGINX config:

worker_processes  2;

events {
    worker_connections  8192;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    server_tokens off;
	ssl_session_timeout 30m;
        ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
	ssl_certificate      SSL/cert.pem;
	ssl_certificate_key  SSL/private.key;
        ssl_session_cache shared:SSL:10m;

    sendfile        off;

gzip on;
gzip_disable "msie6";

gzip_comp_level 6;
gzip_min_length 1100;
gzip_buffers 16 8k;
gzip_proxied any;
gzip_types
text/plain
text/css
text/js
text/xml
text/javascript
application/javascript
application/x-javascript
application/json
application/xml
application/rss+xml
image/svg+xml;

tcp_nodelay on;

    server_names_hash_bucket_size 128;
    map_hash_bucket_size 64;

## Start: Timeouts ##
    client_body_timeout   10;
    client_header_timeout 10;
    keepalive_timeout     30;
    send_timeout          10;
    keepalive_requests    10;
## End: Timeouts ##

## Default Listening ##

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
	  return 301 https://$host$request_uri;
}
server {
    listen [::]:443 ssl http2 default_server;
    listen 443 ssl http2 default_server;
    return 401;
}
##EMBY Server##
	
	server {
    listen [::]:443 ssl http2;
    listen 443 ssl http2;
    server_name domain.com; 
	
		#add_header Public-Key-Pins '
		#pin-sha256="8TzXdhbnv+l6EjDG2Vj9EmgGiSmZenrTZSNaUFEwyUE="; 
		#pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="; 
		#pin-sha256="Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys="; 
		#max-age=86400; includeSubDomains';
		
		add_header X-Xss-Protection "1; mode=block" always;
		add_header X-Content-Type-Options "nosniff" always;
		add_header Strict-Transport-Security "max-age=2592000; includeSubdomains" always;
		add_header X-Frame-Options "SAMEORIGIN" always;
		proxy_hide_header X-Powered-By;
		add_header 'Referrer-Policy' 'no-referrer';
		add_header Content-Security-Policy "frame-ancestors domain.com domain.domain.com;";
    	
	
     location / {
         proxy_pass http://127.0.0.1:8096;  

		proxy_set_header Range $http_range;
		proxy_set_header If-Range $http_if_range;
		proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        #Next three lines allow websockets
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
		}
	

}
}

[ebr 14904]

I think the app is probably just now incompatible with the current sever.   We probably aren't accepting the password in the old format we used to send it.

[crusher11 851]

So why can't a newer app be side loaded?

 

And what about the Samsung?

[ebr 14904]

So why can't a newer app be side loaded?

 

Because there is no way to do that without giving away the entire source code of the app and we simply aren't willing to do that.

 

 

And what about the Samsung?

 

The device may be rejecting your certificate but you should post specifics on that one in the Samsung forum.  I think the Roku issue is simply incompatibility.

[pir8radio 1292]

Because there is no way to do that without giving away the entire source code of the app and we simply aren't willing to do that.

 

 

 

The device may be rejecting your certificate but you should post specifics on that one in the Samsung forum.  I think the Roku issue is simply incompatibility.

 

Shouldn't reject the cert if he is using cloudflare's cert.

[crusher11 851]

I am.

[crusher11 851]

I've commented out the 301 line in my config, changed my emby setting to "preferred but not required", and turned off everything in CloudFlare that looked like it might be redirecting, and I still can't get to the http version. It redirects to https every time.

[pir8radio 1292]

if you ever had add_header Strict-Transport-Security "max-age=15552000; preload" always; In your config that stuff gets cached (clearing regular cache wont do anything) for the time you entered in Max-age.  you need to manually remove that HSTS stuff   for example chrome: https://cheapsslsecurity.com/blog/hsts-chrome-firefox-clear-hsts-settings/

 

Not sure if you easily can from the other "apps"

[crusher11 851]

I posted my config earlier in the thread.

[crusher11 851]

Also I had a look at my NGINX error log and I'm seeing a lot of this:

2020/01/22 22:00:31 [crit] 2728#2792: *7018 SSL_write() failed (10053: An established connection was aborted by the software in your host machine) while sending to client

The numbers are all different each time though. And the times don't match to trying the Samsung TV, at least not exclusively.

[pir8radio 1292]

I posted my config earlier in the thread.

 

yea so, thats why its forcing ssl.

[crusher11 851]

Is there anything I can do to work around it?

 

What about that error I keep getting?

[pir8radio 1292]

Is there anything I can do to work around it?

 

What about that error I keep getting?

 

i posted above as a workaround to clear the HSTS cache.       the error 10053 can be almost anything from, firewall, antivirus, network issues, emby, to something completely unrelated.    Those are tough to troubleshoot without using wireshark or something. 

[crusher11 851]

That only works if I'm accessing via a browser though, right? Is there not anything I can do with NGINX?

 

I have no idea what's going on with the 10053 errors. Is that going to cause any symptoms or is it just happening in the background?

[crusher11 851]

Could I kill NGINX and do it that way?

[pir8radio 1292]

That only works if I'm accessing via a browser though, right? Is there not anything I can do with NGINX?

 

I have no idea what's going on with the 10053 errors. Is that going to cause any symptoms or is it just happening in the background?

 

 

Could I kill NGINX and do it that way?

 

 

Right, I'm no good with the other OS's out there, there might be ways to clear that HSTS stuff out but you will have to do some googleing..    The problem with HSTS is that you shouldn't enable it until everything is working HTTP and HTTPS first then enable it a month later lol.   What HSTS does is tells the clients "HEY you should NEVER connect to me using HTTP any more after this first time, always connect to me using HTTPS until this timer runs out (max-age=2592000 seconds) then you can check on HTTP again at that time"  assuming hsts is still enabled it will just reset that timer and connect using https again...     Another thing that happens is most browsers and clients will check a "preload" list that is actually hard programmed into the client/browser software.  Once you are on that list it makes things difficult, until the browser or client is upgraded assuming you fell off the list.    https://hstspreload.org/   to see if you are on the preload list. Your nginx config did not include the preload directive so you should be ok.  If YES then you are better off figuring out how to fix your https setup.    Or comment out that HSTS line now and hope you start to expire.   

 

Long story short HSTS is client side,  nothing you do on your end will change that...     You can change your HSTS max-age to 0 seconds to try to clear out the apps..  then see if you can connect to http again.. assuming you are not on the preload list. 

Edited January 24, 2020 by pir8radio

[pir8radio 1292]

That only works if I'm accessing via a browser though, right? Is there not anything I can do with NGINX?

 

I have no idea what's going on with the 10053 errors. Is that going to cause any symptoms or is it just happening in the background?

 

I think the 10053 errors might be unrelated.   But they do need to be dug into to see whats going on..    Almost sounds like the connection between nginx and emby is getting interrupted.  That could be either emby dropped it, nginx dropped it, some firewall rule is causing the drop, antivirus (with networking) is stopping it.   its a tough one to troubleshoot.  

[crusher11 851]

So is there a way to kill NGINX and access the server via my IP and port? At present trying the IP and port fails, presumably because of something in my setup.