Adding a persistant static route to a hardened embedded QNX Unix device

Question

I'll start by saying forgive my ignorance if this is a simple task. I have enough knowledge of *nix to set it up and get around but this embedded version is a little different (missing 90%+ of standard commands) and I've hit a roadblock.

I have a device that is running QNX 6.5.0 SP1. I have access through its serial port and from there I have shell access with a superuser. The device has two physical network interfaces, en0 and en1. At startup the device uses a net.mgr file to set its network info. That file assigns IP addresses to each interface but only appears to support a single gateway. We are looking to add something to the second Ethernet port and need a route command so I serial into the box and used a standard route command to add the route. This worked as intended but the change was not saved after a reboot.

I am trying to figure out how to get the extra route command to persist through reboots but most methods I've found don't work. There is no cron or things like that. Things I've tried:

• Modifying the net.cfg file and adding another gateway. This doesn't work as it just uses the last gateway entered and doesn't allow multiples
• Modifying the net.cfg file and adding the route command. Knew this wouldn't work but tried anyway.
• Adding a /etc/rc.local file with the route command. File persists but seems to be ignored on startup.
• Adding a /etc/rc.d/rc.local file with the route command. (Per the QNX documentation at http://www.qnx.com/developers/docs/6.5.0/topic/com.qnx.doc.neutrino_user_guide/starting.html?resultof=%22%72%63%2e%6c%6f%63%61%6c%22%20#rc.local). File persists between boots but is also ignored.
• Attempted to modify /sys/bin/rc.local. My changes are ignored (not written to the file). I cannot FTP that file off either, comes out as a 0 byte file while a "cat rc.local" shows its content and I can verify it is using this file based on that content. Tried a 'cat >rc.local' and copying the old contents then adding my route command but the file didn't change. A chmod -x rc.local gives back the file doesn't exist but it does and I'm 99% sure that's whats being executed at boot.

I'm thinking rc.local within the /sys/bin folder is read only? I know one of the two mounts is /ffs0 and the /sys/bin is within that. I have tried to mount it with 'mount -uw /ffs0', make my change, then flip it back to read only but that doesn't seem to work. So I've run out of ideas.

Answer 1

The first thing to understand about QNX 6.X is that there is a boot image that gets executed. That image normally contains the micro kernel and basic drivers (disk etc). However it can be entirely self contained (ie micro kernel, drivers, every command, configuration files etc) for cases where there is just flash memory. In that case it will be impossible to modify anything even if there is a hard drive that contains configuration files (like in /etc/rc.d) and other directories.

You can get some hint of that by looking in /proc/boot. Everything in /proc is what is in the boot image inflated into RAM. It's literally a RAM drive so what you see in there is what's in the boot image. You might get lucky looking into startup-script (this is a compiled script) if you can ftp it off and do a 'strings' command on it to see what's being drivers and scripts are being run.

In a normal QNX boot image (ones you saw in the links) the startup-script will transfer control to /etc/rc.d/rc.sysinit and /etc/rc.d/rc.local once it runs the disk driver and a few other essentials. But embedded systems like yours don't have to do that. That's why your changes in those files aren't taking effect.

I've never heard of /sys/bin/rc.local. That's not part of regular QNX 6 installation so that's something whomever made the device has added. The sys directory may in fact be just a softlink back into the boot image RAM area (which is why you can't change anything there since it's RAM). You can tell if this is so by a 'ls -lrt' at the root file system (ie where sys is located) and seeing if it's a softlink back into /proc or some other place.

Tim