07-31-2024 12:36 PM
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.
08-01-2024 12:51 AM
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
08-01-2024 01:20 PM
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
"
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.