"Authentication Failed: A task was canceled" upon connection attempt

[KWONGCHU TONYWONG]

Hi there, I am encountering the same issue here but after I disable the IPV6, I manage to connect Vpilot but again once I enable the IPV6 connection, the Vpilot could not connect. Is there any update recently caused by the IVP6? thanks

[Marius Johansen]

Hi there! 

I'm also getting this connection error and I don't know what to do...

I ran the IPv6 test and here is my results.

[Ross Carlson]

Strange ... looks like you don't have IPv6 support at all, in which case vPilot should only use IPv4 to do the authentication, and it should work fine. Did this just start happening or have you never been able to connect with vPilot version 3 (since Velocity came out) ?

Have you tried rebooting your PC and rebooting your router?

[Marius Johansen]

I just downloaded it. But I didn't think about reinstall it. I will try that, and come back if it doesn't work. 

[Marius Johansen]

Hi Ross!

I just downloaded it again and sat it up again. It's still the same error...

[Ross Carlson]

Did you see my other questions about rebooting your PC and/or router?

[SERGIO CAMPOS]

Hello Ross:

Answering your questions posted on Jul, 27: - I've never had problems with vPilot before; it all started a month ago. As I said in my post on July 16th, rebooting the router everything works normally. From yesterday until today, everything worked normally, without having to reboot.

[Don Desfosse]

Thanks for the data point, Sergio, though i believe Ross' question was really aimed toward Marius.

[Marius Johansen]

Hello Ross!

Sorry for late answare, I was on vacation! 

I have tried rebooting my pc and my router, still doesn't work...

[Marius Johansen]

Hey Ross!

Did you get my last post?

 

 

[Ross Carlson]

Yeah, I'm afraid I don't know what's causing it.

[SERGIO CAMPOS]

In my case, the problem persists 20% of the time I try to connect vPilot; so, 80% of the time it connects normally.

When there is a problem, I turn the router on and off, and then connect.

Therefore, we will persist in researching the problem, but it is not a serious thing.

So don't worry so much. 

[Thanapong Prathumchat]

I also facing this problem today. Running ipconfig /release and ipconfig /renew seems to be fixing it.

[Marius Johansen]

Okay, Sergio 🙂 

But I have never been abel to connect to the vatsim network on msfs with Vpilot. Everything works fine on xplane with xPilot though...

[Ricardo Jorge]

Hi there 🙂

I have read every single comment on this thread and I am facing this issue since I switched to Windows 11 (clean install), not sure if it's connected but that's what happened to me.

I have read a lot of comments mentioning that this could be an issue of our machines or a specific config. Not being an IT expert I tend to disagree since we have a lot of people facing this issue and started approximately in the same time period...

I strongly believe this is something that can be adjusted/fixed in the vPilot source code and that a new version can cover this up...

In the beginning, in order to have vPilot connected, I was just restarting my pc and everything would work just fine and vPilot would connect again. But that's a pain, since you need to wait for the sim to load again. Now, I am still facing this issue but it became easy to work around... I have a VPN service (Surshark in my case), and the only thing I need to do if vPilot is failing on the authentication part, is to connect my VPN and disconnect right after and then vPilot connects like a charm 🙂

Hope I have helped and please consider to take a look on the vPilot code, a lot of people is facing this in a short period of time.

Thanks

[Ross Carlson]

8 hours ago, Ricardo Jorge said:

Hi there 🙂

I have read every single comment on this thread and I am facing this issue since I switched to Windows 11 (clean install), not sure if it's connected but that's what happened to me.

I have read a lot of comments mentioning that this could be an issue of our machines or a specific config. Not being an IT expert I tend to disagree since we have a lot of people facing this issue and started approximately in the same time period...

I strongly believe this is something that can be adjusted/fixed in the vPilot source code and that a new version can cover this up...

In the beginning, in order to have vPilot connected, I was just restarting my pc and everything would work just fine and vPilot would connect again. But that's a pain, since you need to wait for the sim to load again. Now, I am still facing this issue but it became easy to work around... I have a VPN service (Surshark in my case), and the only thing I need to do if vPilot is failing on the authentication part, is to connect my VPN and disconnect right after and then vPilot connects like a charm 🙂

Hope I have helped and please consider to take a look on the vPilot code, a lot of people is facing this in a short period of time.

Thanks

The reason people started having this issue at the same time is because vPilot switched to VATSIM's new more secure method of authentication, with version 3. This new method is required by VATSIM for all clients to use going forward. This is a good thing because your password is sent to VATSIM in a much more secure manner. Switching back to the old way is not an option.

The issue is that the new authentication mechanism is accessed over IPv6, which is a newer, more-modern protocol for addressing servers. If the user's computer, router, or ISP has faulty IPv6 support, then the authentication fails with the error that you are seeing.

My best guess is that the issue has to do with the IPv6 IP address that has been assigned to your computer by your router. I believe that that IP address becomes invalid after some time passes. This is just a theory, but it is a theory that fits the facts. Most users can resolve the issue by rebooting their PC, or their router, and this may cause your PC to be assigned a new IPv6 address. Manipulating your VPN connection as you describe likely has the same side effect.

In any event, it's not a problem in vPilot's code. The vast majority of users have no issues. That being said, I am still looking for ways to make vPilot detect when the user has faulty IPv6 connectivity, and have it fall back to the old IPv4 protocol. I don't know if or when I'll be able to implement such a workaround in vPilot.

[Venkatesh Nagarajan]

9 hours ago, Ross Carlson said:

The reason people started having this issue at the same time is because vPilot switched to VATSIM's new more secure method of authentication, with version 3. This new method is required by VATSIM for all clients to use going forward. This is a good thing because your password is sent to VATSIM in a much more secure manner. Switching back to the old way is not an option.

The issue is that the new authentication mechanism is accessed over IPv6, which is a newer, more-modern protocol for addressing servers. If the user's computer, router, or ISP has faulty IPv6 support, then the authentication fails with the error that you are seeing.

My best guess is that the issue has to do with the IPv6 IP address that has been assigned to your computer by your router. I believe that that IP address becomes invalid after some time passes. This is just a theory, but it is a theory that fits the facts. Most users can resolve the issue by rebooting their PC, or their router, and this may cause your PC to be assigned a new IPv6 address. Manipulating your VPN connection as you describe likely has the same side effect.

In any event, it's not a problem in vPilot's code. The vast majority of users have no issues. That being said, I am still looking for ways to make vPilot detect when the user has faulty IPv6 connectivity, and have it fall back to the old IPv4 protocol. I don't know if or when I'll be able to implement such a workaround in vPilot.

 

Questions/notes 

1. When did VATSIM move over to the new authentication? 
2. Is it possible to make using the old and non secure protocol an option with big warning to the user. 
3. I have personally seen vpilot lose its connection and when I retried instantly it gave me the above error. I am fairly certain that my IP address provided by my router did not change. So maybe, just maybe, there is more to it 

4. As a coder myself I appreciate how frustrating this kind of bug is to debug. It works for 1000s of people but it some seemingly corner case it fails. So we appreciate your help 

thanks 

[Ross Carlson]

1) I'm not sure when the new authentication scheme became available, but I can say for sure I started using it in vPilot 3.x.

2) Moving to the old protocol is not an option. VATSIM is requiring all clients to move to the secure protocol. The old one is literally decades old.

3) Yeah, the IP address change is just a theory. Though you would need to know for sure that your IPv6 address didn't change in order to rule that theory out.

[Venkatesh Nagarajan]

59 minutes ago, Ross Carlson said:

1) I'm not sure when the new authentication scheme became available, but I can say for sure I started using it in vPilot 3.x.

2) Moving to the old protocol is not an option. VATSIM is requiring all clients to move to the secure protocol. The old one is literally decades old.

3) Yeah, the IP address change is just a theory. Though you would need to know for sure that your IPv6 address didn't change in order to rule that theory out.

Thank you Ross. 

[Luke Kolin]

On 9/23/2022 at 12:51 PM, Ross Carlson said:

In any event, it's not a problem in vPilot's code. The vast majority of users have no issues. That being said, I am still looking for ways to make vPilot detect when the user has faulty IPv6 connectivity, and have it fall back to the old IPv4 protocol. I don't know if or when I'll be able to implement such a workaround in vPilot.

I respectfully disagree - just because you have an IP address doesn't mean that you have connectivity, and while AT&T has given me IPv6 for about a decade I still go a day or two where IPv6 connectivity is non-functional even though the lease for my IPv6 address remains valid. Links go down and not everywhere is reachable all the time on all protocols.

As part of my software's startup, it does an ICMP (ping) check on all addresses returned back by DNS to validate whether IPv4 or IPv6 connectivity actually works and then prefer a particular socket type during that session. Like with VPilot, most people didn't have problems. But I did. 😄

Cheers!

Luke

Edited September 24, 2022 at 07:30 PM by Luke Kolin

[Ross Carlson]

4 hours ago, Luke Kolin said:

I respectfully disagree

What is it that you disagree with?

[Sami Turk]

A few days ago i also started getting this issue. Ive tried everything with Ipconfig /reset and renew and flushing my DNS however it hasnt solved the issue. Is there any fix?

[Ross Carlson]

4 hours ago, Sami Turk said:

A few days ago i also started getting this issue. Ive tried everything with Ipconfig /reset and renew and flushing my DNS however it hasnt solved the issue. Is there any fix?

Did you try rebooting your router? That has cleared it up for some people.

Other than that, the only fix I know of is to completely disable IPv6 in your network interface configuration in Windows. Obviously, that's a ham-fisted workaround as it has the downside of disabling IPv6 for everything you connect to from the PC, not just VATSIM authentication.

I've been working on changing vPilot so that it only uses IPv4 addresses when doing the VATSIM authentication request. If you (or anyone else) would like to test it out, find me in Discord, user name is RossCarlsonBTV#7854.

[Luke Kolin]

On 9/24/2022 at 7:42 PM, Ross Carlson said:

What is it that you disagree with?

I disagree with the statement that the problem isn't the code. I'm sure the code is working correctly as designed, though. 🙂

In a dual-stack world, it's likely that clients will have both IPv4 and IPv6 addresses (in the case of the latter, several) , and it's entirely possible that one, either (or both!) do not have connectivity to the end host. You can't make any assumptions about routability based on the address itself, since the IPv4 ones may be RFC1918 (or not, there are some crazy NAT implementations out there) and at the end of the day because of firewalls and bad routing tables and weed smoking network admins, some may not work - and then they do.

I ended up just doing the ICMP check - it's better to use IPv6, but with a fallback. You may want to look at how Chrome does it - it prefers IPv6 but in cases of connection latency will do multiples connections in parallel (IPv4/IPv6) and then stick with what works.

Cheers

Luke

[Ross Carlson]

1 hour ago, Luke Kolin said:

I disagree with the statement that the problem isn't the code. I'm sure the code is working correctly as designed, though. 🙂

Ahh, I see. When I say it's not a problem in the code, I mean it's not a bug. The worst you could say is that it's a lack of a feature. (That feature being a workaround for people with bad connectivity.) I am of course fully aware that the presence of an IPv6 address does not guarantee IPv6 connectivity. Anyone that thinks it does just doesn't understand networking at all.

Whether or not I should feel compelled to build a workaround into vPilot is a subjective matter. I generally make calls like that based on the percentage of the user base that is affected and the "cost" of implementing the workaround, in terms of my time, time which may be better-spent elsewhere.

I think in this case, the number of affected users is small but not insignificant, and the cost of adding the workaround is pretty low. I've already written some rough code that fetches all the DNS addresses, picks one of the v4 addresses at random, and builds the HTTP request manually, using that address, and a Host: header. It works in my basic testing. I'm thinking I can do the regular call first, with a relatively short timeout, and if that times out, I can try the v4-only call. I think I'd prefer that over doing an ICMP check, because lack of ICMP response does not necessarily mean IPv6 will fail for the HTTPS connection. (I really wish Fast Fallback (aka "Happy Eyeballs") was built into the .NET HttpClient, but it's not, yet. I assume that's the algorithm Chrome uses.)