[ 3004.388.5 alpha Build(s) ] Testing available build(s)

[Damit1]

65H uptime for 160Mhz.
For me, Xmas arrived early this year, and Santa slided through the chimney.

Hope the login thing will be resolved to the Beta.

 

[maxbraketorque]

Simply click the link at the bottom of that page (Bandwidth Monitor), in it it states clearly the necessity for TrendMicro (Apps analysis only or?) and what is what and how it works.
As far as I know... For me it works just fine.

I think he's just trying to help debug this version.

 

[MDM]

I think he's just trying to help debug this version.

That is clear, noone said the opposite. I just tried to answer as best as I can...
But he also asked another question "Not sure if this is correct but under QoS - WAN/LAN Bandwidth Monitor, even though I have Apps analysis set to off, yet after a few seconds on that page, I start seeing values", and he has the info on that link.

 

[Damit1]

Christmas definitely arrvied earlier.
Never seen this Wireless uptime before!

90H of Wireless uptime in 160Mhz!
Woo-Hoo!

 

[aex.perez]

That is clear, noone said the opposite. I just tried to answer as best as I can...
But he also asked another question "Not sure if this is correct but under QoS - WAN/LAN Bandwidth Monitor, even though I have Apps analysis set to off, yet after a few seconds on that page, I start seeing values", and he has the info on that link.

It was rhetorical to some extent since I don't know if it is normal and why it works sometimes and not others, but I do know its dependent on bwdpi being enabled by whatever is triggering it. When bwdpi is enabled it works when its off it doesn't but what is starting and stopping it I don't know. Going to Bandwidth Monitor or Classification does seem to enable/disable bwdpi, so some other function is.

I believe I know some of the conditions that should cause bwdpi to start (stop?) from searching through forum posts, but I doubt I know all.

If anyone has a list on what actions/conditions start (stop ?) the bwdpi engine, I can try to narrow this down further. Remember the router is running untouched under normal conditions (other than regular network actitivity), when bwdpi starts. I'm assuming I can determine when bwdpi starts by looking at the content of; /tmp/bwdpi/cat dcd.stat and if started resulting from the tested condition, confirm by then being to see results in Bandwidth Monitor and Classfication that would otherwise not have any metrics.

Note: Upon further inspection, I realize now the TrendMicro is On and required because I have DDNS configured on the WAN - DDNS tab
I also have the Asus Router App on the phone, and Account Binding with my Google credentials (Remote Access disabled in the App and through the GUI) which is another of the conditions (Account Binding, DDNS, Google Assistant, Alexa™, IFTTT™ and Remote connection) enabing TrendMicro, I have logged out and disabled it to better monitor/control this. Not sure what to do about DDNS if anything.

 

[Difides]

without a single problem, good job

 

[maxbraketorque]

This thread is pretty quiet, so seems that this alpha is working pretty well. I may have to try it this weekend.

 

[John Fitzgerald]

This thread is pretty quiet, so seems that this alpha is working pretty well. I may have to try it this weekend.

When you first load it, give it time to settle, 10-15min and a reboot.

I tried right away and had some weird web delayed surfing results and it didn't behave well, so once a sufficient amount of time elapsed, its been good.

 

[shabbs]

This thread is pretty quiet, so seems that this alpha is working pretty well. I may have to try it this weekend.

Keep in mind tho that for this alpha - it's mainly component updates and a couple of fixes that Eric has implemented. There is no new GPL from Asus that's been integrated so no change in wireless drivers, other closed source pieces etc...

 

[Analog-1]

There is no new GPL from Asus that's been integrated so no change in wireless drivers, other closed source pieces etc...

Why is this ? There is new GPL released by Asus for several models. No point in using 388.5 final then as it will be outdated from the first day.

 

[MDM]

Why is this ? There is new GPL released by Asus for several models. No point in using 388.5 final then as it will be outdated from the first day.

Have you first read This..?
An just to clarify, no a new FW is not same as a new GPL (released).

 

[maxbraketorque]

Keep in mind tho that for this alpha - it's mainly component updates and a couple of fixes that Eric has implemented. There is no new GPL from Asus that's been integrated so no change in wireless drivers, other closed source pieces etc...

Yeah, will be interesting to see if ASUS provides another 388 FW update for the "pro" stuff. I guess a good indicator that there will be another 388 FW update for the pro stuff is that a 388 FW update was posted for the ZenWiFi Pro XT12 a few weeks ago.

 

[RMerlin]

No point in using 388.5 final then as it will be outdated from the first day.

Are you saying that all of the changes currently included in 3004.388.5 are "pointless"? Then I guess I should just quit developing, and you should stick with the stock firmware since everything else I do is "pointless", all that matters is Asus' latest GPL code.

Obtaining, merging and testing a new GPL is a 6-8 weeks job. 388.4 was released back in August, I'm not going to delay 388.5 until February, there are plenty of worthwhile fixes and changes in the pipeline for 3004.388.5. That has always been my plan with 388.5.

 

[Analog-1]

Are you saying that all of the changes currently included in 3004.388.5 are "pointless"? Then I guess I should just quit developing, and you should stick with the stock firmware since everything else I do is "pointless", all that matters is Asus' latest GPL code.

Obtaining, merging and testing a new GPL is a 6-8 weeks job. 388.4 was released back in August, I'm not going to delay 388.5 until February, there are plenty of worthwhile fixes and changes in the pipeline for 3004.388.5. That has always been my plan with 388.5.

Look man. No disrespect intended. Just saying. I like your work been using it since the N66 days.

 

[NikL]

just a few words. 388.5 alpha works better for me than the latest GPL released by Asus

 

[dave14305]

There is new GPL released by Asus for several models.

Let us know where the most recent GPL source code is posted for those models. I only see binary images here and there.

 

[SomeWhereOverTheRainBow]

Are you saying that all of the changes currently included in 3004.388.5 are "pointless"? Then I guess I should just quit developing, and you should stick with the stock firmware since everything else I do is "pointless", all that matters is Asus' latest GPL code.

Obtaining, merging and testing a new GPL is a 6-8 weeks job. 388.4 was released back in August, I'm not going to delay 388.5 until February, there are plenty of worthwhile fixes and changes in the pipeline for 3004.388.5. That has always been my plan with 388.5.

The silly thing about it is, I don't think people actually realize when you merge the GPL's. I have seen where you have merged two, sometimes even three different GPL releases in one version change. Sometimes it is due to them falling out of alignment, but all the same. All I want to say is- Thank you everytime I see a new release. I know you are not ASUS. People think because they are here talking to you, that some how ASUS is going to spit out a big fat GPL. I have news for everyone, that's not the case. Especially now that we are approaching some big holidays for people in many regions of the world. People may think, we celebrate holidays. I have yet to take "weeks" off for my holidays. Where I am, we are lucky if we get a true "week-end". I am done ranting, We all appreciate your work @RMerlin .

 

[Wadadli]

Are you saying that all of the changes currently included in 3004.388.5 are "pointless"? Then I guess I should just quit developing, and you should stick with the stock firmware since everything else I do is "pointless", all that matters is Asus' latest GPL code.

Obtaining, merging and testing a new GPL is a 6-8 weeks job. 388.4 was released back in August, I'm not going to delay 388.5 until February, there are plenty of worthwhile fixes and changes in the pipeline for 3004.388.5. That has always been my plan with 388.5.

Perhaps you should have released this alpha as 388.4_2 instead. Where's the tipping point anyway? You are confusing us not-so-smart people who think that 388.5 is a whole new release. IMHO

 

[Mutzli]

I actually like updates without a new GPL integration. This usually means a more stable firmware with all the minor bugs and other issues resolved - hence the working Classification Page in QoS.

 

[JGrana]

Ahh, release naming philosophy - the holy wars of software engineering…

Here is my humble opinion for most software release -

Any digit change is a “new” release. In the vast majority of software products/releases, one should consider something like this:

If the number increased on the far right digit after a decimal point - the release is a “minor” release - typically bug fixes, performance improvements, security patches etc.
If the number increased on the far left, before decimal point(s), it is typically a “major” release with all the attributes of a minor release - but also major changes like new features.

Maybe the underscore is clouding the issue - but I view that as simply a very minor patch release. Not unlike the Linux kernel guys using “-rc” as part of the release name.

With all this said, if you really want to get confused on the release naming process, read this:

The Linux Kernel Archives - Releases

www.kernel.org

Note the reason that the first digit gets changed…
(if any kernel developers are reading this, don’t flame me. Been there).