On 2 Apr 2003 22:16:53 GMT, Bill Caroselli <email@example.com> wrote:
Norman Branitsky <> firstname.lastname@example.org> > 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.
Swapped cables for one that was verified as working.
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
tcprt 1/40 1
nameloc is running.
The client is calling me long distance from Kitchener right now
Wednesday April 2, 2003 17:21
Any suggestions greatly appreciated.
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
/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