hi,
as many users in our group has problem of intermittent visibility, and I discovered they do not opened UDP 6112 port or are not sure they are able to do that, can be useful a menu function to check own port forwarding functionality in the client, and a visible warning light in the main window saying the status of router port forwarding. Something similar to Transmission (the Torrent opensource client)
port forwarding ON check
Re: port forwarding ON check
Hi,
I'm not sure that it's possible to access the router settings from JoinFS. It's quite an easy thing to configure it manually though, and it only needs doing once.
Peter
I'm not sure that it's possible to access the router settings from JoinFS. It's quite an easy thing to configure it manually though, and it only needs doing once.
Peter
-
JarangMandi
- Posts: 22
- Joined: Thu Apr 13, 2017 10:20 am
Re: port forwarding ON check
I believe "other" programs have in the past used UPnP (with apologies if I've got the capitalisation wrong) to manipulate the router configuration.
I'm specifically thinking FSInn which was (is?) a VATSIM/IVAO/FSD style client which used to establish a peer to peer network between aircraft that were physically close together thus eliminating the lag problems that aren't so important when you can't actually see the other aircraft.
UPnP has however gotten a lot of bad press as a result of bad people taking advantage of some of its weaknesses to effectively be able to open the front door from inside the house - which means that it's quite often disabled on the router either by default or deliberately. Whether UPnP can be used to interrogate router status, rather than manipulate it, I don't know. Like all these things you hear about that sound like a silver bullet, it's not until you actually try to use them in your specific scenario that you find out they're about as much use as a chocolate teapot.
I'm specifically thinking FSInn which was (is?) a VATSIM/IVAO/FSD style client which used to establish a peer to peer network between aircraft that were physically close together thus eliminating the lag problems that aren't so important when you can't actually see the other aircraft.
UPnP has however gotten a lot of bad press as a result of bad people taking advantage of some of its weaknesses to effectively be able to open the front door from inside the house - which means that it's quite often disabled on the router either by default or deliberately. Whether UPnP can be used to interrogate router status, rather than manipulate it, I don't know. Like all these things you hear about that sound like a silver bullet, it's not until you actually try to use them in your specific scenario that you find out they're about as much use as a chocolate teapot.
Re: port forwarding ON check
I do not have to be well explained, sorry.
What I'm thinking on, is a net connection test like the one performed by Torrent clients.
This is performed from outside "on the Net", to the user PC with JoinFS, passing the router, and PC SW firewall, without accessing router settings.
This can done in two manner:
1) When JoinFS on user PC is disconnected from flight session, require a "connection server" with a fixed IP:PortX. JoinFS open a socket to fixed IP:PortX and ask a test connection, and the server try to open a socket to user PC JoinFS on UDP 6112, then report the result on the first socket, and JoinFS report it to the user via the GUI.
2) When JoinFS on user PC is connected to a flight session, does not require a server with fixed IP:PortX. JoinFS open a socket on PortX to one of the connected PC in the session (the one that hosted the session has surely the door open) and ask a test connection, and the remote PC try to open a socket to user PC JoinFS on UDP 6112, then report the result on the first socket, and JoinFS report it to the user via the GUI.
Maybe PortX=6112 if you modify/add the function to JoinFS/your protocol.
I understand that situation 1) require an always ON server that can be considered contrary to JoinFS policy, and worse require some infrastructure (and money) by you, so can be avoided and in reality is not necessary once 2) is covered.
What I'm thinking on, is a net connection test like the one performed by Torrent clients.
This is performed from outside "on the Net", to the user PC with JoinFS, passing the router, and PC SW firewall, without accessing router settings.
This can done in two manner:
1) When JoinFS on user PC is disconnected from flight session, require a "connection server" with a fixed IP:PortX. JoinFS open a socket to fixed IP:PortX and ask a test connection, and the server try to open a socket to user PC JoinFS on UDP 6112, then report the result on the first socket, and JoinFS report it to the user via the GUI.
2) When JoinFS on user PC is connected to a flight session, does not require a server with fixed IP:PortX. JoinFS open a socket on PortX to one of the connected PC in the session (the one that hosted the session has surely the door open) and ask a test connection, and the remote PC try to open a socket to user PC JoinFS on UDP 6112, then report the result on the first socket, and JoinFS report it to the user via the GUI.
Maybe PortX=6112 if you modify/add the function to JoinFS/your protocol.
I understand that situation 1) require an always ON server that can be considered contrary to JoinFS policy, and worse require some infrastructure (and money) by you, so can be avoided and in reality is not necessary once 2) is covered.
Re: port forwarding ON check
We had the same issue with people not being able to see others until we set our "Server" port to 6464. It seems that they were connecting to my flight computer and not the server. When doing this they could not be seen or see others. A quick test is to close 6112 on your flight computer. See Thread: http://pmem.uk/joinfs/forum/viewtopic.php?f=2&t=515
Re: port forwarding ON check
Sounds like a neat idea. I'll take a look at that.efa wrote: 2) When JoinFS on user PC is connected to a flight session, does not require a server with fixed IP:PortX. JoinFS open a socket on PortX to one of the connected PC in the session (the one that hosted the session has surely the door open) and ask a test connection, and the remote PC try to open a socket to user PC JoinFS on UDP 6112, then report the result on the first socket, and JoinFS report it to the user via the GUI.
Peter
Re: port forwarding ON check
I assume that the implementation of opensource:
https://en.wikipedia.org/wiki/Transmiss ... nt_client)
can be used as a guide.
https://en.wikipedia.org/wiki/Transmiss ... nt_client)
can be used as a guide.