I too have this issue unless I set the mode to AC/N-Mixed. Then my devices will connect at AC speeds. Also for what it is worth, this bug appears to be present in all dd-wrt builds.
Fired up /sbin/qtn_monitor it pushed some rpc calls to Quantenna... ... and I got 433Mbs on my phone.. lol. Developers, is this secure?
ps Come on, guys... you can do this, i believe in you!
Joined: 26 Mar 2013 Posts: 1855 Location: Hung Hom, Hong Kong
Posted: Mon Sep 18, 2017 20:51 Post subject: Signal processing of 802.11ac routers
mozuku wrote:
1 Reboot with openvpn client enabled , wifi doesn't boroadcast.
2 When using only 2.4Ghz, the wireless channnel width does not work properly.
It is always set to 40Mhz regardless of selection.
Out of curiosity, is the signal processing in wireless routers hardware or software? I would be surprised if it's done by software/firmware/microcodes....
802.11ac is a software-driven or firmware-driven approach? Unlike previous 802.11 b/g/n? Because of beam-forming and channel hopping? _________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
Posted: Mon Sep 18, 2017 21:47 Post subject: Re: Signal processing of 802.11ac routers
mwchang wrote:
mozuku wrote:
1 Reboot with openvpn client enabled , wifi doesn't boroadcast.
2 When using only 2.4Ghz, the wireless channnel width does not work properly.
It is always set to 40Mhz regardless of selection.
Out of curiosity, is the signal processing in wireless routers hardware or software? I would be surprised if it's done by software/firmware/microcodes....
802.11ac is a software-driven or firmware-driven approach? Unlike previous 802.11 b/g/n? Because of beam-forming and channel hopping?
Probably the boot process or hardware initialization has failed.
This problem always appears when restarting with openvpn enabled.
It doesn't happen with kong firmware.
Syslog:
Sep 18 21:28:19 [router name] daemon.notice openvpn[980]: SIGTERM[hard,init_instance] received, process exiting
Sep 18 21:30:00 [router name] user.info : Maybe igmprt had died, we need to re-exec it
Router/Version: Tplink Archer C9 v1
Firmware: DD-WRT v3.0-r30880 std (09/11/17)
Previous: DD-WRT v3.0-r33345 std (08/03/17)
Kernel Version: Linux 4.4.32-rc1 #1578 SMP Mon Nov 14 10:53:35 CET 2016 armv7l
Mode/Status: Router
Reset: No
Issues/Errors: OpenVPN fails to start. When running 33345 on my Netgear R7500 v2 in OpenVPN Server mode (Use new EasyRSA2 or EasyRSA3 to make keys.
"Signature Algorithm: md5WithRSAEncryption" no longer valid w/new openSSL
should be - "Signature Algorithm: sha256WithRSAEncryption") it works perfectly. Daemon starts up and clients able to connect and route (Laptops with OpenVPN clients).
The issue is with the DD-WRT OpenVPN client side. On my tplink archer c9v1 router with any firmware newer than r30880, the cpu runs high and gets stuck on "ebtables"
See below for result of "top"
This happens upon reboot or when OpenVPN client is disabled and then I save changes after enabling it. Seems to be an open ticket (http://svn.dd-wrt.com/ticket/5807), but this is causing me to continue to run r30880. I already have updated certificates and it seems like it wanted to connect, but ebtables stops it from completing. [/code]