From owner-cvs-all@FreeBSD.ORG Wed Jul 7 19:19:23 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 455A816A4CE; Wed, 7 Jul 2004 19:19:23 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC54E43D2F; Wed, 7 Jul 2004 19:19:22 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i67JJLWi029279 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 7 Jul 2004 12:19:22 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: Bill Paul Date: Wed, 7 Jul 2004 12:21:54 -0700 User-Agent: KMail/1.6.1 References: <200407071746.i67HkUSQ075464@repoman.freebsd.org> In-Reply-To: <200407071746.i67HkUSQ075464@repoman.freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407071221.54962.sam@errno.com> cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/compat/ndis ndis_var.h subr_ndis.c src/sys/dev/if_ndis if_ndis.c if_ndisvar.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2004 19:19:23 -0000 On Wednesday 07 July 2004 10:46 am, Bill Paul wrote: > - Create am NDIS_INITIALIZED() macro in if_ndisvar.h and use it in > if_ndis.c to test whether the device has been initialized rather > than checking for the presence of the IFF_UP flag in if_flags. > While debugging the previous problem, I noticed that bringing > up the device would always produce failures from ndis_setmulti(). > It turns out that the following steps now occur during device > initialization: > > - IFF_UP flag is set in if_flags > - ifp->if_ioctl() called with SIOCSIFADDR (which we don't handle) > - ifp->if_ioctl() called with SIOCADDMULTI > - ifp->if_ioctl() called with SIOCADDMULTI (again) > - ifp->if_ioctl() called with SIOCADDMULTI (yet again) > - ifp->if_ioctl() called with SIOCSIFFLAGS > > Setting the receive filter and multicast filters can only be done > when the underlying NDIS driver has been initialized, which is done > by ifp->if_init(). However, we don't call ifp->if_init() until > ifp->if_ioctl() is called with SIOCSIFFLAGS and IFF_UP has been > set. It appears that now, the network stack tries to add multicast > addresses to interface's filter before those steps occur. Normally, > ndis_setmulti() would trap this condition by checking for the IFF_UP > flag, but the network code has in fact set this flag already, so > ndis_setmulti() is fooled into thinking the interface has been > initialized when it really hasn't. > > It turns out this is usually harmless because the ifp->if_init() > routine (in this case ndis_init()) will set up the multicast > filter when it initializes the hardware anyway, and the underlying > routines (ndis_get_info()/ndis_set_info()) know that the driver/NIC > haven't been initialized yet, but you end up spurious error messages > on the console all the time. > > Something tells me this new behavior isn't really correct. I think > the intention was to fix it so that ifp->if_init() is only called > once when we ifconfig an interface up, but the end result seems a > little bogus: the change of the IFF_UP flag should be propagated > down to the driver before calling any other ioctl() that might actually > require the hardware to be up and running. This "new behaviour" is many many months old (assuming it's what I think it is). The if_init routine is only called by the 802.11 ioctl routine when you mark the interface up to avoid forcing a device initialization (and run of the 802.11 state machine) on every ioctl that's done before marking the if up. This is done based on the setting of the IFF_UP flag. In general IFF_UP means the interface is "ready for traffic to flow". A device should be capable of editing it's multicast state as soon as it marks itself IFF_RUNNING. Sam