ath(4) and stealth AP

Tatoku Ogaito <tachatack.fukui-med.ac.jp> writes:

> Hi,
>
> I'm having a problem with the ath(4) device recently.
>
> After the "Big update on ath and net80211",

> http://mail-index.netbsd.org/source-changes/2006
/03/02/0001.html,
> both of my ath on pci (ThinkPad X31) and ath on cardbus
cannot find
> wireless network which provided by stealth Access
Point.
>
> Since wi(4) and iwi(4) can connect the same network at
same time,
> I think it is the problem on ath.
>
> Also, when I change the AP setting to announce its
SSID, ath 
> CAN connect to the network.
>
> Has anybody else noticed any problem like this ?

Not with ath, but with ral AND wpa_supplicant. It's unable
to
find the AP is SSID broadcast is off.

-- 
  Rui Paulo			<rpaulo{NetBSD{,-PT}.org,fnop.net}>

Rui Paulo wrote:
> Tatoku Ogaito <tachatack.fukui-med.ac.jp>
writes:
> 
>> Hi,
>>
>> I'm having a problem with the ath(4) device
recently.
>>
>> After the "Big update on ath and
net80211", 
>> http://mail-index.netbsd.org/source-changes/2006
/03/02/0001.html,
>> both of my ath on pci (ThinkPad X31) and ath on
cardbus cannot find
>> wireless network which provided by stealth Access
Point.
>>
>> Since wi(4) and iwi(4) can connect the same network
at same time,
>> I think it is the problem on ath.
>>
>> Also, when I change the AP setting to announce its
SSID, ath 
>> CAN connect to the network.
>>
>> Has anybody else noticed any problem like this ?
> 
> Not with ath, but with ral AND wpa_supplicant. It's
unable to
> find the AP is SSID broadcast is off.
> 
Is the channel marked for passive scan only?

	Sam

Sam Leffler <samerrno.com> writes:

> Rui Paulo wrote:
>> Tatoku Ogaito <tachatack.fukui-med.ac.jp>
writes:
>>
>>> Hi,
>>>
>>> I'm having a problem with the ath(4) device
recently.
>>>
>>> After the "Big update on ath and
net80211",
>>> http://mail-index.netbsd.org/source-changes/2006
/03/02/0001.html,
>>> both of my ath on pci (ThinkPad X31) and ath on
cardbus cannot find
>>> wireless network which provided by stealth
Access Point.
>>>
>>> Since wi(4) and iwi(4) can connect the same
network at same time,
>>> I think it is the problem on ath.
>>>
>>> Also, when I change the AP setting to announce
its SSID, ath CAN
>>> connect to the network.
>>>
>>> Has anybody else noticed any problem like this
?
>> Not with ath, but with ral AND wpa_supplicant.
It's unable to
>> find the AP is SSID broadcast is off.
>>
> Is the channel marked for passive scan only?

I think it was for active scan (if you mean scan_ssid=1),
but I'm
packaging and I already shut down the box..

-- 
  Rui Paulo			<rpaulo{NetBSD{,-PT}.org,fnop.net}>

Rui Paulo wrote:
> Sam Leffler <samerrno.com> writes:
> 
>> Rui Paulo wrote:
>>> Tatoku Ogaito <tachatack.fukui-med.ac.jp>
writes:
>>>
>>>> Hi,
>>>>
>>>> I'm having a problem with the ath(4)
device recently.
>>>>
>>>> After the "Big update on ath and
net80211",
>>>> http://mail-index.netbsd.org/source-changes/2006
/03/02/0001.html,
>>>> both of my ath on pci (ThinkPad X31) and
ath on cardbus cannot find
>>>> wireless network which provided by stealth
Access Point.
>>>>
>>>> Since wi(4) and iwi(4) can connect the same
network at same time,
>>>> I think it is the problem on ath.
>>>>
>>>> Also, when I change the AP setting to
announce its SSID, ath CAN
>>>> connect to the network.
>>>>
>>>> Has anybody else noticed any problem like
this ?
>>> Not with ath, but with ral AND wpa_supplicant.
It's unable to
>>> find the AP is SSID broadcast is off.
>>>
>> Is the channel marked for passive scan only?
> 
> I think it was for active scan (if you mean
scan_ssid=1), but I'm
> packaging and I already shut down the box..
> 

Channels are marked passive according to local regulatory
constraints. 
When scanning you're not supposed to send a probe req on a
channel setup 
this way unless you know it's being used for 802.11
communication.  The 
code currently in cvs will listen on such channels but when
the ap is 
not broadcasting it's ssid this is insufficient.

So was the ap setup on a channel marked for passive scan
only?  In 
freebsd you can tell by doing

ifconfig ath0 list chan

and channels marked passive have a '*'.

	Sam

On Wed, 19 Apr 2006 17:50:37 +0100, Rui Paulo <rpaulofnop.net> wrote:

>
> > Is the channel marked for passive scan only?
> 
> I think it was for active scan (if you mean
scan_ssid=1), but I'm
> packaging and I already shut down the box..
> 
I can test tonight with an ath interface compiled from
yesterday's
source.  I don't know the US regulatory constraints -- what
should I
expect to happen?

		--Steven M. Bellovin, http://www.cs.columbi
a.edu/~smb

Hi. 

>> In Message <44466BD8.6010103errno.com>
 at Wed, 19 Apr 2006 09:56:56 -0700
 Sam Leffler <samerrno.com> wrote:

 > Channels are marked passive according to local
regulatory constraints. 
 > When scanning you're not supposed to send a probe req
on a channel setup 
 > this way unless you know it's being used for 802.11
communication.  The 
 > code currently in cvs will listen on such channels but
when the ap is 
 > not broadcasting it's ssid this is insufficient.
 > 
 > So was the ap setup on a channel marked for passive
scan only?  In 
 > freebsd you can tell by doing
 > 
 > ifconfig ath0 list chan
 > 
 > and channels marked passive have a '*'.


Unfortunately the ifconfig bundled with NetBSD does not
support
"list command".

[tamp]/tmp% /sbin/ifconfig ath0 list chan
ifconfig: list: bad value

So I stole list_channels function (and required function)
from FreeBSD's
ifconfig, and I got the following results.

[tamp]/usr/current/src/sbin/ifconfig# ./ifconfig ath0
ath0:
flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu
1500
Channel   1 : 2412* Mhz 11g          Channel  10 : 2457* Mhz
11g          
Channel   2 : 2417* Mhz 11g          Channel  11 : 2462* Mhz
11g          
Channel   3 : 2422* Mhz 11g          Channel  12 : 2467* Mhz
11g          
Channel   4 : 2427* Mhz 11g          Channel  13 : 2472* Mhz
11g          
Channel   5 : 2432* Mhz 11g          Channel  14 : 2484* Mhz
11b          
Channel   6 : 2437* Mhz 11g          Channel  34 : 5170* Mhz
11a          
Channel   7 : 2442* Mhz 11g          Channel  38 : 5190* Mhz
11a          
Channel   8 : 2447* Mhz 11g          Channel  42 : 5210* Mhz
11a          
Channel   9 : 2452* Mhz 11g          Channel  46 : 5230* Mhz
11a          
....


What shall/can I do next ?

Thanks

Tacha

Tatoku Ogaito wrote:
> Hi. 
> 
>>> In Message <44466BD8.6010103errno.com>
>  at Wed, 19 Apr 2006 09:56:56 -0700
>  Sam Leffler <samerrno.com> wrote:
> 
>  > Channels are marked passive according to local
regulatory constraints. 
>  > When scanning you're not supposed to send a
probe req on a channel setup 
>  > this way unless you know it's being used for
802.11 communication.  The 
>  > code currently in cvs will listen on such
channels but when the ap is 
>  > not broadcasting it's ssid this is insufficient.
>  > 
>  > So was the ap setup on a channel marked for
passive scan only?  In 
>  > freebsd you can tell by doing
>  > 
>  > ifconfig ath0 list chan
>  > 
>  > and channels marked passive have a '*'.
> 
> 
> Unfortunately the ifconfig bundled with NetBSD does not
support
> "list command".
> 
> [tamp]/tmp% /sbin/ifconfig ath0 list chan
> ifconfig: list: bad value
> 
> So I stole list_channels function (and required
function) from FreeBSD's
> ifconfig, and I got the following results.
> 
> [tamp]/usr/current/src/sbin/ifconfig# ./ifconfig ath0
> ath0:
flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu
1500
> Channel   1 : 2412* Mhz 11g          Channel  10 :
2457* Mhz 11g          
> Channel   2 : 2417* Mhz 11g          Channel  11 :
2462* Mhz 11g          
> Channel   3 : 2422* Mhz 11g          Channel  12 :
2467* Mhz 11g          
> Channel   4 : 2427* Mhz 11g          Channel  13 :
2472* Mhz 11g          
> Channel   5 : 2432* Mhz 11g          Channel  14 :
2484* Mhz 11b          
> Channel   6 : 2437* Mhz 11g          Channel  34 :
5170* Mhz 11a          
> Channel   7 : 2442* Mhz 11g          Channel  38 :
5190* Mhz 11a          
> Channel   8 : 2447* Mhz 11g          Channel  42 :
5210* Mhz 11a          
> Channel   9 : 2452* Mhz 11g          Channel  46 :
5230* Mhz 11a          
> ....
> 
> 
> What shall/can I do next ?

I have changes in freebsd to dtrt.  I started to import them
yesterday 
but netbsd locked up on my dell 600m when I brought up an
ath interface 
so I set it aside.  This is a GENERIC_LAPTOP kernel from cvs
of 
yesterday morning w/o any mods fwiw.

	Sam

Hi.

I updated my ThinkPad X31 to current as of 30 Apr, 2006.

In my case, bringing up an ath interface does not lock up
my system.  Although the ath cannot find stealth AP, 
it works w/ normal AP.

Just FYI.

Tacha

Hello again.

>> In Message <4447B267.70201errno.com>
 at Thu, 20 Apr 2006 09:10:15 -0700
 Sam Leffler <samerrno.com> wrote:

 > I have changes in freebsd to dtrt.  I started to
import them yesterday 

I digged a cvsweb.freebsd.org and found that you fixed the
probelm in
http://freebsd.rambler.ru/bsdmail/cvs-src_2006/msg03
210.html

Relevant diffs for our tree are as follows and this works
for me well.
May I commit them ?

TIA

Tacha

Index: src/sys/net80211/ieee80211_input.c
============================================================
=======
RCS file:
/cvsroot/NetBSD-cvs/main/src/sys/net80211/ieee80211_input.c,
v
Prereq: 1.59
diff -u -p -r1.59 ieee80211_input.c
 -2092,6
+2092,18  ieee80211_recv_mgmt(struct ieee80211com 
 		 * If scanning, just pass information to the scan module.
 		 */
 		if (ic->ic_flags & IEEE80211_F_SCAN) {
+			if (ic->ic_flags_ext & IEEE80211_FEXT_PROBECHAN)
{
+				/*
+				 * Actively scanning a channel marked passive;
+				 * send a probe request now that we know there
+				 * is 802.11 traffic present.
+				 *
+				 * XXX check if the beacon we recv'd gives
+				 * us what we need and suppress the probe req
+				 */
+				ieee80211_probe_curchan(ic, 1);
+				ic->ic_flags_ext &= ~IEEE80211_FEXT_PROBECHAN;
+			}
 			ieee80211_add_scan(ic, &scan, wh,
 				subtype, rssi, rstamp);
 			return;


Index: src/sys/net80211/ieee80211_node.c
============================================================
=======
RCS file:
/cvsroot/NetBSD-cvs/main/src/sys/net80211/ieee80211_node.c,v
Prereq: 1.56
diff -u -p -r1.56 ieee80211_node.c
 -340,6
+340,7  ieee80211_next_scan(struct ieee80211com 
 	 * flushing anything queued in the driver and below.
 	 */
 	ic->ic_mgt_timer = 0;
+	ic->ic_flags_ext &= ~IEEE80211_FEXT_PROBECHAN;
 
 	chan = ic->ic_curchan;
 	do {
 -366,6
+367,31  ieee80211_next_scan(struct ieee80211com 
 	return 0;
 }
 
+/*
+ * Probe the curent channel, if allowed, while scanning.
+ * If the channel is not marked passive-only then send
+ * a probe request immediately.  Otherwise mark state and
+ * listen for beacons on the channel; if we receive
something
+ * then we'll transmit a probe request.
+ */
+void
+ieee80211_probe_curchan(struct ieee80211com *ic, int force)
+{
+	struct ifnet *ifp = ic->ic_ifp;
+
+	if ((ic->ic_curchan->ic_flags &
IEEE80211_CHAN_PASSIVE) == 0 || force) {
+		/*
+		 * XXX send both broadcast+directed probe request
+		 */
+		ieee80211_send_probereq(ic->ic_bss,
+			ic->ic_myaddr, ifp->if_broadcastaddr,
+			ifp->if_broadcastaddr,
+			ic->ic_des_essid, ic->ic_des_esslen,
+			ic->ic_opt_ie, ic->ic_opt_ie_len);
+	} else
+		ic->ic_flags_ext |= IEEE80211_FEXT_PROBECHAN;
+}
+
 static __inline void
 copy_bss(struct ieee80211_node *nbss, const struct
ieee80211_node *obss)
 {
 -610,6
+636,7  ieee80211_cancel_scan(struct ieee80211co
 		(ic->ic_flags & IEEE80211_F_ASCAN) ? 
"active" : "passive");
 
 	ic->ic_flags &= ~(IEEE80211_F_SCAN |
IEEE80211_F_ASCAN);
+	ic->ic_flags_ext &= ~IEEE80211_FEXT_PROBECHAN;
 }
 
 /*


Index: src/sys/net80211/ieee80211_node.h
============================================================
=======
RCS file:
/cvsroot/NetBSD-cvs/main/src/sys/net80211/ieee80211_node.h,v
Prereq: 1.21
diff -u -p -r1.21 ieee80211_node.h
 -191,6
+191,7  void	ieee80211_node_unauthorize(struct i
 
 void	ieee80211_begin_scan(struct ieee80211com *, int);
 int	ieee80211_next_scan(struct ieee80211com *);
+void	ieee80211_probe_curchan(struct ieee80211com *, int);
 void	ieee80211_create_ibss(struct ieee80211com*, struct
ieee80211_channel *);
 void	ieee80211_reset_bss(struct ieee80211com *);
 void	ieee80211_cancel_scan(struct ieee80211com *);


Index: src/sys/net80211/ieee80211_proto.c
============================================================
=======
RCS file:
/cvsroot/NetBSD-cvs/main/src/sys/net80211/ieee80211_proto.c,
v
Prereq: 1.24
diff -u -p -r1.24 ieee80211_proto.c
 -991,19
+991,11  ieee80211_newstate(struct ieee80211com *
 			break;
 		case IEEE80211_S_SCAN:
 			/*
-			 * Scan next. If doing an active scan and the
-			 * channel is not marked passive-only then send
-			 * a probe request.  Otherwise just listen for
-			 * beacons on the channel.
+			 * Scan next. If doing an active scan probe
+			 * for the requested ap (if any).
 			 */
-			if ((ic->ic_flags & IEEE80211_F_ASCAN) &&
-			    (ic->ic_curchan->ic_flags &
IEEE80211_CHAN_PASSIVE) == 0) {
-				ieee80211_send_probereq(ni,
-					ic->ic_myaddr, ifp->if_broadcastaddr,
-					ifp->if_broadcastaddr,
-					ic->ic_des_essid, ic->ic_des_esslen,
-					ic->ic_opt_ie, ic->ic_opt_ie_len);
-			}
+			if (ic->ic_flags & IEEE80211_F_ASCAN)
+				ieee80211_probe_curchan(ic, 0);
 			break;
 		case IEEE80211_S_RUN:
 			/* beacon miss */


Index: src/sys/net80211/ieee80211_var.h
============================================================
=======
RCS file:
/cvsroot/NetBSD-cvs/main/src/sys/net80211/ieee80211_var.h,v
Prereq: 1.24
diff -u -p -r1.24 ieee80211_var.h
 -256,6
+256,7  extern struct ieee80211com_head ieee8021
 #define	IEEE80211_FEXT_WDS	0x00000001	/* CONF: 4 addr
allowed */
 /* 0x00000006 reserved */
 #define	IEEE80211_FEXT_BGSCAN	0x00000008	/* STATUS: enable
full bgscan completion */
+#define	IEEE80211_FEXT_PROBECHAN 0x00020000	/* CONF: probe
passive channel*/
 
 /* ic_caps */
 #define	IEEE80211_C_WEP		0x00000001	/* CAPABILITY: WEP
available */

Tatoku Ogaito wrote:
> I digged a cvsweb.freebsd.org and found that you fixed
the probelm in
> http://freebsd.rambler.ru/bsdmail/cvs-src_2006/msg03
210.html
> 
> Relevant diffs for our tree are as follows and this
works for me well.
> May I commit them ?

I overlooked the beginnings of this thread in April, so just
to check
if I understand the issue correctly -

This is a change that adds the ability to associate with a
stealth AP
when the channel used is declared passive-only in the local
regulatory
domain?

And the reason I have never had a problem with my ath
associating with
my stealth AP on chan 11 must be that chan 11 is not
passive-only in
the US (or in my part of the US)?

Just checking to make sure I'm not missing something.
Thanks!

-Chap