orinoco_cs, RF monitor patch [Was Re: Orinoco and 5Ghz cards?]

[Patrick Cole]

Sun, Aug 11, 2002 at 10:31:52AM +1000, David Gibson wrote:

> On Fri, Aug 09, 2002 at 11:56:03AM -0500, Jamin W. Collins wrote:
> > Has anyone had success with the 5Ghz cards and the Orinoco driver?  I'm
> > thinking of upgrading my wireless setup to 5Ghz in an attempt to get
> > better throughput (mainly by moving to a less used range), but would am
> > having difficulty finding any clear indication of whether there is support
> > for the hardware under Linux.
> 
> As far as I know the 802.11a cards use a different chipset, so the
> orinoco driver won't support them.

One thing that I have been asking myself is if the 802.11a cards still transmit 
802.11 standard frames or a modified version specific to revision a, and if they 
are the same, it should theoretically be possible to make a card that will process 
802.11a and 802.11b with a minimum of cost as the MAC would not need to be changed,
only the radio to be able to cope with two different frequencies and two antennae 
(one for 2.4ghz and one for 5ghz, or maybe two wideband sector antennae).

To david specifically, though: 

After a long long time of using the Lucent binary driver without any
hitches I decided to try out your driver again to see if it was a
happening thing these days, and to my surprise it seems to be working
fine. My real motivation, however, was the RF monitor patches that are
floating around for it.  The version of your driver I have running is
0.11b, as 0.12*, etc totally barf (machine lockups, and all sorts of
weird things).  

Anyhow, I'm having trouble getting the RF monitor patch working
properly. One thing that initially seemed to be causing problems was
that when in monitor mode the driver would still try and transmit
packets which seemed to cause the whole thing to go beserk. I fixed that
by returning 1 from the orinoco_xmit function if we were in monitor
mode, not sure if that is the best thing to do as it seemed as if
returning 1 just meant the kernel kept trying to transmit the packet
instead of dropping it. Perhaps returning 0 is the best thing to do, as
that will fool the kernel into thinking the packet was actually transmitted?

Doing that fixed it going beserk for no reason, however, it still goes
beserk after a few packets have been received, and I'm trying to work
out why. By beserk, I mean when the driver hits the interrupt handler
for an RX, it thinks that the card has been removed.  Any idea why this
would happen?

Could it be a race thing with the hopper program that runs and does an 
ioctl every n milliseconds to change the monitoring channel?

Aug  9 18:28:38 jaded kernel: eth1: <- orinoco_ioctl()
Aug  9 18:28:38 jaded kernel: eth1: Bad CRC on Rx. Frame dropped.
Aug  9 18:28:38 jaded kernel: orinoco_interrupt(): card removed
Aug  9 18:28:38 jaded kernel: hermes @ IO 0x100: Card removed while waiting for command completion.
Aug  9 18:28:38 jaded kernel: hermes @ IO 0x100: Card removed while waiting for command completion.

If I am interpreting that debug output correctly? then the orinoco_ioctl 
had been called and then an interrupt occurred while inside the ioctl.

And then it proceeds to continually think the card is removed. 

Any help would be appreciated.  Will keep hacking however.

-- 
Patrick Cole <Patrick.Cole at anu.edu.au>
Programmer, the John Curtin School of Medical Research, ANU 
PGP 1024R/60D74C7D C8E0BC7969BE7899AA0FEB16F84BFE5A