I am still willing to step through test builds, or bisect r50932 through r50962 to help locate where the crash begins.
BTW not only at boot firmware switch to Vanilla it can also easily be triggered with apply button in wireless settings.
BrainSlayer wrote:
again the single crash is intentional. to reload the firmware vom dd-wrt to vanilla it have todo a very dirty trick
which may crash the wifi card. (depends on the chipset) but it reloads the vanilla firmware then and reinitializes.
In the case of wireless settings (no changes) there is no reload from dd-wrt to vanilla just click apply radios crash.
Still think there are benefits to step through changes if anything to better understand why vanilla is now so fragile.
Builds r50474 through r50931 dmesg are clean no crashes are displayed and same vanilla binary crc32 4716237b.
Upgraded from: DD-WRT v3.0-r51741 std (02/18/23) (had been up for nearly 4 weeks)
Reset: No, not this time
Status: Up and running for 8 hours, basic setup as Gateway, static leases, port forwarding DDNS, WOL, 2,4GHz, VAP for IoT, 5Ghz, (Vanilla Firmware, Disabled Airtime), DDNS (Inadyn) to freedns.afraid.org.
On demand governor with minimum 800 MHz.
IPv6 working with PD /56.
Errors: The 5 GHz channel selection is action up. After upgrade it had reverted to auto (I had 80 MHz, 100 UU) the channel was OK and was working, in the end I had to choose 112 LL.
Log was clean and performance was good.
Thanks BS!
I reverted to 51741.
5 GHz is acting up the signal seems weaker but the main problem started after I Enabled VLAN on the switch config tab (a new setting), I lost WAN access
It turned out my CPU ports became tagged which stops WAN access, I could untagged them which restored WAN access but this is just BAD!
After downgrading it was completely borked and I had to reset to defaults luckily I had a backup.
Not good this build
this is caused by a bugfix. the switch config tab was inoperational the last builds. now its working again. so you stumbled about a working feature and you reverted because the non working page made less troubles?
and of course you can tag ports per vlan. (or not). just do it. its just a checkbox
what you miss is that its not possible that a port is member of multiple vlans. your screenshot of openwrt shows nothing else. so its enough to set the tag property by port which becomes than a property of the vlan membership then. so the vlan assigned to the port is then tagged (or untagged). thats all.
about the so called "weaker" signal. there was also a fix for the power setting which may have not worked for some builds. so the so called weaker signal might be just caused by your now working output power setting. (which you can increase of course)
Thanks for looking into this.
What I miss in the Switch config tab are two things:
1. The CPU ports in the interface
2. The ability to set the tagging of a port per VLAN, according to the RFC it is possible to have one untagged VLAN and one or more tagged VLANs per port, with DDWRT it is all or nothing.
regarding the tagged CPU ports, as far as I know all single arm routers have a tagged CPU port.
Do they also have problems with the WAN or are they just configured correctly?
Upgraded from: DD-WRT v3.0-r51741 std (02/18/23) (had been up for nearly 4 weeks)
Reset: No, not this time
Status: Up and running for 8 hours, basic setup as Gateway, static leases, port forwarding DDNS, WOL, 2,4GHz, VAP for IoT, 5Ghz, (Vanilla Firmware, Disabled Airtime), DDNS (Inadyn) to freedns.afraid.org.
On demand governor with minimum 800 MHz.
IPv6 working with PD /56.
Errors: The 5 GHz channel selection is action up. After upgrade it had reverted to auto (I had 80 MHz, 100 UU) the channel was OK and was working, in the end I had to choose 112 LL.
Log was clean and performance was good.
Thanks BS!
I reverted to 51741.
5 GHz is acting up the signal seems weaker but the main problem started after I Enabled VLAN on the switch config tab (a new setting), I lost WAN access
It turned out my CPU ports became tagged which stops WAN access, I could untagged them which restored WAN access but this is just BAD!
After downgrading it was completely borked and I had to reset to defaults luckily I had a backup.
Not good this build
this is caused by a bugfix. the switch config tab was inoperational the last builds. now its working again. so you stumbled about a working feature and you reverted because the non working page made less troubles?
and of course you can tag ports per vlan. (or not). just do it. its just a checkbox
what you miss is that its not possible that a port is member of multiple vlans. your screenshot of openwrt shows nothing else. so its enough to set the tag property by port which becomes than a property of the vlan membership then. so the vlan assigned to the port is then tagged (or untagged). thats all.
about the so called "weaker" signal. there was also a fix for the power setting which may have not worked for some builds. so the so called weaker signal might be just caused by your now working output power setting. (which you can increase of course)
Thanks for looking into this.
What I miss in the Switch config tab are two things:
1. The CPU ports in the interface
2. The ability to set the tagging of a port per VLAN, according to the RFC it is possible to have one untagged VLAN and one or more tagged VLANs per port, with DDWRT it is all or nothing.
See attached picture how that would look like for DDWRT
the point is not what your RFC says. the switch doesnt like more than one vlan assigned per port. so setting the tagged/untagged flag per port is enough since its just a assigned to a single vlan anyway
and configs like "ports: 1 2 3 5" make no sense. the vlan1 here is then just a assignment group. the vlan1 does not do anything. you connected just the ports together. all communication is handled by the cpu port. no vlan is involved. but that not the point of the gui. if its just about that what you want, then we have another problem. the vlan enable flag of the switch. to assign such ports the vlan_enable flag must be 0. but this also means that all other vlans wont work anymore. you have to consider how the switch works. no matter what you want or think is right. the switch is more limited than you think _________________ "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
EA8500 r51976 crashing (without recovery) is fixed with r52004, but remains single a crash per radio since r50963.
I am still willing to step through test builds, or bisect r50932 through r50962 to help locate where the crash begins.
BTW not only at boot firmware switch to Vanilla it can also easily be triggered with apply button in wireless settings.
blkt wrote:
In the case of wireless settings (no changes) there is no reload from dd-wrt to vanilla just click apply radios crash.
Still think there are benefits to step through changes if anything to better understand why vanilla is now so fragile.
Builds r50474 through r50931 dmesg are clean no crashes are displayed and same vanilla binary crc32 4716237b.
Apologies for blaming dynamic autoburst, but also before buried as an experimentaloption dmesg looked like this:
ath10k_pci 0001:01:00.0: set sifs trigger time 0 (qboost) for vdev 0
ath10k_pci 0001:01:00.0: dynamic auto burst disabled
ath10k_pci 0001:01:00.0: firmware crashed! (uuid n/a)
Hindsight is always 20/20, I never enabled TurboQAM (QAM256) or Q-Boost, so narrowed down these changesets: