| Message ID | 20230428150833.218605-1-martin.kaistra@linutronix.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | wifi: rtl8xxxu: Add AP mode support for 8188f | expand |
Hi Martin, On 28.04.23 17:08, Martin Kaistra wrote: > This series intends to bring AP mode support to the rtl8xxxu driver, > more specifically for the 8188f, because this is the HW I have. Awesome work, thanks a lot! I have access to and will try getting AP mode working on the RTL8192CUS by filling in the gen1 implementation parts. If someone is already working on gen1 support, please let me know. Same if there are know pitfalls I might encounter. :) Kind regards, Reto
Hi Martin, Am 28.04.23 um 17:08 schrieb Martin Kaistra: > This series intends to bring AP mode support to the rtl8xxxu driver, > more specifically for the 8188f, because this is the HW I have. > The work is based on the vendor driver as I do not have access to > datasheets. I tried to enable AP mode for a 8188EU device (TP-Link TL-WN725N) with some mixed results. I added .supports_ap = 1 and .max_macid_num = 16 to rtl8188eu_fops. The AP was visible and I once was able to connect to it. When connected, the link was stable, but I didn't do any benchmarks. Most of my tries I was not able to establish a connection (looks like timeouts) and once I got this message: usb 1-4: rtl8xxxu_send_beacon_frame: Failed to read beacon valid bit The driver I am using currently is the out-of-tree driver rtl8188eu [1], which has a stable AP mode, but has some stability issues in managed mode. Please give me a hint if and how I may help tracking down the issue to enable AP mode for 8188EU as well. Best regards, Georg [1] https://github.com/lwfinger/rtl8188eu/tree/v5.2.2.4
Hi Georg, Am 05.07.23 um 11:00 schrieb Georg Müller: > Hi Martin, > > Am 28.04.23 um 17:08 schrieb Martin Kaistra: >> This series intends to bring AP mode support to the rtl8xxxu driver, >> more specifically for the 8188f, because this is the HW I have. >> The work is based on the vendor driver as I do not have access to >> datasheets. > > I tried to enable AP mode for a 8188EU device (TP-Link TL-WN725N) with > some mixed results. > > I added .supports_ap = 1 and .max_macid_num = 16 to rtl8188eu_fops. According to [1], you might be able to increase max_macid_num to 64. > > The AP was visible and I once was able to connect to it. When connected, > the link was stable, but I didn't do any benchmarks. > > Most of my tries I was not able to establish a connection (looks like > timeouts) and once I got this message: > > usb 1-4: rtl8xxxu_send_beacon_frame: Failed to read beacon valid bit > > The driver I am using currently is the out-of-tree driver rtl8188eu [1], > which has a stable AP mode, but has some stability issues in managed mode. > > Please give me a hint if and how I may help tracking down the issue to > enable AP mode for 8188EU as well. I would suggest the following: - in rtl8xxxu_fill_txdesc_v3, set macid, HW_SEQ like in the v2 function - 8188e does decide on the tx rate in software, so rtl8188e_handle_ra_tx_report2() will probably need some adjustments to handle multiple macids (maybe ra_info in rtl8xxxu_priv should be an array of size RTL8XXXU_MAX_MAC_ID_NUM?) For testing I use a separate machine (or at least separate wifi interface) in monitoring mode, which I can set to the correct channel and then see in wireshark, if all beacons, ACKs and other frames get sent correctly. If you have a wireshark trace of a problematic behavior and need some help with determining the cause or have some further questions, let me know. Thanks, Martin > > Best regards, > Georg > > [1] > https://github.com/lwfinger/rtl8188eu/tree/v5.2.2.4 [1] https://lore.kernel.org/linux-wireless/27e83382-4c84-1841-c428-d1e5143ea20c@gmail.com/
On 07/07/2023 10:23, Martin Kaistra wrote: > Hi Georg, > > Am 05.07.23 um 11:00 schrieb Georg Müller: >> Hi Martin, >> [...] >> Please give me a hint if and how I may help tracking down the issue to >> enable AP mode for 8188EU as well. > > I would suggest the following: > - in rtl8xxxu_fill_txdesc_v3, set macid, HW_SEQ like in the v2 function > - 8188e does decide on the tx rate in software, so rtl8188e_handle_ra_tx_report2() will probably need some adjustments to handle multiple macids (maybe ra_info in rtl8xxxu_priv should be an array of size RTL8XXXU_MAX_MAC_ID_NUM?) ra_info should be an array(?), except the dynamic_tx_rpt_timing_counter member should be moved to rtl8xxxu_priv. In the vendor driver it was a static variable in the odm_rate_decision_8188e() function. An array or some dynamic data structure? The array would take up at least 3072 bytes, including when the driver is handling some other chip which doesn't need the array. Additionally, rtl8xxxu_sta_add() and rtl8xxxu_sta_remove() need to increase/decrease REG_TX_REPORT_CTRL + 1, otherwise you will only get correct rate control for the first station which connects to the AP.