- r47006 trunk: a new Luci theme "material" included. Default is still "bootstrap"

I  included for testing purposes also a new theme "material" in the firmware. It may suit especially tablet users better. It is responsive and react nicely to changes at display width etc.

If you try the "material" theme (option at System / System / Language-Style), leave the possible feedback at the developer's bug tracker: https://github.com/LuttyYang/luci-theme-material/issues
Discussion thread about the theme: https://forum.openwrt.org/viewtopic.php?id=59696

I am not sure, if the theme will be permanently included, but is there at least for a while.

Default theme is still "bootstrap", which is also installed.

(Last edited by hnyman on 18 Sep 2015, 15:17)

Very nice theme.

Thanks for updating hnyman!

I have been out of the loop. What firmware do you recommend for a home environment? Latest Trunk or Chaos Calmer? I just want to do basic port forwarding and good stability. I have WNDR3700 v1.

Thanks!

(Last edited by ZzBloopzZ on 25 Sep 2015, 04:11)

There is not much functional difference, but as the CC1505 build pulls add-on packages from the release repo, it is maybe easier in the long run. So I would recommend the CC build. But also trunk is usually quite OK and stable.

Great, I will go with CC build.

One last question, what method do you suggest to update firmware? I usually log-in to LuCi then go to Flash Operations > Flash New Firmware Image... Deslect "Keep Settings" then flash image. Then re-configure everything from scratch.

Hope that is most reliable way?

Thanks!

(Last edited by ZzBloopzZ on 25 Sep 2015, 06:19)

Weird, so I just updated to latest CC for my proper router WNDR3700. The LuCi GUI is going crazy slow and times out. I restarted router several times, reset to defaults with pushing the pin for 15 seconds. It goes so slow then times out, especially when trying to edit LAN settings.

Should I update back to the one I came from to see if it fixes it? Safe to downgrade to older version? I don't want to risk a brick.

Edit: I restarted computer and deleted cache. Timeout part is fixed. However, annoying bug. Every time I try to go to a different menu under System, such as Startup or System. It takes me to the "Authorization Required" screen and requires me to login then takes me back to the main Status screen after successful login.

After doing it 3-4 times, it finally goes to the page I am trying to visit. Anyone else having this bizarre issue?

Even to have default password to change it finally stuck after 5-6 times. Perhaps I should go to latest trunk instead of this CC? I have always used Trunk in past with no crazy issues like this.

Thanks!

(Last edited by ZzBloopzZ on 25 Sep 2015, 07:21)

I have seen that sometimes when there have been several tabs open with Luci, especially if the tabs have auto refreshing components like status info. The web server in Openwrt does not apparently like several concurrent sessions to the same browser.

Ah, I had tab open on another machine. Everything is working great with chaos-r46989-20150917 for WNDR3700 v1.

Thanks!!

r47073: build environment: scripts modified, support both git and svn as the main repo

The changes have no impact for "end-users" of my firmware, instead they have implications to people cloning my build environment (explanation in message #2 of this thread).

I have edited the build scripts in a major way, and here is a short explanation about the changes.

I have noticed that GIT is steadily getting more popular as the preferred cvs platform. I still use SVN for the Openwrt main sources, and the Openwrt repo itself and bug tracker are still SVN based. But in any case, the new build scripts support either SVN or GIT as the cvs platform. You can select one of them in the "buildroot creation" script.

Main changes:
* All build scripts are now in <buildroot>/hnscripts instead of <buildroot>, and the scripts are included in the -openwrt.patch
* New buildroot creation script is packaged separately and has been clarified.
* User can select to use either GIT or SVN as the main Openwrt repo format when creating a new build environment. (I have tested both going from SVN to GIT repo and from GIT back to a new SVN environment.)
* Buildscripts have been edited to support both SVN and GIT as the main repo.
* Explicit requirement for /Openwrt as the base has been removed. The build environment can now be created anywhere (as long as the path stays reasonably short).
* The log file "build.log" has been moved to <buildroot>/logs.

Differences between SVN and GIT versions:
- My SVN version continues to use the last check-in in any repo as the version, while GIT uses explicitly the default Openwrt logic about last check-in that has affected this branch (trunk or chaos). E.g. currently the SVN chaos build says r47073 while GIT version would say r47072 (as 47073 did not affecto chaos branch). (As feeds evolve separately, I prefer to set the version as recent as possible, but with GIT there is no possibility for that logic.)
- GIT build is also partially hurt by the default .gitignore, where <buildroot>/files has been excluded from version control. My build has files there, so I may edit the default .gitignore in near future. I understand the exclusion logic for the core Openwrt developers, for treating that folder normally eases things for people building private builds.
- Both versions will create an otherwise identical "release package", but the -status.txt and the -openwrt.patch files have small format differences due to GIT/SVN differences. "Release packages" created in either cvs are compatible and can be used to create either build environment the next time.

Note: if you have an existing copy of my build system and you want the new scripts, it is possible to copy the new scripts into your old repo (to <buildroot>/hnscripts directory), as the build system structure has not changed otherwise. You can probably get the new scripts easiest by grabbing the most recent release (r47073 or newer) from Dropbox and either
- use the new creation script to create a surplus copy of the build system to a new location and then manually copy the new scripts to your old build environment, or
- copy the -openwrt.patch from the newest release and edit that to extract just the new scripts.
In either case, add the new scripts to svn/git version control to preserve them properly.

Nice. Thanks for your sharing.

huawei g8 hülle

(Last edited by FiQYUU on 3 Oct 2015, 09:32)

- r47102: Old qos-scripts has been removed and SQM is the only QoS in firmware

I have removed the old qos-scripts from the firmware. I have used SQM for over a year and it works well.

If you still want the old qos-scripts (and luci-app-qos), install them manually.

- r47244: Note: Material theme seems to be broken

There have been changes in the Luci URL handling in the past two days. The security token (like stok=571709a6dee935b0ffff3175a8c08634) has been removed from the URLs. The change has caused some trouble with e.g. login and flashing, but the known problems in the Luci itself have been fixed.
(See e.g. https://github.com/openwrt/luci/issues/516 )

One known thing is that the Material theme seems to be negatively affected by the change. The left-side menu is missing and some pages are scrambled. So, if you use that theme, be aware of the possible issues.

EDIT:
Regarding Material theme:
The issue is apparently using the existence of ";" in the URL to sniff if the user is logged in or still at the login screen. In the new scheme there is no ";" in the URL, so Material gets it wrong.

I made a small patch in a live router to /www/luci-static/material/js/script.js . I eliminated the sniffing for ";". This works for me otherwise ok, but there is an empty left menu visible at the login screen:

My interim fix is included in the r47245 build.

EDIT2:
The theme has been fixed by the author.

(Last edited by hnyman on 27 Oct 2015, 16:57)

- r47486: enable sha256 certs in Luci by switching to default SSL implementation (polarssl)

I switched both trunk and CC15.05 builds to use the default SSL implementation (polarssl) in Luci. Earlier I have saved a few kB by using px5g-standalone for the Luci/uhttpd certificate creation, as all other software other components except px5g have been able to use openssl based SSL library, which is included anyway due to vsftpd-ssl.

But the SHA1 deprecation (see below) is progressing and so far only the px5g (with libpolarssl) in trunk has been patched to generate SHA256 certificates. Patching px5g-standalone would require more work, and has not been done so far. So I sacrificed a few kB and switched my builds to use px5g, which is the standard Openwrt way. The SHA256 fix has been backported to my CC15.05 build.

Background for the SHA1-->SHA256 change is that major browsers (IE, Firefox, Chrome) will soon actively mark the sites with SHA1 certificates with various security errors.

https://blogs.windows.com/msedgedev/201 … on-update/
https://blog.mozilla.org/security/2015/ … tificates/
https://googleonlinesecurity.blogspot.c … sha-1.html

So did I. And I just noticed there is new algorithm supported called CAKE. It is supposed to be even better than the already fantastic fq_codel:

http://www.bufferbloat.net/projects/codel/wiki/Cake

From the description text of the SQM scripts it looks like there should be a new CAKE qdisc type. The dropdown however does not contain such a qdisc. Instead there is a note about missing entries:

I'm not really sure how to do that in OpenWRT. Could you please tell, if it is possible to use CAKE with the current DD builds and how to get access to the new qdisc?

(Last edited by gogo on 24 Nov 2015, 19:57)

I know about cake. To my knowledge, it is not yet the the mainstream kernel, but instead it is still under development. The cake package should thus be manually included. Developers' own pages look like they have been testing it with 3.10 and 3.18 kernels, meaning BB14.07 and CC15.05 instead of trunk. So far I haven't tried to integrate it to my build.

So, SQM supports cake, but the actual cake is not included.

I might look into it.

(Last edited by hnyman on 24 Nov 2015, 21:29)

I've integrated the CeroWrt cake package in my build and it works with 4.1:

https://github.com/dtaht/ceropackages-3 … sched-cake

You also need an updated version of tc:

https://github.com/dtaht/ceropackages-3 … net/tc-adv

Yeah, I did just the same a few minutes go. I copied the package Makefiles (and tc-adv patches etc.) to my build system, corrected the pie dependency in tc-adv and compiled. SQM with cake seems to start ok.

             Tin 0       Tin 1       Tin 2       Tin 3
  thresh        10Mbit    9375Kbit    7500Kbit    2500Kbit
  target         5.0ms       5.0ms       5.0ms       7.3ms
  interval     100.0ms     100.0ms     100.0ms     102.3ms
  pk_delay       1.4ms       809us       120us       129us
  av_delay       172us        91us         5us         2us
  sp_delay         6us         3us         5us         2us
  pkts           44845        1355         112           6
  bytes       22758404      212062        9567        1136
  way_inds        1961          42           0           0
  way_miss        2501         144         111           5
  way_cols           0           0           0           0
  drops              1           0           0           0
  marks              0           0           0           0
  sp_flows           0           1           1           1
  bk_flows           2           1           0           0
  last_len        1444          74          94         161
  max_len         1459        1490         152         219

Haven't yet stress tested it.

I will check from your build, if you have solved the tc vs. tc-adv clash.

I am not yet sure if I will leave them into my build. The tc-adv application seems to lack a few fixes that have been done on the Openwrt side to the original tc in iproute2 since tc-adv was copied. Maintaining that as a completely separate entity may work in cake's development, but that is not ok in the long run.

EDIT:
hmmm.
I have to correct my code: fq_pie is not in kmod-sched as I thought (only pie is there).

(Last edited by hnyman on 25 Nov 2015, 11:18)

You can just modify the dependency of sqm-scripts to use tc-adv instead of tc. Seems I forgot to remove tc from my config, but the installed package has no files, so I guess tc-adv took preference.

What fixes are you thinking about? From what I can see the latest patch for iproute2 is 7 months old, so I wouldn't worry about that. CeroWrt is OpenWrt as well, so they need the same feature set. Their tc-adv package uses 4.1-git so should be more up to date regarding fixes.

@arokh:

At least this LDFLAGS thing. Probably minor, but still.
http://git.openwrt.org/?p=openwrt.git;a … b9cd7f2222
After noticing that, I didn't look very closely on the other 3-4 changes, if any of them was relevant. Probably not.

Have you actually used cake for a longer period? Any noticeable differency compared to the default SQM fq_codel?
I have a nice fibre 100/15 connection and the ping latency to the nearmost ISP router is only 1-2 ms, so I have been pretty happy with the 3-bin fq_codel approach. I stress-tested cake for a while, but did not see anything really special. tc statistics print is much nicer, which is a naturally benefit, but rather minor one ;-)

Hi gogo,

Just close all browser windows pointed at the luci web interface, that should do the trick. But unless you actually installed sch_cake this will not make any difference in the reported qdiscs... We tried hard to make it more difficult to select non-working settings in the sqm GUI and missing modules are rather simple to detect

Best Regards
        M.

Cake is supposed to do a number of things more efficiently and in general to be more easy to configure (that part is lost when you use luci-app-sqm though, since we try to keep that generic; note there are a few changes coming to allow better cake integration.).
         Cake will be able to handle GRO/GSO meta-packets in a saner way than sqm- or qos-scripts (cake aims for disassembling the aggregates into individually queued MTU-packets if transfer of the aggregate takes more than a certain transfer time on the link, so fast links that can handle meta packets well can keep them while slower links will "peel" them (but on slower links there should be sufficient waiting time between transfers to accommodate the peeling and handling of more packets...)).
        Cake should allow higher shaping rates on slower hardware than HTB or HFSC, but I believe that needs a re-measurement after the recent cake development activity subsides (some of the recent changes might have introduced performance regressions).
        Cake does more efficient accounting for ATM links than default sqm-scripts (then again since ATM links are typically slow this will just free up more CPU for other stuff but will not increase the network performance, puuh, saved by ATM's relative low maximum speed )

Best Regards
        M.

- r47641 trunk: added "cake" modules for SQM QoS  (might be temporary)

I added the cake, fq_pie and tc-av modules to my r47641 trunk build. So, "cake" is selectable as qdisc and "layer_cake.qos" as the SQM startup script. i am not sure if I will leave them to the build, but at least for now they are available there.

(Last edited by hnyman on 25 Nov 2015, 14:00)

@hnyman

Sorry, not tested much as my internet connection is way faster than my wdr4900 can handle

Thank you hnyman for adding CAKE to your build.
Also thanks to arokh and moeller0 for providing additional details.

hnyman,
sorry to hijack this thread but can you help me unlock the art partition on an archer C5 ? I edited target/linux/ar71xx/image/Makefile and replaced all art)ro by art) that I have found, make dirclean, make, and I still can't unlock the partition or write to it:

root@gateway:/tmp# mtd unlock art
Could not open mtd device: art
Could not open mtd device: art

what am I doing wrong?

cheers