Brin Brody Posted September 21, 2017 at 03:09 AM Posted September 21, 2017 at 03:09 AM Hi, I recently put together and released a new sector file updated to AIRAC 1709 for the Anchorage ARTCC. The creation is fine, and it loads into VRC fine, with all diagrams showing up properly. However, when a user attempts to connect to the network with the new sector file loaded, it connects them, and then instantly disconnects them. If they revert to a previous version of the sector file, it works fine. This problem is sporadic, and VRC will sometimes connect to the network without any issue. Is there something wrong with the sector file that would be causing this problem? Download a copy here. Thanks for the help. Brin Brody Link to comment Share on other sites More sharing options...
Ross Carlson Posted September 21, 2017 at 05:03 AM Posted September 21, 2017 at 05:03 AM I don't see how a sector file could cause disconnects. You say it's sporadic, so I'm guessing it's something else. Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Brin Brody Posted September 21, 2017 at 10:04 AM Author Posted September 21, 2017 at 10:04 AM I don't see how a sector file could cause disconnects. You say it's sporadic, so I'm guessing it's something else. That was my thought too. However, it happens ONLY with the new sector file, and not with any of the old ones. The rest of our staff couldn't find any good reason, as sector files don't influence connections. There's been no reliable way to reproduce the problem past trying to connect using that sector file. Did you see anything abnormal in the file itself? Brin Brody Link to comment Share on other sites More sharing options...
Board of Governors Don Desfosse Posted September 21, 2017 at 01:52 PM Board of Governors Posted September 21, 2017 at 01:52 PM I also just tried to connect, and was immediately disconnected. How much changed between the old file and the new file? You may want to start with looking at the changes that were made. One suggestion is to load both into Word and then use Word's Compare Docomeents functionality to see if something jumps out at you. Don Desfosse Vice President, Operations Link to comment Share on other sites More sharing options...
Board of Governors Don Desfosse Posted September 21, 2017 at 02:18 PM Board of Governors Posted September 21, 2017 at 02:18 PM One other troubleshooting note: The new sector file works on Sweatbox, just not on the live servers. Don Desfosse Vice President, Operations Link to comment Share on other sites More sharing options...
Board of Governors Don Desfosse Posted September 21, 2017 at 02:38 PM Board of Governors Posted September 21, 2017 at 02:38 PM Got it! In line 25 of the file, a/k/a the first line under [iNFO], remove the colon (:). Ross -- would you be willing to update the docomeentation (http://www1.metacraft.com/VRC/docs/doc.php?page=appendix_g) to show this limitation? Don Desfosse Vice President, Operations Link to comment Share on other sites More sharing options...
Bradley Grafelman Posted September 21, 2017 at 02:43 PM Posted September 21, 2017 at 02:43 PM After playing with Wireshark for a bit, I figured out what the problem was. @Brin: You need to remove the ":" (colon) from the first line under the [iNFO] section. @Ross: VRC apparently doesn't strip/escape/translate protocol delimiters in the [iNFO] section. Not sure if that's known/docomeented somewhere... but a .sct2 file that looks like this: [INFO] ZAN-VRC: AIRAC 1709 will break the protocol by including the ":" field delimiter unescaped in "$CR" messages: $CRZLA_BN_OBS:AKA1637:CAPS:VERSION=1:SECPOS=1:ATCINFO=1:MODELDESC=1 $CRZLA_BN_OBS:AKA1637:RN:Bradley Grafelman:ZAN-VRC: AIRAC 1709:5 $CRZLA_BN_OBS:AKA1637:ATIS:E:1 This causes the FSD server to quietly kill the connection (sets the FIN flag in the next TCP packet). EDIT: Damn, Don beat me to it. Link to comment Share on other sites More sharing options...
Brin Brody Posted September 21, 2017 at 02:46 PM Author Posted September 21, 2017 at 02:46 PM That's my own stupidity. You'd think I would learn something from a few years of programming. Thanks for the help guys. Brin Brody Link to comment Share on other sites More sharing options...
Board of Governors Don Desfosse Posted September 21, 2017 at 02:47 PM Board of Governors Posted September 21, 2017 at 02:47 PM Well, you know all that code gobbledygook. I just beat the thing with a hammer, stripped out 9.8MB of junk in many multiple p[Mod - Happy Thoughts]es, kept testing variants of the file with tweaks, etc., kept trying to find "the variable" until my hammer hit the colon. I could get rid of the symptoms, you knowing all that code gobbledygook and coordinating with Ross might actually cure the illness / solve the problem! Don Desfosse Vice President, Operations Link to comment Share on other sites More sharing options...
Ross Carlson Posted September 22, 2017 at 12:06 AM Posted September 22, 2017 at 12:06 AM Strange that it's intermittent ... I would think the invalid packet would happen every time. Maybe the data server doesn't do a real name request on every connection. (I [Mod - Happy Thoughts]umed it did, but maybe not.) That's what the CQ:RN packet is a response to. What's also strange is that you don't get a syntax error before the disconnect. I guess the server is silently killing the connection. Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Board of Governors Don Desfosse Posted September 22, 2017 at 02:18 PM Board of Governors Posted September 22, 2017 at 02:18 PM When I did my testing yesterday, I was disconnected every time. In almost all of the cases, it was within one second. I didn't keep records, but I think in one or two cases it may have taken up to 4 or 5 seconds before the disconnect happened. Don Desfosse Vice President, Operations Link to comment Share on other sites More sharing options...
Brin Brody Posted September 22, 2017 at 07:35 PM Author Posted September 22, 2017 at 07:35 PM When I did my testing yesterday, I was disconnected every time. In almost all of the cases, it was within one second. I didn't keep records, but I think in one or two cases it may have taken up to 4 or 5 seconds before the disconnect happened. Personally it happened every time... I had people reporting that it was working for them every once in a while though. Hence "sporadic". They might've just been using the old sector file? Brin Brody Link to comment Share on other sites More sharing options...
Bradley Grafelman Posted September 22, 2017 at 07:43 PM Posted September 22, 2017 at 07:43 PM Personally it happened every time... I had people reporting that it was working for them every once in a while though. Hence "sporadic". They might've just been using the old sector file? Another explanation would be that they either had no traffic or didn't have traffic using a certain pilot client. From what I can tell, the "CQ:RN" packet Ross referenced above isn't a request generated by the server (at least not within the minute or two I sat waiting for it) but instead by individual pilot connections. It could be that not all pilot clients request the "real name" value for all traffic/observers in the area. Link to comment Share on other sites More sharing options...
Ross Carlson Posted September 22, 2017 at 08:48 PM Posted September 22, 2017 at 08:48 PM Some of the controller clients also send the real name request, at least to other controller clients, but also to pilot clients, I think ... I'd have to check ... Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Recommended Posts