In general I wonder why that should be. The final product you want is the amended config files, and so wouldn't it be better to tell somebody what that should look like so he might go and do it himself?
I searched for config samples, but they were all uploaded by people who were having problems.
REQUESTS
If anybody knows good sample configs for a guest Wifi, please link. (Or provide in reply?)
If there are instructions on "translating" uci commands to resulting config, please link.
config device 'guest_dev'
option type 'bridge'
option name 'br-guest'
and see a rough correspondence.
But not exact. For example, the second and the third uci lines resulted transferring the quoted words (bridge and br-guest) to the config lines, again as quoted. But from the first uci line not the quoted device but the unquoted guest_dev ends up quoted as guest_dev in the corresponding config line.
That seems pretty random, and unless I knew all such kinks I couldn't "translate" uci into config in my mind.
I suppose I could follow the sample uci scripts the first time, open the configs and see what the scripts did, and afterwards use that for my model.
You raise a valid point -- if the goal is to see the configs as they will appear in the files themselves, rather than UCI CLI syntax, that is currently not included in the guest wifi config tutorials.
If you search the forums, though, you will find many examples where the text files are indeed shown.
Yes, I've done that. But those uploads are mostly incomplete and raised for the purpose of enabling others to diagnose a problem. I could cobble something together from many such samples if nothing more authoritative is on hand now.
Yes. It does help to contextualize. Thanks. But LuCI would be rather more indirect than uci. I want to manipulate the configs directly as it seems the best learning experience.
An easy way to get the config file view to compliment the CLI implementation in the wiki would be to simply run the commands from OpenWrt's default state and post the guest related stanzas. While I could do this directly, I'd want to make sure everything was completely consistent.
Meanwhile, the only hesitation I personally have with posting the full configs is that they may vary from device to device (i.e. DSA vs swconfig, number of ethernet ports, etc.).
That said, would a section at the bottom of the tutorial page that showed the results be sufficient to help clarify how the CLI commands translate to the file output and provide the context that you're looking for?
Oh yes. If you or someone else could append just those relevant stanzas to the bottom of the tutorial, that would be just the official guidance I was looking for.
If I understand you right, fullness (including lines unrelated to guest Wifi) would only confuse.
I'll see if I can get some time to do this. If not, maybe someone else can jump in to do it (we'd welcome your help to do this, if you're comfortable; I'm happy to review)
Yes, that's my point, and it seems we're on the same page here.
Meanwhile, this thread may be best in the "talk about documentation" section of the forums. Would you mind if I moved it there?
I'd be happy to try. I'll PM you when I have results.
(It may take me longer than a normal person here. Because I am at a level of thinking, "Hm, I don't want to run all these uci scripts line by line. So I should turn them into a script. Now, I did that once. Something about permissions. Where is my how-to file for that?")
One difficulty that is usual to my trying to read code is to distinguish part of command syntax from an arbitrary name I may change.
For example, suppose I wanted my guest interface to have the name gist.
Which instances of guest occurring in the linked page should I change to gist? All of them? Or only some of them because the other instances of guest are actually part of command syntax and must stay guest? (I am sure "part of command syntax" is not the right term, but I hope the meaning is intelligible.)
Can these, for example
uci -q delete network.guest_dev
uci set network.guest_dev="device"
uci set network.guest_dev.type="bridge"
uci set network.guest_dev.name="br-guest"
become
uci -q delete network.gist_dev
uci set network.gist_dev="device"
uci set network.gist_dev.type="bridge"
uci set network.gist_dev.name="br-gist"
I hope there would be some general principles you can give me as I certainly don't expect you to go line by line for me. Thanks.
most of the names are arbitrary. It is helpful if they are human-readable and descriptive, but there's not technical reason that they need to be spelled one way or another, as long as things are properly consistent from both the technical side (syntax) and human logic (following the config progression).
What you've done will technically work, so no issue there.
It is generally preferred to use English on the forum and the wiki (although the wiki does have localization, IIRC). With that in mind, my personal recommendation would be to keep "guest" spelling as it was (conforming to North American or British English; we often see "gast" or "gist" from those who speak other languages). Again, this is not a requirement and what you've written is technically valid.
Thanks for the confirm that technically the replacement would be okay. On preserving "guest," I am looking ahead to the time when I might need "guest2" (and would have to know which instances of "guest" should remain as is). I believe I will actually use the LuCI method (no chance for me to corrupt hard-coded expressions) with conspicuously arbitrary names like "cowinterface" and "cowzone" and examine the resulting stanzas in the config files.
For anybody else exploring the area, I have found some video tutorials, each emphasizing different aspects: