QNX4 Network problem

A QNX4 server in my client’s branch office in Kitchener crashed.
We built a new QNX4 server in his head office in Toronto.
We tested the server with a small Ethernet switch and a laptop.
The laptop had no problems accessing the server.

He took the server to Kitchener.
He connected the server to a brand new 16 port switch.
He connected his latop to the switch.
The lights look right.

Can’t ping.
Swapped cables for one that was verified as working.
No help.

netinfo -L 1 shows
Transmitted packets good 42
Received packets good 0

The last time I saw a system that could trasmit but not receive
was a system with a license problem.

sin in shows 40 nodes
licinfo -a shows
vgerx 0/1
vger 0/1
phrt 0/2
rdos 0/39
winrt 0/38
tcprt 1/40 1
qnx 0/40

nameloc is running.

The client is calling me long distance from Kitchener right now
Wednesday April 2, 2003 17:21

Any suggestions greatly appreciated.
TIA

Norman Branitsky <norman@cherniak.on.ca> wrote:

A QNX4 server in my client’s branch office in Kitchener crashed.
We built a new QNX4 server in his head office in Toronto.
We tested the server with a small Ethernet switch and a laptop.
The laptop had no problems accessing the server.

He took the server to Kitchener.
He connected the server to a brand new 16 port switch.
He connected his latop to the switch.
The lights look right.

Can’t ping.
Swapped cables for one that was verified as working.
No help.

netinfo -L 1 shows
Transmitted packets good 42
Received packets good 0

The last time I saw a system that could trasmit but not receive
was a system with a license problem.

sin in shows 40 nodes
licinfo -a shows
vgerx 0/1
vger 0/1
phrt 0/2
rdos 0/39
winrt 0/38
tcprt 1/40 1
qnx 0/40

nameloc is running.

The client is calling me long distance from Kitchener right now
Wednesday April 2, 2003 17:21

Any suggestions greatly appreciated.
TIA

I would first want to confirm if the NIC can receive anything.
Stick it on a network with some microsoft boxes. They tend to transmit
a lot of broadcast packets. Are there any received packets?

Since you mentioned ping I assume your trying to get just TCP/IP
working and haven’t tried native QNX fleet networking. If there
is a second QNX system on that ethernert see if it can get any
fleet packets in. Don’t forget to edit your /etc/netmap file if
necessary.

OK. On to TCP/IP.

Look at the interface. type netstat -in
Is it UP? What is it’s IP address?
Does the other system have a route to that host?

I have often seen situations where one host can send to a second host
but the second host can’t reply, because there wasn’t a route back
to the original host defined.


Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net

Are the netmap files correct? You can still have problems with TCP/IP
if the netmap files are incorrect. Eg. You start Net, then the drivers,
followed by a netmap -f. The MAC addresses in the netmap file override
those already in Net.

What driver are you using? What is the output from netinfo and netinfo -l?

Previously, Norman Branitsky wrote in qdn.public.qnx4:

A QNX4 server in my client’s branch office in Kitchener crashed.
We built a new QNX4 server in his head office in Toronto.
We tested the server with a small Ethernet switch and a laptop.
The laptop had no problems accessing the server.

He took the server to Kitchener.
He connected the server to a brand new 16 port switch.
He connected his latop to the switch.
The lights look right.

Can’t ping.
Swapped cables for one that was verified as working.
No help.

netinfo -L 1 shows
Transmitted packets good 42
Received packets good 0

The last time I saw a system that could trasmit but not receive
was a system with a license problem.

sin in shows 40 nodes
licinfo -a shows
vgerx 0/1
vger 0/1
phrt 0/2
rdos 0/39
winrt 0/38
tcprt 1/40 1
qnx 0/40

nameloc is running.

The client is calling me long distance from Kitchener right now
Wednesday April 2, 2003 17:21

Any suggestions greatly appreciated.
TIA

On 2 Apr 2003 22:16:53 GMT, Bill Caroselli <qtps@earthlink.net> wrote:

Norman Branitsky <> norman@cherniak.on.ca> > wrote:
A QNX4 server in my client’s branch office in Kitchener crashed.
We built a new QNX4 server in his head office in Toronto.
We tested the server with a small Ethernet switch and a laptop.
The laptop had no problems accessing the server.

He took the server to Kitchener.
He connected the server to a brand new 16 port switch.
He connected his latop to the switch.
The lights look right.

Can’t ping.
Swapped cables for one that was verified as working.
No help.

netinfo -L 1 shows
Transmitted packets good 42
Received packets good 0

The last time I saw a system that could trasmit but not receive
was a system with a license problem.

sin in shows 40 nodes
licinfo -a shows
vgerx 0/1
vger 0/1
phrt 0/2
rdos 0/39
winrt 0/38
tcprt 1/40 1
qnx 0/40

nameloc is running.

The client is calling me long distance from Kitchener right now
Wednesday April 2, 2003 17:21

Any suggestions greatly appreciated.
TIA

I would first want to confirm if the NIC can receive anything.
Stick it on a network with some microsoft boxes. They tend to transmit
a lot of broadcast packets. Are there any received packets?
This was actually the client’s second trip to Kitchener.

When we couldn’t make the server receive packets last Friday,
he returned the box to Toronto, plugged it back into his Toronto
network (after changing it’s node number from 1 to 4)
and everything worked correctly.
This, I believe, demonstrates that the NIC functions correctly.

Since you mentioned ping I assume your trying to get just TCP/IP
working and haven’t tried native QNX fleet networking. If there
is a second QNX system on that ethernert see if it can get any
fleet packets in. Don’t forget to edit your /etc/netmap file if necessary.
Unfortunately, there are no other QNX boxes in Kitchener.



OK. On to TCP/IP.
Look at the interface. type netstat -in
Is it UP? What is it’s IP address?
Does the other system have a route to that host?
Yes, netstat -ni and netstat -nr all look correct.

MAC address correctly displayed; 2 lo0 and 2 en1 interfaces.
Default Route defined though this shouldn’t really be neccessary for
devices on the same network segment

I have often seen situations where one host can send to a second host
but the second host can’t reply, because there wasn’t a route back
to the original host defined.
Yes, I’ve seen this too but only in situations where the machines were

on different networks.
Again, the small test network of 1 new 16 port switch, the server, and
1 MS Windows laptop are all on the same network.
I’ve also seen an old Cisco hub that had a 4 user license
and the 5th device added would displace a previous MAC address from
the table. That ain’t happening here.

This morning the client is bringing the server, laptop, switch, and
cables back to Toronto.
My gut feeling is that this is a licensing problem.
The server works fine when connected to the Toronto network
where it gets its licenses from the network.
The server doesn’t transmit when it is running stand alone.

Just to be sure, the client did the following:
mv /etc/licenses /etc/licenses.old
mkdir /etc/licenses
license /dev/fd0
license -r

/etc/licenses now contained 39 licenses.
There is 1 set of licenses from the CD installation in /.licenses.
sin in shows 40 nodes.
licinfo -a shows tcprt 1/40 1

Hugh Brown <hsbrown@qnx.com> wrote:

Are the netmap files correct? You can still have problems with TCP/IP
if the netmap files are incorrect. Eg. You start Net, then the drivers,
followed by a netmap -f. The MAC addresses in the netmap file override
those already in Net.

What driver are you using? What is the output from netinfo and netinfo -l?

Hugh can you explain this? This is news to me and I thought I knew
QNX4 pretty well. The /etc/netmap file MAC addresses won’t cause the
MAC addresses reported by netinfo -l to change. I thought they could
only be changed by arguments to the Net.driver.

Also, since netinto -l reports data at the hardware level as opposed to
the TCP/IP stack, and since he said received packets = 0, then the
hardware isn’t receiving any packets, isn’t that right?

The hardware may be receiving packets but not counting them because
they are addresses to a different MAC address. Norman said that all
hosts are are the same network (segment?). So the packets should be
there. Perhaps Norman you should try to put a -P on the Net.driver
to put it into promiscuous mode.

BTW, I don’t think it’s a licensing issue. te output from licinfo -a
all looks good.

Previously, Bill Caroselli wrote in qdn.public.qnx4:

Hugh Brown <> hsbrown@qnx.com> > wrote:
Are the netmap files correct? You can still have problems with TCP/IP
if the netmap files are incorrect. Eg. You start Net, then the drivers,
followed by a netmap -f. The MAC addresses in the netmap file override
those already in Net.

What driver are you using? What is the output from netinfo and netinfo -l?

Hugh can you explain this? This is news to me and I thought I knew
QNX4 pretty well. The /etc/netmap file MAC addresses won’t cause the
MAC addresses reported by netinfo -l to change. I thought they could
only be changed by arguments to the Net.driver.

The following is the course of events:

  1. Net starts
  2. A driver starts and registers its hardware MAC address with Net.
  3. netmap -f is run with a different MAC address than the hardware.
  4. Socket/Tcpip is started and reads the MAC address from Net.
  5. TCP/IP sends out a message to the driver’s raw interface.
  6. The driver sends the message out with the incorrect MAC address.
  7. The receiving host responds with the incorrect MAC address which
    is not seen by the network card as the MAC does not agree.

You can try the above scenario if you wish!

Also, since netinto -l reports data at the hardware level as opposed to
the TCP/IP stack, and since he said received packets = 0, then the
hardware isn’t receiving any packets, isn’t that right?

The hardware may be receiving packets but not counting them because
they are addresses to a different MAC address. Norman said that all
hosts are are the same network (segment?). So the packets should be
there. Perhaps Norman you should try to put a -P on the Net.driver
to put it into promiscuous mode.

BTW, I don’t think it’s a licensing issue. te output from licinfo -a
all looks good.

On Thu, 3 Apr 2003 08:26:58 -0500, Hugh Brown <hsbrown@qnx.com> wrote:

Are the netmap files correct? You can still have problems with TCP/IP
if the netmap files are incorrect. Eg. You start Net, then the drivers,
followed by a netmap -f. The MAC addresses in the netmap file override
those already in Net.
OK this solved the problem.

We set up the server, laptop, and switch in Toronto.
I did “mv /etc/config/netmap /etc/config/netmap.old” and rebooted.
Networking worked correctly.
I then did "netmap -n1 >/etc/config/netmap.
Here is the new netmap:

Logical Lan Physical Tx Count Last Transmit

1 1 0002B3 417E55 ; 0

Here is the old netmap
1 1 0002B3 417E55

The old netmap was copied from the original node 1 in the Toronto
network. The definitions for nodes 1, 2, and 3 were deleted and
the node 4 definition was changed to node 1 for standalone operation.

So what’s going on?

Hugh Brown <hsbrown@qnx.com> wrote:

The following is the course of events:

  1. Net starts
  2. A driver starts and registers its hardware MAC address with Net.
  3. netmap -f is run with a different MAC address than the hardware.
  4. Socket/Tcpip is started and reads the MAC address from Net.
  5. TCP/IP sends out a message to the driver’s raw interface.
  6. The driver sends the message out with the incorrect MAC address.
  7. The receiving host responds with the incorrect MAC address which
    is not seen by the network card as the MAC does not agree.

You can try the above scenario if you wish!

I didn’t realize that TCP/IP gets the MAC from Net (as opposed to the
Net.driver). But that makes perfect sense.

Previously, Norman Branitsky wrote in qdn.public.qnx4:

On Thu, 3 Apr 2003 08:26:58 -0500, Hugh Brown <> hsbrown@qnx.com> > wrote:

Are the netmap files correct? You can still have problems with TCP/IP
if the netmap files are incorrect. Eg. You start Net, then the drivers,
followed by a netmap -f. The MAC addresses in the netmap file override
those already in Net.
OK this solved the problem.
We set up the server, laptop, and switch in Toronto.
I did “mv /etc/config/netmap /etc/config/netmap.old” and rebooted.
Networking worked correctly.
I then did "netmap -n1 >/etc/config/netmap.
Here is the new netmap:

Logical Lan Physical Tx Count Last Transmit

1 1 0002B3 417E55 ; 0

Here is the old netmap
1 1 0002B3 417E55

The old netmap was copied from the original node 1 in the Toronto
network. The definitions for nodes 1, 2, and 3 were deleted and
the node 4 definition was changed to node 1 for standalone operation.

So what’s going on?

Is this the same as the MAC address of the network card on node 1?
When I set up a netmap file, I prefer to leave the entry for that node
blank, so that Net will always get the MAC address from the network
driver. eg. node1 will have entries in the netmap file for all the other
nodes in the network except itself.