What's new

Coming from DD-WRT/OTRW2, confused

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

t3chnomanc3r

New Around Here
1st, let me thank you for your work. Only been a week or so exploring it and already I have growing pains migrating from DD-WRT/OTRW2 but this firmware is as sweet as the new router which forced my migration. Likely some of my observations are wrong but I have been knee deep converting old DD-WRT setup to run on Asuswrt-Merlin so call me eager?:D

Biggest gripe: "root" user renamed vs. just adding admin!? root should be "root" with it's own password and then admin add as a second, distinct superuser. This cost me days & eventual full reinstall partially because I am trying to adapt my old config files.

On my old WRT610N V1 using various BS & Kong builds (as on my various 54G predecessor models) NVRAM space & daemon features always meant using OTRW2 to replace the baked-in services like dnsmasq & samba with writable /opt versions to gain features, .conf files, & minimize NVRAM bloat. Forget using anemic sized /jffs for settings on older routers also.

Now with this new AC-68 I find despite it's lavish amount of NVRAM & JFFS space mapped out by nice custom firmware that an alarming amount of config data is still controlled by, left over, and/or *mirrored* in NVRAM. That is to say I write a .conf for a service, those settings override what the NVRAM was but then the settings also end up *IN* NVRAM as it's new settings. Take for example dropbear keys which exist in /tmp/etc/dropbear & then also NVRAM after dropbear has been spawned.

Add to the mix my issue with baked-in Samba seemingly permanently hamstrung by dumbed down, overly simplistic stock Asus interface. Normally this is where I'd usually disable firmware version & ipkg-opt install a OTRW2 version + SWAT front end but you've kindly loaded the newer Samba v3.6 (thank you!) so what's missing for me is SWAT on /opt to manage everything with files skipping Asus' interface

So the questions as a humble, confused convert from DD-WRT+OTRW2 would be:

1. Why does forced initial rename of web admin actually rename "root" account?
2. can dropbear be configured to not use any NVRAM?
3. can I ipkg-opt install SWAT, add my smb.conf + db's to /jffs/configs/, and control the baked-in Samba like I would have with OTWR2 samba36?
4. What's need to eliminate NVRAM values for services/daemons in favor of /jffs & /opt configs?

Thank you and sorry for longish post!
 
Storing settings in nvram is the way every Broadcom-based router has worked for years, since this is how Broadcom's SDK is designed. Changing this behaviour is beyond the scope of this project, and would introduce a lot of other problems. This architecture ensures that settings can be accessed from the bootloader, and also that they can be wiped from the bootloader (or through the WPS button). Otherwise, a corrupted setting/config in jffs2 could make it impossible for you to recover your router, as the bootloader has no way to access the jffs2 partition to wipe it.

The JFFS partition wasn't available in stock firmware until recently. Additionally, the size can change between firmware flashes as not every router has a fixed, dedicated partition allocated to it. The RT-N66U partition for instance is based on whatever space is left out of the total 32 MB of NAND it has. And even in the cases where they can have a fixed allocated partition, it can still be corrupted/overwritten, for example with the RT-AC68U recent CFE upgrade that bumped the rootfs to 64 MB.

The design I'm going with is to have settings inside nvram where they will be persistent, and only have the JFFS partition hold config files and scripts that you want to be able to edit with an editor, or would be a waste of nvram space. The whole firmware needs to be able to be fully functional without the JFFS partition content in case of corruption, or the need to do a factory default reset (which disables the jffs2 partition).

The superuser wasn't renamed, it was already called "admin" in the stock firmware as well. I suspect this is also the way Broadcom's SDK is designed. Changing this back to root would have made no sense, and lead to a lot of other issues.

Just because OpenWRT or DD-WRT decided to do things differently does not mean that the rest of the world is wrong. They're actually the ones who decided to go in a different direction than the OEMs intended with their official SDKs.
 
Storing settings in nvram is the way every Broadcom-based router has worked for years, since this is how Broadcom's SDK is designed. Changing this behaviour is beyond the scope of this project, and would introduce a lot of other problems. This architecture ensures that settings can be accessed from the bootloader, and also that they can be wiped from the bootloader (or through the WPS button). Otherwise, a corrupted setting/config in jffs2 could make it impossible for you to recover your router, as the bootloader has no way to access the jffs2 partition to wipe it.

1st, as I tried to impart, I know very well about the kludge of NVRAM & why it's used having been around since the 1st emergence of the Linksys WRT.

It's not an issue of "changing behavior" since Samba (for example) complied for Optware didn't store anything in NVRAM AFAIK, same as a "normal" Linux version does. So it's actually the reverse of "changing the behavior", in the sense NVRAM support had to be added (by someone), no? Core services needed to run basic router/wap functionality relying on NVRAM after factory reset is not mutually exclusive of being able to ditch SOME degree of NVRAM use


The JFFS partition wasn't available in stock firmware until recently. Additionally, the size can change between firmware flashes as not every router has a fixed, dedicated partition allocated to it. The RT-N66U partition for instance is based on whatever space is left out of the total 32 MB of NAND it has. And even in the cases where they can have a fixed allocated partition, it can still be corrupted/overwritten, for example with the RT-AC68U recent CFE upgrade that bumped the rootfs to 64 MB.

Granted and JFFS is something I am using only now after a few years of /opt via usb storage support & Optware, thus JFFS is just gravy on top of that not the end all vs. NVRAM.

The design I'm going with is to have settings inside nvram where they will be persistent, and only have the JFFS partition hold config files and scripts that you want to be able to edit with an editor, or would be a waste of nvram space.

Without /jffs or /opt on a customized router most of the functionality is lost anyway as services revert back to limited configuration options that NVRAM+webgui can do.

So to talk about:

The whole firmware needs to be able to be fully functional without the JFFS partition content in case of corruption, or the need to do a factory default reset (which disables the jffs2 partition).

Not sure your definition of "fully functional" but I think the phrase you mean is more along the lines of "factory reset must be fully functional". One means if /jffs & /opt croak the router continues to function as configured while the later implies ability to revert to factory state & start from scratch. If those die, there's no way NVRAM is keeping the router up or we'd simply be using NVRAM from the start.

Granted there are services that need to be live long before the filesystem mounts thus some NVRAM use is unavoidable but SSH is not one of them. No need wasting NVRAM on 3 SSH host keys + 1 client key when they are on storage and the service not needed "before the filesystem is usable".

The superuser wasn't renamed, it was already called "admin" in the stock firmware as well. I suspect this is also the way Broadcom's SDK is designed. Changing this back to root would have made no sense, and lead to a lot of other issues.

Just because OpenWRT or DD-WRT decided to do things differently does not mean that the rest of the world is wrong. They're actually the ones who decided to go in a different direction than the OEMs intended with their official SDKs.

Something bothering you about the other firmwares & their design choices?

I asked about root because all my previous WRT routers used root for shell & admin for webgui as far back as I can remember. Only reason I knew there was an issue was my SSH client w/ existing profile I had been using on the 610N wouldn't connect until I changed from root to admin.

LOL, different direction? Dunno if you call "open" different but I do know Linksys before Cisco backtracked away from *their* OSS solution really fast when they saw how popular 3rd party firmware was and played the game cutting hardware corners ever since. Broadcom != OEMs and I don't think direction was as much an issue for OEMs as the support costs if they did endorse 3rd party firmware.

Hopefully this is worded well enough because I am not here to detract or disparage, just trying to move forward with my new router which pretty much dictates switching from DD-WRT to Merlin thus I feel the need to make a little noise as I run into things that confound. While I realize you're making non-bloated firmware, it's the only good thing running for AC68 right now and the ability to build upon base rather than be hindered by it is important I think.

In all of this I still don't know if I can safely add SWAT to configure the samba you bake in or if I am looking at needing to cut up your firmware image to remove binaries in favor of other versions. Not a good 1st impression.

Merry Christmas!
 
Not a good 1st impression.

Take it or leave it. I've always made it clear that the goal was to tweak the original Asus firmware, not to redesign everything and make it impossible afterward to keep in sync with Asus' own code. My goal was never to attract the widest userbase either, but to address a certain segment of users who liked the original firmware for what it was, and only wanted a little extra on top of it. That means the original architecture as designed by Asus will remain. If you're looking for something radically different from the original firmware, then this project won't satisfy your own needs.
 
.....Not a good 1st impression.

Merry Christmas!


But isn't the Asus RT-AC68U a DD-WRT supported device, so why not flash with DD-WRT? One of the principal reasons I bought that router was its being supported by all the major open-source groups as well as, what I call, Merlin's hybrid firmware.

For me, Merlin's firmware is a welcome breath of fresh air after DD-WRT, which confused the hell out of me with all the different builds, warnings against trusting the database, critical information scattered across the Internet, and everything so problematic to set up, if not deliberately abstruse to exclude the uninitiated. I came to believe that "DD" stood for Dog's Dinner. In contrast, the Merlin-Asus firmware was so easy to set up I felt I had to be doing something wrong. And I didn't even need to know what a binary is.

Martin
 
But isn't the Asus RT-AC68U a DD-WRT supported device, so why not flash with DD-WRT? One of the principal reasons I bought that router was its being supported by all the major open-source groups as well as, what I call, Merlin's hybrid firmware.

For me, Merlin's firmware is a welcome breath of fresh air after DD-WRT, which confused the hell out of me with all the different builds, warnings against trusting the database, critical information scattered across the Internet, and everything so problematic to set up, if not deliberately abstruse to exclude the uninitiated. I came to believe that "DD" stood for Dog's Dinner. In contrast, the Merlin-Asus firmware was so easy to set up I felt I had to be doing something wrong. And I didn't even need to know what a binary is.

Martin

Indeed. A favorite saying of mine is "all good, just different."


@t3chnomanc3r
If DD-WRT is what you prefer, why not use it?

I use pfSense, tomato shibby, and Asuswrt-merlin, because they all serve my purposes in different ways. Each project has it's strengths and weaknesses. I support offering well-reasoned, constructive criticism but it is out of line to declare one project is doing it wrong simply because it is not emulating another project.

and, to re-use your closing comment; regarding your first few posts... not a good 1st impression.
 
Take it or leave it. I've always made it clear that the goal was to tweak the original Asus firmware, not to redesign everything and make it impossible afterward to keep in sync with Asus' own code. My goal was never to attract the widest userbase either, but to address a certain segment of users who liked the original firmware for what it was, and only wanted a little extra on top of it. That means the original architecture as designed by Asus will remain. If you're looking for something radically different from the original firmware, then this project won't satisfy your own needs.

Well the seeming cold breeze in hear & obvious misinterpretations of both my tone & reason for speaking don't bode well. Why this is the case after re-reading what little I've posted I am not sure.

I'm not looking for a redesign, reread what I posted if you think otherwise. I've simply posted some observations and then stumbled my way through a responding to what seems like bad vibes from you. Not sure where to go from there since it seems open communication with this base is negative if you decent or question the status quo.
 
Indeed. A favorite saying of mine is "all good, just different."


@t3chnomanc3r
If DD-WRT is what you prefer, why not use it?

I use pfSense, tomato shibby, and Asuswrt-merlin, because they all serve my purposes in different ways. Each project has it's strengths and weaknesses. I support offering well-reasoned, constructive criticism but it is out of line to declare one project is doing it wrong simply because it is not emulating another project.

and, to re-use your closing comment; regarding your first few posts... not a good 1st impression.

I DID NOT CLAIM THIS PROJECT WAS *WRONG* VS. SOME OTHER ONE, THAT BIT OF (IMPLIED?) NEGATIVITY CAME FROM MERLIN'S POST!

I'm here because switch to ARM complicated my DD-WRT situation thus I decided to give the project I heard the most about in the same sentence with Asus AC68 a try.
 
I DID NOT CLAIM THIS PROJECT WAS *WRONG* VS. SOME OTHER ONE, THAT BIT OF (IMPLIED?) NEGATIVITY CAME FROM MERLIN'S POST!

I'm here because switch to ARM complicated my DD-WRT situation thus I decided to give the project I heard the most about in the same sentence with Asus AC68 a try.

My apologies, I may have misinterpreted what you said and the tone used to say it.

I think Merlin said it most respectfully and succinctly with "take it or leave it."

The forum is very helpful if you have any questions regarding how to overcome your difficulties transitioning from DD-WRT. You will need to be open to changing your configuration methods, compared to DD-WRT.


I am not sure, but I think there is a version of tomato that supports ARM that may be easier for you to work with.
 
As for the RT-AC68/TM-AC1900 and DD-WRT, its not worth the hassle as the similar Broadcom ARM-based routers (R7000 and AC68U AFAIK) have drivers in current builds (since 24345) that makes them reboot every 2~ hours.

I hopscotched from Merlin to TomatoUSB to DD-WRT in search of functional firmware with working IPv6 and bandwidth throttling. AsusWRT/merlin (since Merlin's code is based off of official AsusWRT) has broken bandwidth throttling (upload limit works, download does not. Limits IPv6 download speed to upload speed) but working IPv6.

TomatoUSB (Shibby, Toastman, or RAF) have working bandwidth throttling, but IPv6 is broken by default that even with specific instructions by google searching and Comcast's own instructions cannot even get it working (IPv6 information is stored in a dead-end portion of the firmware). DD-WRT is as detailed above (actually has working IPv6 now and has had one of the best bandwidth throttling features of any open source firmware, but crashes make it unusable till new drivers are released).

So I settle on Merlin because it looks to have the most potential for now at getting some working code for the broken features from Asus (as much as Merlin has control over). I'd say working IPv6 is the biggest feature as far as future-proofing.
 
Well a few days for dust settle and no actual useful insights? Funny thing is I've never seen this kind of hostility from BrainSlayer or Kong and they've fielded a lot worse than n00b questions like mine.

Sad, the one project with proper working AC68 support has a hostile maintainer & userbase for what reason I have no clue. So much for being a part of this guess I'll have to hope DD-WRT catches up sooner than later or I find a good fork of this one open to conversation.
 
Well a few days for dust settle and no actual useful insights? Funny thing is I've never seen this kind of hostility from BrainSlayer or Kong and they've fielded a lot worse than n00b questions like mine.

Sad, the one project with proper working AC68 support has a hostile maintainer & userbase for what reason I have no clue. So much for being a part of this guess I'll have to hope DD-WRT catches up sooner than later or I find a good fork of this one open to conversation.

Regardless of blame, if you have literally "no clue" why this thread did not go the way you wanted, that is unfortunate. Something should be learned from any experience.


One thing I learned with forums (or any text) was what I meant to say, and what is actually interpreted by someone else can be vastly different. Neither interpretation is wrong or right, but I think it is important to be aware.
Perhaps this only applies to me but I noticed that my mood always comes through in some way, regardless of the mood I am trying to present. Meaning, I would angrily argue something, but try to type it out like I was calm and collected. The anger always came through and the threads usually went down-hill, and I swore it wasn't my fault. I eventually learned I was at least partly to blame.

If you really want to argue compassionately, try to first disprove yourself instead of others.

As just one favor to me, search through RMerlin's post history and see if he is truly a "hostile maintainer".
Anyway, I'm not sure why I typed all this. Do whatever you want. :)
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top