NetBSD Problem Report #9548

Received: (qmail 4017 invoked from network); 5 Mar 2000 22:32:38 -0000
Message-Id: <200003052227.RAA00594@zorkmid.mit.edu>
Date: Sun, 5 Mar 2000 17:27:32 -0500 (EST)
From: John Hawkinson <jhawk@mit.edu>
Reply-To: jhawk@mit.edu
To: gnats-bugs@gnats.netbsd.org
Subject: fxp0 can get all 1's mac address
X-Send-Pr-Version: 3.95

>Number:         9548
>Category:       kern
>Synopsis:       fxp0 can get all 1's mac address
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    jhawk
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 05 14:33:01 +0000 2000
>Closed-Date:    
>Last-Modified:  Mon Jun 05 21:35:07 +0000 2000
>Originator:     John Hawkinson
>Release:        1.4.1
>Organization:
MIT
>Environment:

System: NetBSD zorkmid.mit.edu 1.4.1 NetBSD 1.4.1 (ZORKMID) #9: Sun Mar 5 15:44:11 EST 2000 jhawk@zorkmid.mit.edu:/usr/src/sys/arch/i386/compile/ZORKMID i386


>Description:
	This problem ocurrs under 1.4.1, 1.4.2, as well as the 2/26/2000
	snapshots of -current.

	Booting NetBSD via a warm boot from Win98 on a Sony VAIO
	PCB-Z505HE with a built-in Intel 82555-based ethernet (fxp),
	NetBSD probes the ethernet's MAC address as ff:ff:ff:ff:ff:ff (the
	ethernet broadcast address). Needless to say, actually trying
	to use this MAC address would cause serious problems.

	In point of fact, though, actually attempting to use the card
	in this state causes the kernel to printf fxp0: WARNING: SCB timed
	out! And then the machine hangs.

>How-To-Repeat:

	Boot Win98, select Shutdown, Restart, and boot NetBSD.

>Fix:
	The kernel should check to see if the MAC address is sane before
	attaching it. I offer the following patch; presumably if this
	were against -current it would use if_detach(), but I don't
	have the resources to deal with -current right now.

===================================================================
RCS file: net/RCS/if_ethersubr.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -c -r1.1 -r1.2
*** net/if_ethersubr.c	2000/03/05 10:20:49	1.1
--- net/if_ethersubr.c	2000/03/05 22:14:02	1.2
***************
*** 679,684 ****
--- 679,685 ----
  	return (etherbuf);
  }

+ u_char ether_zeroaddr[6] = {0, 0, 0, 0, 0, 0};
  /*
   * Perform common duties while attaching to interface list
   */
***************
*** 689,694 ****
--- 690,710 ----
  {
  	struct sockaddr_dl *sdl;

+ 	/*
+ 	 * Some drivers, particularly with newer ethernet cards and
+ 	 * pcmcia cards, screw up occasionally and get
+ 	 * ff:ff:ff:ff:ff:ff as a MAC address; use of such a MAC
+ 	 * address (the ethernet bcast) can cause real trouble.  So do
+ 	 * a few checks to validate the addr.
+ 	 */
+ 	if (ETHER_IS_MULTICAST(lla) || !bcmp(lla, ether_zeroaddr,
+ 	    sizeof(ether_zeroaddr))) {
+ 	      printf("%s: ether_ifattach() detected illegal MAC %s;"
+ 	          " removing interface.\n", ifp->if_xname, ether_sprintf(lla));
+ 	  TAILQ_REMOVE(&ifnet, ifp, if_list);
+ 	  return;
+ 	}
+ 	    
  	ifp->if_type = IFT_ETHER;
  	ifp->if_addrlen = 6;
  	ifp->if_hdrlen = 14;


Despite this patch, the fxp driver still needs to be fixed to get
this to work. I'm not sure how to go about doing it. mycroft and
I spent some time last night futzing around with it and didn't
reach any conclusion. But I suppose we're available to work on it
at some point in the future, when I finish settling in with my
new laptop.
>Release-Note:
>Audit-Trail:

From: John Hawkinson <jhawk@MIT.EDU>
To: gnats-bugs@gnats.netbsd.org, kern-bug-people@netbsd.org
Cc:  Subject: Re: kern/9548: fxp0 can get all 1's mac address 
Date: Mon, 06 Mar 2000 15:45:05 -0500

 This is actually a dupe of kern/9370: "system hangs on fxp0 configuration
 if w98 was ran before".

 I'd suggest changing this (kern/9548) to a change-request scoped for
 the addition of checking for invalid ethernet MAC addresses, and leave
 kern/9370 open for the tracking of this bug.

 --jhawk
State-Changed-From-To: open->closed 
State-Changed-By: thorpej 
State-Changed-When: Thu May 18 12:12:20 PDT 2000 
State-Changed-Why:  
The underlying problems have been fixed, and this is something that 
could potentially plague all network drivers. 
State-Changed-From-To: closed->open 
State-Changed-By: jhawk 
State-Changed-When: Thu May 18 12:22:20 PDT 2000 
State-Changed-Why:  
The fact that this can conceivably plague all network drivers is reason 
to stopgap it for all network drivers, not to close the PR. 


Responsible-Changed-From-To: kern-bug-people->jhawk 
Responsible-Changed-By: jhawk 
Responsible-Changed-When: Thu May 18 12:22:20 PDT 2000 
Responsible-Changed-Why:  
I'll take responsibility for up-porting this to -current. 

From: Jason R Thorpe <thorpej@zembu.com>
To: jhawk@netbsd.org
Cc: jhawk@MIT.EDU, kern-bug-people@netbsd.org
Subject: Re: kern/9548
Date: Thu, 18 May 2000 12:25:01 -0700

 On Thu, May 18, 2000 at 07:24:11PM -0000, jhawk@netbsd.org wrote:

  > Synopsis: fxp0 can get all 1's mac address
  > 
  > State-Changed-From-To: closed->open
  > State-Changed-By: jhawk
  > State-Changed-When: Thu May 18 12:22:20 PDT 2000
  > State-Changed-Why: 
  > The fact that this can conceivably plague all network drivers is reason
  > to stopgap it for all network drivers, not to close the PR.

 No, it does not call for a stopgap in all driver.  It calls for the
 appropriate interface change to ether_ifattach() and putting appropriate
 sanity checks there.

 -- 
         -- Jason R. Thorpe <thorpej@zembu.com>

From: John Hawkinson <jhawk@MIT.EDU>
To: thorpej@zembu.com
Cc: kern-bug-people@netbsd.org
Subject: Re: kern/9548 
Date: Thu, 18 May 2000 15:32:13 -0400

 > > The fact that this can conceivably plague all network drivers is reason
 > > to stopgap it for all network drivers, not to close the PR.
 >
 >No, it does not call for a stopgap in all driver.  It calls for the
 >appropriate interface change to ether_ifattach() and putting appropriate
 >sanity checks there.

 "for all drivers" != "in all drivers".

 Please note that that patch in the PR in fact does place
 the check in if_ethersubr().

 --jhawk
>Unformatted:

Home	PR Database Search