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.