Notes: 1. SFE accelerated NAT is in 33006+ builds but only in kernel 3.10 and newer 2. krack fixes for Broadcom were completed in r33678, including k26 (33655) & k24 (33656); use build 33772 or later.
3. Bridge modes on k4.4 devices may sometimes work in some configurations in certain builds but are not supported by the bcmdhd driver. Use client or repeater instead as WDS doesn't work with Broadcom ARM either (see Issue #4 below).
4.R6400v2 support added in r36811-36818, 36825, and 36826. R6700v3 support added in r36828-36840.
Tickets closed as 'fixed' (Broadcom-related and general): -
Important: if any issues are found, please provide log info (GUI syslog, `dmesg`, `cat /var/log/messages`).
Or put into SVN ticket. For firewall issues, also provide "iptables" info (`iptables -L`, `iptables -t nat -L`, & the /tmp/.ipt file).
Template to copy (after "Code:") for posting issues, be sure to include the mode in use (gateway, AP, CB, etc.):
WARNING:This thread is to report on flashing this experimental test build, providing important info for both developers and users. Always state your hardware model, version, mode (e.g. Repeater) and SPECIFIC build (e.g. 33555_NEWD-2_K3.x_mega-nv64k.bin). Please avoid discussions and create a new thread to discuss specific problems or questions, as this thread is for reporting, not support. Posts may be deleted or moved to keep this thread manageable and useful. If you don't understand the risks or what to flash and how, with a means of recovery if it bricks, do NOT flash this experimental test build.
Router/Version: Netgear R7000
Firmware: DD-WRT v3.0-r38159 std (01/02/19)
Kernel: Linux 4.4.169 #4419 SMP Mon Dec 31 09:50:12 CET 2018 armv7l
Previous: r38155
Mode/Status: Gateway / working
Reset: no
Issues/Errors: No issues so far.
Uptime: 44m
Temperatures: CPU 63.6 °C / WL0 48.3 °C / WL1 52.0 °C
Router/Version: Linksys WRT54GL 1.1
File: https://download1.dd-wrt.com/dd-wrtv2/downloads/betas/2019/01-02-2019-r38159/broadcom/dd-wrt.v24_voip_generic.bin
Firmware: DD-WRT v3.0-r38159 voip (01/02/19)
Kernel: Linux 2.4.37 #51569 Wed Jan 2 08:01:08 CET 2019 mips
Mode: Gateway / working
Status: All good! (but the only option I ever really use is SNMP)
Prior to this upgrade, I had been using dd-wrt.v24-15230_NEWD_std-nokaid_nohotspot_nostor.bin for the past 8+ years.
Last edited by uziq on Thu Jan 03, 2019 20:05; edited 1 time in total
Posted: Thu Jan 03, 2019 3:14 Post subject: new build daily??
What is this ? BS is going to be building FW files every day now ? _________________ WRT54GL v1.1 - Flashed
Linksys WRT54G2 v1 - Flashed
EA6350 v2 - Flashed
Joined: 08 May 2018 Posts: 14221 Location: Texas, USA
Posted: Thu Jan 03, 2019 7:22 Post subject: Re: new build daily??
technoside2 wrote:
What is this ? BS is going to be building FW files every day now ?
Apparently so, but nothing on Broadcom units are being worked on outside of what <Kong> supports directly, so I don't see the point in building Broadcom device builds until Broadcom-specific commits are made to the repository:
<Kong> wrote:
Broadcom HW is outdated right now. Especially MIPS based devices. I don't even have a single unit with this soc.
ARM broadcom will get more attention again once we receive new broadcom based units. But right now it is more fun to play with atheros, especially when you don't have to workaround the number of issues broadcoms nas has.
That being said, anyone who feels up to the tasks of fixing Broadcom-specific issues (and not just ARM devices).... the only problem is, 'we' don't have access to the SDKs and source codes required to un-muck things....
Posted: Thu Jan 03, 2019 7:25 Post subject: Re: new build daily??
kernel-panic69 wrote:
technoside2 wrote:
What is this ? BS is going to be building FW files every day now ?
Apparently so, but nothing on Broadcom units are being worked on outside of what <Kong> supports directly, so I don't see the point in building Broadcom device builds until Broadcom-specific commits are made to the repository:
<Kong> wrote:
Broadcom HW is outdated right now. Especially MIPS based devices. I don't even have a single unit with this soc.
ARM broadcom will get more attention again once we receive new broadcom based units. But right now it is more fun to play with atheros, especially when you don't have to workaround the number of issues broadcoms nas has.
That being said, anyone who feels up to the tasks of fixing Broadcom-specific issues (and not just ARM devices).... the only problem is, 'we' don't have access to the SDKs and source codes required to un-muck things....
they just proved that: A good business is, added new functions without being asked, but bugs who cares? Leave the bugs to user and they are going to enjoy, users love bugs......... or....... maybe not.......?
Joined: 08 May 2018 Posts: 14221 Location: Texas, USA
Posted: Thu Jan 03, 2019 16:27 Post subject:
My intent wasn't necessarily to be the Devil's Advocate or put anything toxic into the mix. There are a few things being worked on, but the concentration of the development effort is not Broadcom-specific. Not a matter of the devices being totally useless. Just a matter of a lot of broken things that need attention, and until that attention is given, user workarounds and bandaid fixes are our only resource outside of <Kong> supported devices.
My biggest problem right now is what to say and where to say it - and I would rather contribute to fixing things than the demise of this (part of the) forum or this project in general. BUT, navigating the repository is tedious....
I actually replaced an Atheros based router (D-Link DIR-825) with a Broadcom router (Archer C9) partly because of its vlan support (useful for ftth in our case). I always assumed that Broadcom hardware allows for more advanced network setups than Atheros but I might've been wrong.
Anyway I hope the devs keep supporting Broadcom or at least that they fix several major bugs in more recent builds. I went back to old build 35244 to regain actual VHT80 AC speeds (with 866 Mbps link speeds) and the possibility to set a fixed channel number instead of auto channel as the only option available with that channel width.
I actually replaced an Atheros based router (D-Link DIR-825) with a Broadcom router (Archer C9) partly because of its vlan support (useful for ftth in our case). I always assumed that Broadcom hardware allows for more advanced network setups than Atheros but I might've been wrong.
Anyway I hope the devs keep supporting Broadcom or at least that they fix several major bugs in more recent builds. I went back to old build 35244 to regain actual VHT80 AC speeds (with 866 Mbps link speeds) and the possibility to set a fixed channel number instead of auto channel as the only option available with that channel width.
i'm using a c9 on this build and i'm able to choose a fixed channel and i get ac speeds without issue.
Posted: Thu Jan 03, 2019 23:01 Post subject: EA6350 V2
I wasn't trying to be rude or anything, I was just noticing BS has been releasing alot of new builds lately. Is my EA6350v2 considered a SOC or an ARM based. I think it's lumped into the Broadcom SOC you guys are talking about. If so that kind of sucks, b/c I have no way of reverting back to Stock and I'm kind of stuck with DD-wrt indefinitely on this router. "broadcom bcm4708" is what I see for CPU model.
I'd like to see a fix for the 2.4Ghz Wireless security. Every time the Router reboots the 2.4Ghz goes unprotected. I have to re-apply in Web GUI to re-protect my 2.4Ghz wireless.
anyone have a workaround for this? _________________ WRT54GL v1.1 - Flashed
Linksys WRT54G2 v1 - Flashed
EA6350 v2 - Flashed
Joined: 08 May 2018 Posts: 14221 Location: Texas, USA
Posted: Fri Jan 04, 2019 15:55 Post subject:
@technoside2, you weren't being rude, it was an honest question. Yes, your devices is a Broadcom-ARM SoC, so it will probably get more attention than the older MIPS devices, whenever attention focuses back on Broadcom anything.
Here's my 'report'. Same details as before with the exception of build number and file number, nothing new, no problems fixed... but, it is operational. Really wished I could pinpoint which commit(s) caused the filesystem errors and kernel panic....