-
Notifications
You must be signed in to change notification settings - Fork 600
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Concurrent mode not being really concurrent #447
Comments
Another thing we've observed, stressing the single interface wlan0 (Access Point): [ 313.931576] RTW: send_beacon fail! 184 ms |
Realtek recommends doing it the other way around:
(from Realtek_WiFi_concurrent_mode_Introduction.pdf) |
Hi,
Our base hardware is a beaglebone running 4.19.94-ti-r42 kernel, and our 8188eu device is as follows:
root@beaglebone:/opt/rtl8188eu# lsusb
Bus 001 Device 003: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
We've compiled the driver with the concurrent mode option on, which allows us to effectively have 2 wlan interfaces:
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.50 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::36c9:f0ff:fe8c:ec7c prefixlen 64 scopeid 0x20
ether 34:c9:f0:8c:ec:7c txqueuelen 1000 (Ethernet)
RX packets 259797 bytes 774644 (756.4 KiB)
RX errors 0 dropped 742 overruns 0 frame 0
TX packets 2047 bytes 454838 (444.1 KiB)
TX errors 0 dropped 12 overruns 0 carrier 0 collisions 0
wlan1: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500
inet 172.26.10.143 netmask 255.255.0.0 broadcast 172.26.255.255
inet6 fe80::34c9:f0ff:fe8c:ec7c prefixlen 64 scopeid 0x20
ether 36:c9:f0:8c:ec:7c txqueuelen 1000 (Ethernet)
RX packets 255407 bytes 32287932 (30.7 MiB)
RX errors 0 dropped 35737 overruns 0 frame 0
TX packets 5622 bytes 4332110 (4.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0 is an access point interface for users to connect.
wlan1 is the interface used for the adapter to connect to other SSIDs.
Things seem to work fine, except for when we combine traffic over the 2 interfaces.
For clarity, I am adding a node.js test:
const puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch({ headless: "new", ignoreHTTPSErrors: true});
const page1 = await browser.newPage();
const page2 = await browser.newPage();
var promises=[];
promises.push(page1.goto('https://192.168.1.50/panel/login', { waitUntil: 'networkidle2' }));
promises.push(page2.goto('https://172.26.10.143/panel/login', { waitUntil: 'networkidle2' }));
await Promise.all(promises);
await browser.close();
})();
Some times this works, others it produces the adapter to completely crash.
[ 257.818325] RTW: wlan1 bBusyTraffic == true
[ 265.451662] RTW: rtw_update_ramask => mac_id:0, networkType:0x0b, mask:0x00000000000f0000
==> rssi_level:5, rate_bitmap:0x0000000000000000, shortGIrate=1
==> bw:0, ignore_bw:0x1
[ 267.996509] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 268.100578] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 268.204557] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 268.308589] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 268.412623] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 268.516678] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 268.620620] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 268.724641] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 268.828681] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 268.932686] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 269.036753] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 269.140733] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 269.244752] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 269.348764] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 269.452793] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 269.556870] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 269.660831] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 269.764846] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
[ 269.868869] RTW: rtw_sctx_wait timeout: dump_mgntframe_and_wait
...
[ 283.532059] RTW: issue_beacon, fail!
[ 283.705718] RTW: issue_beacon, fail!
[ 283.893890] RTW: issue_beacon, fail!
[ 284.076365] RTW: issue_beacon, fail!
[ 284.257778] RTW: issue_beacon, fail!
[ 284.433639] RTW: issue_beacon, fail!
[ 284.606069] RTW: issue_beacon, fail!
[ 287.922490] RTW: issue_beacon, fail!
[ 300.052775] RTW: issue_beacon, fail!
[ 300.243144] RTW: issue_beacon, fail!
Eventually petitions end timeouting. And the client device connecting to the AP ends losing the connection.
Any ideas?
The text was updated successfully, but these errors were encountered: