From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 16:50:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6E2616A4CE for ; Tue, 5 Oct 2004 16:50:34 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7954843D2F for ; Tue, 5 Oct 2004 16:50:34 +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 i95GoUWi059448 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 5 Oct 2004 09:50:30 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: freebsd-current@freebsd.org Date: Tue, 5 Oct 2004 09:53:58 -0700 User-Agent: KMail/1.7 References: <4161C4D8.4040308@ispro.net.tr> <416313F0.2000508@ispro.net.tr> <20041005.100800.111987973.imp@bsdimp.com> In-Reply-To: <20041005.100800.111987973.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410050953.58739.sam@errno.com> cc: marcos@thepacific.net cc: yurtesen@ispro.net.tr cc: "M. Warner Losh" Subject: Re: atheros frecuencies limited X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2004 16:50:34 -0000 On Tuesday 05 October 2004 09:08 am, M. Warner Losh wrote: > In message: <416313F0.2000508@ispro.net.tr> > > Evren Yurtesen writes: > : For one thing, why shouldnt FreeBSD able to do that? > > Because the HAL layer is a binary glob. > > : The other thing is that I thought atheros doesnt have firmware and the > : driver handles the regulatory domain settings. Thats why atheros is not > : giving out the source code for their drivers (I think there was such > : problem) > > The driver handles the regulatory domain, but it always uses what is > in the falsh on the part. > > : Anyhow. I am not a pro in this so I better shut up :) But it is possible > : to enable all the channels etc. available in atheros chip from the > : driver. At least StarOS is able to do it so... > > I'm hoping that ath driver author would reply. And I was hoping the "ath driver author" could stay out of this topic because it has been discussed repeatedly. The issue is that the ath driver supports ap operation. As such you are not permitted to change the regulatory domain from what is set in the eeprom to insure compliance with local regulatory agencies. Drivers that let you set the regulatory domain--that I know about--support only station operation so this is not an issue (e.g. you are not normally broadcasting beacons). I have considered ways to support ap and non-ap operation in a single driver and still allow the regulatory domain to be changed but haven't implemented them. Sam