SquawkBox Bugs
 
Bugzilla Bug 50
  Can't connect to VATSIM
     Query page      Enter new bug
Bug#: 50   Platform:   Reporter: chairman@simsouthwest.com (Paul Biderman)
Product:   OS:   Add CC:
Component:   Version:   CC:
Status: VERIFIED   Priority:  
Resolution: FIXED   Severity:  
Assigned To: joel@deyoung.net (Joel DeYoung)    
URL:
Summary:

Attachment Type Modified Status Actions
Create a New Attachment (proposed patch, testcase, etc.) View All


Additional Comments:


Leave as VERIFIED FIXED
Reopen bug
Mark bug as CLOSED

View Bug Activity   |   Format For Printing

Description: Opened: 2004-05-08 11:20

Has the alpha been disabled by VATSIM?  I tried every VATSIM server this 
morning, and they all refused the connection.

Then tried ASRC and it connected fine.

------- Additional Comment #1 From Paul Biderman 2004-05-08 11:31 -------
Ok, after further investigation, I was able to connect, BUT, for some reason I 
had to retype my VATSIM password in SB3 to get it to connect.

NOTHING has changed on my computer or with my VATSIM account since the last 
time I connected, so the password must have corrupted??

------- Additional Comment #2 From Joel DeYoung 2004-05-08 18:16 -------
I think this might be caused by the fact that the password hash is partially
based on the server name.

------- Additional Comment #3 From Paul Biderman 2004-05-09 09:52 -------
That would explain it if I had changed servers before attempting to connect.  
However, I changed nothing on my system until my first attempt was rejected, 
by the same server that I always connect to.  And after I retyped my password, 
it connected to that same server as always, USA-W.

------- Additional Comment #4 From Matt Johnson 2004-05-11 15:22 -------
No, I think the bug is more fundamental... I haven't changed servers and SB3
consistently fails to place the correct password. I only get 5 chars in the
password field on the Connect window, when SB retrieves the password from the
registry (it should be 6).

The registry entry for the password contains binary and appears to be
unicode-ish... given that hashing is mentioned this is probably as desired? The
SZ in the registry is of the form:

xx 00 xx 00 xx 00 xx 00 xx 00 00 00

where all xx are < 0x20. The last null looks highly suspicious.

------- Additional Comment #5 From Joel DeYoung 2004-05-11 17:15 -------
To fix this, make the password entry in the registy REG_BINARY instead of
REG_SZ.  This happens when equivalent string positions in the server and the
password are the same, resulting in a null being inserted into the hashed
password entry, which causes a truncation when read out as a string.

So this would be pretty likely to happen to someone that entered their server
name as a numeric IP address.

------- Additional Comment #6 From Joel DeYoung 2004-05-11 17:57 -------
Done.

------- Additional Comment #7 From Paul Biderman 2004-05-14 17:00 -------
Had this problem again yesterday.  See Bug 82 for a possible reason, although 
I'm not 100% convinced yet this is related.

Related to Bug 82 or not, I did have this issue again with the new Alpha build.

------- Additional Comment #8 From Joel DeYoung 2004-05-24 15:50 -------
Released in May 24, 2004 alpha build.

     Query page      Enter new bug
Actions: New | Query | bug # | Reports   Home | Log In