Source Code Archive

[Thorgear]

Chasing down the dropbear issue?

Just asking...

Nope. My AC68 hung when I changed a setting. I've been busy replacing it with a backup router and trying to figure out what happened. I must have flashed the thing thirty times already. I know it's a FW bug, but I havn't yet been able to make it reproducible. It's working now on 380.61_alpha1. It hasn't locked up yet, but changing any setting could break it.

 

[RMerlin]

Also - for the first build - one wants to have a fairly good size diskfile if running in a VM, it's not the AsusWRT that will take up the space, it's building the toolchain - 32GB likely is too small unless you're in a minimal Linux distro... 60GB should be much more than sufficient...

The toolchain is already compiled, and part of the repo.

 

[Thorgear]

And the reason for the VM suggestion ...

The short-term reason for the source-code is to make a script that extracts the settings from the .cfg. I couldn't find one anywhere. If there's something in the nvram that breaks the router, it's in the .cfg file too. I'm hoping I can track down the setting that breaks the router.

 

[sfx2000]

It's working now on 380.61_alpha1. It hasn't locked up yet, but changing any setting could break it.

Lot of developers, and a lot of code over time - and it's probably due for a redesign consistent with modern expectations of stability, security, and privilege separation...

Dig deep into that code base, and you'll gain a better appreciation for the folks that do take on the Augean task of cleaning up that stable and dropping new code/fixing bugs... it's incredibly brittle stuff inside - years of it...

Every software project hits that point at some time...

 

[Thorgear]

Lot of developers, and a lot of code over time - and it's probably due for a redesign consistent with modern expectations of stability, security, and privilege separation...

Dig deep into that code base, and you'll gain a better appreciation for the folks that do take on the Augean task of cleaning up that stable and dropping new code/fixing bugs... it's incredibly brittle stuff inside - years of it...

Every software project hits that point at some time...

Definitely agreed.

 

[sfx2000]

Folks, don't take the comment in the wrong way - it's just one person's educated opinion - some of the stuff is pretty good, but touching that code in some places can break things in unexpected other places...

There's multiple layers of this code - the Asus stuff - which is intended to be somewhat portable across different chips/architectures, and the vendor code - and all the glue* between them - and this is what makes doing changes inside AsusWRT such a challenge.

*glue - third party code and objects, including original GPL code from many sources... and some proprietary code/API's, which may or may not be fully documented.

AsusWRT is a complicated beast...

 

[Thorgear]

Folks, don't take the comment in the wrong way...

I'm totally offended. ;-)

 

[sfx2000]

The toolchain is already compiled, and part of the repo.

Been there - but if one is cross compiling across multiple builds outside of AsusWRT, it starts to become a problem... I'm also doing RPi stuff across armel/armhf, and yes, building AsusWRT pretty much took me down the path of not doing that, but keeping everything sandboxed within a VM...