I’m struggling with two problems as a result of an upgrade from 6.1 to 6.2.
First, I have an application that wants to include libcpp.so.2 and
libcpp.so.2a. I’ve checked all the *.so libraries that I load in the
application, as well as the *.a libraries that I link in. Nothing else uses
libcpp.so.2. I’ve removed all the object files and rebuilt the app; of
course it still needs llibcpp.so.2. Everything else for which I’ve included
the libcpp.so uses the libcpp.so.2a. I’ve run objdump on every executable
and library that I’ve compiled and I can’t find any other instance where
libcpp.so.2 is needed. Any suggestions?
Second, I can’t get routed to read the /etc/gateways file anymore. I can add
a route after the system starts, but that kind of defeats the purpose of an
embedded system. My gateways file is unchanged from the 6.1 installation, as
is the command to start routed. Following is the only entry in my gateways
file
net 192.168.110.0 gateway 192.168.2.1 metric 1 passive
Again any suggestions?
Thanks,
David Kuechenmeister
Let me throw out a little more information and see if I can get someone to
bite.
When I start the routed daemon, I get this output
routed -d &
[1] 274446
Apr 25 20:38:22 nto routed[274446-1]: adding route to net/host 192.168.2.0
thr
ough gateway 192.168.2.0: Operation not supported
SIOCADDRT: No such process
Again, the gateways file is below and is correct, I think. All this worked
fine with 6.1, what’s different?
Thanks,
David Kuechenmeister
“David Kuechenmeister” <david.kuechenmeister@viasat.com> wrote in message
news:b89cuh$l1q$1@inn.qnx.com…
I’m struggling with two problems as a result of an upgrade from 6.1 to
6.2.
First, I have an application that wants to include libcpp.so.2 and
libcpp.so.2a. I’ve checked all the *.so libraries that I load in the
application, as well as the *.a libraries that I link in. Nothing else
uses
libcpp.so.2. I’ve removed all the object files and rebuilt the app; of
course it still needs llibcpp.so.2. Everything else for which I’ve
included
the libcpp.so uses the libcpp.so.2a. I’ve run objdump on every executable
and library that I’ve compiled and I can’t find any other instance where
libcpp.so.2 is needed. Any suggestions?
Second, I can’t get routed to read the /etc/gateways file anymore. I can
add
a route after the system starts, but that kind of defeats the purpose of
an
embedded system. My gateways file is unchanged from the 6.1 installation,
as
is the command to start routed. Following is the only entry in my gateways
file
net 192.168.110.0 gateway 192.168.2.1 metric 1 passive
Again any suggestions?
Thanks,
David Kuechenmeister
The routing part works for me. Where is the SIOCADDRT coming from?
This is only supported by the tiny stack and isn’t used by routed.
-seanb
David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:
Let me throw out a little more information and see if I can get someone to
bite.
When I start the routed daemon, I get this output
routed -d &
[1] 274446
Apr 25 20:38:22 nto routed[274446-1]: adding route to net/host 192.168.2.0
thr
ough gateway 192.168.2.0: Operation not supported
SIOCADDRT: No such process
Again, the gateways file is below and is correct, I think. All this worked
fine with 6.1, what’s different?
Thanks,
David Kuechenmeister
It’s interesting. I tried to take a short cut and copy files from my 6.2
hard drive to a disk on chip, rather than re-initialize the DOC and rebuild
the O/S from scratch. When I started from scratch, I discovered that my S.E.
Momentics installation disk didn’t install routed in the /usr/sbin
directory. Apparently, I was using the 6.1 version of routed. SIOCADDRT is a
macro defined in the sockio.h I still don’t know why 6.2 didn’t install
/usr/sbin/routed, nor why the 6.1 routed didn’t work. Someone at QSSL will
figure that out for me via a problem report and I’ll post the result.
Will 6.1 executables run on 6.2?
Regards,
David Kuechenmeister
“Sean Boudreau” <seanb@node25.ott.qnx.com> wrote in message
news:b8c226$687$1@nntp.qnx.com…
The routing part works for me. Where is the SIOCADDRT coming from?
This is only supported by the tiny stack and isn’t used by routed.
-seanb
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
Let me throw out a little more information and see if I can get someone
to
bite.
When I start the routed daemon, I get this output
routed -d &
[1] 274446
Apr 25 20:38:22 nto routed[274446-1]: adding route to net/host
192.168.2.0
thr
ough gateway 192.168.2.0: Operation not supported
SIOCADDRT: No such process
Again, the gateways file is below and is correct, I think. All this
worked
fine with 6.1, what’s different?
Thanks,
David Kuechenmeister
The result of the problem report was that routed isn’t supplied with the SE
version of Momentics. Is that right? Why in the world would QSSL supply all
the rest of the network tools that you need to support routing, then leave
out the routing daemon? And on top of that, there is absolutely no notice in
any of the literature that this particular capability has been omitted. To
the contrary, all the literature that I could find spoke of routing sockets
on Neutrino with the standard TCP/IP stack. What a great bunch of guys!
“David Kuechenmeister” <david.kuechenmeister@viasat.com> wrote in message
news:b8k1ng$l8d$1@inn.qnx.com…
It’s interesting. I tried to take a short cut and copy files from my 6.2
hard drive to a disk on chip, rather than re-initialize the DOC and
rebuild
the O/S from scratch. When I started from scratch, I discovered that my
S.E.
Momentics installation disk didn’t install routed in the /usr/sbin
directory. Apparently, I was using the 6.1 version of routed. SIOCADDRT is
a
macro defined in the sockio.h I still don’t know why 6.2 didn’t install
/usr/sbin/routed, nor why the 6.1 routed didn’t work. Someone at QSSL will
figure that out for me via a problem report and I’ll post the result.
Will 6.1 executables run on 6.2?
Regards,
David Kuechenmeister
“Sean Boudreau” <> seanb@node25.ott.qnx.com> > wrote in message
news:b8c226$687$> 1@nntp.qnx.com> …
The routing part works for me. Where is the SIOCADDRT coming from?
This is only supported by the tiny stack and isn’t used by routed.
-seanb
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
Let me throw out a little more information and see if I can get
someone
to
bite.
When I start the routed daemon, I get this output
routed -d &
[1] 274446
Apr 25 20:38:22 nto routed[274446-1]: adding route to net/host
192.168.2.0
thr
ough gateway 192.168.2.0: Operation not supported
SIOCADDRT: No such process
Again, the gateways file is below and is correct, I think. All this
worked
fine with 6.1, what’s different?
Thanks,
David Kuechenmeister
David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:
The result of the problem report was that routed isn’t supplied with the SE
version of Momentics. Is that right? Why in the world would QSSL supply all
the rest of the network tools that you need to support routing, then leave
out the routing daemon? And on top of that, there is absolutely no notice in
any of the literature that this particular capability has been omitted. To
the contrary, all the literature that I could find spoke of routing sockets
on Neutrino with the standard TCP/IP stack. What a great bunch of guys!
I think it is ment to be implied with the little chart on this page.
http://www.qnx.com/products/ps_momentics/
(Pro TCP/IP vs Standard)
It doesn’t do a good job doing full break down of everything included
though. Probably something that would be good to have on the site in the
future.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:
The result of the problem report was that routed isn’t supplied with the SE
version of Momentics. Is that right? Why in the world would QSSL supply all
the rest of the network tools that you need to support routing, then leave
out the routing daemon? And on top of that, there is absolutely no notice in
any of the literature that this particular capability has been omitted. To
the contrary, all the literature that I could find spoke of routing sockets
on Neutrino with the standard TCP/IP stack. What a great bunch of guys!
The standard stack does support routing sockets. If the main
reason you are running routed is to add the route mentioned in
your /etc/gateways, you can do the equivalent with:
route add -net 192.168.110.0 192.168.2.1
-seanb
I did get another answer from QSSL. After telling me that routed was
not included in the SE distribution, they admitted their error and sent
me the omitted files.
Good Work QSSL.
In article <b8mltj$m18$1@inn.qnx.com>, David Kuechenmeister
<david.kuechenmeister@viasat.com> wrote:
The result of the problem report was that routed isn’t supplied with the SE
version of Momentics. Is that right? Why in the world would QSSL supply all
the rest of the network tools that you need to support routing, then leave
out the routing daemon? And on top of that, there is absolutely no notice in
any of the literature that this particular capability has been omitted. To
the contrary, all the literature that I could find spoke of routing sockets
on Neutrino with the standard TCP/IP stack. What a great bunch of guys!
“David Kuechenmeister” <> david.kuechenmeister@viasat.com> > wrote in message
news:b8k1ng$l8d$> 1@inn.qnx.com> …
It’s interesting. I tried to take a short cut and copy files from my 6.2
hard drive to a disk on chip, rather than re-initialize the DOC and
rebuild
the O/S from scratch. When I started from scratch, I discovered that my
S.E.
Momentics installation disk didn’t install routed in the /usr/sbin
directory. Apparently, I was using the 6.1 version of routed. SIOCADDRT is
a
macro defined in the sockio.h I still don’t know why 6.2 didn’t install
/usr/sbin/routed, nor why the 6.1 routed didn’t work. Someone at QSSL will
figure that out for me via a problem report and I’ll post the result.
Will 6.1 executables run on 6.2?
Regards,
David Kuechenmeister
“Sean Boudreau” <> seanb@node25.ott.qnx.com> > wrote in message
news:b8c226$687$> 1@nntp.qnx.com> …
The routing part works for me. Where is the SIOCADDRT coming from?
This is only supported by the tiny stack and isn’t used by routed.
-seanb
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
Let me throw out a little more information and see if I can get
someone
to
bite.
When I start the routed daemon, I get this output
routed -d &
[1] 274446
Apr 25 20:38:22 nto routed[274446-1]: adding route to net/host
192.168.2.0
thr
ough gateway 192.168.2.0: Operation not supported
SIOCADDRT: No such process
Again, the gateways file is below and is correct, I think. All this
worked
fine with 6.1, what’s different?
Thanks,
David Kuechenmeister
I don’t usually quit easily. I saw the table in the reference below,
but I also looked at the document in the following link,
http://www.qnx.com/resource/rs_pdf/rs_neutrino.pdf
and the section
“CHOOSE THE STACK THAT SUITS YOUR SYSTEM
QNX Neutrino offers the following TCP/IP stacks:
NetBSD TCP/IP stack Supports forwarding, routing sockets, broadcast
and multicast, ARP, ICMP, and IGMP, as well as CIFS, DHCP, DNS, NFS,
PPP, PPPoE, UDP, and an embedded web server. To develop applications
for this stack, programmers use the industry-standard BSD socket API.”
gave me a pretty good idea the basic TCP/IP stack should support
routing. See my other post about the QSSL correction.
Regards,
drk
In article <b8mot4$8hv$1@nntp.qnx.com>, Chris McKillop <cdm@qnx.com>
wrote:
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
The result of the problem report was that routed isn’t supplied with the SE
version of Momentics. Is that right? Why in the world would QSSL supply all
the rest of the network tools that you need to support routing, then leave
out the routing daemon? And on top of that, there is absolutely no notice in
any of the literature that this particular capability has been omitted. To
the contrary, all the literature that I could find spoke of routing sockets
on Neutrino with the standard TCP/IP stack. What a great bunch of guys!
I think it is ment to be implied with the little chart on this page.
http://www.qnx.com/products/ps_momentics/
(Pro TCP/IP vs Standard)
It doesn’t do a good job doing full break down of everything included
though. Probably something that would be good to have on the site in the
future.
chris
Okay, I ended up with the routed daemon from QSSL. And I know how to
use route. But for the sake of discussion, how are the routing tables
read without the daemon running?
The reason for using the /etc/gateways file was to have an embedded
system start and configure the routing tables without human
intervention. I could have added the route command to the build file,
but I still don’t see how the table would have been used without the
routed daemon running.
Thanks,
drk
In article <b8n4vs$fbr$1@nntp.qnx.com>, Sean Boudreau
<seanb@node25.ott.qnx.com> wrote:
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
The result of the problem report was that routed isn’t supplied with the SE
version of Momentics. Is that right? Why in the world would QSSL supply all
the rest of the network tools that you need to support routing, then leave
out the routing daemon? And on top of that, there is absolutely no notice in
any of the literature that this particular capability has been omitted. To
the contrary, all the literature that I could find spoke of routing sockets
on Neutrino with the standard TCP/IP stack. What a great bunch of guys!
The standard stack does support routing sockets. If the main
reason you are running routed is to add the route mentioned in
your /etc/gateways, you can do the equivalent with:
route add -net 192.168.110.0 192.168.2.1
-seanb
David Kuechenmeister <k13@b.e.l.l.s.o.u.t.h.n.e.t> wrote:
Okay, I ended up with the routed daemon from QSSL. And I know how to
use route. But for the sake of discussion, how are the routing tables
read without the daemon running?
Your favorite variant of the following can be used to
dump what’s currently in the stack:
netstat -r
netstat -rn
netstat -rn -finet
route -n get
route -n show
-seanb
The reason for using the /etc/gateways file was to have an embedded
system start and configure the routing tables without human
intervention. I could have added the route command to the build file,
but I still don’t see how the table would have been used without the
routed daemon running.
Thanks,
drk
In article <b8n4vs$fbr$> 1@nntp.qnx.com> >, Sean Boudreau
seanb@node25.ott.qnx.com> > wrote:
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
The result of the problem report was that routed isn’t supplied with the SE
version of Momentics. Is that right? Why in the world would QSSL supply all
the rest of the network tools that you need to support routing, then leave
out the routing daemon? And on top of that, there is absolutely no notice in
any of the literature that this particular capability has been omitted. To
the contrary, all the literature that I could find spoke of routing sockets
on Neutrino with the standard TCP/IP stack. What a great bunch of guys!
The standard stack does support routing sockets. If the main
reason you are running routed is to add the route mentioned in
your /etc/gateways, you can do the equivalent with:
route add -net 192.168.110.0 192.168.2.1
-seanb
When I wrote “how are routing tables read…”, I really meant “used”. How
can the IP layer find the right gateway without the routing daemon? In other
words, how is the information in the routing table applied to the routing
problem without routed?
Thanks.
“Sean Boudreau” <seanb@node25.ott.qnx.com> wrote in message
news:b8ohem$c8j$1@nntp.qnx.com…
David Kuechenmeister <> k13@b.e.l.l.s.o.u.t.h.n.e.t> > wrote:
Okay, I ended up with the routed daemon from QSSL. And I know how to
use route. But for the sake of discussion, how are the routing tables
read without the daemon running?
Your favorite variant of the following can be used to
dump what’s currently in the stack:
netstat -r
netstat -rn
netstat -rn -finet
route -n get <dst
route -n show
-seanb
The reason for using the /etc/gateways file was to have an embedded
system start and configure the routing tables without human
intervention. I could have added the route command to the build file,
but I still don’t see how the table would have been used without the
routed daemon running.
Thanks,
drk
In article <b8n4vs$fbr$> 1@nntp.qnx.com> >, Sean Boudreau
seanb@node25.ott.qnx.com> > wrote:
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
The result of the problem report was that routed isn’t supplied with
the SE
version of Momentics. Is that right? Why in the world would QSSL
supply all
the rest of the network tools that you need to support routing, then
leave
out the routing daemon? And on top of that, there is absolutely no
notice in
any of the literature that this particular capability has been
omitted. To
the contrary, all the literature that I could find spoke of routing
sockets
on Neutrino with the standard TCP/IP stack. What a great bunch of
guys!
The standard stack does support routing sockets. If the main
reason you are running routed is to add the route mentioned in
your /etc/gateways, you can do the equivalent with:
route add -net 192.168.110.0 192.168.2.1
-seanb
The routing table in the stack has the final say. routed uses
the RIP protocol to exchange and update the routing table in
the stack dynamically. Nothing I’ve heard indicates you’re using
this functionality of routed.
-seanb
David Kuechenmeister <david.kuechenmeister@viasat.com> wrote:
When I wrote “how are routing tables read…”, I really meant “used”. How
can the IP layer find the right gateway without the routing daemon? In other
words, how is the information in the routing table applied to the routing
problem without routed?
Thanks.
“Sean Boudreau” <> seanb@node25.ott.qnx.com> > wrote in message
news:b8ohem$c8j$> 1@nntp.qnx.com> …
David Kuechenmeister <> k13@b.e.l.l.s.o.u.t.h.n.e.t> > wrote:
Okay, I ended up with the routed daemon from QSSL. And I know how to
use route. But for the sake of discussion, how are the routing tables
read without the daemon running?
Your favorite variant of the following can be used to
dump what’s currently in the stack:
netstat -r
netstat -rn
netstat -rn -finet
route -n get <dst
route -n show
-seanb
The reason for using the /etc/gateways file was to have an embedded
system start and configure the routing tables without human
intervention. I could have added the route command to the build file,
but I still don’t see how the table would have been used without the
routed daemon running.
Thanks,
drk
In article <b8n4vs$fbr$> 1@nntp.qnx.com> >, Sean Boudreau
seanb@node25.ott.qnx.com> > wrote:
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
The result of the problem report was that routed isn’t supplied with
the SE
version of Momentics. Is that right? Why in the world would QSSL
supply all
the rest of the network tools that you need to support routing, then
leave
out the routing daemon? And on top of that, there is absolutely no
notice in
any of the literature that this particular capability has been
omitted. To
the contrary, all the literature that I could find spoke of routing
sockets
on Neutrino with the standard TCP/IP stack. What a great bunch of
guys!
The standard stack does support routing sockets. If the main
reason you are running routed is to add the route mentioned in
your /etc/gateways, you can do the equivalent with:
route add -net 192.168.110.0 192.168.2.1
-seanb
Apparently the only use I have for routed is to read the gateways file. When
I can get back to the system, I’ll have to experiment with it.
Thanks.
“Sean Boudreau” <seanb@node25.ott.qnx.com> wrote in message
news:b8onfb$g9u$1@nntp.qnx.com…
The routing table in the stack has the final say. routed uses
the RIP protocol to exchange and update the routing table in
the stack dynamically. Nothing I’ve heard indicates you’re using
this functionality of routed.
-seanb
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
When I wrote “how are routing tables read…”, I really meant “used”.
How
can the IP layer find the right gateway without the routing daemon? In
other
words, how is the information in the routing table applied to the
routing
problem without routed?
Thanks.
“Sean Boudreau” <> seanb@node25.ott.qnx.com> > wrote in message
news:b8ohem$c8j$> 1@nntp.qnx.com> …
David Kuechenmeister <> k13@b.e.l.l.s.o.u.t.h.n.e.t> > wrote:
Okay, I ended up with the routed daemon from QSSL. And I know how to
use route. But for the sake of discussion, how are the routing tables
read without the daemon running?
Your favorite variant of the following can be used to
dump what’s currently in the stack:
netstat -r
netstat -rn
netstat -rn -finet
route -n get <dst
route -n show
-seanb
The reason for using the /etc/gateways file was to have an embedded
system start and configure the routing tables without human
intervention. I could have added the route command to the build file,
but I still don’t see how the table would have been used without the
routed daemon running.
Thanks,
drk
In article <b8n4vs$fbr$> 1@nntp.qnx.com> >, Sean Boudreau
seanb@node25.ott.qnx.com> > wrote:
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
The result of the problem report was that routed isn’t supplied
with
the SE
version of Momentics. Is that right? Why in the world would QSSL
supply all
the rest of the network tools that you need to support routing,
then
leave
out the routing daemon? And on top of that, there is absolutely no
notice in
any of the literature that this particular capability has been
omitted. To
the contrary, all the literature that I could find spoke of
routing
sockets
on Neutrino with the standard TCP/IP stack. What a great bunch of
guys!
The standard stack does support routing sockets. If the main
reason you are running routed is to add the route mentioned in
your /etc/gateways, you can do the equivalent with:
route add -net 192.168.110.0 192.168.2.1
-seanb
Sean Boudreau <seanb@node25.ott.qnx.com> wrote:
SB > David Kuechenmeister <k13@b.e.l.l.s.o.u.t.h.n.e.t> wrote:
Okay, I ended up with the routed daemon from QSSL. And I know how to
use route. But for the sake of discussion, how are the routing tables
read without the daemon running?
SB > Your favorite variant of the following can be used to
SB > dump what’s currently in the stack:
SB > # netstat -r
SB > # netstat -rn
SB > # netstat -rn -finet
SB > # route -n get
SB > # route -n show
SB > -seanb
Baby buglet:
‘use netstat’ does not show the -f option.
It is described in the helpviewer pages.
Baby buglet:
‘use netstat’ does not show the -f option.
It is described in the helpviewer pages.
PR’d.
Thanks for the info!
–
Doug Smith
Technical Publications
QNX Software Systems