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

[David Gibson]

On Sun, Aug 11, 2002 at 03:47:12PM +1000, Patrick Cole wrote:
> 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).

The MAC is the same.  Just because it's possible doesn't mean
manufacturers will do it, of course.

> 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).  

Urg, yes.  I realised my mistake with 0.12* a few days ago.  The
locking scheme I was attempting to use cannot work :-(.

> 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?

I don't know much about the monitor mode patch.  I'll know more once I
actually have time to intergrate it.

> 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?

No, not really.  I've seen some reports of this, and so far I'm a bit
mystified.

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

That might be it.  If the interrupt handler ran while the card was
resetting for the channel change this might happen.  But the locks
should precent that.

> 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.
> 

-- 
David Gibson			| For every complex problem there is a
david at gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson