ath: a few questions

[Sam Leffler]

Kris Maglione wrote:
> Bruce M Simpson wrote:
> 
>> On Tue, Jan 18, 2005 at 09:40:21AM -0500, Kris Maglione wrote:
>>  
>>
>>> Second, according to CVS, hw.ath.outdoors was made tunable a year 
>>> ago, but sysctl says it's readonly when I try to change it. It's 
>>> stuck at 1, which seems to be a possible explanation for why it's 
>>> indoor use sucks so badly compared to the windows driver, especially 
>>> through walls.
>>>   
>>
>>
>> I'm running 5.3-STABLE as of last Wednesday and do not see this sysctl.
>>
>> Please give version information (uname -a) when posting this kind of 
>> query,
>> as it's next to impossible to give useful advice otherwise.
>>  
>>
> Sorry about that. No uname -a, but it's the 5-STABLE from about a few 
> days ago. The kernel config file is actually the (minimally modified) 
> FreesBIE config file from a few months ago, but why is a long story.

The setting is a read-only sysctl because once the module is loaded 
changing it has no effect.  Set it before you kldload the module or in 
your hints file if you want it different than the default.

> 
>> You should be able to 'tcpdump -i ath0 -y ieee802_11' to verify that you
>> can capture 802.11 packets straight off the card.
>>  
>>
> I have done that, and I have used kismet. My problem with kismet turned 
> out to just be a wierd way that kismet reports things.

kismet has been broken for a while.  It used to work but something broke 
it and I've had no time to dig (it's painful to debug as it's a 
multi-process app written in C++ and makes heavy use of STL so 
inspecting data structures is a pain).

> 
>> I haven't experienced the problems with walls you mention.
>>  
>>
> I use 11a. Like I said, there is no problem with windows. I forgot to 
> mention that windows also reports higher data rates (54Mbps when FreeBSD 
> reports 18Mbps, but I don't trust that, really. It reports up to 108Mbps 
> in turbo, but the AP only supports 76). Also, through a wall or two, 
> windows reports high signal, but I can't test that in freebsd, since the 
> driver doesn't seem to support it.

You've provided zero useful information so I've been ignoring your 
winging.  Regardless you are comparing apples and oranges.  The NDIS 
driver supports several hardware features that the open source driver 
does not.  At least one of those, XR mode, can be a significant factor 
in the extended range performance you see.  The other critical factor is 
that the NDIS driver has an excellent transmit rate control algorithm 
while the onoe rate control code is little more than a noop.  I've 
solicited better algorithms for almost 3 years but noone's stepped up. 
I cannot do one because I am familiar with several proprietary 
algorithms and so "tainted".

> 
>>  
>>
>>> Last, dstumbler doesn't work. It complains, something about ioctl. I 
>>> don't feel like booting the laptop to get the exact messate at the 
>>> moment, but I will later.
>>>   
>>
>>
>> dstumbler is for PRISM2 cards only.
>>  
>>
> thanks, I had a feeling that it was, but I had to ask.

dstumbler should work with ath however I don't find it (or kismet) 
especially useful.

	Sam