Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Ian Goldberg (iancypherpunks.ca)
Date: Fri Jun 28 2002 - 16:46:08 CDT
On Fri, 2002-06-28 at 12:07, Ian Goldberg wrote:
> I had done the equivalent thing with the 0.3.3 version of your driver
> and the orinoco 0.11 patch, and found that it did work, but only for
> about a minute. Then it would stop receiving packets for some reason.
OK, I've started tracking down this problem.
The packet flow stoppage (hereinafter, "badness") happens more often if
orinono_hopper's interval setting is lower. [orinoco_hopper basically
iwpriv eth0 monitor 2 $chan
chan = (chan % numchans) + 1
My guess is that the badness happens if the iwpriv monitor ioctl happens
at just the wrong time. Maybe a locking issue? I notice that the
monitor call does orinoco_lock_user() while the interrupt handler for
packet reception does orinoco_lock(). [This makes sense, of course.]
These two routines do the right thing if invoked concurrently?
I also note that the iwpriv monitor ioctl does quite a bit of work,
including turning on RFMonitor mode, *even* if it was on before, and
we're just changing the channel.
I think if I get a bit of time this weekend, I'll do something like make
"iwpriv eth0 monitor 3 x" set the monitor channel to x by calling
hermes_write_wordrec(hw, USER_BAP, HERMES_RID_CNF_CHANNEL, channel);
and not doing a whole lot of the other work. [I guess I'll make sure
that monitor mode is in fact on in the first place.] Then
orinoco_hopper could do "iwpriv eth0 monitor 2 1" to begin with, and
then a bunch of "iwpric eth0 monitor 3 x"'s.
If the problem is that the *firmware/chipset* has sensitive timing