[quote="RangerZ, post:24, topic:966, full:true"]If not "Router", then what is the proper term for the default delivered LEDE firmware configuration?[/quote]I thought you were talking of the LAN part only, that's not "router", it's a device with a fixed address and a DHCP server.
[quote]As a dumb user, I will suggest that the terminology on the latest version of the QSG is just not clear enough to the non-technical target audience[/quote]Meh, most people calls "modem" or "router" what is actually a modem/router/wifi-access-point/switch(/firewall/voip/whatever) all-in-one devices, so anything we write there needs an explanation anyway.
Clients/Routers/Gateways (and explanations) are already what imho are good enough broad categories for the devices we have here. True networking would also split access points, firewalls, switches, and divide client devices into more stuff (true clients and actual servers).
The only thing that I'd like to set in stone is that we should be dividing guides by usage, not by actual hardware type. Someone could just buy a 150$ router with bells and whistles and use it as a "client" device in his network, providing shared folders, various servers and wifi, and that user would need to look at the "Client" device configuration regardless of what device he is using.
[quote]* Router - The default LEDE config on first boot (LEDE Router).[/quote] True only on devices with LAN and WAN ports, and even then it's a very basic router config that is unlikely to really work at all, so while they indeed have a stub config to be routers, they are pretty much useless without further configuration.
Devices with only LAN (either because they have a single port or because of other reasons) are usually set with fixed address and DHCP server enabled to facilitate the first connection to it so you can configure it easily. Again these devices too have a network config that is 99% useless without further configuration.
I'd personally say that LEDE devices ship with a basic config that allows easy access for further configuration, but they don't have configurations that allows to divide them into true categories.
Anyway, nitpicking aside, I call Routers devices that are only doing NAT, that is bridging two different ipv4 networks, because that's what a router does, at the end of the day.
Ideally we should not have many of these as people at home should avoid having double NAT (as apart from some specific cases it has no real benefit and only bad sides).
[quote]* Client - A Router above, reconfigured from delivered to be a slave to another primary device. The client is typically not the primary DHCP controller. It may be a wired device (Dumb AP) or a wireless device (Repeater Bridge). Others?[/quote]Client for me is a generic catch-all for devices that aren't Routers or Gateways, as regardless of what they are actually doing, their network configuration is the same. Fixed address and all that jazz.
So you have pretty much anything in here, routers used as wifi-access-point/NAS, actual NAS, SBCs, lousy 4MiB-flash devices converted to do IoT jobs like controlling power relays (switches power on and off) through crelay package or connected to sensors or other stuff, whatever.
[quote]* Gateway - The primary device which converts the ISPs incoming connection to a WAN, in the case of a "Modem", or LAN in the case of a "Modem\Router" (ADSL Modem Router or Cable MODEM Router). Conceptually this could also be a "3G\4G Modem". Others?[/quote]Yeah correct, Gateways should be the most common non-Client device.
Most modern 3G/4G dongles or "modems", also those integrated in routers, are actually pretty scary devices that act as routers themselves (emulate a ethernet port over usb), so any device downstream must be set as "client" or you get a double NAT.
[quote]I know where I am, that RCN offered a choice of Modem or Modem\Router. It may be worth a note to suggest users inquire with this vendors on this.[/quote]It may not be that relevant. Ethernet modems capable of full bridging aren't expensive, even the one of a kind that can convert pppoA into pppoE so you can do proper bridging can be found for like 30$ on ebay.
[quote]It appears that, and we I think agree, there are more than one hardware scenario to address, based upon the supplied ISP components.[/quote]Yeah that's an accurate depiction of the possible situations people can have in their home networks.
Note that in many cases for DSL contracts it is possible to replace ISP modem or modem/router with another modem that supports bridging, and connect that to a LEDE device that will become a true "Gateway". See answer below.
(also as said above, many modern 3G/4G modems that force LEDE to act as dumb AP)
[quote]I am not clear about the ToH devices of Device Type "Modem". Is there LEDE firmware that includes the Modem functionality that an ISP will actually support?[/quote]Most ISPs using DSL are using standardized protocols usually (some are not, especially for fiber like FastWeb, or those offering VOIP phone contracts), so any modem able of bridging will work fine.
LEDE devices with modem should theoretically work fine (never used one) as the modem hardware itself is running the same blob that uses in stock firmware anyway, and they deal only with low-level stuff, while it's LEDE that deals with things like configuring the connection, doing authentication using your contract's credentials, and so on.
I've used bridged modems (that are basically doing the same, but the modem itself is external) when I still had a DSL contract and all was fine (with the one-of-a-kind modem model I talked about).
Technically I could also swap my current ISP's 4G-over-WiMax modem-router with a dumb usb dongle covering the same frequencies too (if I could find one) as it's not using any kind of gimmick, it recognizes my contract by using the SIM's number, the firmware in the device is pretty much stock stuff with some window dressing.
[quote]I will suggest that for QSG we can limit this to upgrading from a device with a GUI. I think it is fair to say that anyone operating "Development" with a CLi interface and who wishes to upgrade via CLi is at a higher skill level than the intended audience. We still want this, but it's a lower priority I think? [/quote]Well, even people with higher skill level will like to have some kind of quick start guide instead of having to read all documentation first. I personally learn faster by doing. And as I said if we keep the guides separated we risk going out of sync, but yeah it's probably less important for now.
[quote]From a design perspective (how people come in and navigate) I see at least 3 options.
- A "Start" page with some level of definition to the above configurations and links to individual QSG pages.
- A single QSG page with links out to other pages for secondary scenarios and other details (similar to today)
- A single QSG page with expanding sections using the "hidden" plugin.[/quote]I'd love to get point 3 working. Single page where we serve most basic configuration cases (both with Luci and with command line), and we keep it tidy and readable by hiding paragraphs that the user isn't interested in.
If that fails to be satisfactory, I'd do point 1 ("make your decision" page that sends people to a dedicated QSG for their usecase) . Having a single page that sends people around for each paragraph is confusing imho.
[quote]We can expect both approaches to have some external linking, for example, to a page on "Firmware Validation using HASH Values" or even the current "Standard Flashing Instructions". [/quote]Agree. These are actually same for all, they are their own topic with their own beginning and their own end, so they are fine as standalone articles that get referenced.
What I think should be avoided is to split a single article/topic (like the QSG) in dozens of partial subtopics with their own page so people has to click back and forth to reach the conclusion of the procedure.
[quote]I think that we should put the content aside for now and try to agree to on both the scenarios and approach, as this will probably impact the content details. I also think we should prioritize the scenarios (my take above). [/quote]Well, I expressed my view about this above.
Will make a tl:dr
Most important setups will have to be Client and Gateway (in this order), both luci and command line, and possibly all should be kept in the same QSG but with paragraphs hidden with that plugin.
Since the "let's replace the ISP-provided hardware" may or may not be possible, and may or may not be worth the hassle for the user, I would not use the dd-wrt steps as a skeleton of it, Rich wrote down a good structure imho.