Hello all. I am new when it comes to the QNX level, but we have some building automation controllers that have 2 ethernet ports and the underlying OS is QNX.
The issue that we are having is that only EN0 has a specified Gateway. If I want to route specific traffic out over EN1, then I need to make a static route.
Assuming my target is 1.2.3.4 and EN1 is 192.168.2.1…
When I get to the Shell and do a “route add 1.2.3.4 192.168.2.1” the entry does come up in the “route show” command, but when I reboot the panel, the entry is lost.
Is there a way to make that route persistent over reboots? I cannot find the file where this would be stored and loaded on boot.
6.41 is very close in functionality to 6.5. All the QNX 6’s to my knowledge used a convention that startup files were in /etc/rc.d. Files in this directory were all prefixed by pr. The main script file was rc.sysinit. rc.local was the intended place that you put local commands so that if you upgraded the system, it would not be overwritten.
Note I said by convention. There is no reason that someone configuring a system, especially an embedded system needs to use this convention. Here are the startup steps that occur in booting QNX 6 from a hard drive.
The bios reads in the first second which is a partition loader and jumps into it. The code uses the bios to read the disk and looks for the active partition and then loads the first sector of this partition and jumps to it. It also throws up a option to choose a different partition. That’s if you are using the QNX loader.
The partition loader looks in the partition for a file .boot or a directory .boot. In the later case things get a little more complicated but basically a boot file is loaded into memory and jumped to.
The system is initialized. The steps involved are documented, but basically the kernel is started and it starts running script. The residue of the script can be dumped from directory /proc/boot. By convention at the end of that script a disk driver has been loaded, the QNX partition has been mounted and the script /etc/rc.d/rc.sysinit is started.
The end of step 3 is where your problem is. If you don’t have the boot build file you don’t know what is happening. It would be challenging for a novice to figure out. If another script is run then that is what you need to update. It is possible that the entire startup is all within the .boot file in which case you would need to update the build file, which you might not have, rebuild it and copy it into place. These are things you should not attempt unless you know what you are doing.
A good suggestion, but I don’t think so. net.cfg is maintained by a Photon GUI program called phlip. You can edit the file yourself. Looking at the window phlip puts up I can see that you can add additional IP’s to the gateway in the like listed as “route” but there isn’t anything to set up a specific route.
My issue is that I don’t know the Syntax to add. I don’t have access to use Phlip. So if anyone could let me know what would be added into that file, it would be great.
I would think that Gateway would be 192.168.2.1 / Destination would be 1.2.3.4 / and Netmask would be 255.255.255.255. And then if someone did an add, what would it add to that file?
suggests you can add the routes to net.cfg and the netmanager will pick them up. That implies that netmanger was used to configure TCPIP (it only runs once then exits so we can’t know if it was used but its quite likely it was).
Your system runs on PPC, this means it is not a PC based system. So the boot process is different than the one explained by maschoen.
Do you have knowledge of the hardware ? Do you know which peripheral it boots from (SDcard, FLASH memory…) ?
More importantly, do you have the BSP sources for your hardware ?
I know that it boots from flash. But I don’t have much knowledge of the inter-workings of the hardware itself and how it was programmed at this level. So no BSP resources.
I am most familiar with the application that it running on the hardware which is for building automation. The static routing function isn’t something that is supported in their GUI/programming tools.
There is a need for this functionality. I am just trying to accomplish a solution that is outside of the software that is running on the device.
If the device boots from flash there may not even be any writable medium (hard disk, CF card etc). How big is the physical device and do you know if it has a writable medium. If it doesn’t there is NO way you will be able to modify routes in a permanent manner.
If you can’t open the device or judge by it’s size whether it has writable medium then can you try doing a ‘df’ command and see what it reports for disks. It’s entirely possible there is nothing but flash memory that contains a bootable QNX image (which essentially can’t be modified).
On embedded systems, most of the time, there is an in-RAM file system initialised at startup. This file system is populated with the content of the QNX image created with BSP tools. So, you get a writeable file system that is reinitialised at each boot.
