qnet crashing on ICMP packets

We manufacturer an embedded system running QNX 6.1 that has been running
very well for several years. It is X86 based, and we start both TCP/IP and
qnet protocols on the Ethernet interface.

We recently added some embedded devices to our network that have Zworld
Rabbit processors. Now the QNX boxes only run a few seconds after power up
before locking up completely. If the Ethernet cable is not plugged in until
10 or 20 seconds after startup, the QNX boxes run fine.

Using an MaaTec Ethernet packet sniffer, it looks like the QNX boxes
broadcast a qnet “I am here” message on startup. Usually only other QNX
boxes respond, but the Zworld Rabbit boxes respond with an “ICMP Dest
Unreachable - Protocol Unreachable” message. Several of these messages come
back at once, and this seems to crash qnet and take down the whole box.
It’s completely dead and I can’t get any information out of it post mortem.
Dumps of the packet contents are below.

Is this a known bug in qnet? Does anyone have any suggestions? Upgrading
to 6.3 would take a great deal of effort due to the expense and the
recertification of the box, but would that solve the problem?

Thanks for any help,
Jon Wyatt



The packet broadcast from the QNX box is:
Ethernet II
Dest FFFFFFFFFFFF (Broadcast)
Src 0050C21303F1
Ethertype: 0800 (IP - Internet Protocol)

IPv4 - Internet Protocol v4
Ver/IHL: 45
Ver: 4 Header Length: 5 (20 bytes)
Type of Service: 00
Precedence: 0 (Routine)
normal delay | normal throughput | normal reliability
Total Length: 61
Identification: 0
Fragmentation: 0000
may fragment | last fragment
Fragment Offset: 0
Time to Live: 255
Protocol: 106 (QNX)
Checksum: 47959
Src 0.0.0.0
Dest 0.0.0.0

Remaining Data
…)!e$… …I… 11 02 00 29 21 65 24 F9 00 00 00 00 49 B5
00 02 00 00 00 00
…astc01 07.astcqnx 00 11 12 00 61 73 74 63 30 31 30 37 00 61 73 74
63 71 6E 78
… 00

The response packet is:
Ethernet II
Dest 0050C21303F1
Src 0090C2C4BD8A
Ethertype: 0800 (IP - Internet Protocol)

IPv4 - Internet Protocol v4
Ver/IHL: 45
Ver: 4 Header Length: 5 (20 bytes)
Type of Service: 00
Precedence: 0 (Routine)
normal delay | normal throughput | normal reliability
Total Length: 56
Identification: 19
Fragmentation: 0000
may fragment | last fragment
Fragment Offset: 0
Time to Live: 64
Protocol: 1 (Internet Control Message)
Checksum: 31411
Src 0.0.0.0
Dest 0.0.0.0

ICMP - Internet Control Message Protocol
Type: 3 (ICMP - Dest Unreachable)
Code: 2 (Protocol Unreachable)
Checksum: 42356
Unused: 0

Original datagram
IPv4 - Internet Protocol v4
Ver/IHL: 45
Ver: 4 Header Length: 5 (20 bytes)
Type of Service: 00
Precedence: 0 (Routine)
normal delay | normal throughput | normal reliability
Total Length: 61
Identification: 0
Fragmentation: 0000
may fragment | last fragment
Fragment Offset: 0
Time to Live: 255
Protocol: 106 (QNX)
Checksum: 47959
Src 0.0.0.0
Dest 0.0.0.0

Remaining Data
…)!e$. 11 02 00 29 21 65 24 F9


\

“Jon Wyatt” postmaster@127.0.0.1 wrote in message
news:ctpa9e$1ce$1@inn.qnx.com

We manufacturer an embedded system running QNX 6.1 that has been running
very well for several years. It is X86 based, and we start both TCP/IP
and qnet protocols on the Ethernet interface.

We recently added some embedded devices to our network that have Zworld
Rabbit processors. Now the QNX boxes only run a few seconds after power
up before locking up completely. If the Ethernet cable is not plugged in
until 10 or 20 seconds after startup, the QNX boxes run fine.

Using an MaaTec Ethernet packet sniffer, it looks like the QNX boxes
broadcast a qnet “I am here” message on startup. Usually only other QNX
boxes respond, but the Zworld Rabbit boxes respond with an “ICMP Dest
Unreachable - Protocol Unreachable” message. Several of these messages
come back at once, and this seems to crash qnet and take down the whole
box. It’s completely dead and I can’t get any information out of it post
mortem. Dumps of the packet contents are below.

Is this a known bug in qnet? Does anyone have any suggestions? Upgrading
to 6.3 would take a great deal of effort due to the expense and the
recertification of the box, but would that solve the problem?

Thanks for any help,
Jon Wyatt

Hum unless you need QNET to be routable you could bind it to the ethernet
driver. That way QNET packet wouldn’t be embedded in an IP packet. They
would be ignore by the Rabbit processor. Now there could be some issue with
QNET being binded to ethernet with QNX6.1, that I don’t remember.

The packet broadcast from the QNX box is:
Ethernet II
Dest FFFFFFFFFFFF (Broadcast)
Src 0050C21303F1
Ethertype: 0800 (IP - Internet Protocol)

IPv4 - Internet Protocol v4
Ver/IHL: 45
Ver: 4 Header Length: 5 (20 bytes)
Type of Service: 00
Precedence: 0 (Routine)
normal delay | normal throughput | normal reliability
Total Length: 61
Identification: 0
Fragmentation: 0000
may fragment | last fragment
Fragment Offset: 0
Time to Live: 255
Protocol: 106 (QNX)
Checksum: 47959
Src 0.0.0.0
Dest 0.0.0.0

Remaining Data
…)!e$… …I… 11 02 00 29 21 65 24 F9 00 00 00 00 49
B5 00 02 00 00 00 00
…astc01 07.astcqnx 00 11 12 00 61 73 74 63 30 31 30 37 00 61 73 74
63 71 6E 78
. 00

The response packet is:
Ethernet II
Dest 0050C21303F1
Src 0090C2C4BD8A
Ethertype: 0800 (IP - Internet Protocol)

IPv4 - Internet Protocol v4
Ver/IHL: 45
Ver: 4 Header Length: 5 (20 bytes)
Type of Service: 00
Precedence: 0 (Routine)
normal delay | normal throughput | normal reliability
Total Length: 56
Identification: 19
Fragmentation: 0000
may fragment | last fragment
Fragment Offset: 0
Time to Live: 64
Protocol: 1 (Internet Control Message)
Checksum: 31411
Src 0.0.0.0
Dest 0.0.0.0

ICMP - Internet Control Message Protocol
Type: 3 (ICMP - Dest Unreachable)
Code: 2 (Protocol Unreachable)
Checksum: 42356
Unused: 0

Original datagram
IPv4 - Internet Protocol v4
Ver/IHL: 45
Ver: 4 Header Length: 5 (20 bytes)
Type of Service: 00
Precedence: 0 (Routine)
normal delay | normal throughput | normal reliability
Total Length: 61
Identification: 0
Fragmentation: 0000
may fragment | last fragment
Fragment Offset: 0
Time to Live: 255
Protocol: 106 (QNX)
Checksum: 47959
Src 0.0.0.0
Dest 0.0.0.0

Remaining Data
…)!e$. 11 02 00 29 21 65 24 F9


\