Network can send but not receive

I have a Macronix MX98715 card in my QNX RTP 6.1 PC (“siskel”). I run

io-net -d tulip chipset=98715 -p tcpip

and it seems to see the card. I can set the interface’s IP address with ifconfig. I can ping the NIC’s local address successfully.

When I try to ping another machine on my LAN, though, I don’t get anything back. Running a network sniffer on the target machine (“culdesac”, a Linux box) reveals that siskel is sending
out ARP requests looking for culdesac, but isn’t seeing the responses. The ping command on siskel spits out “host is down” errors, which is what I’d expect if it wasn’t getting ARP
responses.

For grins, on the thought that it might be an ARP problem, I tried adding culdesac’s address to siskel’s ARP cache (using arp -s). That causes the ping packets to hit culdesac, but siskel
doesn’t see the ARP requests culdesac sends out in its attempt to respond. Next I added siskel’s address to culdesac’s ARP cache. That gets rid of the ARP requests and leaves culdesac
seeing incoming pings and sending responses, but siskel doesn’t see anything.

All of which leads me to conclude that the problem is what it seems: QNX plus my NIC equals no packets received.

One suspicious thing: nicinfo shows that the interface is in half-duplex mode. It’s a full-duplex-capable card connected to a full-duplex switch. I tried adding duplex=1 to the io-net options but
it had no effect. The lights on my switch show that siskel is in half-duplex mode. Of course it ought to work just fine, but maybe something is getting confused about duplex settings, which
would certainly account for data only flowing one way.

Here’s the relevant output from the usual set of commands I’ve seen people run here:

pidin ar | grep io-net

925730 io-net -d tulip chipset=98715 -p tcpip
1351720 grep io-net

pci -v



PCI version = 2.10

[… a bunch of other entries …]

Class = Network (Ethernet)
Vendor ID = 10d9h, Macronix International Co. Ltd.
Device ID = 531h, MX98715/725 Single Chip Fast Ethernet NIC Controller
PCI index = 0h
Class Codes = 020000h
Revision ID = 20h
Bus number = 0
Device number = 10
Function num = 0
Status Reg = 290h
Command Reg = 87h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 20h
Cache Line Size= 8h un-cacheable
PCI IO Address = 9400h length 256 enabled
PCI Mem Address = f3111000h 32bit length 256 enabled
PCI Expansion ROM = f2000000h length 65536 disabled
Max Lat = 56ns
Min Gnt = 8ns
PCI Int Pin = INT A
Interrupt line = 5
Capabilities Pointer = 44h
Capability ID = 1h
Capabilities = 9211h - 0h

cat /etc/net.cfg

nto network config file v1.2

version v1.2

[global]
hostname siskel
domain midwinter.com
nameserver 192.168.0.2

[en0]
type ethernet
mode manual
manual_ip 192.168.0.5
manual_netmask 255.255.255.0

nicinfo



Tulip: Macronix 98715 Ethernet Controller
Physical Node ID … 0080AD 3ABF23
Current Physical Node ID … 0080AD 3ABF23
Media Rate … 0 kb/s half-duplex UTP
MTU … 1514
Lan … 0
I/O Port Range … 0x9400 → 0x94FF
Hardware Interrupt … 0x5
Promiscuous … Disabled
Multicast … Enabled

Total Packets Txd OK … 732
Total Packets Txd Bad … 0
Total Packets Rxd OK … 0
Total Rx Errors … 2

Total Bytes Txd … 61138
Total Bytes Rxd … 0

Tx Collision Errors … 0
Tx Collisions Errors (aborted) … 0
Carrier Sense Lost on Tx … 0
FIFO Underruns During Tx … 0
Tx deferred … 0
Out of Window Collisions … 0
FIFO Overruns During Rx … 0
Alignment errors … 0
CRC errors … 2

Hi Steven,

Letme see what the developer of the tulip driver sais about this.

Thanks

E.


Steven Grimm <koreth-qnx@midwinter.com> wrote:

I have a Macronix MX98715 card in my QNX RTP 6.1 PC (“siskel”). I run

io-net -d tulip chipset=98715 -p tcpip

and it seems to see the card. I can set the interface’s IP address with ifconfig. I can ping the NIC’s local address successfully.

When I try to ping another machine on my LAN, though, I don’t get anything back. Running a network sniffer on the target machine (“culdesac”, a Linux box) reveals that siskel is sending
out ARP requests looking for culdesac, but isn’t seeing the responses. The ping command on siskel spits out “host is down” errors, which is what I’d expect if it wasn’t getting ARP
responses.

For grins, on the thought that it might be an ARP problem, I tried adding culdesac’s address to siskel’s ARP cache (using arp -s). That causes the ping packets to hit culdesac, but siskel
doesn’t see the ARP requests culdesac sends out in its attempt to respond. Next I added siskel’s address to culdesac’s ARP cache. That gets rid of the ARP requests and leaves culdesac
seeing incoming pings and sending responses, but siskel doesn’t see anything.

All of which leads me to conclude that the problem is what it seems: QNX plus my NIC equals no packets received.

One suspicious thing: nicinfo shows that the interface is in half-duplex mode. It’s a full-duplex-capable card connected to a full-duplex switch. I tried adding duplex=1 to the io-net options but
it had no effect. The lights on my switch show that siskel is in half-duplex mode. Of course it ought to work just fine, but maybe something is getting confused about duplex settings, which
would certainly account for data only flowing one way.

Here’s the relevant output from the usual set of commands I’ve seen people run here:

pidin ar | grep io-net

925730 io-net -d tulip chipset=98715 -p tcpip
1351720 grep io-net

pci -v



PCI version = 2.10

[… a bunch of other entries …]

Class = Network (Ethernet)
Vendor ID = 10d9h, Macronix International Co. Ltd.
Device ID = 531h, MX98715/725 Single Chip Fast Ethernet NIC Controller
PCI index = 0h
Class Codes = 020000h
Revision ID = 20h
Bus number = 0
Device number = 10
Function num = 0
Status Reg = 290h
Command Reg = 87h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 20h
Cache Line Size= 8h un-cacheable
PCI IO Address = 9400h length 256 enabled
PCI Mem Address = f3111000h 32bit length 256 enabled
PCI Expansion ROM = f2000000h length 65536 disabled
Max Lat = 56ns
Min Gnt = 8ns
PCI Int Pin = INT A
Interrupt line = 5
Capabilities Pointer = 44h
Capability ID = 1h
Capabilities = 9211h - 0h

cat /etc/net.cfg

nto network config file v1.2

version v1.2

[global]
hostname siskel
domain midwinter.com
nameserver 192.168.0.2

[en0]
type ethernet
mode manual
manual_ip 192.168.0.5
manual_netmask 255.255.255.0

nicinfo



Tulip: Macronix 98715 Ethernet Controller
Physical Node ID … 0080AD 3ABF23
Current Physical Node ID … 0080AD 3ABF23
Media Rate … 0 kb/s half-duplex UTP
MTU … 1514
Lan … 0
I/O Port Range … 0x9400 → 0x94FF
Hardware Interrupt … 0x5
Promiscuous … Disabled
Multicast … Enabled

Total Packets Txd OK … 732
Total Packets Txd Bad … 0
Total Packets Rxd OK … 0
Total Rx Errors … 2

Total Bytes Txd … 61138
Total Bytes Rxd … 0

Tx Collision Errors … 0
Tx Collisions Errors (aborted) … 0
Carrier Sense Lost on Tx … 0
FIFO Underruns During Tx … 0
Tx deferred … 0
Out of Window Collisions … 0
FIFO Overruns During Rx … 0
Alignment errors … 0
CRC errors … 2

I should add, since I didn’t mention it, that when I boot this machine up in WinME the Ethernet card works fine and my switch shows it’s set to full duplex mode. So it’s not a matter of faulty
hardware or wiring (or if it is, the fault can clearly be avoided in software).

Thanks for the quick response!

-Steve

It sounds like you have defined a route to your other host but the other
host may not have a route back to you. This is common if you are going
through a PPP link.


Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net

“Steven Grimm” <koreth-qnx@midwinter.com> wrote in message
news:1104_1003189402@flippant…

I should add, since I didn’t mention it, that when I boot this machine up
in WinME the Ethernet card works fine and my switch shows it’s set to full

duplex mode. So it’s not a matter of faulty

hardware or wiring (or if it is, the fault can clearly be avoided in
software).

Thanks for the quick response!

-Steve

Hi Steven,

Have you tried starting the driver manually?
and forcing full duplex?

E.


Steven Grimm <koreth-qnx@midwinter.com> wrote:

I should add, since I didn’t mention it, that when I boot this machine up in WinME the Ethernet card works fine and my switch shows it’s set to full duplex mode. So it’s not a matter of faulty
hardware or wiring (or if it is, the fault can clearly be avoided in software).

Thanks for the quick response!

-Steve

On Mon, 15 Oct 2001 17:30:52 -0700, “Bill Caroselli (Q-TPS)” <qtps@earthlink.net> wrote:

It sounds like you have defined a route to your other host but the other
host may not have a route back to you. This is common if you are going
through a PPP link.

Both machines are on the same Ethernet and the other host can see all the
non-QNX machines. No PPP anywhere in the picture, and since the other
host actually sends the ping replies once I run arp -s to tell it the QNX box’s
Ethernet address, it’s not a routing problem. If I boot the QNX machine under
Windows and give it the same IP address it has under QNX, it receives ping
responses (and other network traffic) with no trouble.

-Steve

On 16 Oct 2001 14:14:34 GMT, Hardware Support Account <hw@qnx.com> wrote:

Hi Steven,

Have you tried starting the driver manually?
and forcing full duplex?

Yes, I mentioned that in my original message – forcing full duplex (with “duplex=1”
as described in the tulip manpage) seems to have no effect. It still comes up in
half duplex mode according to nicinfo.

-Steve

On 15 Oct 2001 14:36:27 GMT, Hardware Support Account <hw@qnx.com> wrote:

Letme see what the developer of the tulip driver sais about this.

Any word from the developer on this problem yet?

-Steve