This has to be simple, but it isn’t obvious to me.
We may know too much about too many other ix’s but -
route add -net xxx.xxx.xxx.0 -iface en0
comes back with a “bad value en0” and does the same for
en0 is a realtek card, we cannot use the built in 3c940 as there is no driver yet.
ifconfig -a shows that it exists, but it is coming up as half-duplex (always) . We have had some configurations where we could ping it directly after using the mount commands to start things by hand, but we have been unable to tell the system to actually USE the interface provided. Nor have we, initiating io-net by hand, been able to persuade it to go full duplex.
So what are we doing wrong here?
Why are there 5 separate processes starting for each call to io-net?
Solaris and Linux experience seems to be more confusing than helpful right now.
I am not sure those options are supported - which would explain the error. I never use it much beyond
route add default
and it just works.
As has been mentioned a ton of times, there is a problem with the realtek driver in 6.2.0 and fixed in 6.2.1, but make sure you do the complete install to get the fix (install, reboot, finish install).
If you are looking at io-net with pidin (pidin -P io-net), it shows all the threads (note the pid is the same for each).
Just as there are differences between solaris and linux, qnx is also the same, but different. That is truely the legacy of all *ix styled OSes. You have the concepts right, but in many cases, the defaults and / or command line options may be slightly different.
We were able to get it to start from a clean reboot, using the io-net -d rtl --etc-- followed by an ifconfig en0 192.168.x.y
As for the options, we looked for these in the manual pages (help pages, “man” gets a blank stare, I may set up some aliases in my ksh to stay sane). Supposedly -iface or -interface are supported and tell it that this network is what is outside that interface, except that it doesn’t accept any interface names. Still doesn’t.
We ultimately succeeded in getting it to ping and telnet and ftp from (but not into) the box. Something about the server/services is still not right for that.
Now we want to make it execute that io-net command/configure the network on boot. Which is apparently not something to do in rc.local. Something else is running io-net first, but we haven’t figured out where that is coming from. sysinit is full of stuff but the actual config we need is not clear.
Sure the system starts io-net for you, but you can slay it and restart it if required. I do that with my wifi card in my laptop. I check to see if it is inserted, then restart io-net. Not only does this work, it is the correct way to do it.
You can invoke the ‘use’ utility rather than man to get some command line info:
Yes, we did finally work out what was wrong. The inetd was easy to figure out. I checked the config and decided it was OK, then tried to get the PID and aha! there is no PID, it isn’t running yet and lets start it… I approve. Now if I knew there weren’t any really NASTY holes in the security.
The rc.local needs a waitfor on the restart before applying the ifconfig statement to set the address. I don’t mind doing all this, but it would’ve been really keen for someone to have set up a small text description of this little difference, perhaps like “# NETWORK SETUP IS DONE IN RC.LOCAL” and leave it in an easily discovered place like /etc/rc.d/rc.local. This is the commercial version mind, so it actually IS supposed to have a complete trail of bread crumbs for us to follow. A very minor kvetch.
It’s OK though. I was surprised to find ksh and not bash in the distribution. I like both so it is perfectly fine. I was not so pleased to find that the gcc is the 2.95 variant. I’d have hoped to see that upgraded more agressively, but find no such support on the official QNX site.
I think it is OK though. We are moving forward well enough, and I expect we’ll have parts of our product ported in short order.
bash is certainly available on the the 3rd party cd, so it is not a big deal to get it installed and running. As far as gcc goes, 3.3.1 is in the upcoming 6.3.0 release, so at some point, it will be available.