Showing results for 
Search instead for 
Did you mean: 

VxWorks cRIO not getting response from DHCP server after formatting

Go to solution



I've got an issue with a cRIO-9073 not getting a DHCP address if it's been formatted so has no software beyond the base VxWorks & base NI image installed. The PN is 198944C-04L, so is the newer of the two parts that were named the cRIO-9073. This newer model is supposed to fall back to Link-Local addressing if DHCP doesn't work, and it does do that at least. Also, when the cRIO has software on it, it is able to get a DHCP address from the server.


Working with my IT department, we found the DHCP server was seeing the request for an address, which the cRIO sent 4 times, but the server was not responding to the request. A second IT staffer then looked further into it and discovered the cRIO was requesting a lease time of 14,002 days(!), which is why the DHCP server on our corporate user network ignored it. Curiously our lab network was okay with it and gave it an address.

Per this IT staffer, I was asked to reach out to NI and ask "what are the firmware settings they put in for DHCP lease time Option 51 are and if they are adjustable/removable".

Fortunately I'm able to work around this by connecting the cRIO directly to a PC's Ethernet jack. As the PC Ethernet is configured for DHCP they form a link-local ad-hoc network and NI-MAX can then find it and install software on it (again) after which it is able to get a DHCP address from the server. But this is very inconvenient for cRIOs we have in in hard-to-access locations, and we've run into situations where installing new software on the cRIOs will fail unless the cRIO is first reformatted and reloaded with the Real Time drivers. Fortunately nearly all of those are using static IP addresses, but there's always a chance that during a re-format someone will forget to select the option to preserve the existing network configuration.

So, is there any way to change this? Is there a firmware update available for it? NI-MAX doesn't say anything about a firmware version on these, so I have no idea what is on there currently. Or is this something that could be changed in NI-MAX (which "reformatted" the cRIO in the first place)?

BTW - This is my second issue with VxWorks cRIOs & DHCP in the forums (see here:




0 Kudos
Message 1 of 3
Accepted by topic author ErikL68

You realize that all VxWorks (and Pharlap) RT targets are since several  years EOL? And LabVIEW support for them ceased with version 2020. This means you should not expect any bug fixes and changes anymore. What is there is there and what isn't, never will come to happen anymore. Not even if you point out a major security vulnerability to them. The development tools are archived, and the hardware on which they still can run was since sent to the electronics scrap processor. The cross development tools for VxWorks 6.3 can't run on anything beyond Windows 7, 32-bit  The according Diabolo compiler and debugging IDE nether and it was not only insanely expensive but is also not available anymore.


When you reformat a controller, a basic boot loader is installed and nothing more. This bootloader is a minimalistic version of the OS that just comes with the barely necessary stuff to get the hardware into a state where it can be accessed over a terminal, provide a file system for the on board hard disk, and serve minimal network options. Under Linux this is best comparable with Grub, but for these targets it uses its own basic boot loader that VxWorks normally uses. Once you install a specific version of the LabVIEW RT Runtime platform, the actual Vxworks 6.3 (6.1 if you use LabVIEW 8.2) based OS is installed. And this is the version that seems to work fine with your DHCP server. How much the bootloader is configurable is probably something that is only "maybe" documented in the VxWorks SDK documentation, but you can't officially get that anymore for these versions (and had to buy it back in those days, for a significant amount of bucks). The way to deal with the bootloader was back in those days to enable the terminal of the device and attach a serial terminal (emulator) to it. Then use the bootloader commands to do things. Full network support in the bootloader itself was usually more experimental than anything else. 


Unfortunately it's not just NI which ceased support for these OSes. Virtual Zero discontinued Pharlap ETS in 2013 and WindRiver discontinued VxWorks 6.8 in 2019 and put VxWorks 6.9 into Legacy mode in 2020, to be EOLed soon. But NI uses VxWorks 6.3 which has been long since already WindRiver. You may say, why did they not just upgrade to a later supported version and the answer is simple. The PPC platforms were designed at a time when Intel had serious trouble with their CPUs to perform well without being a good replacement for your central heating system too. PPC at that time had a very good performance/power ratio in comparison. With the release of Atom and especially the new Core architecture Intel finally managed to get into the power efficient region and their CPUs got a viable option for embedded hardware. And with the ubiquitous presence of the x86/64 architecture everywhere, it was the logical choice for new designs and the Linux OS in a realtime optimized form was the obvious choice, rather than trying to use yet another specialized realtime OS that may or may not get discontinued at the whim of the manufacturer. VxWorks still is around, but their record of providing 16 years of active support for VxWorks 5.5 (from 2002 to 2018) hasn't been quite continued and they typically discontinue even long time support versions after 10 years or less and in between versions like 6.3 that NI used even sooner. 

Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 3

Hi Rolf,

I suspected it being EOL would make it unlikely, but took a chance that it could just be something solved ages ago that I missed simply because I hadn't run into the issue previously.

Hopefully the post will be useful to others that might run into this issue.


0 Kudos
Message 3 of 3