Hi All,
Beaconing support in rtl8192cu (AP and ad-hoc modes) was already
mostly there, but code for actually sending out beacon frames was
missing. The following patch works for me, meaning that I can use
hostapd to set up a functioning AP.
Beaconing in rtl8192cu seems to work such that the user needs to
explicitly send one beacon frame, which the hardware then starts
repeating. The explicitly sent frames show up in hostapd's mon.wlan0
and then hostapd also prints out a message "unknown mgmt cb frame
subtype 8". I don't know how to fix that. It doesn't seem to matter,
though.
Also, hostapd.conf should have "dtim_period=1", since the hardware
doesn't change dtim count in the beacon frames it sends. Furthermore,
the period is hardcoded to 1 in the realtek vendor driver. Is there a
way for a driver to inform mac80211 and hostapd about this limitation?
How does the patch look? My knowledge in this area is very limited:
basically, I guess the patch is ok, since my kernel doesn't panic. :)
(I realize that the patch modifies the common rtlwifi code, so it
should condition the new beaconing code for rtl8192cu only.)
Colin
diff -Nurp a/compat-wireless-3.5.1-1-snpc/drivers/net/wireless/rtlwifi/core.c
b/compat-wireless-3.5.1-1-snpc/drivers/net/wireless/rtlwifi/core.c
--- a/compat-wireless-3.5.1-1-snpc/drivers/net/wireless/rtlwifi/core.c 2012-08-14
07:49:58.000000000 +0300
+++ b/compat-wireless-3.5.1-1-snpc/drivers/net/wireless/rtlwifi/core.c 2012-09-01
23:38:19.598281038 +0300
@@ -572,6 +572,25 @@ static int rtl_op_conf_tx(struct ieee802
return 0;
}
+static void _rtl_update_beacon(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif)
+{
+ struct sk_buff *skb;
+
+ skb = ieee80211_beacon_get(hw, vif);
+ rtl_op_tx(hw, skb);
+}
+
+static int rtl_op_set_tim(struct ieee80211_hw *hw, struct ieee80211_sta *sta,
+ bool set)
+{
+ struct rtl_priv *rtlpriv = rtl_priv(hw);
+
+ _rtl_update_beacon(hw, rtlpriv->mac80211.vif);
+
+ return 0;
+}
+
static void rtl_op_bss_info_changed(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_bss_conf *bss_conf, u32 changed)
@@ -589,6 +608,7 @@ static void rtl_op_bss_info_changed(stru
if ((changed & BSS_CHANGED_BEACON) ||
(changed & BSS_CHANGED_BEACON_ENABLED &&
bss_conf->enable_beacon)) {
+ _rtl_update_beacon(hw, vif);
if (mac->beacon_enabled == 0) {
RT_TRACE(rtlpriv, COMP_MAC80211, DBG_DMESG,
"BSS_CHANGED_BEACON_ENABLED\n");
@@ -1181,6 +1201,7 @@ const struct ieee80211_ops rtl_ops = {
.configure_filter = rtl_op_configure_filter,
.sta_add = rtl_op_sta_add,
.sta_remove = rtl_op_sta_remove,
+ .set_tim = rtl_op_set_tim,
.set_key = rtl_op_set_key,
.conf_tx = rtl_op_conf_tx,
.bss_info_changed = rtl_op_bss_info_changed,
On Sun, 2012-09-02 at 20:01 -0500, Larry Finger wrote:
> On 09/02/2012 06:20 PM, Johannes Berg wrote:
> >
> > Just FYI -- that's not guaranteed if "iw scan" returns results, you'd
> > have to run "iw scan passive" to make sure you pick up beacons rather
> > than just probe responses.
>
> That is good to know. Unfortunately, 'iw wlan0 scan passive' run as an
> unprivileged user results in "command failed: Operation not permitted (-1)".
> When I run it as root, then I get "command failed: Operation not supported
> (-95)". I am assuming that my version of iw (0.9.22) is not new enough.
Seems like, though it's a bit strange that'd you'd get operation not
supported. Not sure why that is.
> When I run 'iwlist scan' in unprivileged mode, I did see the beacon, thus I got
> the right answer.
You can't run "iwlist scan" in unprivileged mode either, in this mode
it'll just return the existing results list that is still there due to
wpa_supplicant (or some other process) triggering a scan.
If you want to check if you saw a beacon, you can run
iw wlan0 scan dump -b
and check if it prints
"Information elements from Beacon frame:"
for that AP.
johannes
On 09/02/2012 01:50 PM, coekbe wrote:
> Hi All,
>
> Beaconing support in rtl8192cu (AP and ad-hoc modes) was already
> mostly there, but code for actually sending out beacon frames was
> missing. The following patch works for me, meaning that I can use
> hostapd to set up a functioning AP.
>
> Beaconing in rtl8192cu seems to work such that the user needs to
> explicitly send one beacon frame, which the hardware then starts
> repeating. The explicitly sent frames show up in hostapd's mon.wlan0
> and then hostapd also prints out a message "unknown mgmt cb frame
> subtype 8". I don't know how to fix that. It doesn't seem to matter,
> though.
>
> Also, hostapd.conf should have "dtim_period=1", since the hardware
> doesn't change dtim count in the beacon frames it sends. Furthermore,
> the period is hardcoded to 1 in the realtek vendor driver. Is there a
> way for a driver to inform mac80211 and hostapd about this limitation?
>
> How does the patch look? My knowledge in this area is very limited:
> basically, I guess the patch is ok, since my kernel doesn't panic. :)
> (I realize that the patch modifies the common rtlwifi code, so it
> should condition the new beaconing code for rtl8192cu only.)
Changing rtlwifi is not acceptable when you only wish to modify a single driver.
That code in any other routine than usb.c will affect all the other drivers.
I used my hostapd script to start an AP with rtl8192cu using the ESSID "TEST".
After I did tat, I did an 'iw scan' with a different interface and got
BSS 00:1f:1f:c8:8e:cb (on wlan2)
TSF: 3249538351 usec (0d, 00:54:09)
freq: 2462
beacon interval: 100
capability: ESS Privacy ShortSlotTime (0x0411)
signal: -30.00 dBm
last seen: 24 ms ago
SSID: TEST
Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
DS Parameter set: channel 11
Country: US Environment: Indoor/Outdoor
Channels [1 - 11] @ 20 dBm
ERP: Barker_Preamble_Mode
Extended supported rates: 24.0 36.0 48.0 54.0
RSN: * Version: 1
* Group cipher: CCMP
* Pairwise ciphers: CCMP
* Authentication suites: PSK
* Capabilities: 16-PTKSA-RC (0x000c)
HT capabilities:
Capabilities: 0x186c
HT20
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
No RX STBC
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 16 usec (0x07)
HT TX/RX MCS rate indexes supported: 0-7, 32
HT operation:
* primary channel: 11
* secondary channel offset: no secondary
* STA channel width: 20 MHz
* RIFS: 0
* HT protection: no
* non-GF present: 0
* OBSS non-GF present: 0
* dual beacon: 0
* dual CTS protection: 0
* STBC beacon: 0
* L-SIG TXOP Prot: 0
* PCO active: 0
* PCO phase: 0
WMM: * Parameter version 1
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 3008 usec
* VO: CW 3-7, AIFSN 2, TXOP 1504 usec
Obviously, the rtl8192cu is beaconing with no changes to the wireless-testing
code. This driver has the hooks to set the beacon time, but it is not being
changed - that needs investigation. A second machine could authenticate and
associate; however, I could get no ping throughput.
I will be looking at this driver when I get time; however, I must warn that I
consider problems using these drivers as an AP to have low priority. You can;
however, use your patch to make it work, but that patch will not be accepted.
Larry
On 09/02/2012 06:20 PM, Johannes Berg wrote:
>
> Just FYI -- that's not guaranteed if "iw scan" returns results, you'd
> have to run "iw scan passive" to make sure you pick up beacons rather
> than just probe responses.
That is good to know. Unfortunately, 'iw wlan0 scan passive' run as an
unprivileged user results in "command failed: Operation not permitted (-1)".
When I run it as root, then I get "command failed: Operation not supported
(-95)". I am assuming that my version of iw (0.9.22) is not new enough.
When I run 'iwlist scan' in unprivileged mode, I did see the beacon, thus I got
the right answer.
Larry
On Sun, 2012-09-02 at 18:02 -0500, Larry Finger wrote:
> Changing rtlwifi is not acceptable when you only wish to modify a single driver.
> That code in any other routine than usb.c will affect all the other drivers.
>
> I used my hostapd script to start an AP with rtl8192cu using the ESSID "TEST".
> After I did tat, I did an 'iw scan' with a different interface and got
>
> BSS 00:1f:1f:c8:8e:cb (on wlan2)
...
> Obviously, the rtl8192cu is beaconing with no changes to the wireless-testing
> code.
Just FYI -- that's not guaranteed if "iw scan" returns results, you'd
have to run "iw scan passive" to make sure you pick up beacons rather
than just probe responses.
johannes