[Resolved] Errors while using dhcp.client

Hi everyone,

For a project I need to launch dhcp.client in order to get a valid IP address from a rooter.

I followed the script sequence from there : http://www.qnx.com/developers/docs/6.5.0/index.jsp?topic=%2Fcom.qnx.doc.neutrino_utilities%2Fd%2Fdhcp.client.html :

So far so good, I have my dynamic IP and my target is reachable.

I’ve observed 2 disturbed facts though :

1/ /dev/log reads :

What is the script purpose? Can I use dhcp.client without it? If so, how do I disable the error message?

2/ More disturbing, from time to time while booting up, my target crashes, see file attached. The memory dump suggests it is due to if_up binary failure… So in my script I removed “if_up enx”. It seems to work without it. I still get a valid dynamic IP from the rooter. Besides I got rid of the problem (no failure after 1400+ reboot).

So my question is, what is if_up purpose in the sequence? (I don’t understant the documentation) And can I launch dhcp.client without it?


In the documentation, it is stated :

The two lines you provided don’t fulfil this requirement.

It is also mentionned the use of the following files if present :

You should find example files in your Momentics installation.

Hi nico04, thanks for the quick answer.

The full script I’m using :

io-pkt-v4 -dvortex
waitfor /dev/io-net
dhcp.client &
if_up enx

It doesn"t explain why if_up fails on my target from time to time.
The real question is, what is it for? When I removed if_up from the script it seems to work as before (I get an IP from the server).

Correct but the mention “if present” makes me expect no error message in the log if I don’t need them (default config seems just fine).

if_up just pauses your startup script until the network interface is ‘available’. See doc’s here:

qnx.com/developers/docs/6.5. … if_up.html

You may not need it at all if the driver manages to get the interface up in time for dhcp.client. 1400 reboots would tend to make me think you don’t need it but you never know.

Not sure why it’s crashing your machine. But I do see you are running HAM and most people aren’t doing that. Maybe HAM thinks if_up isn’t responding in time (if it’s waiting) and so it’s trying to restart it and that’s causing the node to crash. You could test that by not starting HAM and seeing if the crashes go away. If they do, then it’s some combination of HAM and if_up


@Tim : To my knowledge, HAM manages processes explicitly declared to be monitored.

@KB : Why are you not using service pack 1 (SDP 6.5.0SP1) and more recent patches ?

I’m testing this right now. Thanks.

I am using 6.5.0SP1.

In your crash report, we can read “QNX Version 6.5.0 Release 2010/07/09-14:42:57EDT”
SP1 has been released after 2010. But maybe procnto was not modified in SP1.
However, there is a patch for procnto which has been released on June 2019.

I’m sure I have SP1 installed because we fixed an issue a week ago with another engineer working on the project without SP1 installed. And we had differences between application binaries (same source code).
Besides I double checked and there is a “6.5.0SP1” directory in “C:\QNX650\install\qnxsdp”.

I’m aware of that, unfortunatelly one need QNX maintenance support in order to download it and it is quiet expensive.

“C:\QNX650\install\qnxsdp” is where are building your own source code.

Have you actually built a new .boot image under SP1 and updated it on your machine? That’s what’s actually crashing. Based on what Nico04 has pointed out it appears that you have not.


Hi Tim,

I have built a new ifs file using QNX system builder from Momentics (and a bsp provided by the the manufacturer of my board, a Vortex DX2 x86).
The ifs file had been pushed to .boot folder on the target.

Here’s an old post I found where someone crashed the system with something semi-similar to what you have experienced.

community.qnx.com/sf/discussion/ … /post90348

They claim it’s having 2 network cards on the same subnet. How many cards do you have in your machine and what driver are you using?

Also note that if_up outputs something to the screen for them:

I wonder if your crash happens when if_up attempts to output something if some other needed process isn’t running.


Hi Tim,

I have only one network card.
The board is Vortex DX2 (x86).
I think the message “if_up: retries exhausted” is not relevant, as it is not always linked to a dump (see other image attached).

I have another scenario which leads to a system crash.
I have 7 processes to launch at startup. Here the sequence :

./P_LOG &
sleep 0.5
sleep 1
./P_HAL &
sleep 1
sleep 1
sleep 1
sleep 1
./P_VD-IP &

If I remove the sleep instructions, I have regularly a system crash (more often then with the “if_up” issue) I have attached the corresponding dump.

I’m concerned about what Nico and you mentionned earlier concerning the SP1 which is missing in the dump.
Maybe I have an incompatibily between the boot image (which would be 6.5.0) and mly application (my 7 processes compiled on 6.5.0 SP1) ?
The dump suggest that my system is running on 6.5.0 (no SP1). How can I know for sure? As I said I’ve built an ifs file with Momentics and SP1 installed… However the besp of the board I am using (provided by the manufacturer) is 6.3.2.

To check for procnto version, what I would do is (I’m using Windows as dev OS) :

  • Transfer /proc/boot/procnto-smp(*) from QNX target to your PC using Momentics. Edit(**) procnto-smp and search for “6.5.0”.
  • Edit C:\QNX650\target\qnx6\x86\boot\sys\procnto-smp(***) and search for “6.5.0”.
  • Compare both search results. The important part is after “6.5.0”, the date should be the same, or not.


  • : This can be another version of procnto, like procnto, procnto-instr or procnto-smp-instr.
    ** : Please use a “real” editor like Notepad++ for Windows since the file is big and binary. You can also use a binary editor with text search functionality.
    *** : On a linux PC, use the path you installed QNX dev tools in.

Thanks Nico ! This was a good one!
I have indeed a problem with the embedded procnto…

The one in C:\QNX650\target\qnx6\x86\boot\sys reads : 2012/06/20-13:50:45EDT.6.5.0
The one in /proc/boot reads 2010/07/09-14:42:57EDT.6.5.0

I don’t know how to transfer procnto-2012 onto the target (I trieds to rebuild an ifs but I don’t know how to add this version of procnto in the builder)…

Have you run “clean” before “build” ?

There is no “clean” in the builder view (see picture attached).
I’m sure I have recompiled the ifs because I changed the welcome message printed in the shell.
Buf for a reason I ignored it doesn’t include the file I have on C:\QNX650\target\qnx6\x86\boot\sys

edit: I’ll have a go with the instrumented kernel…
edit2: OK same date (2012) on target and host with the instrumented kernel ! The binaries are different though (winmerge comparison)…

Main menu Project/Clean…

Check there is no procnto in your BSP precompiled folder/subfolders

Before being added to the ifs, executables are stripped (not needed information like debug data are removed).

OK I switched back to procnto (tried procnto-instr before), recompiled the ifs and now I have the same year (2012) on both host and target!
So far the kernel seems more stable (no dump), I will wait few hours to be sure.
I’m not sure how I’ve ended up with a 2010-procnto on the target in the first place…anyway…
Thanks Nico for the good lead!

Presumably you are using the QNX IDE (ifs project) to build your ifs image.

You likely have your copy of the 2012-procnto in the wrong directory. You probably have to manually copy the 2012-procnto to the right spot in order for the IDE to include it in the ifs image.

One way is to search your Windows harddrive (assuming you using Windows and not Linux to compile) looking for procnto (I use agent ransack but there are other good tools for searching). You’ll likely come across more than 1 (in fact I think they are called something like procnto-x86-smp so best to just search for procnto). The IDE usually copies the right one (based on X86 vs PPC vs SMP vs non-SMP) and renames it to procnto in the ifs.


Switching procnto to procnto-instr to procnto solved the issue for… procnto.
What about other binaries made to run with this version of procnto ?
Among others, libc.so is a critical one.
You should really investigate further to make sure everything is up to date.

Clean then build is the first step ;)