Re: athn(4): hidenwid?

2020-07-20 Thread Mogens Jensen
‐‐‐ Original Message ‐‐‐
On Thursday, July 16, 2020 9:33 AM, Stefan Sperling  wrote:

> Nevermind, I have found the problem.

Thanks.

BTW some time ago I watched your EuroBSDcon 2017 talk on device driver
development. I found this introduction very clear and interesting.


Regards,
Mogens Jensen



athn(4): hidenwid?

2020-07-16 Thread Mogens Jensen
I'm testing an athn(4) wireless adapter (Qualcomm Atheros AR9280) in
"Host AP" mode on OpenBSD 6.7 (amd64). While trying the hidenwid flag,
I discovered that the ESSID is sent in responses to unspecified probe
requests. This can be seen by capturing packets on another machine with
wireless adapter in monitor mode. The ifconfig(8) manpage says this:

"The ‘hidenwid’ flag will hide the network ID (ESSID) in beacon
frames when operating in Host AP mode. It will also prevent responses
to probe requests with an unspecified network ID."

I can confirm that no ESSID is sent in beacon frames, but the adapter
will both respond to probe requests and also add the ESSID to those
responses.

In athn(4) manpage under "CAVEATS" there is no information about
problems with the hidenwid flag.

# cat /etc/hostname.athn0
mediaopt hostap mode 11g chan 6
nwid TEST-AP wpakey 123456789 nwflag hidenwid
inet 192.168.10.1 255.255.255.0 192.168.10.255

# ifconfig athn0
athn0: flags=8843 mtu 1500
lladdr XX:XX:XX:XX:XX:XX
index 4 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect mode 11g hostap
status: active
ieee80211: nwid TEST-AP chan 6 bssid XX:XX:XX:XX:XX:XX -95dBm \
wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp \
hidenwid
inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255

Does anyone have an idea what could be the problem?

I'm not trying to start a discussion on whether hiding the ESSID is
ridiculous or not, I'm just testing different things, so I know which
features work and which don't.


Regards,
Mogens Jensen



Re: athn(4): hidenwid?

2020-07-16 Thread Stefan Sperling
On Thu, Jul 16, 2020 at 11:10:58AM +0200, Stefan Sperling wrote:
> Line 1927 of 
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net80211/ieee80211_input.c?annotate=1.218
> 
> This code runs before a response is generated for a probe request and it
> should ensure that a probe request is only generated if the SSID matches.
> 
> The next step would be to find out how this check is being bypassed in
> your case.

Nevermind, I have found the problem.

I moved the HIDENWID flag to a different variable some time ago:
[[[
CVSROOT:/cvs
Module name:src
Changes by: s...@cvs.openbsd.org2019/05/12 12:12:38

Modified files:
sbin/ifconfig  : ifconfig.8 
sys/dev/ic : if_wi.c 
sys/net80211   : ieee80211_input.c ieee80211_ioctl.c 
 ieee80211_ioctl.h ieee80211_output.c 
 ieee80211_var.h 

Log message:
Fix 'ifconfig nwflags; These flags ended up overlapping with other flags
in ieee80211com's ic_flags because we haven't been paying attention to
them (they're not in the same place in the code and hence easy to miss).
Move them to a dedicated variable to avoid this problem in the future.

Add a new 'stayauth' nwflag which can be set to let net80211 ignore
deauth frames. This can be useful when deauth frames are being
persistently spoofed by an attacker. Idea from beck@

ok beck@ phessler@
]]]

There is some use of the HIDENWID flag which I missed in this conversion.
This patch should fix it.

diff b38ea36846c22ecbc2e7394f8dcf015e2b6a523f /usr/src
blob - 8942bc3b47923fe0d78a4435b181777069b2a119
file + sys/dev/ic/bwfm.c
--- sys/dev/ic/bwfm.c
+++ sys/dev/ic/bwfm.c
@@ -1959,7 +1959,7 @@ bwfm_hostap(struct bwfm_softc *sc)
memset(join.assoc.bssid, 0xff, sizeof(join.assoc.bssid));
bwfm_fwvar_cmd_set_data(sc, BWFM_C_SET_SSID, &join, sizeof(join));
bwfm_fwvar_var_set_int(sc, "closednet",
-   (ic->ic_flags & IEEE80211_F_HIDENWID) != 0);
+   (ic->ic_userflags & IEEE80211_F_HIDENWID) != 0);
 }
 #endif
 
blob - 0cea2f80840c2b7bdbbf2dd7de3d83e3beabc7fa
file + sys/dev/ic/rt2560.c
--- sys/dev/ic/rt2560.c
+++ sys/dev/ic/rt2560.c
@@ -1588,7 +1588,7 @@ rt2560_tx_bcn(struct rt2560_softc *sc, struct mbuf *m0
mtod(m0, uint8_t *) +
sizeof (struct ieee80211_frame) +
8 + 2 + 2 +
-   ((ic->ic_flags & IEEE80211_F_HIDENWID) ?
+   ((ic->ic_userflags & IEEE80211_F_HIDENWID) ?
1 : 2 + ni->ni_esslen) +
2 + min(ni->ni_rates.rs_nrates, IEEE80211_RATE_SIZE) +
2 + 1 +
blob - 7170cb0085cbb2f47ff2d02d204f5706f4eb22a2
file + sys/dev/ic/rt2661.c
--- sys/dev/ic/rt2661.c
+++ sys/dev/ic/rt2661.c
@@ -2935,7 +2935,7 @@ rt2661_prepare_beacon(struct rt2661_softc *sc)
RT2661_HW_BEACON_BASE0 + 24 +
sizeof (struct ieee80211_frame) +
8 + 2 + 2 +
-   ((ic->ic_flags & IEEE80211_F_HIDENWID) ?
+   ((ic->ic_userflags & IEEE80211_F_HIDENWID) ?
1 : 2 + ni->ni_esslen) +
2 + min(ni->ni_rates.rs_nrates, IEEE80211_RATE_SIZE) +
2 + 1 +
blob - 098aa9bce19481ce09676ce3c4fc0040f14c9b93
file + sys/net80211/ieee80211_input.c
--- sys/net80211/ieee80211_input.c
+++ sys/net80211/ieee80211_input.c
@@ -1937,7 +1937,7 @@ ieee80211_recv_probe_req(struct ieee80211com *ic, stru
return;
}
/* refuse wildcard SSID if we're hiding our SSID in beacons */
-   if (ssid[1] == 0 && (ic->ic_flags & IEEE80211_F_HIDENWID)) {
+   if (ssid[1] == 0 && (ic->ic_userflags & IEEE80211_F_HIDENWID)) {
DPRINTF(("wildcard SSID rejected"));
ic->ic_stats.is_rx_ssidmismatch++;
return;




Re: athn(4): hidenwid?

2020-07-16 Thread Stefan Sperling
On Thu, Jul 16, 2020 at 06:19:40AM +, Mogens Jensen wrote:
> I'm not trying to start a discussion on whether hiding the ESSID is
> ridiculous or not, I'm just testing different things, so I know which
> features work and which don't.

Thanks for digging into this. Since there are no automated tests for
the wifi stack it is difficult to determine whether the code is fully
correct. And regressions do sometimes occur. So getting test reports
such as this is very valuable.

There is this chunk of code which is supposed to catch a wrong SSID and
it does take "hidenwid" mode into account:

/* SSID element is mandatory */
if (ssid == NULL || ssid[1] > IEEE80211_NWID_LEN) {
DPRINTF(("invalid SSID element\n"));
return;
}
/* check that the specified SSID (if not wildcard) matches ours */
if (ssid[1] != 0 && (ssid[1] != ic->ic_bss->ni_esslen ||
memcmp(&ssid[2], ic->ic_bss->ni_essid, ic->ic_bss->ni_esslen))) {
DPRINTF(("SSID mismatch\n"));
ic->ic_stats.is_rx_ssidmismatch++;
return;
}
/* refuse wildcard SSID if we're hiding our SSID in beacons */
if (ssid[1] == 0 && (ic->ic_flags & IEEE80211_F_HIDENWID)) {
DPRINTF(("wildcard SSID rejected"));
ic->ic_stats.is_rx_ssidmismatch++;
return;
}

Line 1927 of 
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net80211/ieee80211_input.c?annotate=1.218

This code runs before a response is generated for a probe request and it
should ensure that a probe request is only generated if the SSID matches.

The next step would be to find out how this check is being bypassed in
your case. Are you really sure that probe responses are sent to the MAC
address of clients which do not already know the correct SSID? The patch
below will make the kernel print the MAC addresses of rejected clients
to 'dmesg':

diff b38ea36846c22ecbc2e7394f8dcf015e2b6a523f /usr/src
blob - 098aa9bce19481ce09676ce3c4fc0040f14c9b93
file + sys/net80211/ieee80211_input.c
--- sys/net80211/ieee80211_input.c
+++ sys/net80211/ieee80211_input.c
@@ -1932,13 +1932,15 @@ ieee80211_recv_probe_req(struct ieee80211com *ic, stru
/* check that the specified SSID (if not wildcard) matches ours */
if (ssid[1] != 0 && (ssid[1] != ic->ic_bss->ni_esslen ||
memcmp(&ssid[2], ic->ic_bss->ni_essid, ic->ic_bss->ni_esslen))) {
-   DPRINTF(("SSID mismatch\n"));
+   printf("SSID mismatch from %s\n",
+   ether_sprintf((u_int8_t *)wh->i_addr2));
ic->ic_stats.is_rx_ssidmismatch++;
return;
}
/* refuse wildcard SSID if we're hiding our SSID in beacons */
if (ssid[1] == 0 && (ic->ic_flags & IEEE80211_F_HIDENWID)) {
-   DPRINTF(("wildcard SSID rejected"));
+   printf("wildcard SSID rejected from %s\n",
+   ether_sprintf((u_int8_t *)wh->i_addr2));
ic->ic_stats.is_rx_ssidmismatch++;
return;
}