devnp-i82544.so

QNX USERS QNX6 - OS
1

Hello Friends.

My system – QNX 6.4.0………I run into with strange problem. I have SBC with NIC – 82571EB Gigabit Ethernet Controller, i.e. driver - devnp-82544.so……………….When I invoke “io-pkt-v4-hc -d i82544 –p tcpip” (……i check , that I invoke only ONE copy of io-pkt-v4-hc…) , then all network system is hang (duration is about 30 seconds), because if invoke 3 commands consequally –

  1. io-pkt-v4-hc -d i82544 –p tcpip
  2. ifconfig wm0 193.232.173.5
  3. ping 193.232.173.1 (this host is up, I’ve check this)

Ping is start to work perfectly only after 30 seconds. I attach output of the ping.

Ping: sendto: Host is down
Ping: sendto: Host is down
Ping: sendto: Host is down
Ping: sendto: Host is down
Ping: sendto: Host is down
Ping: sendto: Host is down
Ping: sendto: Host is down
Ping: sendto: Host is down
Ping: sendto: Host is down
Ping: sendto: Host is down
Ping: sendto: Host is down
Ping: sendto: Host is down
Ping: sendto: Host is down
Ping: sendto: Host is down
Ping: sendto: Host is down
64 bytes from 193.232.173.1: icmp_seq=27 ttl=64 time=0 ms
64 bytes from 193.232.173.1: icmp_seq=28 ttl=64 time=0 ms

As you see, that ICMP_SEQ not 1, but 27. What I do wrong.

2

Try running this command immediately after ifconfig (assuming *.1is your router.

route add default 193.232.173.1

3

Thanks Denkelly. I try it. But , any ip addr can be instead of 193.232.173.1.

4

As I said, the address should be your router address.

5

No. This solution don’t help me. Btw, when I start driver (io-pkt-v4-hc …) , arp table become empty. May be, it is a key of the problem.

6

The arp table has to be empty when the stack starts. The arp table is “collected” physical addresses “sniffed” from the local LAN segment.

It is normal for some time to be required before the interface is usable - but 25-30 seconds is excessively long. I observed 4-5 seconds but this is on a live network.

Perhaps you have no traffic on the router for ~30 seconds? You could try adding a second host to the router and run ping on it while you bring up QNX?

7

Do you have a nameserver specified?

At least in QNX 6.3, I’ve found that if I have a nameserver specified and that nameserver isn’t available that ‘ping’ commands even to a direct ip address like 193.232.173.1 take about 30 seconds until I start getting responses. As soon as I remove the namesever, ping immediately works. I see the same behavior with direct telnet IP’s as well.

It makes me think QNX is asking to resolve names even on direct IP’s if a nameserver is specified.

Tim

8

When I connect two comps directly , via cross cable, all work correctly.

9

My /etc/resolv.conf is empty.

10

Tim is right - if a nameserver is specified, the OS tries to use it. It’s the same on Windows AFAIR.

11

What I must check? Maybe, nameserver is my problem?

12

After you call ifconfig, try

echo “nameserver 8.8.8.8” > /etc/resolv.conf

This works if the router is on the internet - seems it would make it worse if you are not.

13

What brand of switch are you using. Some (Cisco) can be setup to do some fancy negotiation, checking for loops and such. The switch we use takes exaclty 30 secondes to complete the negotication/validation/verification

14

The brand of my switch is d-link dgs-1100-24. But, friends, I don’t understand . Problem was gone. I can’t catch it again. All work correctly even when I add “nameserver 8.8.8.8” to resolv.conf . But…some observations.
Yesterday, speed was 1000 mb/s. Now - 100 mb/s.
And…net subsystem start to work correctly when I connect two comps via cross cable…it seems.

15

While unlikely, I’m going to throw out the possibility of a hardware configuration problem.
Specifically, the link speed vs. cable type, from Wikipedia.

Cat 5 = 100Mhz
Cat 5e = 100Mhz
Cat 6 = 250Mhz
Cat 6a = 500Mhz
Cat 7 = 600Mhz
Cat 7a = 1200Mhz

I’m not really sure how the NIC cards figure out the performance limits on a cable, but if your NIC was trying to run at 1Ghz and you have less than a Cat 7a cable, you could run into trouble.

16

Hello Friends.

Today I’ve catch this cituation.
As result — SWITCH — is the root of the evil. When I had changed the swith to model D-Link Des-1100-26, net subsys start to work correctly, without 30 sec’s delay…But I can’t understand, why all work correctly yesterday.