IP address is not on the target's allowable access list and local hosts file

[xl600]

I'm using LabView RT (PharLap) on a PXIe-8135RT and would like to know if it's possible to use symbolic host names in the target access lists.  It appears that I can, as long as the name is resolvable at the RT target's configured DNS address, but when that DNS isn't available, it's not at all reliable (Sometimes works, sometimes doesn't).

Is there a local hosts file that can be edited on a RT target (PharLap) to prevent this issue?  Or am I stuck using IPv4 addresses always?

Thanks,

XL600

[Bob_Schor]

If the PXI is the RT Target, it should (almost never) need to know anyone's IP address.  Ideally, the Host would find out the IP addresses of possible RT Targets (which it can do), connect to the Target, and (if it were truly necessary) send the Target its own IP address (in the unlikely event that the Target needs to contact the Host).

A month or two ago, there was a post about setting up Network Streams, where both Host and Target IP addresses were used, and the Poster was having problems.  I pointed out how to set up Streams using only the Target's IP address, which works quite well (for me, anyway).

Bob Schor

[xl600]

That's true and in general, there's no hard coded IP addresses in any of my RT VIs, but the access list is not a VI.  I'm asked (By my IT group) to enforce host based access restrictions so my target has to refuse to communicate with any IP other than my host IP.  This works fine if I enter my host's IP directly in the RT target's access list, but not always if I enter it as a hostname.  The RT target does not always have access to DNS  unfortunately (It's portable) so I was hoping there was something like an /etc/hosts or /windows/system32/etc/hosts construct under PharLap.

[diabeticdaniel]

I was unable to find any configuration file that allows you to perform a similar task to Windows' hosts file. It would make sense that the PXI system is unable to resolve the machine name without access to a DNS server, and the best solution with the tools available is to reference your host machine by its IP address rather than host name.

If the IP address of the host is currently not set to a static IP, I would suggest performing this configuration so that you don't have a situation with the host excluded from the white list.

[xl600]

Thanks for looking into this!  I also wasn't able to find any config files which would appear to perform that function.  The network stack of PharLap does have a DNS capability so I was hoping there would also be the ability to use a local hosts type of file (Like every OS seems to have).

[Bob_Schor]

As I understand it, a Hosts File is simply a (tab-separated) Text file with IPs in dotted format followed by corresponding Host name.  I see no reason why you couldn't create such a file on your Remote and include in its initialization code logic to parse this file.  I'm not at all sure how this will help you, however, as you'll still need for the Remote to know the Host Name.  I suppose it could allow a little bit of flexibility by letting you build your Remote RTEXE with code that says "Look up in c:\ni-rt\config\HostFile.dat the IP of MyHost", distribute that to your Remote, then build (on the Host) the HostFile with an entry of <Host IP><tab>"MyHost" and FTP it to the Remote.  Still, you're not doing any kind of run-time search, you're just storing a Constant on the Remote.

Never mind -- if your system requires the Target to refuse requests from the Host unless the Host is on the "Approved" list, you can't use FTP to set the Target's "Approved" list.  Wow!  How can you possibly work in such a (foolishly-)restrictive environment?  Do your IT "Rules" allow direct connections through a second NIC configured with an unroutable IP (I use 10.0.x.x)?  Do they understand the concept of an "instrument" that uses TCP/IP as a data-streaming protocol, not an "Internet" protocol?

Bob Schor

[xl600]

Yes it is restrictive.  I had a second NIC but my host is a laptop which only has one interface and USB to Ethernet adapters are flakey, slow, and prone to breakage.  So I have to have both of my systems (RT and host) on the same subnet which also happens to be a IT controlled LAN.  Hench I have to adhere to the rules.  If I have to use direct IP addresses, it's not that big of a deal and I don't really even mind the restrictions (They pay me to do this ).  I was just hoping for something a bit more abstract.

All ports that I open between RT and my host are known and the RT target won't listen to any unknown IPs by design.  It's more for the VI server, shared variables, FTP, WebDAV, web interface, and other non VI based access to the RT target that I don't control.  On Linux, this would all be done using iptables, auth, and other common methods.  On Windows (Domain connected), domain policies and firewall rules.  Nothing so fancy for PharLap.

[Bob_Schor]

---

@xl600 wrote:

On Linux, this would all be done using iptables, auth, and other common methods.  On Windows (Domain connected), domain policies and firewall rules.  Nothing so fancy for PharLap.

---

"You Pays Your Money, You Takes Your Choice".  In this case, PharLap has determinism, RT behavior, and a minimalist approach to the "system".

Bob Schor