Odd problem with HTTP traffic

[ITjay 1]

Since last Friday, I am unable to access the Emby page over HTTP on the same LAN. I am able to access the page over HTTPS. Even with debugging logging on, all I usually see is one HTTP 200 in the logs accessing /web/css/images/favicon.ico from the IP in question, then nothing else in the logs from the client IP. If I let the page sit for greater than 15 minutes, it will load. HTTPS page load is almost instant. While doing a Wireshark capture, I see the server sending the client a Reset.To make matters even stranger, I can access the page over HTTP from a VPN client (different subnet, but local to the Emby server through an internal router).

 

I am running CentOS 7 fresh install (I reinstalled a new VM and Emby after this started) Emby 3.0.5912.0 and Mono 4.2.1. HTTP port is 8096 and HTTPS port is 8920. The firewall has been turned off on the server testing with no improvement.

 

I am out of ideas. Any help would be appreciated.

 

Thanks

 

 

[Retsoru 0]

I don't really see how this could be emby itself. Can you prop up apache listening on some http ports and see if the behavior is the same?  You could even stop emby and try binding apache to 8096 with a little test index page and see if it helps. At least that's what I'd try.

 

Pretty bizarre behavior. I'd try removing as many variables in the paths to connecting to the service as possible; eg can you connect when ssh'd into the box via a CLI browser like elinks/w3m/lynx? Or ssh -X in and try firing up a gui browser to browse http://localhost:8096

[individualist 0]

I thought it was just me - I'm running OpenMediaVault 2.2, which at it's core is Debian 7, with a 3.16 backports kernel. I was considering scrapping the whole OS and rebuilding the box with something newer after removing the OMV-plugin installed version of Emby (which had been doing some of it's own updates) and replacing it with the official Debian 7 Emby package with the newest Emby resulted in the same behavior...

 

I tried Chrome and Edge, and IE. 

 

I hadn't tried HTTPS before I read your post, but I'm seeing the same behavior as you. HTTPS response is immediate. 

 

None of the other HTTP services on the box are exhibiting this behavior. 

 

Hitting the Emby REST API in the chrome, IE or chrome with postman via HTTP, like the main page - results in the browser waiting and waiting also.

Hitting the rest API via HTTP using curl on the same box the browsers response is immediate... 

Hitting the rest API via HTTP using curl on the same box as Emby is immediate...

 

I'm on mono 4.2.3...

 

Still looking to see what's going on - whether or not, as Retsoru said,  something is interfering....

 

 

 

 

 

[ITjay 1]

I did ssh to the box and then accessed http://localhost:8096 and the behavior is the same. The other wierd thing is that I installed Emby on a Windows Server 2012 R2 box as well, and had the same results. 3 different servers acting the same. I am also accessing them from 3 different clients. I am at a loss.

[individualist 0]

I never found a definitive cause. Re-installing seems to have corrected the issue for me. Good luck.