I couldn’t enlarge your pics but the first pic is ens33 which is your 192 address space. So it appears that Plex is still using the correct interface but the binding is showing 10 address space which might just be wrong.
@cayers
that is my point… its hard to tell exactly what plex is doing but circumstanitally since there is traffic on ens33 it ‘may’ be on that adapter…
but for clients, streaming brain and the other half baked stuff plex does… what is it advertising as ‘local network’
even if its using the correct adapter, if its advertising 10.55 as local and my clients are on 192.168 then they will behave badly…
either way its not right… period
You can help mitigate part of that problem with the “LAN Networks” setting found at /settings/server/networks
Enter any local networks there to make sure they are always processed as local.
so let me get this right… as a plex ninja your logic is…
plex cant grab or announce the right adapter
plex doesnt let me speciify a adapter bind
but you want me to advertise the right and wrong subnets as local so that plex that is malfunctioning ‘might’ not fall on its face as bad…
talk about a bass-acwards solution to what should be a simple fix… but then the devs would acutally have to fix it…
Please don’t put words in my mouth that I haven’t said.
My logic is simple, it should/needs to be fixed. But I also tried to give you a tip that might help you until such time as it does get fixed. Nothing more, nothing less.
Carlo
what say we get the devs to finally fix this once and forall since I have found multiple threads on this issue…
further… I think its high time that plex allow us to bind plex to an adapter
and lastly, plex need to be much more forthcoming on its routing methods
I have upnp and other consumer discovery and tunneling off due to security isses yet plex seems to be able to tunnel through just about anything these days… I get it… they want it to be idiot proof to limit complaints but if plex is indeed grabbing a non routed subnet adapter and tunneling into the internet though my firewall it needs to stop.
tcpdump -w capture.pcap -i ens160
@“Ach!lles”
found some additional info on this…
since plex has no secure file transfer and even if they did I cant be sure passwords and other credentials or sensitive info isnt flying around my network a tcpip dump being uploaded to a public forum is out of the question.
so what I did was look at the behavior of plex clients that I run on osx platforms that have little snitch running… little snitch is a firewall type program that tracks applications reqests for internet access and server connections and allows you to firewall the outgoing request not just the incoming …
long story short… here is what I found the largealphnumeric is for security/id I imagine
when I open PMP on my mac it wants 4 connections
in order
mywanip.largealphanumeric.plex.direct on port 32400
plex.tv port 443
sentry.io over 443
pubsub.plex.tv port 443
and lo and behold
10-55-x-x.largealphanumeric.plex.direct port 32400
compelling
further …
plex.direct shows to be in amsterdam so that adds some latency to these exchanges
after getting the PMS started up and connected to my server and starting a movie… I bring up the info screen… with the ‘i’ key and its showing that indeed its using the 192.168 address to connect to the movie source…
ok… on my laptop connected to the 192.168.0.1 router I did a nslookup to see what these server requests look like
I added xxxxx to the alphnum to redact my personal info but that is the address PMP was asking for a connection to
nslookup 10-55-0-12.b0662b2073ff401a9dc35a5xxxxxxxxx.plex.direct
Server: 192.168.0.1
Address: 192.168.0.1#53
Non-authoritative answer:
Name: 10-55-0-12.b0662b2073ff401a9dc35a5xxxxxxxxxxx.plex.direct
Address: 10.55.0.12
so a lookup of the request with the 10-55 returns my router and the non routed subnet
it was further explained to me by sa2000 that plex will listen on 0.0.0.0:32400 and also send details of any adapter that is sees… thus if a client can get through on 10.55 it will try the others but plex will reply to any requests to 32400
so these server exchanges with plex.direct are acting like a psudo DNS of sorts… returning to clients the wan location and internal routes within that network… and even though on the server settings page it announces that its using 10.55 … in reality it has told the cloud that 192.168 is there also… and when clients cant route on 10.55 which in my case it shouldn’t be able to … it is indeed routing the client to the server via 192.168 … as evidenced by the info screen of playing media on PMS showing that 192.168 is the source location…
seems a bit rube goldberg to me …
what say you achilles?
Since PMS binds to all IPs available in the box, thats exactly what I expected it to be doing with the exception that it shows the 10.55.0.12 in the PMS web UI. That seems like a bug.
