You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Clients tend to deal with that by dropping back to using the control connection IP. I've not seen any actual issue from returning the wrong IP for clients using PASV through the router. Its possible some client out there won't.
I have router use with plain and with TLS implemented into this app and only 1 is necessary for IPv4 as the port range is too great for good port forwarding use. (edit: technically it isn't as can use port triggering instead. See linked pull request below for more info.)
Edit:
1. will be included with an upcoming pull request for TLS since I need to deal with everything anyway (local, remote aka pasv internet access to router, ports, etc) and currently have it implemented and working there anyway.
Don't see any reason to do 2. as all clients tested - including newly working ones - are not showing any problem with this (note that clients can simply fallback to using the control connection IP to deal with it themselves) even though its the expected thing... since I don't see a problem, and as everything works, its not particularly useful in the end. (Someone else can if they see a need.)
Nothing else is necessary for internet router use.
Edit: There is a problem when not doing 0 full random (it currently uses 0 full random). Limiting the scope, I've experienced port failure. Another edit: This is more involved and will leave it to info that will be applied to a future pull request that includes port limiting instead of here.
1-pasv port range
2-ip for pasv reply
3-option for prev - not for LAN
The text was updated successfully, but these errors were encountered: