Trouble with Error 66 in LV 8.2.1

[mikeporter]

I'm having a strange problem. I am trying to access LV 8.2.1 on one computer (windows) from a copy of LV 8.2.1 running on another computer (also windows). This is something I have done thousands of times in the past but now it's causing problems. All I get is an Error 66 which means that the LV application I'm talking to is rejecting the connection. In the VI Server Configuration page I have TCP/IP enabled and have the correct port set; and on the Machine Access page I have entries for the specific machine I am accessing it from as well as "*" (everybody). Still no joy...

If I shut LV down I get a different error (56) which is a timeout and is what I would expect. In addition, if I boot-up LV7.1 on the remote computer I can connect to it just fine. Any ideas?

Mike...

[Ben]

This was reported to NI Support under SR# 1033787.

The CAR# 400AQB3S

has notes about obsolete tokens in the ini file and a new one!

Can we get more info on this?

Please.....

Ben

[mikeporter]

Well there's not a whole lot to tell so far. By duplicating the server.tcp.acl tag from the system I was trying to access the remote LV from and putting it in the target LV's ini file, I got the connection working. But this is a less than totally satisfying solution since that tag should have been there already, plus there is no documentation as to what this tag actually does. I'm guessing from the abbreviation and the fact that the server.tcp.access tag has been deprecated that "acl" stands for Access Control List. It would be nice if LV generated this tag since it is clearly needed - it would be even nicer if it were documented. Magic numbers make me uncomfortable.

One other note, NI support says they can't duplicate the problem but are continuing to look into it...

Mike...

[Ben]

Thanks for the update Mike.

Re: NI's inability to duplicate

No you are not crazy (in this regard  ). I saw it myself.

Ben

[mikeporter]

Just got a call from NI and an engineer is looking into the "acl" value and will be posting some documentation on it to this thread in the near future. Also, R&D is trying to figure out what is causing the original no access problem - so stay tuned. In addition, as a work around there is also an application property (under the Server submenu) that allows you to programmatically control access to a VI server connection. There is also an example VI showing how to use it.

Mike...

[Craig_D]

Ben,

The CAR which you were referring to deals with copying over the server.tcp.acl token from your LabVIEW.ini file to an executable's ini file as shown in KB 41CJ25OC.  This was due to a problem which stemmed from copying VI Server tokens from the LabVIEW.ini file when building an executable.

However, from what I understand, you are encountering a problem trying to communicate between LabVIEW development environments on different computers.  The server.tcp.acl token should be generated by LabVIEW in the LabVIEW.ini file when the machine access is changed in options.  You should not have to manually add it.  In fact, if you delete the token from the ini file, the machine access will go back to the default values.  Then, when you change the access again, it will regenerate the token.  Is this not what you're seeing?

I'm not completely familiar with the server.tcp.acl token, but it seems to just be controlling machine access.  I'm guessing the reason you can't find much documentation on it is because, ideally, the end user should not have had to ever touch this token.  Also, I'm guessing the reason for the long hex string is for security reasons, but again, I'm not completely sure.  I'm going to check into this a bit more and let you know what I find.

Regards,

Craig D
Applications Engineer
National Instruments

[mikeporter]

---

@craig D wrote:

However, from what I understand, you are encountering a problem trying to communicate between LabVIEW development environments on different computers.  The server.tcp.acl token should be generated by LabVIEW in the LabVIEW.ini file when the machine access is changed in options.  You should not have to manually add it.  In fact, if you delete the token from the ini file, the machine access will go back to the default values.  Then, when you change the access again, it will regenerate the token.  Is this not what you're seeing?

Yes, that is exactly what I am not seeing... The only way to get that value into the ini file for the development version of LV was to copy and paste it. I changed the settings from the appropriate options tab several times, stopped and restarted LV several times (even rebooted the computer) and the only way I could get that value into the ini file was to paste it in myself.

Plus, according to the person who handled my original report, she was able to get VI Server to work even with the value completely missing from the ini files on both ends of the connection.

Mike...

---

[Roy_F]

---

@Ben wrote:

This was reported to NI Support under SR# 1033787.

The CAR# 400AQB3S has notes about obsolete tokens in the ini file and a new one!

---

The above CAR was closed (for internal reasons).  The CAR that will actually address this problem is CAR# 3I7B7BJ1.

Roy

[THailey3]

Hi all,

Whenever you change settings in the Tools->Options dialog, we save those settings in the LabVIEW.ini file using many different ini tokens.  When a token is absent from the ini file, that means the default setting is being used.  Said another way, if you don't change the default setting in the Options dialog, there will be no ini token pertaining to that setting in the LabVIEW.ini file.  I can confirm that when using the default VI Server settings for both Machine Access and User Access, there is no server.tcp.acl token present in LabVIEW.ini.  FYI, the default setting for VI Server: Machine Access is allowing access from only the development machine's IP address.  If you change the settings for either Machine Access or User Access, you will see a server.tcp.acl entry in LabVIEW.ini.

Now, when you create an executable and choose to "Use the default LabVIEW Configuration file (LabVIEW.ini)" (from the Advanced tab in the Build Specifications), an ini file is created for your application that pulls from the settings located in LabVIEW.ini.  We try to be smart in doing so by filtering out settings that only apply to the development environment and wouldn't make sense to include in the built application's ini file (i.e. Recent File Open list, editor options, etc.).  In this case, it looks like our filter isn't so smart and is incorrectly filtering out the server.tcp.acl token.  Contrary to the CAR IDs mentioned above posts, this was reported to R&D (# 400C2N00) for further investigation.  If you're going to track a CAR ID in bug future fix lists for this issue, # 400C2N00 is the one to track.  CAR # 400AQB3S was closed, as Roy mentions, for internal administrative reasons.  CAR # 3I7B7BJ1 is being used to track brainstorming on making inclusion of all possible application-related ini tokens easier, more thorough, and more intuitive for users through some sort of UI.

I hope this helps,

[rolfk]

---

@craig D wrote:

I'm not completely familiar with the server.tcp.acl token, but it seems to just be controlling machine access.  I'm guessing the reason you can't find much documentation on it is because, ideally, the end user should not have had to ever touch this token.  Also, I'm guessing the reason for the long hex string is for security reasons, but again, I'm not completely sure.  I'm going to check into this a bit more and let you know what I find.

---

I might be wrong but the ACL seems to be structured just as the ACLs in Windows and as such the long Hex string has nothing to do with security in itself (it's use of course is for security here) but is just the representation of a GUID (globally unique identifier) which rely on an algorithme for creating them that is supposed to generate truelly globally unique values on every system. Seeing how they are used everywhere I start to doubt that they are still that, but for most purposes that is not a problem.

The idea to shield any user from this mess is noble but I think it won't work completely. At least documenting it will help to understand how it works. As it is now it feels and smells like the whole password security relies heavily on security through obscurity and I don't think that is what NI wants power users to see it like, who will have to decide for corporate use if they want to rely on this technology.

Rolf Kalbermatter