Make Static Route Persistent Over Reboots

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.

  1. 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.

  2. 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.

  3. 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.

Yeah most of that is going to be over my head.

I do see a net.cfg file that holds the IP information for the EN0/1 ports.

Could I put anything in there?

Here is what I see in the file…

[global]
hostname Panel109
nameserver 192.168.1.1
route 192.168.1.1

[en0]
type ethernet
mode manual
manual_ip 192.168.1.109
manual_netmask 255.255.255.0

[en1]
type ethernet
mode manual
manual_ip 192.168.2.109
manual_netmask 255.255.255.0

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.

Based on this… imgur.com/a/vFp0rtl

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?

Again I have no way to test that.

The net.cfg file doesn’t seem to have the facility to put in a route other than the gateway.

I think the obvious solution is to contact the provider of this device and find out if they give you any way to make the change you desire.

This old post

[forums.openqnx.com/t/topic/3200/1)

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).

Tim

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 ?

Nico,

  I completely missed that.   What did you see in the post that indicated this.  Ouch, so PPC was still available in 6.41?  I'm surprised.

Mitchell

Mitchell,

This is visible in the picture posted by the op in this message : https://openqnx.com/phpbbforum/posting.php?mode=reply&f=10&t=16114#pr59131
PPC is supported till 6.5.0 (inclusive). Releases 6.6.0 and upper support only x86 and arm platforms.

Nicolas

This is a link to reply on openqnx, but I’ll take your word for it, there is a photo,

Thanks

Mitchell,

Yes, I gave the link of the reply on openqnx. In this reply, there is this link : imgur.com/a/AgAmwAO where you can see the CPU is PPC.

Nicolas

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.

Webbyz,

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).

Tim

If there wasn’t a medium to write to, then II would think that there wouldn’t be a way for me to make changes to the IP addresses at all?

Maybe I am wrong in thinking that? But from conversations in the past, I have always been told that there is flash memory on board.

You’re wrong.

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.

As requested by Tim, can you execute “df” command on your QNX system to show which file systems are active ?

df

/dev/etfs6 11776 1156 10620 10% /aram0/
/dev/etfs4 1920 106 1814 6% /ram0/
/dev/etfs2 122880 57712 65168 47% /ffs0/
/dev/etfs6 11960 11960 0 100% (/aram0/)
/dev/etfs5 0 0 0 100%
/dev/etfs4 1950 1950 0 100% (/ram0/)
/dev/etfs3 0 0 0 100%
/dev/etfs2 124800 124800 0 100% (/ffs0/)
/dev/etfs1 8320 8320 0 100%

It looks like you get a “Flash File System” on your machine.

To go further, can you send me the content of /proc/boot/.scritp file in a private message ?
Copy/paste will not work as this is a binary file (with text inside).
This script file is executed at startup. Decoding it will show what’s executed at startup. Maybe another writeable script file is executed from it.
Beware that this file can contain private data so you might not want to share it.

Sent. Thanks!

Ok, so here is your .script content :

procmgr_symlink ../../proc/boot/libc.so.3 /usr/lib/ldqnx.so.2
optslotscan
dbgjmpr
reopen /dev/serconsole
display_msg Welcome to QNX Neutrino 6.4 on the NPM 2xx (ppc405)

ksh /sys/bin/rc.local
ksh /sys/bin/tinit &

In order of execution :

  • The fisrt line is always there in .script files. : libc.so.3 is redirected to ldqnx.so.2
  • optslotscan and dbgjmpr are executed.
  • Standard input, standard output, and standard error are redirected to /dev/serconsole
  • Display the Welcome message
  • Execute /sys/bin/rc.local through ksh
  • Execute /sys/bin/tinit through ksh in background

ksh refers to /proc/boot/ksh

optslotscan and dbgjmpr are executed with no environment variables defined.

/sys/bin/rc.local and /sys/bin/tinit are executed with the following environment variables :
SYSNAME=nto
TERM=qansi
HOME=/
PATH=:/proc/boot:/bin:/usr/bin:/opt/bin:/sys/bin:
LD_LIBRARY_PATH=:/proc/boot:/lib:/usr/lib:/lib/dll:/opt/lib: