Yes, I did so
In that case, and if you didn’t do so already, try Striker’s advice: http://cubpilotshangar.net/page105.html
Yes, I did so
In that case, and if you didn’t do so already, try Striker’s advice: http://cubpilotshangar.net/page105.html
When you tried to reflash the Cougar, did you reset the Cougar to factory defaults first? The procedure is to plug in the USB connector while holding the trigger.
Did you try pulling the trigger and then plugging the USB in? This should reset the firmware. You’ll need to upgrade the firmware after this, if it brings the Cougar back to life. If that doesn’t work, check the USB cable with a multimeter, perhaps it’s damaged. If it’s really the PCB that’s broken, than things are not so simple as Thrustmaster made you believe. Most likely one of the “big chips” is broken, and they are hard to unsolder, perhaps no longer available, and at least one of them holds microcode that you don’t have.
If you got a friend with a Cougar, you could try swapping in his PCB to see whether it’s really the PCB that’s causing problems.
I thought of an issue with this approach. Ideally, clients should be able to connect without port forwarding setup at their side. Sort of the Holy Grail. This requires NAT traversal to establish the peer-to-peer connections between clients, but that’s already in place (in RAKNET). However, by having the server query port 2935 on the client side, you basically require port forwarding on the client side. Of course, if things depend on the parameter AllowDubiousConnections, this could be acceptable.
With my current ISP provided “2WIRE” router (previous DLink I cant get working with this ISP) If I set up port forward
on 2934-2935 then FoL see me as a dubious connection. So can’t connect.
That’s probably due to the fact that your router changes the source port (2935) of your outbound packets, even though you got port forwarding setup. Most consumer routers will conserve the source port if there exists a corresponding rule for inbound packets.
If I then set up a DMZ I connect, but my local area network is screwed as my PC now has an external IP.
I’m sure you know, but DMZ is a really bad idea. It exposes your PC to the internet, and makes you vulnerable for all kinds of attacks.
My solution was/is no port forwarding & no DMZ, apparently thanks to update 4,5 or 6.
You probably got the “routing through host” to thank for that. It didn’t function as it should at first, but that was fixed in update 4 or 5. If you start BMS with the “-mono” command switch, it creates a log file in ./user/logs. Not fun reading, but if you search for “routing through host”, you might confirm my suspicion.
I think a system where everybody is able to log on to the server, but only well-connected clients are able to join a mission, is ideal.
Ideal is a system that is robust enough to deal with flaky client connections, IMO.
Yes, agreed, but if flaky connections were good enough for a perfect MP experience, we wouldn’t need good connections… So I think that’s unrealistic.
On the other hand, BMS now supports “routing through host” reliably. That creates the opportunity to define the “minimum network quality” of client connections. I.e. set this option (in BMS.cfg) to “high”, and only well-connected clients were allowed to join a mission, set it to “medium”, and clients that are routing through host could join, set it to “low”, and everybody could join. “High” would then be similar to disallowing dubious connections, but with the added flexibility that clients are allowed to use remapped source ports.
source port being remapped by NAT, say to 1234, then the server responding not to 1234, but to 2935, feels funny. Aren’t we violating some rules when we do this?
No. With dubious=0, it checks the port for equal to 2935, and disconnects otherwise. Of course, it -still- has nothing to do with TCP/IP by doing so.
I assume you mean the disconnecting based on source port (AllowDubious=0), when you state it has nothing to do with tcp/ip? Please keep in mind that this option wasn’t meant for public use IIRC. It was just implemented to ensure proper conditions for MP beta-testing.
The idea of having the server respond to 2935 instead of the possibly remapped source port ensures that 2935 is accessible to the server. However, it might still be inaccessible to other clients (i.e. symmetric NAT). The “ultimate” test would be to have all the clients report what the status of their part of the mesh network is, and display messages and/or kick users based on that information. The server could maintain an array of connection statuses of clients to other clients. It’s not trivial what to do with that information. E.g. when client A connects that can only connect to the server, and not to any of the existing clients, not only will this client A list all his statuses as “not connected”, or “routing through host”, all other clients will have one connection status read “not connected”, or “routing through host”, namely the connection to client A. Kick A because overall status was OK before he connected? What if A connected as the first client? No other clients could join then.
I think a system where everybody is able to log on to the server, but only well-connected clients are able to join a mission, is ideal. Of course, the UI should indicate in some way what the interconnection status of each client is.
@sthalik: I expect you need to spend a few more words to convey your thoughts fully to a programmer.
I’d like to discuss things a bit more first.
The concept of the client initiating communications with the server using source port 2935, then that source port being remapped by NAT, say to 1234, then the server responding not to 1234, but to 2935, feels funny. Aren’t we violating some rules when we do this?
Also, it’s still no guarantee that things will be 100%. At least, I believe some NATs are so restricted, that when 2935 is used in conjunction with the server’s ip-address, it can’t be used by other ip-addresses (i.e. the other clients). However, this class of NATs will be a lot smaller than the “I have port forwarding for 2935, but will still remap outbound packets” class.
I’m not sure what the relevance is of Server Hosts All. I believe that has nothing to do with connectivity, just with who controls units in 3D?
Last but not least I wonder whether AllowDubiousConnections should be an issue. If we design a superior mechanism, can’t we forget about this option?
Unfortunately, NAT is under-specified, and routers behaving in this way do not violate any specification.
It’s also valuable to note that reference-firewall/nat impls such as pf from openbsd behave in such a way.
I don’t see how a symmetric NAT could conserve the source port. So if conserving source ports was a requirement, symmetric NATs shouldn’t exist. Not a bad thing for Falcon, as symmetric NATs are impossible to negotiate with NAT traversal as far as I know, but not realistic in the business world.
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.
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.
One can always establish UDP VPN for the purpose of allowing ports open
Never tried that. How would that work? VPN to a software router on the outside? What products could you use for that?
I understand your point of view. However, it was and still is possible to have a reliable MP experience without everybody using source port 2935. In that sense, allowdubiousconnections is too strict. Also, the routing through host feature didn’t work as it should previously. This has been repaired (not sure which release, update 5 or 6 IIRC). So yes, disallowing dubious connections guarantees a good MP experience, but may end up locking out clients that could participate perfectly fine.
For instance, there are routers with a NAT implementation that will forward 2934 and 2935 if set up that way, but these will still renumber the source ports for outbound traffic. No problem connecting to clients behind such routers, but they won’t pass the allowdubiousconnection test, as their actual source port isn’t 2935 according to the server.
When two clients aren’t able to establish a peer-to-peer connection, you’ll see “routing through host” in their monologs, and in the server’s. So keeping an eye on the server’s monolog for this string will give you a good indication whether the connections are good, or not.
Guys, please recognize that you have different views on allowing dubious connections.
Arty likes the option, I assume because he regularly uses it with friends who have their ports nicely forwarded, and restricting the connections to source port 2935 tells him immediately when something screwed up with one of the connections. That client won’t be able to connect, he investigates, solves the problem (it worked before), and he can be certain the mesh network will be complete again.
Blu3wolf dislikes it, because he is located behind a router over which he has no control, and as a consequence, he will never be able to jotin a server that disallows dubious connections. However, I believe not many people use this option (dubious clients are allowed by default), so he will be able to join most servers. Unfortunately, when there are other clients with non-optimal configured routers, the data between them will be routed through the host, causing some lag and bandwidth (at the server side).
AllowDubiousConnections has pros and cons, that’s why it’s optional.
kinda a shame for those of us stuck behind university routers and no port forwarding available…
With dubious connections disallowed, you’re screwed. Without it, you are able to reliably MP with one friend (him being the server), and even reliably MP with a larger party, as long as you are the only one that’s “unreachable”. If everybody else has his ports opened up, you’ll be able to establish peer-to-peer connections with them. One more client like you, and “routing through host” will be necessary between the two of you.
No, you misread. It’s dubious=0 that prevents non-static mappings to work. As said, @mrivers has a problem with non-static mappings. Or something.
I don’t see where I should have read that you meant the situation where dubious=0. That’s non-standard. But you are right: with that switch set, the source port must be unaltered. It’s a crude way to enforce all clients behave “nicely”. Too crude, that’s why it’s off by default IMHO.
That’s not true. Only static mappings work where src port is preserved through NAT. This is very uncommon. It’s been discussed some time back but apparently @mrivers has a different idea of TCP/IP…
I believe you’re misinformed. Source ports may be renumbered. In fact, I’ve found that there are lots of NAT implementations that won’t preserve the source port (outbound) even when you define a port-forwarding rule (inbound).
When setting up the connections, the server notes the actual source port of a client (what NAT made of it), and the source port that client “thinks” it uses (the port used by the PC running BMS behind the NAT). The server sends both ports to the clients that are already connected, and these clients subsequently try to connect to the new client using both these ports. Also the other way around, so the new client receives two ports of all the existing clients and tries to connect the other way around. This gives a total of 4 chances to connect each pair of clients. Unfortunately, as I said before, it won’t work for all NAT implementations.
So break NAT without static port mappings to work around bugs? Oh, bother…
Not sure if I understand you correctly. But in case I do: I didn’t mention that RAKNET has a NAT traversal algorithm. However, this will only work with certain types of NAT’s. So to err on the safe side: open your ports.
Interesting. Could this possibly be the cause for f’d up debriefs (i.e. ordinance released from one jet shows up on another, multiple pilot instances… etc) that we all see from time to time in MP flights?
I can’t rule that out. The debriefs have never been perfect as far as I remember. But in my experience the FU’s you describe often occur when people reconnect, e.g. after being shot down and joining another flight.
Unless your hosting you should not need to forward any ports.
This is only true when there’s only one client. When there are multiple clients, they will try and establish a mesh network. In effect, every client can be viewed as a server then. It won’t fall apart immediately when only one client in a MP has no port forwarding as it will be able to establish connections with other clients through their open ports, but if two or more clients have no port forwarding, they won’t be able to complete the mesh network. BMS has a fallback mechanism in that case: traffic between clients that cannot connect to each other, is routed through the host. Of course, this creates more lag, and takes up bandwidth. Better to configure your router and firewall correctly.
IVC is different. It uses a star topology and as such, each client only connects to the server. There is no need for a client to have open ports, only for the server.