DAQmx Error 209836 on Linux RT target

[StevenHowell]

Good afternoon,

We have an initiative to shut off all web servers on deployed target for IT security. 

I have found out the hard way that if I turn off default web service in the NISystemWebServer.ini file that when I run a DAQmx task I get an error 209836.

This error states that DAQmx cannot find a sync source, as this is a TSN enabled chassis (9053).

The solution on the NI site is that it is a driver corruption, but I have confirmed that not to be the case in this situation. If I turn the web service back on, the error goes away and everything works fine.

My question is two fold:

1) Is there a secondary way to get DAQmx to the sync source it needs without the web server running?

2)If not, can I install a software firewall to block incoming traffic on that port to effectively make the chassis invisible to our network scanners?

Any help would be appreciated. 

[James_McN]

Hi Stephen,

I'm not sure about the sync question but for the firewall iptables is supported (there are some details in https://www.ni.com/pdf/support/us/ni_linux_real-time_security_user_guide.pdf). I also know that Neosoft (neosoft.ca) have been working on a firewall product for cRIOs that makes it easier to work with. I've attached a filer they shared on discord but can't see a link on their site at the minute.

Cheers,

James

[StevenHowell]

James,

Have you ever seen this behavior with the TSN enabled cRIO chassis? I have several projects where I am using them but I have not had to disable web servers on the targets till now. Before I put the iptables entry in there when I turned off the web servers I was getting that error -209836. 

This is the only information I found about that error, but I have confirmed that it is not a driver issue or corruption, it has specifically to do with turning off the default web server on the cRIO chassis that is TSN enabled. 

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000001Dc0TSAS&l=en-US

"

1. This error appears due to DAQmx attempting to start a task before the synchronization domain is complete, or where poor networking performance results in TSN not being found when the task begins. When DAQmx is started, it requires a synchronization domain, even if it is only one device connected, and the TSN processes boot in parallel to a startup executable."

Unfortunately this does not say specifically that "web servers must remain enabled on the target for DAQmx task to start". 

What I ended up doing that solved the issue was to create an iptable entry that anything that was coming in on port 80 from the eth0 interface would be rejected and a reset reply sent via TCP. This essentially makes the network scanner see a closed port. 

I had to make sure that I left the localhost loopback to port 80 open.