mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-01-23 23:20:51 +01:00
10.6.2 - LAN Network option not working #2045
Labels
No labels
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
EFjellyfin.db
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: starred/jellyfin#2045
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @eixel05 on GitHub (Aug 16, 2020).
Using 10.5.5, this works perfectly. I'm using ZeroTier to access my JF remotely (I'm behind CGNAT) and I specified in that option all the devices that are actually in the house. I didn't use IP/Netmask. I manually added the IPs. I do this because my setup of ZT is to bridge. So even if I type the in-house private network instead the one given by ZT, I would still reach it. The IP of the bridging hardware is not added under this option.
.
Whenever I access my JF outside the house using my Mobile Data+ZT, that option applies. I don't see those profiles that are specified not to have remote access.
I upgraded to 10.6.2 (I held until the memory leakage is fixed) and found out that the LAN Network option doesn't work anymore. No matter where I access the server, I still see those Profiles that doesn't have remote access and was able to log-in. It's like the option was defaulted to "left blank" thus the in-house subnet, ZT subnet is all considered Local networks. And no matter what you add, it is ignored.
@thr33face commented on GitHub (Aug 16, 2020):
I'm facing potentially the same issue while trying to enforce the 'internet streaming bitrate limit'
Jellyfin is accessed through a reverse proxy on the same /24 (192.168) and I'd like that IP to be considered public instead of local.
Simplified the setup looks something like this:
[jellyfin | .20] -> [reverse proxy 1 | .60] -> [client 1 | .180]
Since the jellyfin logs show all requests coming from the reverse proxy IP, I assumed that setting 'lan networks' to one of these options would treat .60 as public:
But none of these produce the desired results and the internet streaming limit is never enforced. (i.e.: bitrates higher than the set limit can be by users)
@BaronGreenback commented on GitHub (Aug 16, 2020):
@thr33face Could you test the following please?
In your LAN definition include the IP in [ ] - eg. 192.168.1.0/24,[192.168.1.60/32]
The [ ] (or ! prefix if/when PR3257 gets accepted) is the equivalent to NOT. So to exclude an address from the LAN just enclose it.
This was introduced in 10.6 as a replacement to the virtual interface detection routine which was causing an issue elsewhere.
@thr33face commented on GitHub (Aug 16, 2020):
@BaronGreenback
Unfortunately this did not work either, even negating the whole subnet does not help.
I also bypassed the reverse proxy, and negated the client IP, that didn't work either.
Log:
[2020-08-16 16:11:05.670 +00:00] [INF] RemoteClientBitrateLimit: 6000000, RemoteIp: "192.168.10.180", IsInLocalNetwork: True
@BaronGreenback commented on GitHub (Aug 16, 2020):
I'll dive into the code and see what's happening.
@BaronGreenback commented on GitHub (Aug 16, 2020):
Looks like in 10.6.2 it is hard coded, and so is a bug.
It is one of the many network fixes in PR #3257 which i'm currently testing.
@thr33face commented on GitHub (Aug 16, 2020):
Thank you for investigating
@BaronGreenback commented on GitHub (Aug 16, 2020):
No problems - would you be up to testing the PR once i've got it running on the new unstable version, to make sure it works?
The PR is massive - so i'm currently doing alpha's before hand to ensure i don't break more than i fix.
@thr33face commented on GitHub (Aug 16, 2020):
Sure, I can help testing to the best of my abilities.
I have a jellyfish instance up and running in a throwaway VM, so doesn't matter if that one breaks in the process.
@BaronGreenback commented on GitHub (Aug 19, 2020):
Docket image crobibero/jellyfin:3257 is the PR3257.
It's the latest code image - so some interface things may be broken. If you could fire it up and test the networking side, especially with your setup. It has got loads of fixes in it.
@thr33face commented on GitHub (Aug 22, 2020):
Have the docker image up and running (the one updated on 2020-08-21T17:14:22) and can observe this behavior:
By excluding the /24 the reverse proxy is correctly limited
LAN Networks: !192.168.10.0/24
If I allow the /24 but exclude the /32 the reverse proxy is considered local:
LAN Networks: 192.168.10.0/24, !192.168.10.60/32
@BaronGreenback commented on GitHub (Aug 22, 2020):
got it - thanks - will get it fixed.
Thanks for the feedback!
@BaronGreenback commented on GitHub (Aug 22, 2020):
Just asked for the docker image to be updated - so it may take a while.
Could you test it again please? - I altered the logic - and my tests routines say it should work correctly now.
@thr33face commented on GitHub (Aug 22, 2020):
Looking good, working as expected now:
LAN Networks: 192.168.10.0/24, !192.168.10.60/32
Playing via reverse proxy 192.168.10.60/32
Directly access server with unrestricted client 192.168.10.180/32
@stale[bot] commented on GitHub (Dec 20, 2020):
This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments.
If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or nightlies, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label.
This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on Matrix or Social Media.