WAN IP (172.58) tagged as Local IP by Emby

[MBSki 1020]

I don't use 172 on my local network though. Verizon is giving my device that IP. Why would it give my device a local IP? 

So it sounds like Emby looks at 172 and thinks (well, that's a local device). Is that right?

[Guest]

It could and it may be that the 172 range needs additional 'care' in Emby.. like stopping it at a certain range instead of encompassing the entire range..

[Carlo 4330]

Yes if it's an IP that falls into the part of 172 address space that is reserved.  Not all of 172 is reserved only part of it.

But as has been stated, Emby DOES NOT handle the 10 and 192 address space the same as 172 which does need fixing.

[Happy2Play 8296]

6 minutes ago, mbarylski said:

I don't use 172 on my local network though. Verizon is giving my device that IP. Why would it give my device a local IP? 

So it sounds like Emby looks at 172 and thinks (well, that's a local device). Is that right?

Does not matter whether you use it or not all of 192 and 10 and some of 172 are private networks.

But yes Emby had codes part of 172 ((aka 172.16.0.0 – 172.31.255.255)).

So the question still remains of what 172 address the device has.

[MBSki 1020]

1 minute ago, Happy2Play said:

So the question still remains of what 172 address the device has.

The address my device was assigned was 172.58.187.xxx. That doesn't seem to fall in the bucket above so it appears to be getting missed. 

@cayars So you think a wider range needs to be added to Emby?

[Happy2Play 8296]

I don't know coding really at all or if Emby changed from this but this would suggest that is outside of coded range.

Emby/NetworkManager.cs at master · MediaBrowser/Emby (github.com)

[MBSki 1020]

2 minutes ago, Happy2Play said:

I don't know coding really at all or if Emby changed from this but this would suggest that is outside of coded range.

Emby/NetworkManager.cs at master · MediaBrowser/Emby (github.com)

Seems like the code needs to change because my public ip is getting classified as private when it isn't. It seems the code you referenced is marking ALL 172 in the private category.

[Carlo 4330]

That is a public IP address not a reserved address so unless you have specifically added it to Emby LOCAL ADDRESS space in Networking menu it should be a public/remote address.

[Q-Droid 652]

28 minutes ago, cayars said:

That is a public IP address not a reserved address so unless you have specifically added it to Emby LOCAL ADDRESS space in Networking menu it should be a public/remote address.

Are you certain that Emby is handling 172.16.0.0/12 correctly? Per the referenced thread and your comment there are differences in how 172 is treated from other private subnets. What isn't clear is whether the full /8 is seen as private or just the correct block.

 

Edited April 6, 2021 by Q-Droid

[MBSki 1020]

49 minutes ago, cayars said:

That is a public IP address not a reserved address so unless you have specifically added it to Emby LOCAL ADDRESS space in Networking menu it should be a public/remote address.

Agree. I haven't set it as a local ip. So is this issue now logged internally as a bug?

[Happy2Play 8296]

1 minute ago, mbarylski said:

Agree. I haven't set it as a local ip. So is this issue now logged internally as a bug?

Wrong box, the one above it. But there would appear to be a issue with 172 as two topics are having a issue with it being private.

[MBSki 1020]

2 minutes ago, Happy2Play said:

Wrong box, the one above it. But there would appear to be a issue with 172 as two topics are having a issue with it being private.

You sure? They're both empty, so either way I'm not adding 172 as a local address. 

[Happy2Play 8296]

1 minute ago, mbarylski said:

You sure? They're both empty, so either way I'm not adding 172 as a local address. 

And the issue is here, but also a issue with what part of 172 network as it has private space.  So there would appear to be a issue in how Emby sees the 172 network.

Quote

If left blank, only the server's subnet and common private IP subnets (10.0.0.0/8, 192.168.0.0/24, etc.) are considered to be on the local network.

 

[rbjtech 4283]

12 hours ago, mbarylski said:

Seems like the code needs to change because my public ip is getting classified as private when it isn't. It seems the code you referenced is marking ALL 172 in the private category.

It's not - it's doing an incremental 'for' loop to check to see if the 2nd octet is in the /12 range - ie it checks if it's from 16 to 31.  So the logic, looks reasonable.

for (var i = 16; i <= 31; i++)

BUT we don't know if this is even the correct piece of code, even if it is, we do not know if it is being called for this remote bandwidth function.

We need the Dev's to check the source/compiled code.

Edited April 7, 2021 by rbjtech

[MBSki 1020]

@Luke Do you have this logged as a bug?

[Luke 37095]

On 4/7/2021 at 4:38 AM, rbjtech said:

It's not - it's doing an incremental 'for' loop to check to see if the 2nd octet is in the /12 range - ie it checks if it's from 16 to 31.  So the logic, looks reasonable.

for (var i = 16; i <= 31; i++)

BUT we don't know if this is even the correct piece of code, even if it is, we do not know if it is being called for this remote bandwidth function.

We need the Dev's to check the source/compiled code.

Yes it is. These will be considered in the network.

[Happy2Play 8296]

1 minute ago, Luke said:

On 4/7/2021 at 1:38 AM, rbjtech said:

It's not - it's doing an incremental 'for' loop to check to see if the 2nd octet is in the /12 range - ie it checks if it's from 16 to 31.  So the logic, looks reasonable.

for (var i = 16; i <= 31; i++)

BUT we don't know if this is even the correct piece of code, even if it is, we do not know if it is being called for this remote bandwidth function.

We need the Dev's to check the source/compiled code.

Yes it is. These will be considered in the network.

 

So how is this considered local then?

On 4/6/2021 at 12:34 PM, mbarylski said:

The address my device was assigned was 172.58.187.xxx.

 

[Luke 37095]

1 minute ago, Happy2Play said:

 

So how is this considered local then?

 

Not enough information to answer that. You have to look at the detected lan ip of the server as well as any possible network settings that would impact the decision making.

[Happy2Play 8296]

Network fields are blank and would appear all of 172 is LAN not just 172.16.x.x-172.31.x.x (only going off provided info as I don't have anything with this setup).  Pretty much the same as the other topic trying to exclude 172 on LAN.  It can not be done.

[MBSki 1020]

46 minutes ago, Luke said:

Not enough information to answer that. You have to look at the detected lan ip of the server as well as any possible network settings that would impact the decision making.

Huh? What more do you need? My local LAN is 192.168.xxx.xxx  My client is 172.58.187.xxx, and is getting tagged as local when it should be remote. As I understand it, 172.58.187.xxx should NEVER get tagged as local.

Can you please make sure 172.58.xxx.xxx is considered remote?

[Luke 37095]

Quote

 As I understand it, 172.58.187.xxx should NEVER get tagged as local.

That's not true. There is no address that never gets tagged as local. The answer is always: It depends.

[MBSki 1020]

1 minute ago, Luke said:

That's not true. There is no address that never gets tagged as local. The answer is always: It depends.

Boy that doesn't sound right. Where are you getting this from? I can't find any reference that says 172.58.187.xxx can be local. What exactly do you think it would depend on? In my case, the device is NOT local, but it's getting tagged as local. How do you explain that?

[Happy2Play 8296]

1 minute ago, Luke said:

That's not true. There is no address that never gets tagged as local. The answer is always: It depends.

But it is not a Private address so it should never be Local. 

Quote

If left blank, only the server's subnet and common private IP subnets (10.0.0.0/8, 192.168.0.0/24, etc.) are considered to be on the local network.

So this field is never honored?  Not true as it works for 192 and 10 networks.  So 172 is a problem network and needs work as there a two topics saying it is broke.

[Luke 37095]

1 minute ago, mbarylski said:

Boy that doesn't sound right. Where are you getting this from? I can't find any reference that says 172.58.187.xxx can be local. What exactly do you think it would depend on? In my case, the device is NOT local, but it's getting tagged as local. How do you explain that?

That means they are private if they fall into those ranges. It doesn't guarantee they are not private if they do not.

[Luke 37095]

Did this topic shift gears into the opposite of what it was originally opened for? I thought the issue was you have a device on the local network that is being detected as a remote device.