From owner-freebsd-current@FreeBSD.ORG Wed Oct 6 10:46:56 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 D78C316A4CE for ; Wed, 6 Oct 2004 10:46:56 +0000 (GMT) Received: from supermail.ispro.net.tr (supermail.ispro.net.tr [217.21.68.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69F4E43D31 for ; Wed, 6 Oct 2004 10:46:55 +0000 (GMT) (envelope-from yurtesen-dated-1097923612.d7c4dd@ispro.net.tr) Received: (qmail 6288 invoked by uid 89); 6 Oct 2004 10:46:52 -0000 Received: from [192.168.0.34] (perpetual.yok.utu.fi [130.232.138.155]) by supermail.ispro.net.tr (tmda-ofmipd) with ESMTP; Wed, 06 Oct 2004 13:46:44 +0300 (EEST) Message-ID: <416459A1.7020208@ispro.net.tr> Date: Wed, 06 Oct 2004 13:46:25 -0700 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Leffler References: <4161C4D8.4040308@ispro.net.tr> <20041005.100800.111987973.imp@bsdimp.com> <200410050953.58739.sam@errno.com> In-Reply-To: <200410050953.58739.sam@errno.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Delivery-Agent: TMDA/1.0.2 (Bold Forbes) From: Evren Yurtesen X-Primary-Address: yurtesen@ispro.net.tr cc: freebsd-current@freebsd.org cc: marcos@thepacific.net 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: Wed, 06 Oct 2004 10:46:57 -0000 Sam Leffler wrote: > 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 That can't be true. There is at least StarOS product which can work as an AP and can support every channel. Even the ones which is not in any regulatory domain (I think?!) Actually as a matter of fact I have few Senao APs which has Atheros minipci cards inside and they also allow regulatory domain setting so that some channels become activated and some are disabled etc. depending on the domain you choose. http://www.staros.com/downloads.php ------------ New: Special country code '##' can be used to unlock all channels supported by the Atheros hardware (2312-2732, 4920-6100). It is up to the end user to ensure they stay within their region's regulatory channel ranges. ------------ Evren