When you run the "wl revinfo" command on the manufacturer’s firmware with driver 6.37.14.86 (r456083) is the ucode version:
0x38b006f (Like the Asus's RT-68U firmware since 4/24/14)
33%
[ 3 ]
0x38b006e (Like the DD-WRT RT-68U firmware since 3/29/14)
66%
[ 6 ]
something else (Make sure the driver is driver 6.37.14.86 (r456083) before selecting this option.)
0%
[ 0 ]
Total Votes : 9
Author
Message
TCkDfz DD-WRT Novice
Joined: 23 Aug 2014 Posts: 37
Posted: Wed Jan 14, 2015 22:05 Post subject: Random/sporadic reboots, wl0_ampdu=off, in these routers
Do you experience random/sporadic reboots with any of these routers?
ASUS:
RT-AC66R
RT-AC66U
RT-AC66W
RT-AC68P
RT-AC68R
RT-AC68U
RT-AC68W
RT-AC87R
RT-AC87U
RT-N18U
Buffalo:
WZR-1750DHP
WZR-D1100H
WZR-D1800H
Linksys:
EA6500 v1
EA6500 v2
EA6700
EA6900 v1.0
EA6900 v1.1
Netgear:
AC1450
R6300 v1
R6300 v2
R6700
R7000
TP-LINK:
Archer C8 v1
TRENDnet:
TEW-812DRU v1
TEW-812DRU v2
TEW-818DRU
For months in the forum I've seen many posts using various subjects with everyone having the same random reboot issue seemingly because of the BCM4360 WiFi chipset and incompatibility with certain devices possibly because of the ampdu setting in DD-WRT. I created the above lists mostly using data from https://wikidevi.com. I can't confirm the accuracy and I may have made some errors. I'll be happy to update if needed and am able.
I have an Asus RT-AC68U and have been troubleshooting. I've had various results with different builds, modifications to the 2.4 and 5 GHz settings, and protocols. My best results were associating the newest devices to the 5 GHz and all other devices use the 2.4 in g-mode only but that's not the point of my post.
I tested DD-WRT builds from 23270M to r25887, those are Kong and BrainSlayer builds including those with OLDD and NEWD. I tested the Asus stock firmware from 3.0.0.4.374.371 on 11/20/13 to 3.0.0.4.378.3873 on 1/12/15. When I checked the driver version on them the only two common versions between the DD-WRT and Asus were versions 6.37.14.62 (r437318) and 6.37.14.86 (r456083).
Builds r23320-fix through r23720, and Asus 3.0.0.4.374.583 use driver 6.37.14.62 (r437318). DD-WRT builds from 23838 (NEWD on Kong builds) and Asus 3.0.0.4.374.5656 onward use the 6.37.14.86 (r456083) driver.
If you don't already know how to determine the driver version you telnet or SSH to the router and run the "wl ver" command. (Note: the user name for telnet or SSH is always "root" then the default password or password you set.)
Another option for the wl command is "wl revinfo". When I ran that command everything was identical with the exception of the driverrev and ucoderev fields which changed with the driver version. When I ran it on the DD-WRT and Asus builds with the 6.37.14.62 (r437318) driver those two fields matched. When I ran it on the DD-WRT and Asus builds with the 6.37.14.86 (r456083) driver the driverrev fields matched but the ucoderev didn't. On the DD-WRT builds the ucoderev is 0x38b006e. On the Asus builds since April 2014 it's 0x38b006f. From my research it appears the ucode is also known as the microcode. I haven't been able to find out much about it other than it sets various options on the driver. I googled 0x38b006f and 0x38b006e. The only results were for 0x38b006e in reference to DD_WRT on the TRENDnet TEW-811DRU so it appears that the driver is most likely identical across all the routers with the BCM4360 chipset.
It seems like the cause of the random reboots may be because of the different ucoderev. Since I don't have any of the other routers I'm asking those that do to make a comparison of the "wl revinfo" ucoderev on the DD-WRT and stock firmware. BrainSlayer, Kong, or anyone else, can you provide any insight on the significance of the ucoderev and can we get a build with the 0x38b006f version?
During my testing I also discovered that from the earliest DD-WRT build to the latest there is a 0-11 ms ping delay to the router and a 10-150 ms delay to my ISP gateway but with the stock firmware there is 0 delay to the router and gateway. I haven't had time to research this yet but if anyone has any insight and can point me in the right direction I would greatly appreciate it. _________________ ASUS RT-AC68U using build v3.0-r28000M kongac (10/24/15).
I noticed someone voted but didn't provide any details about which router and firmware they tested. If someone hasn't already posted about your router with the manufacturer's firmware running driver version 6.37.14.86 (r456083) please post details about your findings.
I tested the Asus RT-AC87U and the manufacturer's driver version 6.37.14.86 (r456083) had ucoderev 0x38b006f but the latest DD-WRT build had ucoderev 0x38b006e. _________________ ASUS RT-AC68U using build v3.0-r28000M kongac (10/24/15).
Hi!
Thanks for all your hard work man! I wasn't the guy that voted but I would like to share my appreciation with you for what you (and other guys like Kong and BS) are doing to get this issue solved.
I don't have a device with stock (manufacturers) firmware and it is mission critical so unfortunately I cant help there. However, is the so-called 'ucoderev' 'micro code' a synonim for firmware of the broadcom chip? Do you think if we flash the latest manufacturers firmware the latests version will be updated to the *f version? It could be that the NEWD (latest broadcom) drivers are incompatible with the older *e version.
Joined: 24 Oct 2009 Posts: 319 Location: Buenos Aires-Argentina, End of World and new Pope's home.
Posted: Fri Jan 16, 2015 22:28 Post subject:
I am on r7000 since released, never had a reboot nor disconections. In old specific +250 pages R7000 threads i explained my walk around alot of times, just reboot every day at 5am.
I stay on my sig. firm, test new ones & then go back.
Just my 2 cts. _________________ R7000 testing XVortex/Merlin's firm as AP @ home, VOIP, wifi printer, Roku 3 & 8 clients, Guest wifi, 2 wifi cameras, USB storage. Great firm. No more 1400 oveclocked, no need.
RT-N16 on VicTek's Raf Beta 9014-v1.3d. repeater @ Condominium pool side, a lot of clients messing arround.
wrt600n on wrt610n firm 16214 @ warehouse for 22 colleagues as wifi client @ 2.4 Ghz and 5 Ghz just for me.
wrt54gl on Eko's @ warehose as repeater for 22 coleagues as wifi client
wrt350n oldie 2007, 5 years bricked, recovered from dead & modded with antennas and new agn radio now incredible "NA mixed" on Brainslayer's , repeater at my garage, modding as hobby (picture)
All at service.
Kong said: Yeah that stupid 30/30/30. I already said it multiple times on newer units build in the last 2 years this is not the way to do it
I don't have a device with stock (manufacturers) firmware and it is mission critical so unfortunately I cant help there. However, is the so-called 'ucoderev' 'micro code' a synonim for firmware of the broadcom chip? Do you think if we flash the latest manufacturers firmware the latests version will be updated to the *f version? It could be that the NEWD (latest broadcom) drivers are incompatible with the older *e version.
I'm not exactly sure what the ucoderev is. From all of my Google searches the best I can deduce is that it's microcode within the driver and isn't part of the chipset. When Asus and DD-WRT were both using Broadcom driver 6.37.14.62 (r437318) both reported the driverrev as 0x6250e3e and the ucoderev as 0x3820003. The latest Asus and DD-WRT firmware are using Broadcom driver 6.37.14.86 (r456083). Both report the driverrev as 0x6250e56 but Asus's ucoderev is 0x38b006f and DD-WRT's is 0x38b006e. So far no one has been able to answer why the mismatch on the new driver version but not on the other one.
Asus released firmware with driver versions 6.37.14.73 (r448163) and 6.37.14.34 (r415984) but DD-WRT didn't so I only have the two to compare. I wish I knew a way to determine the ucoderev without loading the firmware so I could check the other manufacturers' but the only way I know how is with the "wl revinfo" command. You can extract the driver from the firmware and get the version by running the strings command but it doesn't show the ucoderev. If someone knows a command or method that will work please let me know.
Briefcase, I appreciate your mission critical situation but if you have a different model, get a maintenance or down-time opportunity, and could load the manufacturers firmware to quickly compare it could be a big help.
mito wrote:
In old specific +250 pages R7000 threads i explained my walk around alot of times, just reboot every day at 5am.
I stay on my sig. firm, test new ones & then go back.
Just my 2 cts.
I appreciate that you find that to be an acceptable workaround. I would too if it weren't for two things: First, the newer versions fix vulnerabilities like in OpenSSL. Second, beamforming takes time to learn and adapt. I need that feature since my router is on one end of the house and all the clients are on the other end. If it weren't for that I'd script my router to clone a new mac address and reboot itself and my cable modem every day too.
I think it's best practice not to upgrade/patch any firmware, drivers, or software just because a new version comes out. I read the release notes and like to stay on the older tested versions that don't have issues that affect me.
mito wrote:
I stay on my sig. firm, test new ones & then go back.
The next time you test a new one will you take a few extra minutes to load the manufacturer's latest and compare the driver version, driverrev, and ucoderev? If you have the time and are willing if you would also test r23720 and a manufacturer's release from around January 2014 both should be running version 6.37.14.62 (r437318) and would provide significant data to determine if the ucoderev usually matches.
The Asus firmware on 11/20/2013 has driver 6.37.14.34 (r415984) and on 2/13/2014 has driver 6.37.14.73 (r448163). I couldn't find any DD-WRT versions with those drivers. Kong's OLDD driver is 6.30.163.42 (r396477) from 10/19/13. _________________ ASUS RT-AC68U using build v3.0-r28000M kongac (10/24/15).
My ASUS RT-AC68U it's stable, there are lots of bugs (read in my signature) but it doesn't reboot randomly. _________________ ASUS RT-AC68U Build 25974 (20 JAN 2015)
builds tried:
23503-23919-25697-25760-25887-25934-25948-25974
BUGS found:
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=945120#945120
Posted: Mon Jan 19, 2015 5:36 Post subject: Re: Routers reboots itself
zabrewolf wrote:
I have a Tp Link WDR4300...Atheros AR9344...And a Tp Link WDR3600 with same chipset.
Booth reboots randomly every 1 or 2 ours.
As you said, those models have Atheros chipsets and not the Broadcom BCM4360 which is what this thread is about. The problem with the BCM4360 seems to be an incompatibility with certain client devices because of the ampdu setting. All of the posts I've seen have been about routers with this chipset rebooting because of client devices with older Broadcom chipsets but I have a D-Link DWA-160 version A2 that caused my router to reboot and I believe it has an Atheros chipset. I don't believe it's likely but it's certainly possible your problem could be the reverse with a Broadcom client causing your routers to reboot.
The fix that has been released by Broadcom and the router manufacturer's is a new driver. DD-WRT supposedly has that new driver but I started this thread to disclose a discrepancy I found and ask others to confirm or disprove it. BrainSlayer has said he can't reproduce the problem so he's waiting on Broadcom to fix it. Since the new driver fixed the problem for the manufacturers it may be a very long time if a new driver is ever released. So far I've been surprised by how few responses I've gotten since the problem seems to affect so many people.
The workaround for the Broadcom routers is to disable the ampdu setting on the 2.4 GHz interface by running the commands:
nvram set wl0_ampdu=off
nvram commit
reboot
The commands for your routers would be the same assuming the 2.4 GHz interface is wl0. If your 5 GHz interface is 0 then the 2.4 GHz would be 1 and the command would be wl1 instead of wl0. As I said it's a workaround and it significantly lowers the speed. To change the setting back to the default the command would be wl0_ampdu=auto. I recommend you backup your config before making the change so you can restore it if needed.
I run those commands by SSHing to the router but you can also use telnet. Theoretically you should be able to run them from the web interface by going to Administration | Commands but I've never done it that way.
My former job was an IT Manager and had to support hundreds of APs and a wide variety of client devices like laptops, printers, scanners, TVs, etc. I can say with certainty that I've seen many performance issues because of incompatibilities between different manufacturer's chipsets. It's even worse when manufacturer's "tweek" their products by deviating from the IEEE or relevant standards like with the proprietary Atheros Super G or Broadcom 125 High Speed Mode. Many times issues can be resolved by changing settings or updating to a newer driver. Unfortunately sometimes the problem is with a device that you can't change settings or update such as a phone, printer, TV, etc. Worse is when the manufacturer no longer supports the device and won't fix their driver. As I pointed out in my post on 12/31/14 I resolved my reboot issues by identifying and removing the incompatible devices which is something you may have to do. I still want to permanently resolve the issue so I can restore my guest network, openwireless.org, and allow any device on my network.
For new readers that have one of the listed routers (except an RT-AC68U or RT-AC87U that I've already tested), or a router I didn't list with the Broadcom BCM4360 chipset please load the manufacturer's latest firmware and compare the driver version, driverrev, and ucoderev to those in DD-WRT. That information can be obtained by telnet or SSH to the router and run the "wl ver" and "wl revinfo" commands. _________________ ASUS RT-AC68U using build v3.0-r28000M kongac (10/24/15).
Posted: Mon Jan 19, 2015 19:34 Post subject: Re: Routers reboots itself
TCkDfz wrote:
The fix that has been released by Broadcom and the router manufacturer's is a new driver. DD-WRT supposedly has that new driver but I started this thread to disclose a discrepancy I found and ask others to confirm or disprove it.
What makes you think that? Kong and BrainSlayer have said time and time again in lots of threads that DD-WRT does NOT have the latest "fixed" Broadcom drivers. The reason is because Broadcom will not supply them. If they did, the reboot issue would be fixed.
Posted: Mon Jan 19, 2015 20:38 Post subject: Communications Team Lead
We are all in a position where we are desperately trying to both make sense of things, help narrow down the problem specifics and try to help everyone.
If anything this whole thing has helped change the very nature of the hostile forum responses. It further has actually engaged people who give a damn about themselves and others.Communication and dialogue are important for development, improvement as is community support of what essentially Free Open Source.
It's not a matter of "time and again" that's great. How about a real statement from the team? Maybe a where we are now and where we are going. This might allay some of the frustration. Yes we know they are working on it but sometimes reaching out to and communicating thoroughly and clearly with your userbase is beneficial to clarify direction. It's been time and again the "them" against "us" mentality simply be put to rest across the community. This responsibility as leaders is on the dev team leads until someone else is identified as the point person to communicate with the public.
tl;dr We need a clear demarcated point of contact to spearhead communication for DD-WRT. A short where we are and where we are going would be of real value to the community as a whole. We are all in this together and want it to be the best firmware it can be. It has grown beyond just BS and involves many many people now. It has been successful beyond probably what anyone ever anticipated. As projects grow and evolve how it maneuvers have reached a point where the Dev team should focus on what they are experts at, development. Someone from the team who is a PR person, media expert or with experience with working with the public step up. It's not that we are trying to whine or be obnoxious, we just actually give a damn about this project. Shit, about this idea of DD-WRT.
Joined: 13 Mar 2014 Posts: 856 Location: Montreal, QC
Posted: Mon Jan 19, 2015 20:52 Post subject: Re: Routers reboots itself
MikeMcr wrote:
TCkDfz wrote:
The fix that has been released by Broadcom and the router manufacturer's is a new driver. DD-WRT supposedly has that new driver but I started this thread to disclose a discrepancy I found and ask others to confirm or disprove it.
What makes you think that? Kong and BrainSlayer have said time and time again in lots of threads that DD-WRT does NOT have the latest "fixed" Broadcom drivers. The reason is because Broadcom will not supply them. If they did, the reboot issue would be fixed.
I also found that quote very misleading considering Kong replied directly to the OP the exact status of the issue days before the OP posted that comment.
<Kong> wrote:
We have enough light on it, we have a crash dump and know that it is a bug in ampdu handling, but I don't have the sources and I'm not affected, Brainslayer has the sources and he cannot reproduce it either, that's why we are waiting for the updated driver, which definitely has a fix for it.
The fix that has been released by Broadcom and the router manufacturer's is a new driver. DD-WRT supposedly has that new driver but I started this thread to disclose a discrepancy I found and ask others to confirm or disprove it.
What makes you think that? Kong and BrainSlayer have said time and time again in lots of threads that DD-WRT does NOT have the latest "fixed" Broadcom drivers. The reason is because Broadcom will not supply them. If they did, the reboot issue would be fixed.
I beieve that because of the testing I performed on my RT-AC66U and RT-AC87U as outlined in my posts. At the beginning of 2014 DD-WRT r23320-fix through r23720, and Asus 3.0.0.4.374.583 used Broadcom driver 6.37.14.62 (r437318) which I determined by running the "wl ver" command. All reported the driverrev as 0x6250e3e and ucoderev as 0x3820003 which I determined by running the "wl revinfo" command.
DD-WRT builds from 23838 (NEWD on Kong builds) and Asus 3.0.0.4.374.5656 onward use Broadcom driver 6.37.14.86 (r456083). When I ran the "wl revinfo" command on those they both report the driverrev as 0x6250e56 but the DD-WRT builds report the ucoderev as 0x38b006e and the Asus builds report 0x38b006f.
I tested 76 Asus and DD-WRT builds. With every one except those with Broadcom version 6.37.14.86 (r456083), the version, driverrev, and ucoderev have all matched. For example:
Broadcom version 6.30.163.42 (r396477) always has driverrev 0x61ea32a and ucoderev 0x32200d0.
Broadcom version 6.37 RC14.62 (r437318) always has driverrev 0x6250e3e and ucoderev 0x3820003.
I find it suspicious that whether the driver came from Asus or DD-WRT those three things always matched until the last version. I can't find any post in the the forum or anywhere else on the internet that references the Broadcom ucoderev. No one has answered my question about the significance of it.
as soon as my r7000 never crashes its hard to identify any issue.
i also have 2 ac68 devices which never crash. i heard that there is a issue with some iphone clients, but as soon as broadcom wont release any fix, i have to wait as well.
I sent him a message asking him to review my findings but I haven't had a response from him. Kong responded to a different post directing people to this subject but his response was just we know the cause and have a workaround. I followed-up asking had he even read my post. I don't think he did and I haven't seen a response. Their builds have had the identical drivers that Asus had until the last one. Does BrainSlayer only have Broadcom driver 6.37.14.86 (r456083) with ucoderev 0x38b006e and he's waiting on patch ucoderev 0x38b006f? I just find that difficult to believe since all the others matched.
Since I haven't heard about all the manufacturer's firmware randomly rebooting for nearly a year why do theirs work fine and DD-WRT's doesn't. As Kong said, we know the cause is with ampdu and the driver. The ucoderev may or may not be the source of the ampdu problem but I believe it probably is so the purpose of my post was to ask for someone to either explain the ucoderev significance or at least help me gather information by testing their model or router to help confirm or disprove my findings. _________________ ASUS RT-AC68U using build v3.0-r28000M kongac (10/24/15).
I'm using the very last official Kong build 25015M with my R6300v1 and had never random reboots.
Actually, I think that the very last official Kong build was 25090M. 25100M also came out just before Kong disappeared for a while, but the code did not differ from 25090M, just added debugging. Not that it matters a whole lot, just to keep the record straight.
I received an email from netgear team yesterday, they asked broadcom to can give us an update for the driver to fix the reboot problem and maybe supply us with the SDK7 needed by the R8000.
