>Number:         18835
>Category:       kern
>Synopsis:       in IBSS mode, wi(4) filters frames using the wrong BSSID
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Oct 27 20:21:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     dyoung@netbsd.org
>Release:        NetBSD 1.6I
>Organization:
OJC Technologies

>Environment:
System: NetBSD anoncuw 1.6J NetBSD 1.6J (NET4501) #1: Thu Oct 24 02:54:59 CDT 2002
Architecture: i386
Machine: i386

wi0 at pcmcia1 function 0: INTERSIL, HFA384x/IEEE, Version 01.02                
wi0: 802.11 address 00:02:6f:01:c7:b1                                           
wi0: using RF:PRISM2.5 MAC:ISL3873B(PCMCIA)                                     
wi0: Intersil Firmware: Primary (1.0.5), Station (1.2.0)                        
wi0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps                                

>Description:
	The BSSID in the wi(4) driver gets out of sync with the firmware's
	BSSID. When this happens, the driver throws away frames in
	ieee80211_input because they carry the "wrong" BSSID.

	Details:

	wi(4) relies on the Link-Stat notification to alert it that the
	BSSID has changed, however, Prism cards do not produce a
	Link-Stat notification in the event of every BSSID change. If
	the BSSID changes because of a BSSID merge, for example, no
	Link-Stat indication is sent.

>How-To-Repeat:
	I am able to demonstrate a BSSID merge with three stations. Call
	the three stations IMC, PM, and SM. IMC and SM cannot "hear" each
	other. IMC and PM can hear each other. PM and SM can hear each
	other. PM and SM form an IBSS independently of IMC, who can only
	be heard intermittently. IMC forms an IBSS independently of PM
	and SM. Then PM and and IMC hear each other, and the IBSS's merge.
	At this point, PM will not communicate with any station.
>Fix:
	If you exempt IBSS packets from the BSSID check in
	net/if_ieee80211subr.c, they will flow again. That is what I do:

***************
*** 274,280 ****
                                bssid = wh->i_addr3;
                        else
                                bssid = wh->i_addr1;
!                       if (!IEEE80211_ADDR_EQ(bssid, ic->ic_bss.ni_bssid) &&
                            !IEEE80211_ADDR_EQ(bssid, ifp->if_broadcastaddr)) {
                                /* not interested in */
                                DPRINTF2(("ieee80211_input: other bss %s\n",
--- 274,281 ----
                                bssid = wh->i_addr3;
                        else
                                bssid = wh->i_addr1;
!                       if (ic->ic_opmode != IEEE80211_M_IBSS &&
!                           !IEEE80211_ADDR_EQ(bssid, ic->ic_bss.ni_bssid) &&
                            !IEEE80211_ADDR_EQ(bssid, ifp->if_broadcastaddr)) {
                                /* not interested in */
                                DPRINTF2(("ieee80211_input: other bss %s\n",



	But that does not change the fact that ifconfig tells the wrong
	BSSID. Also, BPF still taps transmitted packets which carry the
	wrong BSSID, and that is confusing.  (Fortunately, the firmware
	writes the correct BSSID into transmitted packets before they
	are sent.)

	Outside of promiscuous mode, the BSSID can be tracked by
	reading it from the BSSID of packets handed up by the firmware.
	In promiscuous mode, all packets are handed up, so it is more
	difficult to track the BSSID, however, unicast packets addressed
	to the station will (usually) carry the right BSSID. 

	On Prism, the most reliable indication of BSSID is the Current BSSID
	RID, but it is probably expensive to read and re-read that RID all
	the time.

	I don't have any other suggestions right now.
>Release-Note:
>Audit-Trail:
>Unformatted: