@makedir, You're only seeing the bad stuff(typical of a forum). And what you're not seeing or hearing from are those of us who have months of uptime and zero problems.
(Last edited by kirkgbr on 16 Nov 2017, 12:45)
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.
Page 595 of 598
kirkgbr wrote:
@makedir, You're only seeing the bad stuff(typical of a forum). And what you're not seeing or hearing from are those of us who have months of uptime and zero problems.
This and this!
kirkgbr wrote:
@makedir, You're only seeing the bad stuff(typical of a forum). And what you're not seeing or hearing from are those of us who have months of uptime and zero problems.
That doesnt make any sense. This just means, that the majority of people dont come here to "complain", dont know their router doesnt work properly, or they use the original firmware (what I dont want to). What does this also mean? If I want to use Lede/OpenWrt I am forced to use Davids "build" because there are no alternatives. And if I use it and user x and user y have problems z, than I will have them too OR their router has a hardware defect. If many users have the same issues it is highly improbable the user has a hardware defect. I am not a "simple" user. I want to use the router under heavy CPU load, 5GHz wifi, lots of clients (20-30) and I expect zero reboots, zero problems with the Wifi, always max Wifi performance. Anyway, my WRT1200AC v2 is already shipped and will be here tomorrow or on Saturday. The first thing I will do is put latest build of Davids on it and "hope" for the best. I just wanted to know, under current build, that if a 99.9% stable operation is not guranteed for a WRT1200AC v2 with current Lede builds/wifi driver/4.9 kernel and what the chances for it are to work stable.
(Last edited by makedir on 17 Nov 2017, 04:07)
@makedir
Nobody forces you to use community builds. You can also use the official LEDE firmware.
nitroshift
makedir wrote:
kirkgbr wrote:@makedir, You're only seeing the bad stuff(typical of a forum). And what you're not seeing or hearing from are those of us who have months of uptime and zero problems.
That doesnt make any sense. This just means, that the majority of people dont come here to "complain", dont know their router doesnt work properly, or they use the original firmware (what I dont want to). What does this also mean? If I want to use Lede/OpenWrt I am forced to use Davids "build" because there are no alternatives. And if I use it and user x and user y have problems z, than I will have them too OR their router has a hardware defect. If many users have the same issues it is highly improbable the user has a hardware defect. I am not a "simple" user. I want to use the router under heavy CPU load, 5GHz wifi, lots of clients (20-30) and I expect zero reboots, zero problems with the Wifi, always max Wifi performance. Anyway, my WRT1200AC v2 is already shipped and will be here tomorrow or on Saturday. The first thing I will do is put latest build of Davids on it and "hope" for the best. I just wanted to know, under current build, that if a 99.9% stable operation is not guranteed for a WRT1200AC v2 with current Lede builds/wifi driver/4.9 kernel and what the chances for it are to work stable.
You could use snapshot builds, make your own build, use 17.1.4 or run gargoyle. All builds have there own quirks. The most unstable thing for these routers is the 5 GHZ and that is because of the wifi driver it all depends on what wifi clients you have, some people dont have any dropouts but then some people have a lot. I have a wrt3200acm and have uptimes of 10 days +. Then again i just use my 3200 as a router all wifi is handled by a c7 set up as a dumb AP, all QOS DNS UPNP DNSCrypt Addblock routing firewall EG EG is on the wrt3200acm. Hope this helps.
makedir wrote:
kirkgbr wrote:@makedir, You're only seeing the bad stuff(typical of a forum). And what you're not seeing or hearing from are those of us who have months of uptime and zero problems.
That doesnt make any sense. This just means, that the majority of people dont come here to "complain", dont know their router doesnt work properly, or they use the original firmware (what I dont want to). What does this also mean? If I want to use Lede/OpenWrt I am forced to use Davids "build" because there are no alternatives. And if I use it and user x and user y have problems z, than I will have them too OR their router has a hardware defect. If many users have the same issues it is highly improbable the user has a hardware defect. I am not a "simple" user. I want to use the router under heavy CPU load, 5GHz wifi, lots of clients (20-30) and I expect zero reboots, zero problems with the Wifi, always max Wifi performance. Anyway, my WRT1200AC v2 is already shipped and will be here tomorrow or on Saturday. The first thing I will do is put latest build of Davids on it and "hope" for the best. I just wanted to know, under current build, that if a 99.9% stable operation is not guranteed for a WRT1200AC v2 with current Lede builds/wifi driver/4.9 kernel and what the chances for it are to work stable.
I have to disagree with your first point. I believe there are a majority that are silent because they have no problems with LEDE/Openwrt.
Below is my wrt1200acV1 uptime using my own build.
root@caiman:~# uptime
06:39:37 up 27 days, 22:08, load average: 0.01, 0.00, 0.00The only reason for 27 days is because I chose to install a new version. Previous to that, it had literally months of uptime with zero problems.
And as others have said, you have a multitude of choices other than running community builds.
(Last edited by kirkgbr on 17 Nov 2017, 13:51)
I tend to look at it this way....... When one counts all the different sources.. I.E. Trunk, 3rd party (derived from trunk) and stable builds, and the amount of 1200ac, 1900ac(x), and 3200acm downloads per week, which is easily in the thousand(s), there is a small percentage of people having issues. There's no documentation to the following statement, but of those remaining people who have issues, I'd say 50% of those issues are usually solved over time. This leaves the other half to make a decision on if they can live with the issue, try another build, go back to Stock, or buy another unit/Brand. I have found in many cases if one just waits a few weeks, one of the developers will catch the issue and push a commit to fix it without any user intervention. There are other cases, like with wifi, where everone's hands are tied, and we just have to wait, and over time slowly receive a honed driver. Dealing with that, and this is just me, if the driver was that bad, I'd just buy and configure a good AP, disable the Linksys wifi, and hit the ground running. Fortunately, I've never had to do that, but it is certainly a cheap option if forced upon me.
Bottom line is the reason why we are here is because we want or need features the Stock firmware just doesn't deliver on, and there's a FREE way to get those features; using LEDE/OpenWrt. With that said, for this open source software, which has been collectively put together over the years, I'd say it is very successful, but not without its own issues that I believe are the nature of the beast.
My 2 cents --
Speaking of gremlins...
Does anyone know if the 1900AC still hangs/reboots every few days on 4.9 (and above) based builds?
I went back to 4.4 shortly after @sera went on "holidays" 
Cheers
For everyone but me apparently.
Villeneuve wrote:
For everyone but me apparently.
Thanks for that....
Late spring, I was able to trigger a reboot pretty much at will (with my set up @ 4.9/10/11) just by using torrent.
It sounds like things are more stable, so I may try again this weekend (if they bump trunk kernel to 4.9.61 in time)
Cheers
Hi, my 1900ACS v1 keeps random rebooting since lede revsion number after 5365, and r5365 itself is just working fine and stable.
I tried several trunk builds after that, all the same.
Hope I am not alone. It's just a clue before I could deep dive into it.
$ ./scripts/getver.sh 4b091ab01a
r5365-4b091ab01a
$ git log --oneline | grep 4b091ab01a
4b091ab01a ubus: update to the latest version(Last edited by tangsoft on 18 Nov 2017, 07:45)
tangsoft wrote:
Hi, my 1900ACS v1 keeps random rebooting since lede revsion number after 5365, and r5365 itself is just working fine and stable.
I tried several trunk builds after that, all the same.
Hope I am not alone. It's just a clue before I could deep dive into it.$ ./scripts/getver.sh 4b091ab01a r5365-4b091ab01a $ git log --oneline | grep 4b091ab01a 4b091ab01a ubus: update to the latest version
You're not alone if you're on kernel 4.9.
exactly, i am on kernel 4.9.
something wrong with the latest commit.
thanks!
The 4.9 kernel reboot thing is not new. Look at the link Villeneuve provided about 4 posts up. However, what is new is the inability to build 4.4 without having to jump thru hoops. Fortunately and thankfully InkblotAdmirer(previous page) gave some assistance on which hoops they are.
(Last edited by kirkgbr on 18 Nov 2017, 15:15)
kirkgbr wrote:
The 4.9 kernel reboot thing is not new. Look at the link Villeneuve provided about 4 posts up. However, what is new is the inability to build 4.4 without having to jump thru hoops. Fortunately and thankfully InkblotAdmirer(previous page) gave some assistance on which hoops they are.
I believe $tangsoft is speaking of reboot on the WRT1900ACS v1.
This is new, since previous reboot problems with kernel 4.9 were only present for the WRT1900AC v1.
tangsoft wrote:
Hi, my 1900ACS v1 keeps random rebooting since lede revsion number after 5365, and r5365 itself is just working fine and stable.
I tried several trunk builds after that, all the same.
Hope I am not alone. It's just a clue before I could deep dive into it.$ ./scripts/getver.sh 4b091ab01a r5365-4b091ab01a $ git log --oneline | grep 4b091ab01a 4b091ab01a ubus: update to the latest version
If you have a spare USB drive, start logging, so they can be copied and looked at.
yes, I have both 1900AC v1 and 1900ACS v1, ACS random rebooting is new.
I will try a logging as davidc502 said.
adri wrote:
kirkgbr wrote:The 4.9 kernel reboot thing is not new. Look at the link Villeneuve provided about 4 posts up. However, what is new is the inability to build 4.4 without having to jump thru hoops. Fortunately and thankfully InkblotAdmirer(previous page) gave some assistance on which hoops they are.
I believe $tangsoft is speaking of reboot on the WRT1900ACS v1.
This is new, since previous reboot problems with kernel 4.9 were only present for the WRT1900AC v1.
For those who may want to start logging to USB. I realize a vast majority already do and have been for years 
root@lede:~# ls -l /mnt <<< Looking in mnt and nothing there
root@lede:~# mkdir /mnt/usb <<< Make usb directory
root@lede:~# mount /dev/sda /mnt/usb <<< Mount the USB stick
root@lede:~# ls -l /mnt/usb <<<< Look in the usb directory and now see the contents.
-rw-r--r-- 1 root root 28205056 Aug 31 20:45 firewallLog.log
-rw-r--r-- 1 root root 240647 Nov 17 16:11 logging.log
drwx------ 2 root root 16384 May 5 2017 lost+found
-rw------- 1 root root 0 Oct 31 20:32 openvpn.log
root@lede:~# > /mnt/usb/logging.log <<< Just clearing the previous contents of the log.
root@lede:~# logread -f >> /mnt/usb/logging.log & <<< Starting the logread process and redirecting the output to USB.
root@lede:~# ps -ef |grep logread <<< Looking to verify it is now running.
root 3522 3502 0 20:25 pts/0 00:00:00 logread -f <<< Yes is now running
root 3524 3502 0 20:25 pts/0 00:00:00 grep logread5G dead on r5365@WRT1900ACSv1, it's never happened before. I grabbed some logs as following:
# logread
Sun Nov 19 18:20:46 2017 kern.err kernel: [111123.786219] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 19 18:20:46 2017 kern.err kernel: [111123.791762] ieee80211 phy0: return code: 0x1125
Sun Nov 19 18:20:46 2017 kern.err kernel: [111123.796421] ieee80211 phy0: timeout: 0x1125
Sun Nov 19 18:20:50 2017 kern.err kernel: [111127.844990] ieee80211 phy0: cmd 0x9125=BAStream timed out
Sun Nov 19 18:20:50 2017 kern.err kernel: [111127.850529] ieee80211 phy0: return code: 0x1125
Sun Nov 19 18:20:50 2017 kern.err kernel: [111127.855165] ieee80211 phy0: timeout: 0x1125
Sun Nov 19 18:22:24 2017 daemon.err odhcp6c[1275]: Failed to send DHCPV6 message to ff02::1:2 (Permission denied)
Sun Nov 19 18:23:11 2017 user.warn ddns-scripts[2174]: tangsoft_ipv4: Updating IP at DDNS provider failed - starting retry 180/0
Sun Nov 19 18:23:57 2017 daemon.info odhcpd[1210]: Using a RA lifetime of 0 seconds on br-lan
Sun Nov 19 18:24:22 2017 daemon.err odhcp6c[1275]: Failed to send DHCPV6 message to ff02::1:2 (Permission denied)
Sun Nov 19 18:24:22 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 2c:20:0b:3f:7b:18
Sun Nov 19 18:24:22 2017 daemon.info hostapd: wlan0: STA 2c:20:0b:3f:7b:18 IEEE 802.11: disassociated due to inactivity
Sun Nov 19 18:24:26 2017 kern.err kernel: [111344.679865] ieee80211 phy0: cmd 0x9122=UpdateEncryption timed out
Sun Nov 19 18:24:26 2017 kern.err kernel: [111344.686147] ieee80211 phy0: return code: 0x1122
Sun Nov 19 18:24:26 2017 kern.err kernel: [111344.690818] ieee80211 phy0: timeout: 0x1122
Sun Nov 19 18:24:26 2017 kern.err kernel: [111344.695122] wlan0: failed to remove key (0, 2c:20:0b:3f:7b:18) from hardware (-5)
Sun Nov 19 18:24:26 2017 daemon.info hostapd: wlan0: STA 2c:20:0b:3f:7b:18 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Nov 19 18:24:30 2017 kern.err kernel: [111348.689616] ieee80211 phy0: cmd 0x9111=SetNewStation timed out
Sun Nov 19 18:24:30 2017 kern.err kernel: [111348.695572] ieee80211 phy0: return code: 0x1111
Sun Nov 19 18:24:30 2017 kern.err kernel: [111348.700262] ieee80211 phy0: timeout: 0x1111
Sun Nov 19 18:24:33 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 04:52:f3:28:ee:a2
Sun Nov 19 18:24:33 2017 daemon.info hostapd: wlan0: STA 04:52:f3:28:ee:a2 IEEE 802.11: disassociated due to inactivity
Sun Nov 19 18:24:37 2017 kern.err kernel: [111355.700855] ieee80211 phy0: cmd 0x9122=UpdateEncryption timed out
Sun Nov 19 18:24:37 2017 kern.err kernel: [111355.707081] ieee80211 phy0: return code: 0x1122
Sun Nov 19 18:24:37 2017 kern.err kernel: [111355.711717] ieee80211 phy0: timeout: 0x1122
Sun Nov 19 18:24:37 2017 kern.err kernel: [111355.716013] wlan0: failed to remove key (0, 04:52:f3:28:ee:a2) from hardware (-5)
Sun Nov 19 18:24:37 2017 daemon.info hostapd: wlan0: STA 04:52:f3:28:ee:a2 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Nov 19 18:24:37 2017 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5
Sun Nov 19 18:24:41 2017 kern.err kernel: [111359.712860] ieee80211 phy0: cmd 0x9111=SetNewStation timed out
Sun Nov 19 18:24:41 2017 kern.err kernel: [111359.718817] ieee80211 phy0: return code: 0x1111
Sun Nov 19 18:24:41 2017 kern.err kernel: [111359.723456] ieee80211 phy0: timeout: 0x1111
Sun Nov 19 18:24:41 2017 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5
Sun Nov 19 18:25:28 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 6c:19:c0:78:fa:48
Sun Nov 19 18:25:28 2017 daemon.info hostapd: wlan0: STA 6c:19:c0:78:fa:48 IEEE 802.11: disassociated due to inactivity
Sun Nov 19 18:25:32 2017 kern.err kernel: [111410.504405] ieee80211 phy0: cmd 0x9122=UpdateEncryption timed out
Sun Nov 19 18:25:32 2017 kern.err kernel: [111410.510615] ieee80211 phy0: return code: 0x1122
Sun Nov 19 18:25:32 2017 kern.err kernel: [111410.515289] ieee80211 phy0: timeout: 0x1122
Sun Nov 19 18:25:32 2017 kern.err kernel: [111410.519577] wlan0: failed to remove key (0, 6c:19:c0:78:fa:48) from hardware (-5)
Sun Nov 19 18:25:32 2017 daemon.info hostapd: wlan0: STA 6c:19:c0:78:fa:48 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Nov 19 18:25:36 2017 kern.err kernel: [111414.516317] ieee80211 phy0: cmd 0x9111=SetNewStation timed out
Sun Nov 19 18:25:36 2017 kern.err kernel: [111414.522269] ieee80211 phy0: return code: 0x1111
Sun Nov 19 18:25:36 2017 kern.err kernel: [111414.526928] ieee80211 phy0: timeout: 0x1111
Sun Nov 19 18:25:36 2017 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5
Sun Nov 19 18:25:42 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED f0:24:75:99:7c:77
Sun Nov 19 18:25:42 2017 daemon.info hostapd: wlan0: STA f0:24:75:99:7c:77 IEEE 802.11: disassociated due to inactivity
Sun Nov 19 18:25:46 2017 kern.err kernel: [111424.367808] ieee80211 phy0: cmd 0x9122=UpdateEncryption timed out
Sun Nov 19 18:25:46 2017 kern.err kernel: [111424.374053] ieee80211 phy0: return code: 0x1122
Sun Nov 19 18:25:46 2017 kern.err kernel: [111424.378689] ieee80211 phy0: timeout: 0x1122
Sun Nov 19 18:25:46 2017 kern.err kernel: [111424.382987] wlan0: failed to remove key (0, f0:24:75:99:7c:77) from hardware (-5)
Sun Nov 19 18:25:46 2017 daemon.info hostapd: wlan0: STA f0:24:75:99:7c:77 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Nov 19 18:25:50 2017 kern.err kernel: [111428.380004] ieee80211 phy0: cmd 0x9111=SetNewStation timed out
Sun Nov 19 18:25:50 2017 kern.err kernel: [111428.385986] ieee80211 phy0: return code: 0x1111
Sun Nov 19 18:25:50 2017 kern.err kernel: [111428.390640] ieee80211 phy0: timeout: 0x1111
Sun Nov 19 18:25:50 2017 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5
Sun Nov 19 18:25:50 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 00:9e:c8:b5:1e:a8
Sun Nov 19 18:25:50 2017 daemon.info hostapd: wlan0: STA 00:9e:c8:b5:1e:a8 IEEE 802.11: disassociated due to inactivity
Sun Nov 19 18:25:54 2017 kern.err kernel: [111432.371214] ieee80211 phy0: cmd 0x9122=UpdateEncryption timed out
Sun Nov 19 18:25:54 2017 kern.err kernel: [111432.377435] ieee80211 phy0: return code: 0x1122
Sun Nov 19 18:25:54 2017 kern.err kernel: [111432.382080] ieee80211 phy0: timeout: 0x1122
Sun Nov 19 18:25:54 2017 kern.err kernel: [111432.386368] wlan0: failed to remove key (0, 00:9e:c8:b5:1e:a8) from hardware (-5)
Sun Nov 19 18:25:54 2017 daemon.info hostapd: wlan0: STA 00:9e:c8:b5:1e:a8 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Nov 19 18:25:58 2017 kern.err kernel: [111436.361801] ieee80211 phy0: cmd 0x9111=SetNewStation timed out
Sun Nov 19 18:25:58 2017 kern.err kernel: [111436.367757] ieee80211 phy0: return code: 0x1111
Sun Nov 19 18:25:58 2017 kern.err kernel: [111436.372412] ieee80211 phy0: timeout: 0x1111
Sun Nov 19 18:25:58 2017 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5
Sun Nov 19 18:25:58 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 3c:15:c2:d4:98:6a
Sun Nov 19 18:25:58 2017 daemon.info hostapd: wlan0: STA 3c:15:c2:d4:98:6a IEEE 802.11: disassociated due to inactivity
Sun Nov 19 18:26:02 2017 kern.err kernel: [111440.341366] ieee80211 phy0: cmd 0x9122=UpdateEncryption timed out
Sun Nov 19 18:26:02 2017 kern.err kernel: [111440.347587] ieee80211 phy0: return code: 0x1122
Sun Nov 19 18:26:02 2017 kern.err kernel: [111440.352233] ieee80211 phy0: timeout: 0x1122
Sun Nov 19 18:26:02 2017 kern.err kernel: [111440.356521] wlan0: failed to remove key (0, 3c:15:c2:d4:98:6a) from hardware (-5)
Sun Nov 19 18:26:02 2017 daemon.info hostapd: wlan0: STA 3c:15:c2:d4:98:6a IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Nov 19 18:26:06 2017 kern.err kernel: [111444.351616] ieee80211 phy0: cmd 0x9111=SetNewStation timed out
Sun Nov 19 18:26:06 2017 kern.err kernel: [111444.357582] ieee80211 phy0: return code: 0x1111
Sun Nov 19 18:26:06 2017 kern.err kernel: [111444.362236] ieee80211 phy0: timeout: 0x1111
Sun Nov 19 18:26:06 2017 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5
Sun Nov 19 18:26:06 2017 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 00:9e:c8:d1:15:db
Sun Nov 19 18:26:06 2017 daemon.info hostapd: wlan0: STA 00:9e:c8:d1:15:db IEEE 802.11: disassociated due to inactivity
Sun Nov 19 18:26:10 2017 kern.err kernel: [111448.331008] ieee80211 phy0: cmd 0x9122=UpdateEncryption timed out
Sun Nov 19 18:26:10 2017 kern.err kernel: [111448.337256] ieee80211 phy0: return code: 0x1122
Sun Nov 19 18:26:10 2017 kern.err kernel: [111448.341901] ieee80211 phy0: timeout: 0x1122
Sun Nov 19 18:26:10 2017 kern.err kernel: [111448.346189] wlan0: failed to remove key (0, 00:9e:c8:d1:15:db) from hardware (-5)
Sun Nov 19 18:26:10 2017 daemon.info hostapd: wlan0: STA 00:9e:c8:d1:15:db IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Sun Nov 19 18:26:14 2017 kern.err kernel: [111452.328515] ieee80211 phy0: cmd 0x9111=SetNewStation timed out
Sun Nov 19 18:26:14 2017 kern.err kernel: [111452.334470] ieee80211 phy0: return code: 0x1111
Sun Nov 19 18:26:14 2017 kern.err kernel: [111452.339110] ieee80211 phy0: timeout: 0x1111
Sun Nov 19 18:26:18 2017 kern.err kernel: [111456.336412] ieee80211 phy0: cmd 0x8050=broadcast_ssid_enable timed out
Sun Nov 19 18:26:18 2017 kern.err kernel: [111456.343074] ieee80211 phy0: return code: 0x0050
Sun Nov 19 18:26:18 2017 kern.err kernel: [111456.347733] ieee80211 phy0: timeout: 0x0050
Sun Nov 19 18:26:22 2017 kern.err kernel: [111460.337252] ieee80211 phy0: cmd 0x8127=SetInformationElements timed out
Sun Nov 19 18:26:22 2017 kern.err kernel: [111460.343997] ieee80211 phy0: return code: 0x0127
Sun Nov 19 18:26:22 2017 kern.err kernel: [111460.348665] ieee80211 phy0: timeout: 0x0127
Sun Nov 19 18:26:26 2017 kern.err kernel: [111464.347123] ieee80211 phy0: cmd 0x801c=80211RadioControl timed out
Sun Nov 19 18:26:26 2017 kern.err kernel: [111464.353446] ieee80211 phy0: return code: 0x001c
Sun Nov 19 18:26:26 2017 kern.err kernel: [111464.358082] ieee80211 phy0: timeout: 0x001c
Sun Nov 19 18:26:30 2017 kern.err kernel: [111468.353348] ieee80211 phy0: cmd 0x8126=SetFixedRate timed out
Sun Nov 19 18:26:30 2017 kern.err kernel: [111468.359209] ieee80211 phy0: return code: 0x0126
Sun Nov 19 18:26:30 2017 kern.err kernel: [111468.363910] ieee80211 phy0: timeout: 0x0126
Sun Nov 19 18:26:30 2017 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5tangsoft wrote:
yes, I have both 1900AC v1 and 1900ACS v1, ACS random rebooting is new.
I will try a logging as davidc502 said.adri wrote:kirkgbr wrote:The 4.9 kernel reboot thing is not new. Look at the link Villeneuve provided about 4 posts up. However, what is new is the inability to build 4.4 without having to jump thru hoops. Fortunately and thankfully InkblotAdmirer(previous page) gave some assistance on which hoops they are.
I believe $tangsoft is speaking of reboot on the WRT1900ACS v1.
This is new, since previous reboot problems with kernel 4.9 were only present for the WRT1900AC v1.
Open a new issue if you want traction on addressing mwlwifi problems.
Hello there,
I'm wondering if anyone could possibly help me please.
I'm very new to OpenWrt and finding it all quite confusing, but have managed to get "LEDE Reboot 17.01.4 r3560-79f57e422d / LuCI lede-17.01 branch (git-17.290.79498-d3f0685)" working on my WRT 1900ACS v2.
I followed a guide on youtube and it was working fine.
However I have noticed that the 2.4ghz channel will preiodically stop working. 5ghz is always fine, but 2.4ghz will not accept wifi logins. It will say "disabled" on my phone wifi settings and will look like it is going to connect and then doesn't.
Turning the router off and on again restores 2.4ghz for a half day or day, and then it stops working again. I had no problems with the stock firmware, but I changed as the wifi range was SO bad. Lede has much better range, but I can't use it if 2.4ghz won't work.
Can someone please help me? Sorry if this is a known issue or I have missed the proper procedure, but this is super complex for me!
Thanks for any help.
Install current mwlwifi.
Hi thanks for the tip.
After some confusion, I worked out how to do this, but when I try and install the latest MWLWIFI from github through the Luci interface, it says "failed to download" "WGET returned 8". I assume 8 is an error code.
I see people saying to install typing in the wget function, but I don't know how. Is that in "putty"?
I think most questions regarding issues on getting and installing are answered in the thread I linked above.
I think I've worked it out, thanks!
Page 595 of 598