From owner-freebsd-stable@FreeBSD.ORG Sat Aug 13 15:30:59 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EA8716A41F for ; Sat, 13 Aug 2005 15:30:59 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A64843D46 for ; Sat, 13 Aug 2005 15:30:59 +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 j7DFUoBd080029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Aug 2005 08:30:56 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42FE1374.1060508@errno.com> Date: Sat, 13 Aug 2005 08:36:20 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel O'Connor" References: <200508101622.j7AGMUah041503@repoman.freebsd.org> <200508131344.30433.doconnor@gsoft.com.au> <42FD7D9D.3020709@errno.com> <200508131809.53923.doconnor@gsoft.com.au> In-Reply-To: <200508131809.53923.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: cvs commit: src/sys/net80211 ieee80211.c ieee80211_input.c ieee80211_ioctl.c ieee80211_node.c ieee80211_node.h ieee80211_output.c ieee80211_proto.c ieee80211_proto.h ieee80211_var.h src/sys/dev/ath if_ath.c src/sys/dev/ipw if_ipw.c ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2005 15:30:59 -0000 Daniel O'Connor wrote: > On Saturday 13 August 2005 14:27, Sam Leffler wrote: > >>[Not sure why you're sending this to cvs-all] > > > Oops, freebsd-stable@ is probably better. Not really, but whatever. > > >>Daniel O'Connor wrote: >> >>>ipw is still broken [for me].. >> >>Sorry but that wasn't the question. I don't believe the commit you are >>responding to changed the behaviour of the ipw driver and that was what >>I wanted to confirm. > > > OK, same old behaviour then :) > > >>>[inchoate 13:20] ~ >sudo ifconfig ipw0 >>>ipw0: flags=8802 mtu 1500 >>> inet 192.168.1.100 netmask 0xffffff00 broadcast 192.168.1.255 >>> ether 00:04:23:a4:12:74 >>> media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) >>> status: no carrier >>> ssid dons channel 6 >>> authmode OPEN privacy OFF txpowmax 100 >> >>Someone reported the ipw driver at the author's web site works (better); >>you might try that. Unfortunately the code in the tree is not being >>maintained so far as I can tell. > > > Hmm.. Maybe because it hasn't been broken :) > (ie it's older). > > I will try and search for the date of breakage to provide some more > information. > > It is somewhat annoying that both ipw and ndis are hosed and used to work on > at least a basic level. The ipw and iwi drivers (at least) have never worked right so far as I can tell. At one point I tried the iwi driver and it kinda worked but failed in many common scenarios and in general was very fragile. I no longer have the facilities to even test these drivers and given that I know of no cardbus cards w/ intel parts in them it's unlikely I ever will unless someone wants to donate a laptop dedicated to testing. When these drivers (as well as others) were committed to the tree I warned the author they had issues (actually I told him _before_ they were committed). I explained that they were violating net80211 api's reaching inside data structures where they should not be and otherwise had problems that were going to cause trouble (e.g. the locking of the rx path was wrong). When the changes were committed to "support WPA" I again explained that the changes were wrong. All these warnings were ignored. I cannot be responsible for drivers that are unmaintained and written in the ways I've described. The ndis support has a similarly incestuous relationship with the net80211 layer and it's author too has been distant of late. A lot of this is a byproduct of C's inability to properly hide data. When you need to expose information across files anyone can access it and in this case it enables drivers to be written that break when you change the internal workings of net80211. I am very happy to see new drivers in the tree but unless they are maintained it's not clear they should be incorporated. This is in fact the reason I didn't break these drivers into the tree in the first place (i.e. I had no time to maintain them). >>I don't believe the ipw driver does honors any of the net80211 debug >>controls. > > > I see.. >