OpenWrt Forum Archive

Topic: Update on Linksys WRT1900AC support

The content of this topic has been archived between 16 Sep 2014 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

@hyppo Please post the output of the following:

  • Issue:  strings /lib/modules/*.*/mwlwifi.ko | grep "^10.3"

  • /etc/config/wireless

    • Please remove your WiFi password & MACs prior to posting

  • Issue:  opkg list-installed


Additionally, is your router located near (within 20ft) any large electrical appliances (stove, refrigerator, dryer, etc.), a microwave, or anything running 220v+ (hot water heater, central air unit, furnace, etc)?


Please save the following as /mnt/sda1/log.sh, where /mnt/sda1 is the partition of the USB drive.

  1. Create: vi /mnt/sda1/log.sh

  2. Edit: i, then Right Click to paste

  3. Press: ALT + :

  4. Save: :wq then ENTER

  5. Issue: chmod +x /mnt/sda1/log.sh

  6. Run: /mnt/sda1/log.sh

#!/bin/sh

    # Paramaters #
#----------------------------------------

# Modify:
USB=/mnt/sda1

# Logs:
ker=$USB/kernel.log
ram=$USB/ram.log
sys=$USB/system.log


    # Commands #
#----------------------------------------

# Copy System log:
logread -F $sys &


# Tail logs:
logread -F $sys -f &

while cat /proc/meminfo >> $ram;
  do sleep 1;
    echo "" >> $ram;
    echo "---------------------------" >> $ram;
    echo "" >> $ram;
  done & tail -f $ram &

while dmesg -c >> $ker;
  do sleep 1;
  done & tail -f $ker

Once the above is done, please connect the device to WiFi, then place under load.  Once it crashes, log back in via ssh and post output of:

  • /mnt/sda1/kernel.log

  • /mnt/sda1/ram.log

  • /mnt/sda1/system.log

(Last edited by JW0914 on 16 Jun 2017, 18:37)

@JW0914
Hi, thank you for the attention you give to my issue.
It took some time until I can simulate reboot again, but finally it did it.

And here is requested info

root@OpenWrt:~# strings /lib/modules/*.*/mwlwifi.ko | grep "^10.3"
10.3.2.0-20161011
10.3.2.0-20161011

next

root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path 'soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
        option htmode 'HT20'
        option country 'DE'
        option disabled '1'

config wifi-iface
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'none'
        option macaddr '**:**:**:**:**:**'
        option key '***'

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '36'
        option hwmode '11a'
        option path 'soc/soc:pcie-controller/pci0000:00/0000:00:03.0/0000:03:00.0'
        option htmode 'VHT80'
        option country 'DE'
        option disabled '0'

config wifi-iface
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'OpenWrt'
        option macaddr '**:**:**:**:**:**'
        option encryption 'psk2'
        option key '***'

next

root@OpenWrt:~#  opkg list-installed
base-files - 169-50107
block-mount - 2016-07-24-addd7dc21fe99f2701c1d4708071578052af401d
busybox - 1.24.2-1
dnsmasq - 2.76-1
dropbear - 2016.74-1
firewall - 2016-11-29-1
fstools - 2016-07-24-addd7dc21fe99f2701c1d4708071578052af401d
hostapd-common - 2016-06-15-1
ip6tables - 1.4.21-2
iptables - 1.4.21-2
iw - 4.3-1
iwinfo - 2016-01-25-e4aca3910dff532ed878d0ceaf1ab6e8ad7719bf
jshn - 2016-11-29-77a629375d7387a33a59509d9d751a8798134cab
jsonfilter - 2016-07-02-dea067ad67d977c247c300c06676a06adf21e0c7
kernel - 4.4.14-1-54a570815054fa251a48a0c4c2a42bd4
kmod-cfg80211 - 4.4.14+2016-05-12-1
kmod-crypto-hash - 4.4.14-1
kmod-fs-ext4 - 4.4.14-1
kmod-fs-msdos - 4.4.14-1
kmod-fs-vfat - 4.4.14-1
kmod-gpio-button-hotplug - 4.4.14-2
kmod-ip6tables - 4.4.14-1
kmod-ipt-conntrack - 4.4.14-1
kmod-ipt-core - 4.4.14-1
kmod-ipt-nat - 4.4.14-1
kmod-lib-crc-ccitt - 4.4.14-1
kmod-lib-crc16 - 4.4.14-1
kmod-mac80211 - 4.4.14+2016-05-12-1
kmod-mwlwifi - 4.4.14+10.3.2.0-20161013-2
kmod-nf-conntrack - 4.4.14-1
kmod-nf-conntrack6 - 4.4.14-1
kmod-nf-ipt - 4.4.14-1
kmod-nf-ipt6 - 4.4.14-1
kmod-nf-nat - 4.4.14-1
kmod-nls-base - 4.4.14-1
kmod-nls-cp437 - 4.4.14-1
kmod-nls-iso8859-1 - 4.4.14-1
kmod-ppp - 4.4.14-1
kmod-pppoe - 4.4.14-1
kmod-pppox - 4.4.14-1
kmod-scsi-core - 4.4.14-1
kmod-slhc - 4.4.14-1
kmod-usb-core - 4.4.14-1
kmod-usb-storage - 4.4.14-1
libblobmsg-json - 2016-11-29-77a629375d7387a33a59509d9d751a8798134cab
libc - 1.1.16-1
libexpat - 2.2.0-1
libgcc - 5.3.0-1
libip4tc - 1.4.21-2
libip6tc - 1.4.21-2
libiwinfo - 2016-01-25-e4aca3910dff532ed878d0ceaf1ab6e8ad7719bf
libjson-c - 0.12-1
libjson-script - 2016-11-29-77a629375d7387a33a59509d9d751a8798134cab
libnl-tiny - 0.1-5
libubox - 2016-11-29-77a629375d7387a33a59509d9d751a8798134cab
libubus - 2016-07-02-053be7df871e05478284235732f8b0608089512f
libuci - 2016-07-04.1-1
libuclient - 2016-01-28-2e0918c7e0612449024caaaa8d44fb2d7a33f5f3
libxtables - 1.4.21-2
logd - 2016-07-19-aead2c0cbffdda9b46d74a998a4c6aeef423b21a
mtd - 21
netifd - 2016-12-09-edc15caac6c6d3b2d8ea17f98ecbaba81ba573dc
odhcp6c - 2016-02-08-7533a6243dc3ac5a747cf6ccbc4d0539dafd3e07
odhcpd - 2016-10-09-801cfeea100ca7b211c9841f0fcb757b17f47860
opkg - 9c97d5ecd795709c8584e972bfdf3aee3a5b846d-15
ppp - 2.4.7-9
ppp-mod-pppoe - 2.4.7-9
procd - 2016-07-29-2c9f5d4af1559b840c42f1443ede9f9fe809c58b
procd-nand - 2016-07-29-2c9f5d4af1559b840c42f1443ede9f9fe809c58b
swconfig - 11
ubi-utils - 1.5.1-2
uboot-envtools - 2015.10-1
ubox - 2016-07-19-aead2c0cbffdda9b46d74a998a4c6aeef423b21a
ubus - 2016-07-02-053be7df871e05478284235732f8b0608089512f
ubusd - 2016-07-02-053be7df871e05478284235732f8b0608089512f
uci - 2016-07-04.1-1
uclient-fetch - 2016-01-28-2e0918c7e0612449024caaaa8d44fb2d7a33f5f3
usign - 2016-07-04-ef6419142a3b0fbcddcccf536e3c1880302c6f89
wpad-mini - 2016-06-15-1

Logs are uploaded here

There are no any large sources around the router, it is only TV, cable modem and iptv box

(Last edited by hyppo on 17 Jun 2017, 20:51)

@hyppo kernel 4.4.14 is old don't you want to flash to a newer build? We are now on 4.4.71 or 4.9.31

tapper wrote:

@hyppo kernel 4.4.14 is old don't you want to flash to a newer build? We are now on 4.4.71 or 4.9.31

Why?

P.S. this user has the original wrt1900ac which crashes on anything greater than 4.something.

@hyppo Nothing major jumps out to me, however I did see a few things I would recommend trying:

  • Have you tried channels above 36?  5gHz radios should utilize a channel in the 150s, however if you're in Europe, you may only have access to channels 100 - 128 for VHT80 and 100 - 136 for VHT40.

    • I'm not sure how recent the graphic I was looking at to garnish that info is, so those channel ranges could very well have changed.

    • Generally, 36 - 64 is for N, not AC

  • WiFi driver is not the most recent... please see the Wiki for how to obtain the most up to date version.

  • Above all, I personally recommend flashing both partitions via serial, as I've had non-specific issues occur before with a serial flash fixing the issue. 

    • Whenever I have a problem with no apparent cause and a serial flash doesn't fix it, I'll reflash the OEM firmware to the primary and backup partitions via serial, reboot to the Linksys firmware, then once it's fully booted, boot back to Uboot and reflash both partitions with OpenWrt via serial.

      • I don't know exactly why this fixes random stability issues, but with my 1900ac v1, the above has never failed to fix random instability when I know there's no issue with the OpenWrt image I flashed.

    • If this does not fix the issue, please use the WiFi Bug Report link in the wiki to file a bug report.

Seperately from your issue, the only PSK2 wifi encryption algorithm that should be utilized is psk2+ccmp (please see Flashing Firmware)

  • Since you're using kernel 4.x.x, please install dnsmasq-full and remove odhcpd & odhcp6c... unless OpenWrt devs have fixed the bugs in odhcpd for kernels 4.x.x., which I'm not aware of.

On a side note, I forgot to tell you to also remove your WAN IP from your log output... when you have time, please edit the kernel and system [see line 511] logs you uploaded and x out your WAN IP via Find & Replace

(Last edited by JW0914 on 17 Jun 2017, 16:24)

If he flashes to a later build then he will get kernel fixes we are now up to 4.4.73 in master and LEDE 17.1.2 has the latest wifi driver.

tapper wrote:

If he flashes to a later build then he will get kernel fixes we are now up to 4.4.73 in master and LEDE 17.1.2 has the latest wifi driver.

That's not factually accurate... 4.4.14 is the default build kernel, and unless one knows of a specific version that has a fix for this specific issue, upgrading to a custom kernel version would not be recommended, as until the root cause is found, trying out experimental kernel versions may very well exacerbate the issue.

Simply because a kernel version becomes available does not mean someone should upgrade to it just to upgrade to it.  If you're going to go with a non-default kernel, then one should be compiling a custom kernel that's imported when make is ran for the OpenWrt image.

  • Additionally, any custom version prevents one from downloading and installing a significant number of packages from the OpenWrt repo, as any package dependent on a kernel version will need to be built for that version.  This means whenever one wants to install a kernel version dependent package, they must first compile the package in their build environment, then transfer it to the router for install.  This isn't a big deal, however it could become a major inconvenience depending on the user environment.

(Last edited by JW0914 on 17 Jun 2017, 16:44)

JW0914 wrote:

I don't know exactly why this fixes random stability issues, but with my 1900ac v1, the above has never failed to fix random instability when I know there's no issue with the OpenWrt image I flashed.

It looks like my unit is just defective, the only thing I may regret is that I have figured  it out too late, after 2.5 years with 2 years of warranty (but I will write to their customer care anyway)

So it was bad idea to get WRT1900AC in memory of my old WRT54G and I will never buy linksys again. I hope I will be more lucky  with my new powerful  Netgear)

Thanks for your help

(Last edited by hyppo on 17 Jun 2017, 21:06)

@hyppo There's no way to know whether your unit is defective or not until you properly troubleshoot the issue... which, as I stated before, you seem unwilling to do.  A router's radio could fail, however it's highly unlikely... the more likely explanation is what I suggested above.

(Last edited by JW0914 on 17 Jun 2017, 21:57)

JW0914 wrote:
tapper wrote:

If he flashes to a later build then he will get kernel fixes we are now up to 4.4.73 in master and LEDE 17.1.2 has the latest wifi driver.

That's not factually accurate... 4.4.14 is the default build kernel

"Factually accurate" depends on your viewpoint and how tightly see things from Openwrt-only perspective:

* 4.4.14 is the default build kernel in the soon-to-be-deprecated Openwrt DD trunk, which has seen practically no actual development since April 2016.  (and nobody maintains CC15.05, so that is completely dead)
* 4.4.71 is the default in LEDE 17.01 (which is Openwrt of April 2016 plus a year of active development)
* 4.9.31 is the default in LEDE master.

Note that both LEDE branches (master and 17.01) include the newest mwlwifi driver 2017-06-06. That wifi driver was also included in the 17.01.2 release that was released week ago.

Developers are currently voting about the LEDE-Openwrt merge, and so far it looks promising that the merge will go through. Part of the published plan is the scrapping of the current Openwrt codebase and continuing work based on the current LEDE source code. Which would then be renamed as the new Openwrt...

http://www.mail-archive.com/openwrt-dev … 41078.html

*) git trees
- rebrand the lede tree to openwrt

For all practical purposes, LEDE is the current actively maintained up-to-date Openwrt source code except for the name. And even that will be fixed in the forthcoming months. Then hopefully also the die-hard "Openwrt-only" folks will be happy (although they will be using the current LEDE codebase...)

4.9 works ok with all other WRTxxxxAC series except the original wrt1900ac v1. (v1 failure with 4.9 is likely due to some Openwrt/LEDE-specific kernel patch as chadster successfully uses kernel 4.9 in "mcdebian" builds)

For any debugging to have any real value or a chance to get the possibly found bugs fixed, the debugging should be done either with the most recent release 17.01.2 or with the current LEDE master.

(Last edited by hnyman on 18 Jun 2017, 13:17)

@hnyman I wasn't aware of that, thanks! =]

@JW0914

Wiki update request.

In the serial port section:

The label for the WRT1900ACS is J10.

When using a CP210x based serial adapter (perhaps others as well),
you might experience that the esata led turns on immediately after reboot/reset, and nothing more happens.
A possible solution to this problem is to place a 4.7k resistor between GND and RX on the adapter.
The CP210x seem to honor the TTL 5V/3.3V pull-up to some extent, causing 5V/3.3V to be present on the TX pin
of the router during the first ms after reset, causing a mode change of some sort in the router chip.
The 4.7k pull-down resistor eliminates this behavior.

(Last edited by qawsed on 18 Jun 2017, 11:10)

@qawsed I've never used that type of serial adapter, so a few questions:

  • Are you only connecting Gnd, Rx & Tx, or also the VCC 3.3v (Pin 6)?

  • When the problem you describe above occurs, do you get any serial output in the terminal?

  • Are you utilizing the most recent drivers for your adapter?

I'll try to get that added within the next few days, as that's a critical piece of information for other users.


@All I posted a few weeks back regarding wiki updates, so I'll mention it again.  The wiki is in need of a massive update, and I have a list of things that need to be added, however I simply haven't had the time to do so over the past year.  Adding the information to the wiki is the easy part, formatting, previewing the formatting, then adjusting the formatting, etc. is the time consuming bit. 

Anyone wishing to contribute is more than welcome to tackle adding a few things to the wiki.  It requires taking ~1hr to read through the DokuWiki plugin wikis to understand how to utilize the proper formatting plugins, especially the wrap plugin, of which is heavily used throughout the wiki due to it's endless abilities to stylize the text.  This would allow me to simply skim through the additions to ensure there are no formatting inconsistencies, of which could create discombobulation. 

Any users interested in helping out on the wiki, please let me know and I can re-link to the master list with all updates needing to be done.

(Last edited by JW0914 on 19 Jun 2017, 14:13)

@JW0914

- Only GND, RX and TX are connected.
- There is no serial output and no other sign of activity.
- The diver used is the linux, kernel 4.11.5, cp210x module.

@qawsed Thanks, I'll get that information added tomorrow or Tues.


@All Is there any benefit to building the kernel, via make kernel_menuconfig, with something like NTFS support versus utilizing a kernel mod?  There's a handful of kernel mods I utilize that are offered as an option to build the kernel with, but wasn't sure what the pros/cons were of doing it one way versus the other.

JW0914 wrote:

@qawsed Thanks, I'll get that information added tomorrow or Tues.


@All Is there any benefit to building the kernel, via make kernel_menuconfig, with something like NTFS support versus utilizing a kernel mod?  There's a handful of kernel mods I utilize that are offered as an option to build the kernel with, but wasn't sure what the pros/cons were of doing it one way versus the other.

most of the advantages of building things into the kernel don't apply for the OpenWRT type environment. They have to do with ease of installing a kernel, which doesn't apply when the kernel is part of a single image.

it's not worth fighting the system to force them to be built in when it makes it so easy to do them as modules. the disadvantages of bypassing the normal build process will outweigh any advantages there are for them to be built-in as opposed to modules.

@dlang  Thanks!  =]

@qawsed In the Wiki, I've added a USB-to-UART listing under Serial Interfaces, and I've moved Serial Interfaces to their own subsection from the Serial Port subsection. 

Please let me know if anything needs to be modified.

(Last edited by JW0914 on 20 Jun 2017, 04:21)

JW0914 wrote:

@qawsed In the Wiki, I've added a USB-to-UART listing under Serial Interfaces, and I've moved Serial Interfaces to their own subsection from the Serial Port subsection. 

Please let me know if anything needs to be modified.


JW, Thanks for devoting the time and effort on the Wiki.  Too many times we all forget it's all done voluntarily.

(Last edited by kirkgbr on 20 Jun 2017, 12:32)

@kirkgbr No problem at all.


@All Can variables be set & used in /etc/firewall.user?  If so, is a specific package required?

  • firewall.user is supposed to be treated as a shell script, however I know when I tried arokh's firewall.user months back, the $wan variable set in the file wasn't recognized

(Last edited by JW0914 on 20 Jun 2017, 20:03)

@JW0914

The 4.7k resistor should be connected between GND and RX on the adapter.
An alternative is to connect the resistor between GND an TX on the router side, but the modification is probably easier to do on the adapter.

@qawsed Thanks for catching that typo, it's been corrected.


I also corrected orphaned wrt1x00ac_series inter-wiki links from old page move in Oct (~24 in total)

(Last edited by JW0914 on 21 Jun 2017, 15:04)

sera wrote:

swrt-2017-06-13
---------------

This time it's just mwlwifi which now already includes the patches for 4.12 and
the provisional 4.13 besides the usual bumps.

Also backported the pwm-fan properties for armada-385 for modders.

The gpio-keys fixup isn't the on for Mamba, if it weren't already broken there,
it would have been broken now as did the others.


* linux-4.12: bump to 4.12-rc5
* linux-next: bump to next-20170613

* mwlwifi: bump to latest commit, drop patches

* kernel 4.12, 4.11: backport pwm properties for armada-385
* kernel next: drop revert, fixed mwlwifi instead. Add new bugfix for gpio-keys.

swrt-2017-06-13.tar.xz: https://gpldr.in/v/y6GHunaJaJ/BcruDPDuQ8QJolen
sha256sum: 8b2d60af53a598de5261d4c8db50f355c0a11929f1e4d5593626cc831bced237

why 404 not found ?

Ansuel wrote:
sera wrote:

swrt-2017-06-13
---------------

This time it's just mwlwifi which now already includes the patches for 4.12 and
the provisional 4.13 besides the usual bumps.

Also backported the pwm-fan properties for armada-385 for modders.

The gpio-keys fixup isn't the on for Mamba, if it weren't already broken there,
it would have been broken now as did the others.


* linux-4.12: bump to 4.12-rc5
* linux-next: bump to next-20170613

* mwlwifi: bump to latest commit, drop patches

* kernel 4.12, 4.11: backport pwm properties for armada-385
* kernel next: drop revert, fixed mwlwifi instead. Add new bugfix for gpio-keys.

swrt-2017-06-13.tar.xz: https://gpldr.in/v/y6GHunaJaJ/BcruDPDuQ8QJolen
sha256sum: 8b2d60af53a598de5261d4c8db50f355c0a11929f1e4d5593626cc831bced237

why 404 not found ?


Because of a "time window"...@sera .security aproach?

Someone can mirror me the package of explain me how to get last swrt?