linux-kernel - Re: [PATCH] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 31 Oct 2006 09:26:32 -0500
From:	"Holden Karau" <holden@...scanfly.ca>
To:	"Uli Kunitz" <kune@...ne-taler.de>
Cc:	"Johannes Berg" <johannes@...solutions.net>,
	"Daniel Drake" <dsd@...too.org>, zd1211-devs@...ts.sourceforge.net,
	linville@...driver.com, netdev <netdev@...r.kernel.org>,
	linux-kernel@...r.kernel.org, holdenk@...dros.com
Subject: Re: [PATCH] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11

The patch was based off the FIXME comment in the code [which suggested
replacing 11 with the boundary for the regulatory domain]. I'll take a
look at the vendors driver and see about modifying the patch to fit
more with its logic or just limmiting it to the FCC regulatory domain.

On 10/30/06, Uli Kunitz <kune@...ne-taler.de> wrote:
> Johannes Berg wrote:
> >> I'm not so sure about this. This patching might be US-specific and we
> >> cannot simply apply the setting for top channel of another domain
> >> instead of channel 11. One option would be to set the value only under
> >> the US regulatory domain.
> >
> > ??
> > What the patch does is replace the top channel which is hardcoded to 11
> > by the top channel given by the current regulatory domain. How can that
> > be wrong? Except that you may want to init the regulatory domain from
> > the EEPROM but I'm not sure how the ieee80211 code works wrt. that.
> >
> > johannes
>
> The problem is not so much that I don't trust the geo code, but whether
> setting the register to that band-edge value for a higher channel is
> the right thing to do. It looks like that this is a hack for FFC
> compliance. Therefore I suggest to patch CR128 only
> for the US regulatory domain.
>
> Here is the code from the GPL vendor driver (zdhw.c):
>
>     if (pObj->HWFeature & BIT_21)  //6321 for FCC regulation, enabled HWFeature 6M band edge bit (for AL2230, AL2230S)
>      {
>          if (ChannelNo == 1 || ChannelNo == 11)  //MARK_003, band edge, these may depend on PCB layout
>          {
>              pObj->SetReg(reg, ZD_CR128, 0x12);
>              pObj->SetReg(reg, ZD_CR129, 0x12);
>              pObj->SetReg(reg, ZD_CR130, 0x10);
>              pObj->SetReg(reg, ZD_CR47, 0x1E);
>          }
>          else //(ChannelNo 2 ~ 10, 12 ~ 14)
>          {
>              pObj->SetReg(reg, ZD_CR128, 0x14);
>              pObj->SetReg(reg, ZD_CR129, 0x12);
>              pObj->SetReg(reg, ZD_CR130, 0x10);
>              pObj->SetReg(reg, ZD_CR47, 0x1E);
>          }
>      }
>
> The patch from Holden would set ZD_CR128 to 0x12 for the highest channel,
> which would not reflect the logic of the vendor driver.
>
> Kind regards,
>
> Uli
>
> --
> Uli Kunitz (kune@...ne-taler.de)
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Cell: 613-276-1645
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/