Joined: 06 Jun 2006 Posts: 7463 Location: Dresden, Germany
Posted: Mon Sep 09, 2019 18:42 Post subject:
kernel-panic69 wrote:
adasch wrote:
adasch wrote:
Or maybe my Virtual Interfaces have error in config?
in build r35531 it's works in "Bridged" mode but and don't work in Unbridged mode
In build r40900 this feature don't work - other wifi units can't connect.
problem solved in r35531 (very stable for me)
default config put wrong data in one cell.
in tab Setup/Networking sector Bridging window MTU default setup puts data 1500>22 but should be only 1500
next step is turn on DHCP on wl0.1
now visitors receive 172.16.1.xxx ip's and safety DNS
no one see my servers tv's etc
Were the default config errors in 40900? You should be able to change that value and save it, which will commit it to nvram, then you can apply or reboot and should be ok.
if you downgrade you may gut such crap into fields since newer versions added new features. correct it manually or start from scratch. both works _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
Joined: 06 Jun 2006 Posts: 7463 Location: Dresden, Germany
Posted: Mon Sep 09, 2019 18:47 Post subject:
kernel-panic69 wrote:
PeteSL wrote:
I have an Asus AC-3100. I am currently on:
Firmware: DD-WRT v3.0-r40527 std (08/04/19)
I tried the "Experimental Driver" version a few months ago which bricked my router (was able to restore using ASUS firmware loader). I tend to update once a month (more if I experience issues with a particular build) but follow these threads closely. So my question is: "What is the experimental driver?" My follow-up question is "should I continue to periodically try it or should I stick with the standard firmware?"
So far, BTW, the r40527 has been working well for the past month including significant UDP forwarding with SFE turned on.
I'm being nice. This thread is for reporting issues with this build release.
the experimental driver is mac80211 based (brcmfmac). i tested it on a asus ac 88 and it works good for me. it should also resolve all sorts of vap problems. but it doesnt work with a configuration you created from a standard build. you need to reconfigure wireless completelly if you upgrade from a normal build. otherwise wireless will not work _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
Joined: 06 Jun 2006 Posts: 7463 Location: Dresden, Germany
Posted: Mon Sep 09, 2019 19:14 Post subject:
flyzipper wrote:
Router/Version: Netgear R7000
Firmware: DD-WRT v3.0-r40900 std (09/04/19)
Kernel: Linux 4.4.190 #1136 SMP Wed Sep 4 06:03:54 +04 2019 armv7l
Previous: r40890
Mode/Status: Gateway / working
Reset: no
Issues/Errors: Working well so far.
Edit... fq_codel_fast still soft-bricks my router immediately after it's enabled. Looks like I need to learn how to open a ticket...
Uptime: 1hr 5min
Temperatures: CPU 68.6 °C / WL0 48.5 °C / WL1 54.1 °C
you dont need to. its easier if you contact the fq_codel_fast developer. i cannot much help here and it works for most devices. but so far broadcom devices have the problem of the most shit wireless driver in this works. this driver is seeking always for a reason to crash. i can just suggest. avoid broadcom devices in future and all will be fine and more powerfull. since broadcom refuses to update wireless drivers and if i receive a update in some way its just getting worse and even more unstable. _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
I have an Asus AC-3100. I am currently on:
Firmware: DD-WRT v3.0-r40527 std (08/04/19)
I tried the "Experimental Driver" version a few months ago which bricked my router (was able to restore using ASUS firmware loader). I tend to update once a month (more if I experience issues with a particular build) but follow these threads closely. So my question is: "What is the experimental driver?" My follow-up question is "should I continue to periodically try it or should I stick with the standard firmware?"
So far, BTW, the r40527 has been working well for the past month including significant UDP forwarding with SFE turned on.
I'm being nice. This thread is for reporting issues with this build release.
the experimental driver is mac80211 based (brcmfmac). i tested it on a asus ac 88 and it works good for me. it should also resolve all sorts of vap problems. but it doesnt work with a configuration you created from a standard build. you need to reconfigure wireless completelly if you upgrade from a normal build. otherwise wireless will not work
Is the experimental driver good for the AC5300, someone else said it bricked his ac5300, wonder if its ok now. I am having some major issues with 2.4ghz channel. I cant even connect and if I do its super slow and wont even stay up half the time. This is the same issue with NVram resets using both kong and your bullds. I am about to RMA my ac5300.
Joined: 06 Jun 2006 Posts: 7463 Location: Dresden, Germany
Posted: Mon Sep 09, 2019 22:10 Post subject:
at least i tested it on a ac 5300 and it did not brick it. basicly you cannot brick. it. its impossible. there is always a recovery mode _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
at least i tested it on a ac 5300 and it did not brick it. basicly you cannot brick. it. its impossible. there is always a recovery mode
Awesome to hear brainslayer.. maybe I'll give it a try. My 2.4ghz radio is acting up and i doubt this driver will make it work but at this point I'll try anything.
Thanks for all your work on ddwrt. I've been using your builds for over 10yrs, that's an amazing run, hope you can keep going.
you dont need to. its easier if you contact the fq_codel_fast developer. i cannot much help here and it works for most devices. but so far broadcom devices have the problem of the most shit wireless driver in this works. this driver is seeking always for a reason to crash. i can just suggest. avoid broadcom devices in future and all will be fine and more powerfull. since broadcom refuses to update wireless drivers and if i receive a update in some way its just getting worse and even more unstable.
In that case, fq_codel_fast should be removed from Broadcom devices.
Joined: 06 Jun 2006 Posts: 7463 Location: Dresden, Germany
Posted: Thu Sep 12, 2019 14:05 Post subject:
it was fixed one day later with another commit. one user already tested it and its working now as expected. as soon as the nightly build passes without errors i will release a new build with other enhancement. including a new version for the experimental driver for newer broadcom arm devices and a enhance deep packet inspection module _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
it was fixed one day later with another commit. one user already tested it and its working now as expected. as soon as the nightly build passes without errors i will release a new build with other enhancement. including a new version for the experimental driver for newer broadcom arm devices and a enhance deep packet inspection module
Both BrainSlayer and Kernel-Panic69 Thank you so much for all help. I will also try the experimental driver on my AC5300 when you release this latest build.