Dangerzone

Wonderful. Thanks for putting that in incorrect hypothesis to bed so quickly.

I wouldn't class myself as being an expert either (although I have designed numerous TCP and UDP functions within my career, but normally not 'web' service related...) My understanding is that a 400 error means that the server is responding with a 400 error. (So that the request is reaching the server, but the server is erroring out with an 'unknown' error). I would expect a timeout error or similar if routing was broken. However, I also note that the 400 above may not be coming back from the server. It may be an internal error code within dcs.exe that is raised if it runs into problems itself. So, the above message doesn't definitively specify whether Error code 400 is being received by the server, or whether DCS just has an internal error they've called error code "400". The 'No saved authorization found' is also vague. Does that mean 'locally saved' authorization cache, or is it at the server's end where it is unable to find any locally cached authentication on it's end, and has been unable to send the request further upstream? Either way - I notice when I get this error, it errors out first time, maybe even second, but will go through on the 3rd, without me flushing DNS servers, etc - which has me thinking it may not be a routing issue (as I would expect the same route to be taken each time to the end IP address, which the DNS entry would be cached on my PC or router after the first attempt) but something else might be going on, either with the actual client/server protocols, or something at the server end. The other question I have is that (and it might be - and most probably is) coincidence, but I turned on 2FA on my account with DCS over the weekend and now have started to see this error. My understanding of 2FA says that it shouldn't be a factor for the above, but my limited understanding of the full extend on how ED authenticates accounts tells me that I need to not assume quickly. Thus, my question is - is there anyone here that is getting the above errors that is NOT running 2FA? If so, we can rule that out. If not, and everyone getting the error is running 2FA, maybe it's worth disabling that just to see if it's a factor.

My guess is not much. When you're recording client track files while on a multiplayer server, it's doing this for all the other players/aircraft on the server as it is. So, recording additional data for your own would be the same as recording additional data for another player that's on there. Obviously I can't say that with 100% certainty, I'm not saavy to the source code of DCS, but I'm taking an educated guess. There is a workaround for this at the moment. It's a bit clumsy, but it should work: If you start a dedicated server (even on your own computer) and use it to host the mission, and then launch a second instance of DCS to play the mission, you can use the track file that's recorded from the dedicated server to the get recording your looking for. While it's not an ideal solution - it can be used as a workaround in a pinch. (This won't work though if you're wanting to record and replay stuff back from other public servers online - it only works if you are able to host the mission yourself).

This isn't a bad idea, and you may be onto something. From my understanding, the single player track records all users inputs and 'replays' those inputs when you play the track back. The dedicated server can't do this (as it doesn't have this particular data from all the users) so it instead is recording positions, direction, velocity, etc of all units. As a result, the server method isn't relying on replicating exactly the user inputs but a more robust option of x/y/z/speed/direction/etc of the aircraft. However, in saying this, I believe ED would still need single player track to still record the way it does for diagnostic purposes (the original intent of the track if I'm not mistaken). One possible solution is to have both recorded in the track file, along with the option to choose how to replay the track (either 'diagnostic' which replicates the inputs, or 'replay' which uses the "server" recording data would allow us to have cake and eat it too).

Another one here that was experiencing those issues. Sometimes works, sometimes doesn't. Sometimes I just need to restart DCS and it works. When it does work the 'logging in...' seems to take a while sometimes too, not quick like usual. Will send PM with tracert.

Oh, that's what people were/are doing or how ED are trying to use this for trials? Ummm.. OK. I won't say anything further on this re 2FA because I don't want to cause problems by exposing the holes with this approach. Good point though on the hardware based checksum. Hopefully that's already being used, as that would definitely be a way of tracking abusers with the multi-account approach, and thanks for clarifying or giving a reason why people are linking 2FA with 'trial abuse' security. I appreciate the explanation.

Hi Tom, So how it works is like this. The QR code (or the manual seed code) you get is all that's needed for the devices to calculate the authentication. I give an analogy in here how it works. No devices need to know about other devices. If you enter the same manual code, all devices will give you the same number because all it is is combining the initial seed/code with the current date/time to come up with a specific number. (Which number and combinations will be different depending on the starting seed/code) You are correct. If you note the initial secret key/code/seed - you can put it in as many WinAuths (or as many different authenticators as you want). You can have WinAuth running on your PC, Microsoft Authenticator running on your phone, etc. They will all just combine your initial secret key with the current date/time and give you a calculated figure that should match. This is the best 2FA (in my opinion) for this kind of setup, because: 1) It's an open formula that can be used (and is used) by many different programs, and 2) There's no syncing between devices, so you can have multiple independent devices as backups, or convenience, and 3) Unlike SMS messaging, there is no costs involved in it's use, and 4) It's completely separate/independent. There's no network needed. No tracking. No having to give ED any personal information. It's effectively 'free extra security'.

Thanks for clarification Rob. My apologies for misunderstanding where you were coming from and I appreciate the clarification. TBH, it's been a week of headbutting walls, and I misunderstood where you were coming from, so the clarification is greatly appreciated! I also haven't read every post, I got through a few and thought "oh dear - this is a mess that needs clarification" and jumped in.

Thanks for getting back and confirming your experience. Glad I could be of help.

Hey there, I'm really not looking for an argument, but I'd ask that you please refrain from put words into my mouth about what I'm thinking. I never said I think ED is lying to their customers. I have no idea what ED have stated. All I am simply doing is clearing the air as to what 2FA is, what it does, and what it doesn't do, and correct the false assumptions people have, while trying to help people understand it's purpose, potential reasons for it's use, and alternatives besides google or smartphone apps that people have expressed desires for due to understandable, but not relative privacy concerns. The limits of it's use are basic facts and simple. I've worked with the source code myself, but no one needs to trust me. It's freely available on the net for anyone who wants to check and see how simple and basic it really is. It doesn't take much to see how basic it is and confirm if what I'm saying is true or not for anyone who is interested. I'm confused with the resistance to my trying to clear the very smoky air from the misunderstandings about 2FA, and what seems like determination to continue to keep ignorant of it's purpose, capabilities and limitations and be upset about issues that don't need to be issues. But I've spent about as much time on this as I'm willing to and I really don't want to keep going on with people about it if they don't want my knowledge and input, so I'll respectfully bow out of this discussion as it's now past the point of productivity and into diminishing returns.

I think there's a false assumption that 2FA is about stopping abuse of multiple accounts for trials. It's not. It can't be. It doesn't work like that. 2FA has nothing to do with ED not trusting you. It has nothing to do with ED tracking you, or locking your account down to one mobile phone number, or device. It has nothing to do with (nor can it) stop you from making multiple copies of accounts for consistent trials if that is their goal. (Which by your above post, it appears to be your understanding). 2FA can't prove any of this. All 2FA does is add an extra layer of security to your account that means someone requires more than a username and password to get into your account. That is it. That way, if someone manages to get your username and password (such off a hack list) - they still can't get in. Even if they were watching over your shoulder and knew your username and password, and watched you type in your 2FA, once they get home, (or even 30 seconds later) they couldn't log into your account knowing all that - because your 2FA has now changed to another number. All it is is an extra layer that a would be thief would have to get through in order to log into your ED account. That is it. It does not, and can not stop people from abusing the trial licensing. That is not it's purpose. As such, having purchases in your account does nothing to increase or reduce the risk compared to 2FA. Having purchases can't reduce the risk of hacking into your account. From my perspective, the more purchases you have, the better off you are with 2FA. It's the accounts with little to no purchases that are the least risk because what's a thief going to get? Next to nothing. On the contrary, an account with all the terrains and 3/4 of the modules is another matter. We would want extra protection on those. Now, looking at the flip side - if all this is as people are assuming - about ED trying to stop people from using multiple accounts for trials, then yes - your idea would be good. But 2FA isn't for this, and can't do this, so I really think people's assumptions about it's use here are extremely flawed. As to the question why ED has decided to enforce 2FA for accounts that want trials I do not know, nor understand, but I can take an educated guess: That would be that they might be having an increase of issues with people's accounts being hacked that is causing a higher work load, and they want to reduce this. If so, 2FA is one of the simplest solutions for this. But not many people haven't been using it. How can they encourage more to get on it? Well, as people try out new modules, require people to turn it on. These people may not be aware of 2FA until then, or just be apathetic and not care. This gets them over the line. Making it compulsory on trial purchases will have a lot of people switch over to 2FA, securing their accounts better. Doing trial purchases may be the best option, because making it compulsory on existing purchases may be received poorly at forcing people to do this for something they've already paid for. (And given the reactions to the misunderstandings here, if this was their reason, they'd probably be right). If, on the other hand ED are doing this to try and stop multiple-account trial license abuse, then they'd be barking up the wrong tree. 2FA can not make any difference with this except for those who misunderstand it and are scared off by it thinking that it's doing something that it's not.

I think the calculator analogy is almost spot on. Think of it this way: I say to you you’re going to have a unique code. Let’s say it’s 123456. From that unique code, I need you to add the year, the month, the day, the hour, and the minute. you will always have a different number to everybody else, because of the unique code you started with, and someone having a different one. every minute you will get another unique code. That’s all this 2FA app is doing. The summing is a little bit different but at it’s foundation it is only a calculator with a clock. It doesn’t use internet communications. It doesn’t use mobile network. It doesn’t communicate with a server. There’s nothing for someone to intercept and hack. So what security vulnerabilities are left that could be that you consider risky? This isn’t a web service app. It’s a local pc app. Respectfully, in this instance I don’t think your point comes from a true understanding of the security side. I would suggest trusting (or not) pc apps based on compile date is a very poor way to base security. One needs to know what the app is doing for potential venerabilities. I’ll try to elaborate to make it clear as I would consider apps like lastpass or Google authenticator more risk because they are web service in that they tend to store your key in their database (and we’ve seen how cloud databases can get hacked in the past). But that’s just me. I acknowledge even that’s so unlikely it’s not a real factor. But even so, this app has none of that, so it could be argued that even with its age it’s more secure than modern “phone home” apps. This app only stores data locally only on your own PC. How secure it is is up to how well you maintain your own PCs security. If your worried about someone hacking the app, you’ve got bigger issues to worry about as they’re in your PC. In the end I don’t care what people use, I’m just trying to clarify some misinformation and unrealistic concerns here by giving people better information to make their own informed choices based on a better understanding of what all this is.

I’m not sure of your point? 2FA is set. There’s no need to update it. The algorithm is the algorithm. I can use a 20 year old calculator app and get the same answer as a modern app. Winauth was mentioned simply because it’s proven and for the KISS mentality and It’s open source too. But if you’d prefer something else, go for it. The beauty with this kind of 2FA is that it’s effectively public domain and there’s tones of options. If you don’t like any of the many other apps, you could go as far as applying the algorithm and write your own app. I’m not sure. I agree that the web page could be more informative. I understand the hesitation to use Google anything. One of the reasons I use Winauth.

Yeah - that makes it a bit more difficult. Possible solutions may be: 1) ED allowing the same 2FA to be linked to multiple accounts, or 2) Contact ED Support and see if they will migrate the licenses onto a single account. (Given that this 2FA is a new thing, even if you've tried this in the past and were denied, they may be willing to reconsider this time). In either situation, your scenario sounds very unique, so I doubt ED are going to change their options to suit such a unusual scenario. The better bet would be to see what they can do to assist you in getting into a more comfortable setup that's more inline with how the purchases are designed to be.

Same here. I had the X56, ended up having the ghosting signal problems (switches executing without me doing anything), the friction problems, and the throttle 'falling' on it's own. One of my biggest PC regrets I've had after going to VKB and VIRPIL combination. X56 is definitely cheaper, but the ratio of cost/quality is disproportionate. It's quality is far worse than it's price tag should allow for.

You do not need a smart phone, nor tablet, and you can configure 2 factor authenticator. You don't need to use Google Authenticator. I'm assuming you have a Windows PC because you play DCS. If so, check out https://winauth.github.io/winauth/download.html It's free, open source, generic authenticator that can be used with ED/DCS. Simply click the add button, and copy/paste the manual code into this application. My recommendation is to either print and save the manual codes somewhere (so you can use them later if your PC crashes and you lose access), or otherwise setup 2FA on at least 2 separate devices so if one crashes, blows up, is stolen, etc - you still have authentication options on the second device. Edit: It seems that the biggest confusion with all this is that ED's page says "Download Google Authenticator Here". This is giving the uninitiated a wrong impression that Google's authenticator is needed to use 2FA. It's a pitty they've worded it like that, and hopefully they will change their page. However, you don't need Google's authenticator., Any authenticator that supports the algorithm (such as WinAuth) will do the job.

Just FYI - 2FA isn't restricted to one device. I never have my 2FAs on only one device (as I have the same concerns as you - what if my phone is lost or stolen). Using either the QR code, or the manual code, you can have your 2FA on multiple independent devices. I normally go with my phone, as well as an app on my main PC (at a minimum). This gives redundancy/backup.

Do you mean your 'in game' name, as that's about all people will see. I don't think anyone (from within DCS) has any access to your actual account login name for the ED website, unless you give it to someone to 'gift' a game to you. Just go into DCS-> Multiplayer, and up the top right corner, click on your multiplayer name (or the icon next to it) to change it to what you want.

OK - I just realised it doesn't need to be a pain. I'm assuming you have 2 accounts because one is for a server, and the other is for your actual gaming? Firstly, it looks like ED is only requiring 2FA for trial licenses, Thus, you don't need 2FA on your other account(s) such as server accounts - only the gaming account that you want to do trials with. (And I'm assuming you only have one of those, otherwise you may be breaching ED's T&C). This means that ED only require you to have 2FA on one account. (The one that you'll be doing trial licenses with). Secondly, it's worth noting that ED gives you the option to disable 2FA as well. So, you only need to activate 2FA for the time that you want to trial the new module. Once you're finished, you can disable 2FA.

It works off the device's clock. That's all it needs, an accurate time piece. (Plus the original unique encoder code that was used to set it up, which ED provides you both with a manual text version, and a QR code). Sorry, but that is completely incorrect. It can be used without a smart phone. (See my post above, I've already done it) Still requires a "smartphone" That is incorrect. Check out WinAuth for a non-mobile phone option. You don't need to put an app on your phone. Use a non-phone 2FA app if you want. See WinAuth as one (of many) free, open source, PC friendly alternatives. This is the first concern I've read on this forum that actually has some credibility. Maybe it might be possible for ED to allow us to specify our own manual code, or use the same QR/manual code on multiple accounts, so only one 2FA code is required. But that aside, most 2FA applications out there allow you to have many 2FA's displayed simutaneously, so it's not like you need to have a separate app for each one. I've got a 2FA app with probably 15 different authenticators 'in one'. Maybe ED would consider though allowing us to link accounts for a single 2FA? Aaaah - now the penny has dropped. People who don't understand 2FA are seeing "Download Google Authenticator" and are going "Hell No!". OK - I understand. If I didn't understand how 2FA worked, I'd probably be concerned/confused by that as well. Maybe ED needs to change the website to make it a bit clearer that google authenticator is only one of many options available.

I'm not sure if I'm missing something here, but my understanding of 2FA (in the way that ED is implementing it) is very different to what people are sprouting here. Half this thread seems to be giving miss-information. Here's a few things that are needed to clarify the 2FA authenticator method that ED is using: 1) It does not have to be linked to your mobile phone number, or even your mobile phone. 2) You are not forced into a particular application, or company. (It's a open algorithm) 3) You don't have to pay for applications in order to use it 4) You can use a free, stand-alone, open source 2FA applications on your PC if you want to go that way (see below) 5) You do NOT need an internet connection, or mobile phone network, or anything to use 2FA. The only requirement for this method of 2FA to work is that the device you're running the application on (whether it be phone, PC, or some other device) has an accurate clock. In the same way, I don't see how this has anythign to do with ED not trusting their customers. It doesn't help them trace anything back to you. It only confirms future logins are from the same person who setup the 2FA option to start with. It makes the users account more secure (which maybe in turn, makes things more secure for ED - I have no idea how many hacked accounts they're dealing with, and maybe this is the way to get more people to start using 2FA). But all the objections I've read here seem to either account to many people having no clue what 2FA is (they're worried about being forced to reveal phone numbers, or use smart phones, or use Google, of which none of this is true), OR I'm missing something big here. So my question is this - WHY is 2FA a "deal breaker" for so many people? (I'm genuinely wanting to understand). Is it that there is great misunderstanding of the 2FA that ED is using, or otherwise what am I missing? As for free apps you can use that don't require a phone, try WinAuth https://winauth.github.io/winauth/download.html Instead of scanning the QR code, just copy and paste the manual code given by ED into the app.

No, I don't believe they do sorry.

With pedals, HOTAS and in VR - it is absolutely brilliant! I hope you manage to get good rudder pedals one day. I currently use the VKB T-Rudders and find precicion inputs a breeze with them, being able just to use my toes.

OK - I've just found the problem. For some reason, under the Options->Misc tab, there's a checkbox called "Force feedback". This was checked. Unchecking it seems to have resolved the problem.

I have real rudder pedals. My problem is that the trim doesn’t seem to work. So when I push my cycling forward and then press the trim button, I’m expecting to be able to return it back to Center and still have the helicopter fly forward. CTRL T seems to be completely ineffective. Or are you saying that the force trim in the Huey only relates to rudder, and not to the cyclic like it does in other aircraft?