Port Forwarding
-
could I have a specific example where this happened? to clarify, not a mission flop but a port change causing a game crash.
I’m not talking about game crash… u loose datalink, u have jumping airplanes or missiles, u don’t have radar contacts, ACMI recordings r fubared, missiles loose lock and go their way etc
-
Ill take that as a no, then?
-
-
-
Ill take that as a no, then?
nope… to create a good report on what I’m talking u must get synched those:
raknet log
packets log (Boy they r big)
ACMI
server network log - monitoring
clients network log - monitoring
And all clients video recording (fraps)To do so even for one mission will take a large amount of time and effort…
So in general and quick when I hear some troubles over the radio I mark the time. Then I go through the data and try and see if something went wrong about that time, I can’t be exact as Raknet time has different timing then falcon time but u have the raknet time when the mission starts… so u go along.
I hope in the future those would be synched… network time and falcon - mission time, and maybe server clock… that way admins can spot troubles easier and see if it was from client or server or which client had the problem etc etc…
-
but?
No buts. Just (relatively easy to set up, for people with relative networking knowledge) VPN software.
-
well sounds like hamachi … IIRC this was disastrous unless if all users are on this and then it’s different. Sorry as I said ignorant and searching on the subject…
And how stable r those software VPN thingies? like Open VPN?Also as I read on it VPN requires even higher bandwidth cause data goes from vpnclient to vpnserver then they go their way… so this increases server bw demands to the max… right?
wow metrics seem to cause troubles and must be set on all clients on this solution… Headache nightmare for an ignorant like me…
-
nope… to create a good report on what I’m talking u must get synched those:
raknet log
packets log (Boy they r big)
ACMI
server network log - monitoring
clients network log - monitoring
And all clients video recording (fraps)To do so even for one mission will take a large amount of time and effort…
So in general and quick when I hear some troubles over the radio I mark the time. Then I go through the data and try and see if something went wrong about that time, I can’t be exact as Raknet time has different timing then falcon time but u have the raknet time when the mission starts… so u go along.
I hope in the future those would be synched… network time and falcon - mission time, and maybe server clock… that way admins can spot troubles easier and see if it was from client or server or which client had the problem etc etc…
so, to reiterate my question, do you have such an example? or just a guess?
-
-
well sounds like hamachi …
Nonsense.
IIRC this was disastrous unless if all users are on this and then it’s different.
Nonsense.
And how stable r those software VPN thingies? like Open VPN?
Stable enough such-that my phone disables all non-vpn 3G comms.
Also as I read on it VPN requires even higher bandwidth cause data goes from vpnclient to vpnserver then they go their way… so this increases server bw demands to the max… right?
Slightly.
wow metrics seem to cause troubles and must be set on all clients on this solution… Headache nightmare for an ignorant like me…
Metrics are fine with openvpn.
-
many
what is this, 6 posts you’ve dodged answering? when I asked for an example, you said I misunderstood. when I asked for clarification, you backpedaled… and when I ask again, you affirm and try to drop it… leaving us where I asked for an example… where we started.
I will take that as a no, then.
-
ok blue3wolf if u can’t even understand what I’m saying then ok have your no.
Have u ever looked inside a full mission Raknet log? Have u ever looked at a BMS packet log?
If u had then u would understood what I’m telling u. I’m not trying to avoid the subject nor what u clearly imply!!!What I know is that when I experience abnormal behavior (as I described above) is cause of other then 2935 port users r connected.
I see connections redone. I see packet loss.
When they all r on 2935 I don’t see connections requests and disconnections and minor to none packet loss…Peace we don’t have a fortune to devide here. For my side is searching for actions and params to improve the experience, and not prove anything like I know , u don’t and an ego fight…
And to give u an oportunity to balance your negativity do u have something constructive to offer to the subject, or the leave it all a mess is ok with u?
-
Well correct me if I’m wrong but when the port changes maybe a re connection takes place inside racknet? have u seen the log with -mono? What if this takes place in a critical moment and suddenly there is a disturbance in the data flow?
Have a flight of 20+ ppl if 2-4 guys have this during the mission then flip flop???A change of port is not expected with an average router. They typically have a timeout stating how long a route should be maintained (in case of udp). BMS traffic is dense enough not to exceed such a timeout. Of course, if the router is buggy, anything is possible.
-
reconnection? udp is stateless
SCNR
-
staless???
SCNR??? -
reconnection? udp is stateless
UDP is stateless, but that is OSI layer 4. The ppl here are more concerned with RakNet, which is OSI layer 5. And this one is stateful. But, yes, the router only deals with layer 4…
The only thing I can add to this discussion: yes, there are routers out there which do indeed change ports “on their own” when configuring port forwarding. I simply consider these routers broken. Some routers can clearly distinguish between TCP and UDP, others can’t and only work properly if you forward both UDP and TCP for the port in question - which is technically absolute nonsense, but this is how they work.
I remember vividly that this discussion has been going on ever since Falcon existed. We had plenty of “good routers vs. bad routers” topics and lists in various forums over the last decade…
Personally, I never ran into problems with e.g. the AVM FritzBox! (simple) or any router capable of running a custom DD-WRT firmware (complicated).
-
Dunc, you’re misunderstanding.
The routers don’t change ports on inbound, they change outbound, when falcon client first connects to the server.
IOW, if you have two hypothetical UDP clients local:4242 -> remote:4242, they have to mangle local:4242 into local:4269/local:4237 or some other random gobblegook or else it has no way of distinguishing which is which.
-
Sorry, don’t have the time to read all threads in full length anymore…
Could you simply QUICKLY sum up what you want/need? If I understand it correctly, you want the “allow dubious connection” option to be less strict, i.e. allow clients/routers which do incoming port forwarding correctly, but which re-map source ports?
-
Yes.
Allow from-client to-server remapped, but check whether forwarded port is accessible.
-
UDP is stateless, but that is OSI layer 4. The ppl here are more concerned with RakNet, which is OSI layer 5. And this one is stateful. But, yes, the router only deals with layer 4…
The router is, but NAT isn’t IMHO. It puts a timer on a remap, and if that expires, or screws up in some way, the source port will be changed.
The only thing I can add to this discussion: yes, there are routers out there which do indeed change ports “on their own” when configuring port forwarding. I simply consider these routers broken.
Unfortunately, NAT is under-specified, and routers behaving in this way do not violate any specification. I encountered a couple of NATs behaving like this in my team. To make matters worse, some of these routers are mandatory for the ISP in use (typically fiber optics) , so it’s not a simple matter of swapping the router.
Allow from-client to-server remapped, but check whether forwarded port is accessible.
Traffic of each client arrives at the server with a possibly remapped source port. But the client informs the server (as part of the payload) of the source port it actually uses locally (typically 2935). If the server would reply not to the remapped source port, but the actual one, a client without proper port forwarding would be unable to join the server.
Personally, I see more in reporting the connection status of clients in the UI. If the names of the clients in the COMM window were colored, e.g. green for all p2p connections established, orange for at least one peer-to-peer connection routing through host, and red for failed connection with another client (if that is still possible), at least the users would know what’s wrong. All green would be perfect, some orange would be functionally okay although perhaps laggy, and one or more reds would be a no-go. Red users might even be refused to join a mission. Being unable to connect might be a mystery to most users.