Build for WRT3200ACM (Discontinued)

@cybrnook good job getting it rolling creating a pull req. I see that you already have got a reply on the approach and change. Keep up the good work.

Github hint for you. You don't need to close the PR for modifications. It is enough that you add new commits to the same branch and update the PR with "git push". You can even overwrite older commits with "git push -f" (e.g. after squashing/rebasing several commits into one that replaces the original commit). Useful advice can be found in

Additional Github hint: Your fork does not update automatically. (It is currently 266 commits behind lede-project:master)... There are now new commits in LEDE master, but your Github fork needs to be updated manually to see them. In practice you need to first pull new commits into your local repo directly from LEDE upstream master and then push those changes into your fork master at Github. You need to declare Github LEDE master as a "remote" repo for that.

I have done this initially:

git remote add upstream

After the previous gommand git thinks that "origin" is your fork and "upstream" is LEDE master repo:

perus@u1610:/xxx/lede$ git remote -v
origin (fetch)
origin (push)
upstream (fetch)
upstream (push)

Then I update my local repo from the remote "upstream" and push the changes to fork in Github:

git checkout master
git pull upstream master
git push

And finally rebase the "feature branch" to start from the current HEAD (instead of the month old code) to ensure that it merges without problems. And push it to the Github branch overwriting the previous commits forcibly:

git checkout
git rebase master
git push -f


Thanks for the response on the PR, as well as your very detailed response above. I understand that I could work on amending/fixing up the initial PR, however I felt it was better to start fresh anyways. Truth be told, I never intended the PR from last night to be submitted against the LEDE trunk. It happened more on accident as I was just creating my first test PR, and going through the motions as I get more comfortable with the basics of using git ( to which I am attempting to learn ). I thought I could just publish a PR against my own fork, before submitting it to LEDE for approval, seems it all happened in one swoop. As well, seems my fork is out of date, but that is something else I will need to look into as I find that strange as I just forked LEDE source last night prior to testing the PR. So I find it odd that it's 200+ commits out of date. Perhaps this is because I forked LEDE some time ago, just playing around, and have since deleted it from my git? Now that I forked again, it just brought back what I originally had? Will look into it......

With that said, I would much rather submit another, clean, fresh PR that represents what I would actually like to see happen, rather than a tattered one with multiple edit's and revisions. This would be the removal of the cron job all together, and instead creating the fan "daemon". This would allow us to remove the defined "root" crontab, the crontabs folder, the scripts, as well as the sbin folder from the base folder structure.

However, I need a clean way to "deploy" the daemon files, and enable them. Thus I would attempt to use the same logic I attempted to demonstrate in my initial (unintended) PR, as that is the best approach I can see as far as deploying something during first boot (making the 04_mambafan uci script). A quick "if" then.... else it get's deleted, using the mvebu_board_name function.

Likely you just reactivated the original fork in Github and made a new local copy of it. I guess that you have not fully deleted your fork at Github. (Deleting it done via the "Delete this repository" in the repo options in Github GUI.) Your local repo is a completely different thing, just a local incarnation of your fork in Github. You may even have several different copies locally. And you may safely delete the local copy without any effect on the fork origin at Github.

You need to keep your Github fork's remote copy at Github , the "origin", updated like I showed above.

Working with git, Github and PRs is rather nice one you get forward on the learning curve. But you need to always keep clearly in mind the difference between

  • fork's local copy (where you edit things, and which is just a throw-away dirty copy)
  • fork origin in Github (into which you push commits and use to publish PRs, and which you manually keep in sync with LEDE upstream)
  • LEDE upstream in Github (from where you mainly pull changes and where the PRs are visible for others).

Principally you edit everything locally, and when it is ready you push it to the fork origin in Github, after which others can see the commits in your Github repo. After that you can propose the commits to be accepted into LEDE upstream master via PRs.

1 Like

Makes sense :slight_smile:

And as nature would have it, even though when I originally deleted my forked copy (using the "Delete this repository" , enter repository name to confirm) the first time, I guess it just brought it back last night when I forked again. I say this because I did the same motions just now, deleting the forked copy, and then re-forking LEDE and it now says "This branch is even with lede-project:master." - Yeah Yeah, I know you will think I did something silly, but either way I seem to be current now so that's a good starting point. I will work on manually keeping this fork up to date as I go.

The difference between my local copy (on my dev env), my forked git repo, and of course LEDE's repo. As well, it makes sense that all the work I do on my dev env is local to my box, up until the point where I commit it to my forked repo ("origin"). What I got confused on last night, was after I committed my local changes to origin, I did not see any published PR's in my remote copy. So I thought that other users would not be able to see my changes (without having to manually search my entire fork, down to the folder level). So I thought that by clicking the create PR from changes button would publish the PR only against my local fork, not yet going against LEDE. That's how this PR ended up in your lap to begin with, me just trying to learn the mechanics. I thought there would have been yet 1 more step before I would be able to take my PR, and then publish that against LEDE.

The commands, and understanding that I need to work on is on my local (dev env) copy (the "throw away" as it's being called). I hear a lot of terms on this with , throw away, stash, base, rebase, branch, rebranch, force etc..... This is where I need to become proficient. As well as general rules of thumb, like @anomeome pointed out to me. Things like correctly registering my name, email, editor. As well as the switches needed to correctly tag and mark the changes -s and -m, and the need to have to do this after each and every change. I originally thought I could just walk into my local dev copy and modify all to my hearts contents, and then wrap it all up in one command and publish that as a change to my "origin", noting what it all was at that time.......

Anyways, I will start over this evening with the newly gained info, and the actual intended changes. The picture is a little clearer now.

[quote="cybrnook, post:116, topic:545"]
So I thought that other users would not be able to see my changes (without having to manually search my entire fork, down to the folder level). So I thought that by clicking the create PR from changes button would publish the PR only against my local fork, not yet going against LEDE.
[/quote]Yeah, others can see your branch and commits that you have pushed to your Github fork origin, (but naturally not any stuff that is in just your local repo). And others can even clone your fork or download individual commits from it.

To get others to notice things during development, you might need to say in the forum that please check my new stuff on topic XXX in my branch ZZZZ. One good example is the thread about ipq806x thermal sensor driver development/backport that contains a lot of work-in-progress links commits in dissent's Github repo. Supporting thermal sensors on ipq806x

PR is needed only in the final step when you want to ask the code to be imported into LEDE upstream master.

I could keep going with questions :slight_smile:

The example you provided is good. I see there can be many steps, changes along the way prior to a PR being released.

I will create a new branch this evening and will reach our prior to publishing a PR.

If/When I create a branch off my master copy. When I issue future pull requests to resync my master against the current lede trunk, will this also update my branches? Or once a branch is created, this is now it's own independent copy, needing a pull request itself? (or is this now getting into the difference between tree's vs branches?)

Well, you clearly need git basics. I suggest that you google a bit about github, forks and PRs.

[quote="cybrnook, post:118, topic:545"]
If/When I create a branch off my master copy. When I issue future pull requests to resync my master against the current lede trunk, will this also update my branches? Or once a branch is created, this is now it's own independent copy, needing a pull request itself?
[/quote]No, no no... Do not mix "git pull" (= update local copy from a remote repo) and "pull request" (= Github term for proposing your commits to be included upstream in the upstream master in Github). The word "pull" is used in both contexts, but there is a huge difference.

You do not issue "pull requests" to sync your master against the current lede trunk. You issue a "pull request" in Github GUI when you propose to upstream developers that some new code from you (that you have already pushed to your Github fork) should get included in the upstream lede trunk.

You do local updating with "git pull" command, specifically "git pull upstream master" to update your local copy with new commits from lede trunk. (And then you do "git push" to update also your Github fork with those changes. Otherwise it remains stale.)

If you talk about updating your local code with "git pull", you need to update each branch separately. Each branch has its own log of commits included. Thatswhy I gave the "git rebase master" example above, where you first updated the local master branch with "git pull upstream master" and then you checkout out and refreshed (=rebased) a feature branch with the changes in that master. That avoids creating merge commits.

Learning to work with git branches fluently takes some time.

It might help if you look at the branches visually. Here is link to the "packages" feed repo and the LEDE master repo. You can move the chart and see the forks, branches in the forks and the commits in the forks.

This is what I meant. Sorry for misusing git pull and pull request. What I meant (in my head) was when I "pull" the git changes from source to me repo. not issuing a PR.

I think we are just talking too much in the details from a few different topics this morning.... reminds me of a saying "can't see the forest through the tree's" :slight_smile:

I'm fine, thanks for you help today!

Boy you are busy with builds right now. :slight_smile:
Just installed r2763 on my wrt1900acs v1. Running fine so far. I do not use OpenVPN so cannot report on that. I see there is a new wireless driver released, but no one seems to have incorporated it yet.

I see you are getting mentioned on DD-WRT site as having a good build. :grinning: Talking about better throughput. Kong has stated that the kernel being 3.x rather then 4.x is part of their throughput issues.


cybrnook - I've been running your latest build (r2763) on my wrt3200acm.

Compared to a few builds ago this one is fairly solid - though still seeing the router crap out after awhile necessitating a reset (this gets logged quite a bit when it happens):

Thu Jan 5 08:04:45 2017 kern.err kernel: [25122.279018] ieee80211 phy1: cmd 0x801d=MEMAddrAccess timed out
Thu Jan 5 08:04:45 2017 kern.err kernel: [25122.284880] ieee80211 phy1: return code: 0x001d
Thu Jan 5 08:04:45 2017 kern.err kernel: [25122.289427] ieee80211 phy1: timeout: 0x001d
Thu Jan 5 08:04:45 2017 kern.err kernel: [25122.293632] ieee80211 phy1: failed execution
Thu Jan 5 08:04:49 2017 kern.err kernel: [25126.298972] ieee80211 phy1: cmd 0x801d=MEMAddrAccess timed out
Thu Jan 5 08:04:49 2017 kern.err kernel: [25126.304839] ieee80211 phy1: return code: 0x001d
Thu Jan 5 08:04:49 2017 kern.err kernel: [25126.309387] ieee80211 phy1: timeout: 0x001d

keep up the good work! - also been trying davidc502's builds as well....

I'm interested if the latest updates to the driver will help with the wifi issues (intermittent drops)...

:slight_smile: It's all shiny and new, so it's really exciting to me right now.

Yeah, I have seen Kong's mentions of the kernel being a bit behind, though it doesn't need to be as they have already moved their broadcom units to Kernel 4.x some time ago. I think there is just not enough motivation from them to invest the time.
DD-WRT is really good on broadcom, no doubt about that. I did ask a few times in their forums about some of the discrepencies I saw in the builds (mvebu being lumped in with ath etc...) but never got a response. I moved on for now since then.

Now with LEDE/OpenWRT, I am only now realizing what I have been missing for years now. I really, really, really like the carte blanche offering this has.

Yeah, I saw the updates from Jan 2nd. But looking at the actual commits, they seem rather smaller in nature, and I don't think that including them in the builds will yield any world changing performance/stability gains to the community. One is just adding a missed value, and the other is just re categorizing EU as FR. So now FR has dup entries (30 and 32 IIRC).

Will add, not much movement on the 3200 driver/firmware side since last year (under Marvell control). So the stability issues everyone has been facing since then will all still be there. Fingers crossed for a larger update hopefully earlier this year. Especially since Belkin is about to release the new "black" version of the 3200, also promoting open source support.

@anomeome @hnyman

Please be kind :kissing_heart:

So starting at the root of "base-files", you will see "/sbin/" has been removed, as well as "/etc/crontabs/root", since they are no longer needed.

Then, the "new" revision (04_mambafan) which should have been in the first place (@anomeome, things might seem familiar):

(EDIT: Updated branch)

I think I tracked everything correctly this time (been googling a bit this afternoon, and correlating back to both of your instructions which make quite a bit more sense now).

Please share your thoughts if you would be so kind.

Ha, wee lil' bit distracted by the WJC gold medal round between CA-US, but... looks good, should solve the issue me thinks. Questions:

  • I thought deleted files showed as deleted, not a file with deleted lines, but maybe I am missing something when I look at your fork.
  • when no longer anything under a directory hierarchy, are you to delete the directory structure. maybe @hnyman knows?
    -I thought I could create a patch and test it out for you against my build, don't see how, but back to my opening statement, not looking too hard at the moment.
  • WTF is the magic incantation to make bullet lists work in this SW?

Edit: now it pops up WTF, we're in OT. anyways in your working dir, does
git diff
generate a valid patch output?

Edit2: I just looked at the code again and it appears to have changed from when I first looked. I would question the correctness of the reorg, and would argue for the last incarnation that I pushed.

Edit3: Logic is flawed to my way of thinking. Don't need to check HI, sleep is in wrong spot. should check most likely condition first so as to spend least time possible.

I have built against it here locally and it seems to work fine. I am working on one small change right now, that is moving the sleep $INTERVAL from 88 to between 103 and 104, so the fan kicks in faster after boot (so figuring out that right now).

For the deleted files, I am not sure. I tried to do them with:

git rm root
git commit -s -m "blah blah"

git rm
git commit -s -m "blah blah"

EDIT: Okay, just cleaned it up. Will test locally once more.

Then I think I will make one more branch to do this change cleanly now that I seem to have a grip on it (so the timeline is clean, one shot). That is where I would publish the PR from....

For everyone else watching:

new build posted r2796, changes are:

  • new fan daemon for wrt1900acv1 (as seen above)
  • adblock 2.1.0
  • updated /usr/sbin/ script (Verbiage updates and a nice little now or later prompt)


From your comments this am, here would be my revised (un-submitted) PR:

Look Okay?

Well, I am not even using mamba myself, but have just been giving feedback on the coding style. Feedback from real-life mamba users would be good for you.

Regarding the changes, I think that you should

  • combine the four commits into one. google for "git squash". Use "git rebase -i HEAD~4" to start the squashing/rebasing process.
  • chmod the permissions of /sbin/fan_monitor file to executable already in the commit, instead of setting that in uci-defaults. Git stores that info, but you need to set it it before adding & committing the file.

Thanks @hnyman

I did manually set the permissions within my dev env, however I was unsure if git also kept track of file permissions on local env, and then would save that when i committed back to the origin branch. That is why I had opted to also add the chmod command in the uci section. I can remove the unnecessary chmod in that case, one less step (redundant).

I will also work on squashing the commits into one.

Once I do that, is there a way I can publish this to my online repository so that mamba users can download the code as a patch to their devices (without me issuing the final PR)? I know @anomeome said he was not able to pull my (now removed) version from last night down to patch and test on his device. In the meantime, it is already available in my public builds.

It is easy to download a single commit from Github, once you get the hang of it. You simply add the the suffix ".patch" to the link to the commit's Github page.

For example, the commit
can be downloaded as a raw patch file with

your commit modifies the files in the build system, so patch is good for people who incorporate the change to their own build. But the paths are wrong for applying to a live router. You should prepare a separate patch for that, and e.g. upload as a patch to

Example: support for cake qdisc (for SQM) was added to LEDE with my patch, and I made it available earlier for developers via gist. That patch is meant for the build system, but shows how a patch type of file can be easily provided:

Note that if somebody want to apply a patch in a live router, he needs to install the "patch" package first.

And unlike git, "patch" does not know about chmod permissions, so the chmod command is needed there.

1 Like