NetBSD Problem Report #8468

Received: (qmail 22571 invoked from network); 22 Sep 1999 10:41:55 -0000
Message-Id: <199909221041.LAA00546@precedence.co.uk>
Date: Wed, 22 Sep 1999 11:41:45 +0100 (BST)
From: sborrill@precedence.co.uk
Reply-To: netbsd@precedence.co.uk
To: gnats-bugs@gnats.netbsd.org
Subject: Faulty ethernet on NetBSD/arm32 RiscPC
X-Send-Pr-Version: 3.95

>Number:         8468
>Category:       port-arm32
>Synopsis:       RiscPC ethernet non-working
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bjh21
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Sep 22 03:50:00 +0000 1999
>Closed-Date:    Fri Apr 20 13:23:45 +0000 2001
>Last-Modified:  Fri Apr 20 13:23:45 +0000 2001
>Originator:     Stephen Borrill
>Release:        22nd September 1999
>Organization:
	Precedence Technologies Ltd
>Environment:
	System: NetBSD black 1.4K NetBSD 1.4K (RPCFW192.1.4K) #1: Wed 22nd Sep 99 17:36:46 BST 1999 root@black:/usr/src/sys/arch/arm32/compile/RPCFW192.1.4K arm32
	1.4.1 release userland
>Description:
Interface eb0 ifconfig's correctly, but cannot be pinged. tcpdump
shows that all network data is being received. Pinging from the
NetBSD box correctly resolves ARP entries, tcpdump shows that the echo-reply
is being received, but incoming data is getting no further up the IP stack.
Data appears to only be received when the interface is in promiscuous mode.
Similarly, telnetting in from another machine shows that the initial TCP
packet is being received, but once again goes no further.

This has not worked since 1.4C and was notified to the mailing list on
4th June.

>How-To-Repeat:
Use any RiscPC arm32 kernel compiled from -current since the start of June
with a eb0, ea0 or ie0 ethernet card.
>Fix:
	Not known
>Release-Note:
>Audit-Trail:

From: Ben Harris <bjh21@netbsd.org>
To: <netbsd@precedence.co.uk>
Cc: <gnats-bugs@netbsd.org>
Subject: port-arm32/8468: RiscPC ethernet non-working
Date: Sun, 8 Apr 2001 23:35:59 +0100 (BST)

 In a rather ancient bug report, you wrote:

 > Interface eb0 ifconfig's correctly, but cannot be pinged. tcpdump
 > shows that all network data is being received. Pinging from the NetBSD
 > box correctly resolves ARP entries, tcpdump shows that the echo-reply
 > is being received, but incoming data is getting no further up the IP
 > stack.

 I've been working on the "eb" driver lately.  Can you tell me if this bug
 is still present in NetBSD-current (If, indeed, it was present in 1.5)?

 -- 
 Ben Harris                                                   <bjh21@netbsd.org>
 Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>

State-Changed-From-To: open->feedback 
State-Changed-By: bjh21 
State-Changed-When: Thu Apr 19 05:58:13 PDT 2001 
State-Changed-Why:  
Waiting for submitter to confirm state of bug. 


Responsible-Changed-From-To: port-arm32-maintainer->bjh21 
Responsible-Changed-By: bjh21 
Responsible-Changed-When: Thu Apr 19 05:58:13 PDT 2001 
Responsible-Changed-Why:  
I'm responsible for the ea and eb drivers. 

From: Stephen Borrill <netbsd@precedence.co.uk>
To: Ben Harris <bjh21@netbsd.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: port-arm32/8468: RiscPC ethernet non-working
Date: Thu, 19 Apr 2001 18:03:28 +0100 (BST)

 On Sun, 8 Apr 2001, Ben Harris wrote:

 > > Interface eb0 ifconfig's correctly, but cannot be pinged. tcpdump
 > > shows that all network data is being received. Pinging from the NetBSD
 > > box correctly resolves ARP entries, tcpdump shows that the echo-reply
 > > is being received, but incoming data is getting no further up the IP
 > > stack.
 > 
 > I've been working on the "eb" driver lately.  Can you tell me if this bug
 > is still present in NetBSD-current (If, indeed, it was present in 1.5)?

 I've not got -current or 1.5 running on a RiscPC. It's quite a big deal
 for me to get it running at the moment. Could you recreate the problem 
 if I explain it?

 Here is a copy of an email I sent to the list on 14th Dec 1999:

 ----8<---
 Matthias Scheler has committed a small change that goes some way
 to fixing the problems with the eb0 driver (see PR-8527). A very similar
 tweak can be used on the ea driver as well. To recap, since the 18th May
 the drivers for the EtherB and EtherIII have not allowed any inwards
 packets to proceed up through the stack. The fix substantially allows this
 work. However, problems still exist when using ipf.

 For instance, on my network I am using 192.168.1.x with a 24-bit netmask.
 The following rules should work fine:

 block in all
 pass in from 192.168.1.0/24 to any
 pass in on lo0 all
 pass out all

 This has been tried with an EtherN (ne0), EtherM (ne0), EtherI (ie0),
 de0 (on CATS), EtherB (eb0) and EtherIII (ea0) on 1.3 and -current kernels
 (on both arm32 and i386). The only situation that fails is eb0 or ea0 when 
 used on a -current kernel. Altering the second line to the following gets
 everything working:

 pass in from 192.168.0.0/16 to any

 As I'm using a 255.255.255.0 netmask throughout, this shouldn't be the
 case.

 I've compared if_eb.c with if_ie.c and dp8390.c, but I can't see any
 obvious discrepancies.

 I'll submit another PR I guess, but I can't help feeling it's all linked
 in together.

 ----8<---
 I sent this to you on the 25th July 2000
 ----8<---
 Could this perhaps fix the long outstanding bug (which appears to be
 alignment related) when using ipfilter with the ea/eb drivers. An example
 (IIRC) was:

 block in all
 pass in from 192.168.1.0/24 to any
 pass out all

 This would block all inward traffic from the 192.168.1.0/24 network
 (IP address was 192.168.1.1 netmask 255.255.255.0). However,
 "pass in from 192.168.0.0/16 to any" worked OK. Further experimentation
 showed that a netmask > 18 bits blocked inward traffic even if the
 rule should pass it.



From: Ben Harris <bjh21@netbsd.org>
To: Stephen Borrill <netbsd@precedence.co.uk>
Cc: <gnats-bugs@netbsd.org>
Subject: Re: port-arm32/8468: RiscPC ethernet non-working
Date: Thu, 19 Apr 2001 18:48:49 +0100 (BST)

 On Thu, 19 Apr 2001, Stephen Borrill wrote:

 > I've not got -current or 1.5 running on a RiscPC. It's quite a big deal
 > for me to get it running at the moment. Could you recreate the problem
 > if I explain it?

 I expect so, yes.  I've got all the necessary hardware, and I can get away
 with arbitrarily reconfiguring it.

 > Here is a copy of an email I sent to the list on 14th Dec 1999:

 That looks like it's precisely what I want.  And it's now in GNATS, which
 means I'm less likely to mislay it again.  Thanks.  I'll look into it this
 evening.

 -- 
 Ben Harris                                                   <bjh21@netbsd.org>
 Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>


From: Ben Harris <bjh21@netbsd.org>
To: Stephen Borrill <netbsd@precedence.co.uk>
Cc: <gnats-bugs@netbsd.org>
Subject: Re: port-arm32/8468: RiscPC ethernet non-working
Date: Thu, 19 Apr 2001 23:35:11 +0100 (BST)

 On Thu, 19 Apr 2001, Stephen Borrill wrote:

 > For instance, on my network I am using 192.168.1.x with a 24-bit netmask.
 > The following rules should work fine:
 >
 > block in all
 > pass in from 192.168.1.0/24 to any
 > pass in on lo0 all
 > pass out all
 >
 > This has been tried with an EtherN (ne0), EtherM (ne0), EtherI (ie0),
 > de0 (on CATS), EtherB (eb0) and EtherIII (ea0) on 1.3 and -current kernels
 > (on both arm32 and i386). The only situation that fails is eb0 or ea0 when
 > used on a -current kernel.

 Hmm.  I tried these rules:

 southeast-iceland# /usr/sbin/ipfstat -io
 pass out from any to any
 block in from any to any
 pass in from 172.17.11.0/24 to any
 pass in on lo0 from any to any
 southeast-iceland# ifconfig oeb0
 oeb0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING> mtu 1500
         inet 172.17.11.33 netmask 0xffffff00 broadcast 172.17.11.255

 using both the current eb driver and the oeb driver, and it seems to work
 in both cases.  Thus, I _think_ the problem is solved, but since I haven't
 reproduced it I can't be sure.

 -- 
 Ben Harris                                                   <bjh21@netbsd.org>
 Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>

State-Changed-From-To: feedback->closed 
State-Changed-By: bjh21 
State-Changed-When: Fri Apr 20 06:22:51 PDT 2001 
State-Changed-Why:  
Submitter believes bug is likely to have been fixed. 
>Unformatted:

Home	PR Database Search