Posted: Tue May 31, 2022 7:11 Post subject: New Build - 05/31/2022 - r49028
Welcome to Atheros r49028 beta release thread for reporting, feedback to developers and community benefit.
Please do not flash builds until installation is understood, risks involved and device specificrecovery methods.
Avoid discussions, create threads for questions, general problems or use search; this thread is not for support.
Please list router model & revision, operating & wireless mode(s) and exact filename/firmware image flashed.
Issues, observations, and/or workarounds reported:
• WebUI: Clear history or use a portable. Temporary cache bypass: Ctrl+F5, Cmd+Shift+R or new private window/incognito.
• Please report findings with steps needed to reproduce, configuration, clients, output, logs and important information below!
Important:
• Detail issues & relevant configs, logs: syslog klog 'dmesg' 'cat /tmp/var/log/messages' nvram set console_debug=1, serial.
• Firewall NAT: 'iptables -vnL' 'iptables -t nat -vnL' 'iptables -t mangle -vnL' & 'cat /tmp/.ipt'. Misc: stracetcpdumpwireshark.
• Gremlins: reboot. cold boot. Reset & reconfigure not restore backup. Search Trac & discuss in forum before opening tickets.
• Include operating & wireless modes (e.g. Gateway, Router, AP, CB, WDS, Mesh) and applicable configurations to reproduce.
Well, untested beta images and "rock stable" are mutually exclusive.
BS builds a new public version every few days and you don't seriously think that every version is completely bug free?
That would require that all developers involved, including the developers of the external software components, are absolutely perfect and never make a mistake
Besides, I have already recommended a very stable build to you and never received any feedback.
Besides, I have already recommended a very stable build to you and never received any feedback.
thanks for the recommendation, but I don't dare to use my business environment to test the firmware anymore (my issue occurs when there are many wireless devices and I can't simulate with my few personal devices). Another point is that if I need to downgrade to the very old dd-wrt build then probably it's better to just move back to stock Netgear firmware which is still being actively maintained/developed.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Tue May 31, 2022 11:35 Post subject:
IONK wrote:
Reverted to r48971
So whats wrong with build 05-30-2022-r48996?
And again, many many changes went into Atheros drivers since r48971, so a reset just to be sure is recommended. Also read my first reply to this thread.
New code, shit happens, in order to achieve any stability with new code, code needs testing and fixing and maturing after the fact, which then becomes more stable.
But this doesn't mean normally, that just because its a new build that its unstable. And just because in the past nothing substantial changed that any given machine can be considered solid or flaky.
If router is rebooting randomly plug into serial and grab that output, that would be more helpful than some random comment, in order to see wtf is happening, please and thx.
<begin rant>
Im not having a go at anyone in particular or at anyone in general it's a rant of sorts, of real world observations, please keep that in mind whilst reading this part below or turn away now.
What I see ever since I started using DD-WRT many years and years ago and not just DD-WRT many other projects and their bug reports, is that these build threads dd-wrt wise are 90% ineffective from a developer point of view, people literally only report issues according to their setup. If there are no issues according to their setup then everything surely must be fine.
This isnt testing to me of any substance it just means the build wont brick your router and may or may not work in your setup, if different, and since each person may have different setups and some setups are definitely borked, + beyond setups there are issues that IMO are critical and haven't been fixed in years as a result, so real bugs exist but no one tests anything beyond the setup working/not working.
And to add to this, hardly anyone who has real issues provides any actionable information beyond the vague comments (its rare to see in any project any proper reports).
The truth is no one can be expected to do anything, no one is under any obligations whatsoever, to either report anything, provide any evidence or go out of their way to contribute actionable data, my above semi rant is based on experience with real world multi-project testing and reports going back 20+ years (where I even was paid for the job), in that case paid or not, no one would get away with just saying it doesn't work without providing evidence.
<end rant>
So manage expectations based on reality is all I'm saying, that said... someone once said it is better to ask for forgiveness than for permission. So if anyone took any of that personally even it the rant wasn't aimed at anyone at all, I apologize.
@the-joker
the 5-30 build isnt stable either. it crashed my x10 multiple times. (crash hard, no reboot, power cycle necessary)
I wasnt paying attention to my wds sta which is a 7800, but based on uptime stats, that unit did an unexpected reboot. So problems started prior to this build.
And again, many many changes went into Atheros drivers since r48971, so a reset just to be sure is recommended. Also read my first reply to this thread.
noted, thanks. Maybe someone can include the note whether to reset setting, for every new build thread?
I've read your comment above, thanks for letting us laymen know (I usually don't understand shit when looking at the svn diff)
the-joker wrote:
New code, shit happens, in order to achieve any stability with new code, code needs testing and fixing and maturing after the fact, which then becomes more stable.
I understand. Somehow I had the expectation that Atheros devices are given more development effort, especially the R7800/RX500 since it's recommended by everyone everywhere, and the developer has it himself, so I thought it's not as risky to update the firmware as some random 9-year-old Broadcom device which the developers usually don't have time to test.
the-joker wrote:
If router is rebooting randomly plug into serial and grab that output, that would be more helpful than some random comment, in order to see wtf is happening.
I understand your point. However, I don't have much time playing with these routers recently. It takes some reading and tinkering (opening up, connecting to the header pins - need to solder one if it's not already there, finding some way to close the casing with the serial cable still connected, shifting some PC nearer to connect to the serial cable, letting that PC runs 24/7 to catch the log, trimming the log before submission). With the limited time I can spend, the least I can do is to partially report the issue, instead of becoming a lurker.
Thanks for reminding me that serial log is more comprehensive than syslog.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Tue May 31, 2022 12:10 Post subject:
Yea, I get it, time and real life, pesky little things interfering with fun. How does real life dare?
But yea, re: log trimming, please dont. Any logs should be attached as text files and only sensitive info masked out, trimming logs removing what one thinks isn't valid or applicable should be deferred to the developer.
But yea, re: log trimming, please dont. Any logs should be attached as text files and only sensitive info masked out, trimming logs removing what one thinks isn't valid or applicable should be deferred to the developer.
many has told me R7800/XR500 is rock-solid but it doesn't seems to be the case for me
IONK wrote:
I understand. Somehow I had the expectation that Atheros devices are given more development effort, especially the R7800/RX500 since it's recommended by everyone everywhere, and the developer has it himself, so I thought it's not as risky to update the firmware as some random 9-year-old Broadcom device which the developers usually don't have time to test.
I thought R7800/XR500 was different from R7800/X4S which is the original version that most people have, including me. That might be why you and some R9000 people are having problems. Because I believe the favorite child is the original R7800/X4S.
I've been using DD-WRT since 2012. Between 2012-2016 I used a TP-Link TL-WDR4300, which was fine for the time. Then I bought a R7800 in 2016, used BS builds for a bit at the start but moved to Kong builds between 2016-2019. Then back to BS since Kong left. It's been smooth sailing ever since 2020 for me. All throughout the journey I can only remember a couple problems, and all of them were related to PPPoE, which I'm still of the opinion that they were because of my ISP and not DD-WRT, but I can't confirm or deny, because at some point DD-WRT's PPPoE implementation was acting up a bit. It's why I created my forum account very late and was a lurker, cause I rarely had problems.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Tue May 31, 2022 13:56 Post subject:
IONK wrote:
the-joker wrote:
But yea, re: log trimming, please dont. Any logs should be attached as text files and only sensitive info masked out, trimming logs removing what one thinks isn't valid or applicable should be deferred to the developer.
So trim nothing. rule of thumb.
thanks for the info. I usually remove some info lines from the PHP code because it's a bit sensitive to me, but I'll refrain from doing that from now on.
Making info is also a pain for laymen as me, I would appreciate if someone can share some script that can auto prune/mask the sensitive info (MAC address and other shit)
Masking or altering the sensitive data is OK, removing log lines that could have other kinds of information is not:
Usually users tend to only post what they think is important when either, dont know what is or not important or are purposefully hiding something they have screwed with (aside from sensitive info).
@MLandi Since you dont have issues to report, syslog has nothing useful anyway. I looked, its normal.