Updated PROMISC patch

[Gerald Britton]

On Sun, Nov 24, 2002 at 07:26:32AM +0200, Jouni Malinen wrote:
> On Thu, Nov 21, 2002 at 10:39:55PM -0500, Gerald Britton wrote:
> 
> > Updated for the current hostap CVS.  This patch does not quiet the RX error
> > messages, I'm not sure what the best thing to do with them really is.
> 
> Thanks for the patch. I merged it into the CVS version with couple of
> changes (restore correct setting after card reset and initialize queue
> structure a bit earlier).

Cool.  I've been seeing a few weird problems which result in a card reset
actually.  I think it involves something which needs doing (but isn't being
done) in a suspend/resume cycle on my MiniPCI card.  It usually ends up
being similar to this when it happens:

wlan0: hfa384x_setup_bap - timeout after
wlan0: hfa384x_set_rid (rid=fc00, len=2) - failed - res=-110
wlan0: hfa384x_setup_bap - timeout before
wlan0: hfa384x_set_rid (rid=fc02, len=34) - failed - res=-110
...

And eventually results in a card reset.  It always seems to happen when I
resume and then run the redhat 8 ifup script to bring up the card in
managed mode with a specific essid and wep keys.  Bringing up the card
without the wep keys never has the problem.  I will run the ifup script
once, It appears to succeed but the DHCP requests don't appear to be going
out (or atleast, I'm not getting replies).  The DHCP fails and I retry the
script, then I get the bap errors.  It isn't deterministic enough to be
able to fully debug though unfortunately.

I realized that with my new suspend/resume code, i'm not doing a cor_sreset
after a resume, but adding this into the resume cycle does not appear to
make a difference in behavior.

... One other problem I noticed with monitor mode (and other modes too)
It's a "bad thing" to move to managed mode, set an empty ssid, then move
back to another code.  The firmware becomes quite lost.  Perhaps some
safety checking ought to be added for this.

> Have you tested promiscuous mode both in Master and Managed mode? I
> think that in Master mode (i.e., Host AP mode) the AP is already
> receiving all data frames with its own BSSID and promiscuous mode would
> not be needed. Is it clear that enabling it does not cause possible
> problems?

Yeah, it's only really relevant to Managed mode.  It might make sense to do
something a little different in Master mode when bridging packets to other
stations.  IIRC, the driver bridges packets and doesn't even send them up
to the rest of the network layer.  In promisc mode it should send these up
higher as well as bridging them out I suspect.  When using the upper
network layers to do bridging I'm not sure what the correct behavior ought
to be since it is effectively always promiscuous.  We're definately falling
into a trap of the kernel viewing everything from an 802.3 view of the
world.

				-- Gerald