Re: [Madwifi-devel] Proposal to create extra debug/audit country codes to access useful sets of channels

[K <kug...@ku...>]

Fixing the madwifi-old-openhal driver  is a bit tricky:

The old madwifi-old-openhal drivers with CHAN_DEBUG flag let's me use:

   * Channel 1 to 26 in 11b/g mode
   * Channel 27 to 220 in 11a mode

However, the atheros tranceiver supports 276 distinct channels:

   * Channel -12 to 26 in 11b/g mode 2312 MHz to 2732 MHz - 39 channels
   * Channel -16 to 220 in 11b mode 4920 MHz to 6100 MHz - 237 channels

Now the problems:

   * In the set frequency ioctl, the frequency is first converted to
an ieee channel number and the ieee80211 doesn't support negative  
frequency.

   * The overlapping channels makes the conversion in mhz2ieee  
destructive since
it only returns the channel number.

   * The prism header structure uses an unsigned int for channel in  
ieee format.

   * Channel 0 is ignored because it has a special meaning (auto/no  
channel prefered.)

I thought of two ways to get around the above problems:

1/ Stop using ieee channels internally

The frequency will fit nicely in the prism header and can be picked up  
by kismet
and other tools by testing if the channel is above 255.

2/ ieee channel kludge

Move 11b/g channels -12 to 0 to an offset in that u_int keyspace.
Move 11a channels -16 to 26 to another offset.
Increase channel max appropriately...

I prefer the first solution. ieee channels should only be a hint for  
end users.
It fits nicely in the existing data structures.

The second solution is just nasty.

What do you think?

On 05/03/2008, at 1:19 PM, K wrote:
> I am working on a set of patches for madwifi-old-openhal.
>
> The purpose of the patch is to create four new debug country codes
> that enables the following sets of channels:
>
> 	1/ all possible legal channels
> 	2/ all available channels
> 	3/ all restricted channels
> 	4/ all possible channels
>
> The "legal" channels set contains 70 channels that are already  
> accessible by setting the country code parameter repeatedly with the  
> madwifi 0.9.4 driver:
>
> 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,20,25,30,34,35,36,38,40,42,44,45,46,48,50,52,55,56,58,60,64,65,70,75,80,85,90,95,100,104,108,112,116,120,124,128,132,136,140,149,152,153,157,160,161,165,183,184,185,187,188,189,192,196
>
> The "accessible" channels set contains 100 channels which include  
> the above channels plus thirty others that are
> accessible by setting the country code parameter to 0x1ff in madwifi  
> 0.9.4:
>
> 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,20,24,25,26,28,30,32,34,35,36,38,40,42,44,45,46,48,50,52,54,55,56,58,60,62,64,65,66,68,70,72,74,75,76,78,80,82,84,85,86,88,90,92,94,95,96,98,100,102,104,106,108,110,112,114,116,118,120,122,124,126,128,130,132,134,136,140,149,152,153,157,160,161,165,183,184,185,187,188,189,192,196,237
>
> 220 channels are also accessible by using madwifi-old-openhal svn  
> branch and defining CHAN_DEBUG to 1 in openhal/opt_ah.h:
>
> 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220
>
> The restricted set would be the difference between all possible  
> channels and the legal channels.
> the set of channels should be defined by frequency because:
>
> The atheros chipset supports channel 2312 to 2732 MHZ and from 4920  
> to 6100 MHz
> so I have to be careful with these particular cases:
>
> 	a/ Negative 11b/g channels: -12 to 0 (2312 to 2372 MHz)
> 	b/ Negative 11a channels: -16 to 0 (4920 to 5000 MHz)
> 	c/ 11a channels overlap 11b/g channels -12 to 26 (4920 to 5130 MHz)
>
> Probably I'll have to prepare some patches for kismet as well to add  
> a client column to display
> frequencies or support negative channels and type (11a or b/g)
>
> Now, why?
>
> There are several scenarios for which the above features would come  
> in handy:
>
> 1/ Detecting "undetectable" Rogue Access Point
>
> There will be no way to detect the access point using the current  
> drivers using kismet if a disgruntled employee or
> a third party sets up one of these mikrotik eval boards or a PC with  
> an atheros card and set it to use one of the
> restricted channel to set up a  rogue access point.
>
> Note: Mikrotik and Starsomething, sell some obfuscated linux router  
> distribution that lets you set up an access point using any
> of the possible channels.]
>
> 2/ Regulatory compliance
>
> In Indonesia for example, all 5GHz channels are restricted and you  
> will need to obtain a government license. Using the current
> drivers, we can set an atheros card to 100 different channels by  
> setting the country code appropriately  but there is no easy way
> to perform an audit or monitor these channels using kismet without  
> unloading ath_pci and setting the country code repeatedly .
>
>
> Before I continue with my little project, I would like to ask a few  
> questions:
>
> Is it possible to patch the madwifi 0.9.4 code base or are some of  
> the restrictions hardcoded in the binary hal?
>
> How stable is the new ar5k trunk? Should I work on that instead of  
> the madwifi-old-openhal?
>