Divested-WRT: No-nonsense hardened builds for Linksys WRT series

compared to build 21861, it's easily a minute slower to reboot using the latest version compared to this.

there's no easy way to find your internal build number (unless I'm looking in the wrong place) ...I'm also seeing error message spam from ODHCPD in my logs, it seems this is due to a new config in the ODHCPD commit from Feb. Disabling ODHCPD doesn't help (it stops the log errors, but every time my VPN changes, my connection out gets borked due to no route update)..seems this is an issue that the ODHCPD guys are fixing.

Is the 11 June release the same as 23.05 RC1 release? or what build is this based on?

Looks a bit older than that, OpenWRT snapshot went to that kernel version in January, long before 23.05 was branched... https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=6a3816efb736b4ff8b4c7ec725522d275afd7496

fixed the issue with ODHCP, I had to disable the IPV6 portion of it (as I'm not using IPV6)

160MHz doesn't work on 1200/1900ac series iirc, only wrt32x/3200
but dfs is broken on these, which makes it immediately drop back

@SkewedZeppelin I've been running 160Mhz with your builds stable on WRT3200ACM on channel 36 (and "force" enabled), provided I first removed the packages kmod-mwifiex-sdio kmod-btmrvl mwifiex-sdio-firmware
With Intel AX210/AX211 cards, I'm getting consistently stable link speed of 1733Mbps in both Linux and Windows clients.

See my post above for instructions: Divested-WRT: No-nonsense hardened builds for Linksys WRT series - #1154 by tamer.hassan

And response post and report of success also on the WRT32X: Divested-WRT: No-nonsense hardened builds for Linksys WRT series - #1158 by xopher

4 Likes

What is new here?

20230626-00

  • update to 539cb5389d9514c99ec1f87bd4465f77c7ed9b93

@dlinkETA3

1 Like

Thanks, also once 23.05 branch is released will you port or release based on the new stable branch?

@dlinkETA3
no? these builds are always from master, never ever stable branches.

stable branches have too old kernels imo.

Dear Tad,
I hope that you are well and thanks for the great builds - I have a question

Has the DSA-kernel6.1 builds gone live 
( are they working ) for the WRT series ?

I have been using Hannu Nyman's DSA-kernel6.1 on my R7800
I realize that this may be jumping fast forward - however, I am just asking in order to be abreast of the current status of OpenWRT Development for these routers which you so ably support.
Thanks and Peace

1 Like

@directnupe
mvebu stable even on snapshot is still 5.15.x

6.1 for mvebu is tracked here: https://github.com/openwrt/openwrt/pull/12938
looks like it is ready, so hopefully soon :tada:

4 Likes

Thanks Tad - I speak for many if not all ( of this I am certain ) when I say thank you for your expertise, kindness and dedication to this exceptional ( your outstanding builds and support ) ongoing OpenWRT Project and it's Community members
Peace Tad and God Bless You and Yours
Always

what benefits will kernel 6.1 provide?

2 Likes

When i dug deeper into this, i started to suspect that when we follow the "build it yourself" procedure, it's not really an exactly reproducible-build of the images that are being released/listed on the DivestedWRT page - building it ourselves we'd get whatever was master at the time when we're building it instead..

Now that I've looked into it more and learned we can take the extra step of:

  • getting the commit-hashes of the openwrt source-tree from the version.buildinfo, and
  • the commit-hashes from the feeds.buildinfo
  • and can use 'make defconfig' after using config.buildinfo as the .config file

src: per this post.. tho these extra steps weren't mentioned on your page but maybe you could? with an eye towards automating / reproducing an identical image you have release..

but my main concern really is there's also occasionally other important changes that aren't captured in an automation-friendly way:

one example is, the tweak listed in the changelog entry of early May-2023, where you're downgrading the mwlwifi driver, however i don't see anything in that specific release's build dir to show this was done :frowning: (nor did i see the downgrade in the patches dir at the time)

Basically, my goal with this post is to learn how to have a way to automate re-building an exact version of what you have released. And while I later realized you manually posted that change's step here, i'm not sure how that would help with automation, as there's no patch file.

tl;dr - can we be assured that any changes have made for a release, will always have a corresponding patch file or would that not always be the case? if it isn't, where does info end up being in your git repo, for automation's sake please?

2 Likes

@aleks-mariusz
Indeed, I hadn't actually pushed those revert patches besides being noted in the changelog or on forum.
I've refreshed all the patches.

Usually I keep temporary patches in the version/date specific directory and longterm ones in the patches folder.

I don't really want to maintain forks of the submodules for rare case someone wants to reproduce when they can use the buildinfo files. I can maintain a fork for the primary repository if wanted instead of plain .patches. Or just make some more condensed notes on how to reproduce and add to README.

2 Likes

0230701-00

  • update to f24c9b9d863c2635e472e83028d28cc8d0a7c7c6
  • [upstream] update to kernel 5.15.119
  • refresh patches

Do you write detailed change logs? if available?

&& when are we going to see a 6.1 kernel release that was quoted above? thanks

regards

@dlinkETA3

detailed change logs

No, but you can diff the commits: https://github.com/openwrt/openwrt/compare/[old version commit]...[new version commit]

edit: the changelog now has some of these added: https://divested.dev/unofficial-openwrt-builds/mvebu-linksys/CHANGELOG.txt

see a 6.1

When #12938 merges

2 Likes

Thanks for understanding my ask and considering my request. I didn't quite understand this last paragraph, what submodules are you referring to maintaining forks of?

To recap, the buildinfo files only are three: {config,feeds,version}.buildinfo - If i understand correctly, using them you can a.) get the openwrt tree to be the same as when you build (via version.buildinfo), b.) get the kernel to have the same options (via config.buildinfo) and c.) get the packages to be at the same revision (via feeds.buildinfo)

i don't see how any of those helps with more "one-off" modifications (reverting a previous commit, or if something was cherry picked, or even some other operation).

don't want to create more work for you, so i'd ask whatever is easy to consume from an automated system would be preferred (i.e. not needing someone to relying on manually reading the changelog or this forum)..

also yes, i do remember seeing .patches file in the version-specific build, but maybe that was just occasionally overlooked? (if it's even possible to have a revert/cherry-pick or other operation "patchi-fied", or if not, perhaps even a list of git commands to perform said actions ?)

1 Like

Excuse me, strong textfor 20230705-00
update to a20735da211930a50330725d5f0b29f81b2a0b9c
strong text
I wonder whether the WiFis on both 2.4Ghz(20/40Hz) and 5Ghz(VHT80Hz) stable or not on WRT1900ACS v1. I used ddwrt 07-08-2023-r53221 very stable now, but in the history, about 19.0x, 21.0x never stable on WiFi less than 5 min.
Thanks a lot

@saphire_lee
Divested-WRT has stable Wi-Fi and is tested working by myself on WRT1900ACv1, WRT1900ACSv2, and WRT1200ACv2.

Use the templates that are available. DFS is broken. VHT160 and tertiary radio is also broken on WRT32xx series.

1 Like