Subject: port-arm32/8527: RiscPC ethernet
To: None <gnats-bugs@gnats.netbsd.org>
From: None <netbsd@precedence.co.uk>
List: netbsd-bugs
Date: 10/01/1999 04:16:44
>Number: 8527
>Category: port-arm32
>Synopsis: arm32 IP stack not receiving packets from eb0
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: port-arm32-maintainer (NetBSD/arm32 Portmaster)
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Oct 1 03:50:00 1999
>Last-Modified:
>Originator: Stephen Borrill
>Organization:
Precedence Technologies Ltd
>Release: Sep 22 1999
>Environment:
System: NetBSD black 1.4K NetBSD 1.4K (RPCFW192.1.4K) #0: Wed Sep 22 10:41:39 BST 1999 root@cats:/usr/src/sys/arch/arm32/compile/RPCFW192.1.4K arm32
Acorn RiscPC, EtherB ethernet
Userland mainly 1.3, but using -current ping, etc. makes no difference
>Description:
The problem is with the driver for the EtherB ethernet card (eb0 device).
The problem started on or around 4th June after some changes were made to
the driver by cgd. The drivers for the Ether1 (ie0) and Ether3 (ea0) were
also altered, but these have not been tested.
The interface ifconfig's OK:
eb0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING> mtu 1500
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
Pinging the interface access (192.168.1.1) is successful, i.e. 0% packet
loss. If another machine on the same network is pinged (192.168.1.2), there
is 100% packet loss. However, arp -a shows that the arp request has been
successful (there is an ethernet address for the second machine):
black.precedence.co.uk (192.168.1.1) at 00:00:a4:10:bb:7a permanent
grey.precedence.co.uk (192.168.1.2) at 00:c0:32:00:1f:54
? (192.168.1.255) at (incomplete)
tcpdump shows the following (annotated):
192.168.1.1 is the RiscPC (server) running the faulty kernel
192.168.1.2 is a client machine on the network
Ping starts here => ARP request
11:18:18.537287 arp who-has 192.168.1.2 tell 192.168.1.1
11:18:18.538467 arp reply 192.168.1.2 is-at 0:c0:32:0:1f:54
11:18:18.538683 192.168.1.1 > 192.168.1.2: icmp: echo request
11:18:18.539628 192.168.1.2 > 192.168.1.1: icmp: echo reply
11:18:19.544216 192.168.1.1 > 192.168.1.2: icmp: echo request
11:18:19.545636 192.168.1.2 > 192.168.1.1: icmp: echo reply
11:18:20.544136 192.168.1.1 > 192.168.1.2: icmp: echo request
11:18:20.545543 192.168.1.2 > 192.168.1.1: icmp: echo reply
Packets are being sent, received by the client, which is sending replies,
but the replies aren't being received by the IP stack. ping shows
100% packet loss
Here is a telnet attempt from the client:
11:18:54.015676 192.168.1.2.1037 > 192.168.1.1.telnet: S 2075295007:2075295007(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF)
There is no reply from the server.
Here is a telnet attempt from the server to the client:
11:19:35.057649 192.168.1.1.65507 > 192.168.1.2.telnet: S 1168029345:1168029345(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> [tos 0x10]
11:19:35.060220 192.168.1.2.telnet > 192.168.1.1.65507: R 0:0(0) ack 1168029346 win 0
Client receives packet, but refuses connection. Server does not receive the
refusal and hangs.
With a 1.4_BETA kernel everything works as expected. Other ethernet drivers
for the arm32 port are not affected (for instance, the de0 driver works fine
in a CATS with a 1.4K kernel).
>How-To-Repeat:
Get an Acorn RiscPC running NetBSD/arm32 with an EtherB ethernet card.
Install a -current kernel and configure the eb0 ethernet interface. Attempt
to talk to anything else on the network. The situation dsecribed above will
occur.
>Fix:
Not known
>Audit-Trail:
>Unformatted: