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
does:

while(1) {
  iwpriv eth0 monitor 2 $chan
  usleep(interval)
  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
issue

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]