The Linksys WRT AC series is a set of high performance, multi-core, 802.11ac capable devices, designed to be supported by Openwrt out of the box. All of the devices use the mwlwifi driver, an opensource driver with closed source firmware. The look and shape of the devices is a throwback to the Linksys WRT54G.
-2 =force use of particular SSH protocol version 
-p =connect to specified port
cd/tmp && sysupgrade -F-n-v<image-name>
-F =force write, required to bypass metadata check
-n =do not save configuration over reflash
-v =more verbose
If the firmware has become unresponsive and won't boot, chances are you can recover it easily due to the Dual Firmware partition layout, by switching to the alternate firmware.
For this reason, it is recommended to always keep at least one known good version of the firmware on either partition.
Switch router from primary to alternate partition or vice versa using any of the 4 below methods:
In the Windows Creators Update, Intel enabled Receive Side Coalescing (RSC) in their 18.x drivers, which has reportedly slowed down some wifi adapters.
A possible solution can be found here: Step by Step Fix
Solutions that are reported to workaround the issue:
- Disable WMM on the interface (note: this will also disable 802.11n/ac capability)
- Setup radio2 with the mwifiex driver, which does not appear to have this problem
88W8964 VAP SSID broadcasts but clients can't connect
The driver rejects any packets from interfaces which are not within a mask (FD:FF:FF:FF:FF:F0) of the main interface (primary AP or STA).
You should set the locally administered bit for the MAC address, and then freely set any final digit. Keep in mind that the MAC address should be unicast (not multicast) or hostapd will not start the interface. This then leaves you only with even digits for the second digit of the address (i.e. 2, 4, 6, 8, a, c, e).
To make VAPs work, it is recommended to manually set the macaddr for each wifi-iface section of your /etc/config/wireless
e.g. if your primary MAC is 60:38:e0:ce:37:50, your wifi config for 3 APs (1 primary + 2 VAPs)
If eSATA LED lights immediately after reboot with no serial output, add a 4.7KΩ resistor between Gnd & Rx on adapter 4.7KΩ 4 Band:yel | pur | red | gold (±5%)4.7KΩ 5 Band: yel | pur | blk | brn | brn (±1%)
Hit any key to stop autoboot: 321
Marvell >> setenv serverip 192.168.1.254
Marvell >> setenv netmask 255.255.255.0
Marvell >>ping 192.168.1.254
host 192.168.1.254 is alive
Marvell >> run flash_pri_image
Using egiga0 device
TFTP from server 192.168.1.254; our IP address is 192.168.1.1
Load address: 0x2000000
Loading: T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T
T T T
Bytes transferred = 0(00000000 hex)
NAND erase: device 0 offset 0xa00000, size 0x4000000
Erasing at 0x49e0000 --100% complete.
NAND write: device 0 offset 0xa00000, size 0x1fc0000
0 bytes written: OK
Verify TFTP server is running and firmware image is inside TFTP boot directory
Verify PC ↔ Router ethernet connection
The following information has been superceded by current builds and is included only for historical interest.
On Christmas Eve 2014, Marvell released an updated driver for the 88W8864 WiFi chip as found in the WRT1900AC to the OpenWrt developers mailing list
On the 3rd of April 2014, Belkin posted a link to ftp server containing patches, adding WRT1900AC support. They couldn't be applied because of being incorrectly posted, not signed off, and adding binary wireless driver ap8x.ko.
5 days later a patchset in the form of single e-mail was posted to the openwrt-devel. It was malformed and not signed off, so still couldn't be applied. Release of wireless driver has been postponed.
Chrome & HTTPS
Problem: LuCI will not load when utilizing Chrome [due to PolarSSL]
Chrome[v51+] requires AES-GCM and CAMELLIA-GCM ciphersuites to handshake with a server utilizing the ustream-polarssl backend.
If CONFIG_GCM is disabled, ssl_ciphersuite_from_id() returns NULL when cipher 0x9d is queried <sup> TLS_RSA_WITH_AES_256_GCM_SHA384
This results with the call ssl_ciphersuite_match() to fail with POLARSSL_ERR_SSL_INTERNAL_ERROR (RFC 5288)
Utilize this backport, enabling AES-GM and CAMELLIA-GCM ciphersuites in PolarSSL; OR
Completely remove all PolarSSL related components from your build environment, switching to OpenSSL
Certain packages default to PolarSSL[libustream-polarssl] and will require edited makefiles
In the case of cshark, it is not compatible with OpenSSL (unsure about other SSL platforms)
DHCP & DNS
Problem: Active DHCP Leases list enumerates all statically assigned IPs as active, listing all with a netmask of /32.
If utilizing Kernels 4.1.x or 4.4.x, there appears to be an issue with how odhcpd interacts with dnsmasq, resulting in the aforementioned
Uninstall odhcpd & odhcpd6 and install dnsmasq-full in lieu of; OR
toh/linksys/wrt_ac_series.txt · Last modified: 2020/04/06 11:30 by lantis1008