[Madwifi-devel] CHANNEL_HALF / CHANNEL_QUARTER. Changing channel Bandwidth. Help...

[Douglas Diniz]

Hi, i'm working in a project that is using madwifi driver. We need to change
the channel bandwidth, but we saw that there isn't a iwpriv command that do
this. So, we began to code the new comand.
After studing the driver, we saw that CHANNEL_HALF and CHANNEL_QUARTER
should do the thing. I get the last driver on the branch svn, with Hal
0.9.30.13.
To test this feature, i forced the flags in function ath_chan_set. I did
this:

hchan.channelFlags |= CHANNEL_HALF;

But when the driver calls ath_hal_reset, passing this hchan, this error
occurs:

wifi0: ath_chan_set: unable to reset channel 11 (2462 Mhz) flags 0x40c0
'Invalid parameter to function' (HAL status 12)

Note that i'm working in 2,4Ghz and i set the channel 11 in this example.

Somebody knows what i'm doing wrong? What i have to do to set the bandwidth?

Thanks.....

[John Clark]

Post by Douglas Diniz
Hi, i'm working in a project that is using madwifi driver. We need to
change the channel bandwidth, but we saw that there isn't a iwpriv
command that do this. So, we began to code the new comand.
After studing the driver, we saw that CHANNEL_HALF and
CHANNEL_QUARTER should do the thing. I get the last driver on the
branch svn, with Hal 0.9.30.13 <http://0.9.30.13>.
To test this feature, i forced the flags in function ath_chan_set. I
hchan.channelFlags |= CHANNEL_HALF;

A few months ago, when the HAL was released that supported the
half/quarter channel options, I setup a FreeBSD system
to have a look.

It seems to me, that at the moment, these options are only valid for
those devices that can operate in a couple of
'regions'. One region being the 4.9 'Public Safety Band'. I did not see
any region, and I cycled through them all, that
appeared to permit/allow a configuration of narrow bandwidth in the 2.4
region.

I have not followed up with how Madwifi has been modified to select the
narrow bandwith options, even
when a supporting region has been selected.

About a year ago, I got all excited about a Ubiquiti(*) 900 MHz
interface, which alleged to also support the 5/10 MHz
bandwidths, but then read the 'fine print' which seemed to suggest that
only one particular version of 'linux', with
some alternative drivers, was required to really support these options.

What bothers me most about this, is I'd rather just have the HAL itself
as the only dependency on 'binary only'
distributions. I'd rather keep up with versions of Linux that I choose,
and not have to 'wait' for a linux
release from some entity, on their own schedule, because I'm dependent
on their binary driver.

And of course, it goes without say... or maybe not... that the Chip can
be setup to have narrow bandwith options
in the 2.4 band, and not violate some FCC rule of use in the band... but
Atheros has been pretty unsupportive by
not giving those who do have access to the source of the HAL sufficient
documentation, to allow this type of
configuration.

*Someone here did make contact with someone at Ubiquiti, but there was
virtually no follow up in terms of our
technical questions. I tend not to promote companies that don't follow
up on requests for technical info on their
products.

John Clark.

[Douglas Diniz]

I tried all the country codes too :-). Now i have here a 5ghz card. How i
set the narrow bandwidth with this card?
I send a email to Sam and he said me that with this card i can set the 5mhz
and 10mhz bandwidths. Somebody knows how to set?

I tried the country code 842 but the flag CHANNEL_HALF still doesn't works.

When i try iwlist ath0 chan, there is no information about the bandwidths.

[]'s

Post by John Clark

Post by Douglas Diniz
Hi, i'm working in a project that is using madwifi driver. We need to
change the channel bandwidth, but we saw that there isn't a iwpriv
command that do this. So, we began to code the new comand.
After studing the driver, we saw that CHANNEL_HALF and
CHANNEL_QUARTER should do the thing. I get the last driver on the
branch svn, with Hal 0.9.30.13 <http://0.9.30.13>.
To test this feature, i forced the flags in function ath_chan_set. I
hchan.channelFlags |= CHANNEL_HALF;

A few months ago, when the HAL was released that supported the
half/quarter channel options, I setup a FreeBSD system
to have a look.
It seems to me, that at the moment, these options are only valid for
those devices that can operate in a couple of
'regions'. One region being the 4.9 'Public Safety Band'. I did not see
any region, and I cycled through them all, that
appeared to permit/allow a configuration of narrow bandwidth in the 2.4
region.
I have not followed up with how Madwifi has been modified to select the
narrow bandwith options, even
when a supporting region has been selected.
About a year ago, I got all excited about a Ubiquiti(*) 900 MHz
interface, which alleged to also support the 5/10 MHz
bandwidths, but then read the 'fine print' which seemed to suggest that
only one particular version of 'linux', with
some alternative drivers, was required to really support these options.
What bothers me most about this, is I'd rather just have the HAL itself
as the only dependency on 'binary only'
distributions. I'd rather keep up with versions of Linux that I choose,
and not have to 'wait' for a linux
release from some entity, on their own schedule, because I'm dependent
on their binary driver.
And of course, it goes without say... or maybe not... that the Chip can
be setup to have narrow bandwith options
in the 2.4 band, and not violate some FCC rule of use in the band... but
Atheros has been pretty unsupportive by
not giving those who do have access to the source of the HAL sufficient
documentation, to allow this type of
configuration.
*Someone here did make contact with someone at Ubiquiti, but there was
virtually no follow up in terms of our
technical questions. I tend not to promote companies that don't follow
up on requests for technical info on their
products.
John Clark.

[Kea]

Douglas Diniz <dgdiniz <at> gmail.com> writes:

Hi, did you manage to get the channel_quarter working in 11g mode? I'm also
experiencing the same problem.