Updating Standard LEDE Installation/Quick Start page

[quote="richb-hanover, post:19, topic:966, full:true"]* You're in a good position to make the LEDE router your primary router simply by swapping it with your current router.[/quote]It's not that easy and usually requires buying a ethernet modem that supports full bridge mode (or a specific brand and model of ethernet modem supporting full bridge mode if your internet line is using pppoA).
Routers with WAN port usually lack a modem, and in most cases the ISP provides a wifi modem-router that is unable to be used in bridge mode (what is needed to actually use a router with WAN port to replace the other.

[quote]* ... on a router (with LAN and WAN Ethernet port)[/quote]I'll just repeat that due to issues detailed already, the WAN port is not going to be useful in this setup, for a client device you have to set up properly the LAN interface anyway. So we can broaden the public to "any device with a LAN port" and not leave people with other devices wondering how they should configure their device.

[quote]... and a web GUI[/quote]Hm good point, we can drop the CLI instructions from there. I will go fetch them from the page editing history when I make other tutorials.

[quote]That's why I think it would be better to start with the revision from ~3 Feb 2017 (say, https://lede-project.org/docs/guide-quick-start/start?rev=1486145562) as a basis for the QSG. [/quote]There is no way around my "client" setup, sure I will now drop the CLI instructions and add a couple screenshots of the web gui where I have set up the info (as it's all done on the same page). That should be enough to be very easy to follow.

We should not tell people to use double NAT just because it's (marginally) easier to set up, even if it works because we make sure the IPs don't clash.

QoS requires that the LEDE device is itself the gateway, servers (samba, ftp/http/whatever) require that the server and client be in the same subnet, if it's behind a double NAT (one NAT happens on the gateway, second NAT happens on the LEDE device's WAN interface), it's not on the same subnet. So you can get devices connected to the ISP's modem-router that are unable to access whatever server is connected to (or runs on) the LEDE device.

[quote="RangerZ, post:20, topic:966, full:true"]I do not believe that most new users are looking to set up a Dumb AP (or bridge) out of the box[/quote]Me neither, which is why I think we should keep links for people that actually want to set up a true router/gateway.

The "client" device is just the easiest setup to get a LEDE device connected and working to an existing network, with most features also working (sure QoS won't work, nor hardcore networking stuff) so people can take their first steps and see how LEDE works as detailed by Rich above.

Heh, if by "router" we mean canonical router (just bridging two different subnets), then that's what I wrote in the "router" part of the setup, and that's already fine.

If by "router" you mean what most common people call "router" or "modem" (= the box that they use to connect to internet) we need to have instructions on how to connect this thing to the Internet so it can replace the other thing called "router" that is usually a modem/router.
Which means either bridging to an ethernet modem, use its own integrated modem, or a 3G/4G dongle. Basically expanding the stub I wrote in the "Gateway".

[quote]I have advocated elsewhere we change the default LEDE address, however the 3rd item above should avoid the issue, and not require the user to set fixed IPs (As DD-WRT has suggested in the past).[/quote]Heh, it depends on old network setup. More often than not, there is only one old box that is modem/router/wifi/switch/(optional VOIP telephone) that does not support bridging and a LEDE device with a WAN port (a plain "router" with no integrated modem) can't really replace that.

[quote]Related, I would like to clarify that single port devices are, by default in LEDE, configured as a "router". All the LAN side stuff is the same. The only real difference is there is no WAN physical or logical connection delivered by default. What ever flashing instructions for these devices should work up until the point we connect the device to the internet (3 above). At that point there can be a "Single port" bullet item with a link directing the user to another page for configuring the WISP\STation\Hotspot connection. (I have test Rich's instructions twice for this now).[/quote]While you are using "router" improperly, what you mean it's correct (LAN side is nearly always set with static address and DHCP server active) and I agree with this.

[quote]That said, the "Standard Flashing Instructions" should be the same for a user moving from factory or LEDE to a version of Trunk, but require different subsequent handing (SSH, install Luci, etc). While we do strongly discourage this use, it may be the only approach for a user to get their NEW device operating on LEDE, at least until the next Release version. (warrants more discussion)[/quote]I think this can be dealt with by simply having another QSG with command line instructions (also linking to a tutorial to use SSH/serial, possibly with a program that isn't a piece of garbage like putty/kitty, there are at least two that rock for Windows, but everyone and their dog uses putty/kitty)
Or, see the answer below.

[quote]make the QSG more "Quick", at least visually.[/quote]The visual effects of current wiki formatting on QSG are... less than satisfactory also for me.

And I think that keeping things on links is not that cool either especially as steps may change in guide1 may not be mirrored in guide2 so we end out of sync. I was thinking about implementing a spoiler-like system where you can expand blocks where you need them and leave the blocks you don't need hidden.
So you can dump the whole procedure in a single page, but keep all parts shortened until someone clicks on them.

Dokuwiki has a plugin (not installed in the LEDE wiki afaik) here that allows that https://www.dokuwiki.org/plugin:hidden

[quote]Regarding terminology, I would like to suggest that we consider adding a new WIKI section for "Terminology" (Definitions). [/quote]Yeah I agree that this will be useful, so we can keep all pages consistent, and cut explanations in the page itself to a minimum.

The LEDE wiki has a feature that allows it to show explanations for some terms (like for example LAN, if you hover it it pops up a text explaining its meaning), maybe we can use that too.

See https://lede-project.org/playground/sample-device-page#boot_logs for some examples how to hide text. Folded, hidden + outliner plugin are installed.

Not sure if this the right way to go. I fear that the automatic marking of such words will clutter a page with explanation over explanation over...
But we can certainly try this out.

It sounds like we may want to step back a bit from the actual detail and review the scenarios and approach, but I will come back to this.

If not "Router", then what is the proper term for the default delivered LEDE firmware configuration? Not trying to get into a debate on this honestly. I think you agree there is a strict definition and a more practical or accepted definition. I would like to get to a few terms for our immediate use that we can agree on. 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 (Client, Router, Gateway), and we may want to take some space to clarify these terms up front (not necessarily as below). I am open to other or better terms.

  • Router - The default LEDE config on first boot (LEDE Router). In most cases a Router or Wireless Router per the "Device Type" in the ToH. Single port devices with no physical Ethernet WAN, including Travel routers, Wireless AP, Range Extender and NAS(?) per the "Device Type" in the ToH. I realize I have omitted some types including SBC and other.

  • 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?

  • 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?

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.

So, back to my initial comment.

It appears that, and we I think agree, there are more than one hardware scenario to address, based upon the supplied ISP components.

  • ISP Modem => LEDE Router
  • ISP Modem\Router => LEDE Dumb AP
  • ISP Modem\Router => LEDE Repeater Bridge
  • WISP\Hotspot => LEDE Travel Router
  • Cellular Network => 3G\4G Modem attached to LEDE Router
  • Others?

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?

In addition we need to also consider the users Firmware selection. 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? We also need to have a note someplace to address users coming from other 3rd party firmware.

This leaves us with using a GUI (factory or LEDE) and upgrading to "Release" with LuCi or to "Development" without LuCi. I have stated the use case for this above. I think for the Development install, the router scenario above is relatively trivial, and once the GUI is installed, allows for use of the same GUI configuration guides as the other scenarios. I also think that any of the configuration scenarios are independent of whether the user has come from factory or sysupgrade. (flash vs config)

From a design perspective (how people come in and navigate) I see at least 3 options.

  1. A "Start" page with some level of definition to the above configurations and links to individual QSG pages.
  2. A single QSG page with links out to other pages for secondary scenarios and other details (similar to today)
  3. A single QSG page with expanding sections using the "hidden" plugin.

@tmomas, I added some more common text formatting items to the link above. I hope I have made some formatting mistakes as these elements do not appear to display as expected in any of these options. Please review and advise

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". I will not disagree there are challenges to maintaining a large set of individual pages, but maintenance issues are not unique to these scenarios.

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).

Playground Version
While my intent was to try to apply my suggestions from my earlier post with existing content, I basically ended up with a major re-write of the instructions. As I was unable to figure out how to create a Playground page, so the instructions are here. https://lede-project.org/playground/playground The approach is focused around a single page with links out to the deviations for most of the above scenarios (2).

While I built the above, I am not sure it is the easiest of the options to follow, but probably the easiest to maintain. Maybe some more formatting will help. In the HTML world I would take the folding menus, but at the moment I am concerned about the formatting limitations with these tools.

Every kind of folding/hiding has some limitations, see the plugin descriptions

You should avoid to use header inside a hidden section, because there is currently a bug with this case

Although the sample-device-page is currently in the playground, it was not intended to be modified like that. No problem, you couldn't know :slight_smile:
I created https://lede-project.org/playground/hiding_content as example page where you can play around, and also added more detailed working/not working comments.

As you create every other page in the wiki: https://lede-project.org/playground/enterpagenameofyourchoice-thencreatethispage-thenyouredone

[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.

  1. A "Start" page with some level of definition to the above configurations and links to individual QSG pages.
  2. A single QSG page with links out to other pages for secondary scenarios and other details (similar to today)
  3. 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.

[quote="tmomas, post:23, topic:966, full:true"]See https://lede-project.org/playground/sample-device-page#boot_logs for some examples how to hide text. Folded, hidden + outliner plugin are installed.[/quote] Thanks for keeping an eye on what I write lol. :grinning: Will test them later.

[quote]Not sure if this the right way to go. I fear that the automatic marking of such words will clutter a page with explanation over explanation over...
But we can certainly try this out.[/quote]Yeah, I hope we can strike a balance between "only 2-3 words per page have this feature" and "half of the words in each sentence have it so you can't find a resting point for the mouse pointer".

Stupid question time: how do I add more words to it? I don't see a plugin that looks like it in the list, so I don't even know where is the documentation for that feature.

This is not intuitive, especially for a Windows user. I have been looking for a File=>Save process. After a bit I realized that the link you gave me did not exist, but I could edit it

[quote="tmomas, post:25, topic:966"]
I created https://lede-project.org/playground/hiding_content as example page where you can play around, and also added more detailed working/not working comments.
[/quote] Thanks, I will do some testing.

[quote="RangerZ, post:28, topic:966, full:true"]This is not intuitive, especially for a Windows user. I have been looking for a File=>Save process. After a bit I realized that the link you gave me did not exist, but I could edit it[/quote]Afaik this is common in most wiki software. Non-existing internal links land you in a page that can be edited to add it.

Although it's also true that the page description ("You've followed a link to a topic that doesn't exist yet. If permissions allow, you may create it by clicking on “Create this page”. ") isn't really helping newbies here. There is no "create the page" button, only the same "edit page" button on the right.

Something like "Create this page by clicking on Edit button on the right" (while leaving the title as it is) would be better imho.

Hover the mouse over it:

The monobook template would show this as a clearly visible tab...

see https://www.dokuwiki.org/abbreviations
-> conf/acronyms.local.conf

Usage scenarios are constrained by the primary (ISP supplied) device. If it has a WAN then you can do a Router, if it only has LAN outputs then a Client as you call it.

From what I know in the US one needs to either have a ISP supplied device or an ISP approved device. Not sure we can reasonably cover all the alternatives. Not sure the user would understand. I think, right or wrong, the best we can do is have them look at the physical connections on the device.(WAN or LAN). Don't know what the rest of the world is doing.

I have played with the plugins and created a new page intended to support multiple scenarios. It draws in a lot of front end explanations which lengthen the document. Scroll to the lower half and you will find expanding sections at work. https://lede-project.org/playground/qsg_lede_installation_guide

Not clear that we can actually write a QSG for a repeater bridge. I think relayd is probably the solution which will support the broadest hardware, but not sure how well it will work connected to a non LEDE device. No clue as to what the issues are with writing a 3G\4G guide. To many variables in my mind.

I will have little time to spend on this for at least the remainder of the week

I kind of got lost in this discussion. I was under the impression that the most common use-case was installing a Release build on a router using the web GUI.

The current QSG tackles too broad a target, and leaves newcomers to figure out which of the detailed instructions apply to them. Here are a couple questions the current QSG will generate:

  1. I tried to follow the Quick Start Guide, but got stuck at Step 5. I don't know whether I have a client device or a router. Yikes - there's also a "gateway" device... Help!

  2. I keep seeing something about 'using the command line'. I don't know what that is. Do I need this? Where do I find it?

The biggest problem I see with the current version is that newcomers encounter questions that they can't answer while they're in the middle of the process (maybe after they've already made a difficult-to-reverse decision). This forces the procedure to have more and more steps to handle all those unexpected cases.

My preferred alternative is to set limits on what the QSG covers, and handle all the "exceptions" at the front, so that anyone who begins the process is more or less guaranteed to succeed.

The technology employed by ISP's is developing rapidly and so do the changes to the Consumer Premises Equipment (CPE). While I have a modem, I have learned that all the major US carriers are now deploying Gateway devices (combo modem & router) with only LAN ports for the consumer. All but Verizon offer some type of BYOD program which can still get one a Modem. This site summarizes authorized devices by carrier in the US. I expect the trend to lean towards Gateway (Modem Rotuers).

While I believe that for this audience the Modem is still the primary device, Alberto does not agree, but he is on another continent.

I see 4 technologies now:

  • Modem (WAN Port)
  • Gateway (Modem\Router LAN Port)
  • WISP\Hotspot (cafe to Friefunk via Wireless)
  • Cellular (3G\4G)

The default LEDE device config has forever been a basic router.

I agree, the current QSG version does not prepare the user upfront to understand his environment or prepare themselves to make the appropriate decisions. I would like to think I have addressed some of this in my playground version.

I do not wish to own the "approach", but suggest that it have some level of expand-ability, if for example, in the short term we want (and probably should) focus on the standard router we can still add other later with little or no rewrite.

The first 2 sections of my write up could be easily set as the QSG start page, with (eventually) links to these and other detailed guides. I do think it's easier for the user to follow a single page document, especially if they choose to print it.

At this point I do not think the Repeater Bridge and Cellular methods (post 23) are easily accomplished. I think there are too many hardware implications. While I advocated "Travel Router" as a separate category, I now think this is broader. Some locations are offering free broadband at a town or village level, which opens WISP up to even home devices.

and later...

I like this approach (and I have been thinking about it this way all along, but didn't say it very clearly.) This adds one more criterion to my list below:

Thus this page (https://lede-project.org/docs/guide-quick-start/start?rev=1486145562) could be modified like this:

Step 1 (above) remains #1 on the page - the Standard Flashing Instructions with its own separate page
Step 2 (above) is steps #2-4, 7, 10 on the page - connect to LAN with Ethernet, set up Wi-Fi, Done!
Step 3 (above) then becomes a separate page that tells how to reconfigure for the local network environment.

@bobafetthotmail, @RangerZ Does this make sense? If so, I will take a shot at rewriting the page above in this format. Thanks.

Step 1 above does not, in my mind, include flashing. It's all the "prep" work (understanding the equipment, usage scenarios, desired environment, finding and downloading of firmware to a local PC). I think this should be the (revised) "meat" of the start page.

Step 2 above, I have learned from testing, is really 2 parts. Part A is Flashing (the Standard Flashing Instructions Page) and Part B is configuring a usage scenario (currently #2-4, 7 & 10 on the start page for a router). Very distinct and different and IMHO should not be on the same page.

Flash processes (Part A) are mostly the same, however the development "first boot" should have the user install Luci. The resulting device then becomes the same as a Release version for "Part B".

Step 3, Ummm...

I was not really advocating this as an approach. It's just a statement of how the "box" opens, but as I now look at it was confusing.

I think you are suggesting that we have all users build a "Router" and then separately (via WIKI) reconfigure to another usage scenario.

I am suggesting, and I think Alberto is also suggesting, "On First Boot" we lead the user directly to their desired usage scenario.

I think the later works better, and here is an example of why. If I have a Modem\Router and want a Wired (Dumb) AP, if I go to my original Step 3 (reconfigure HW and go on line) with the device as a router, I will run into the double NAT problem and\or both devices may have the same IP. As it's own config, on first boot one would change the IP, disable DHCP, etc. save, shutdown and then move hardware. Repeater Bridge and WISP may actually never get connected. The process differs depending on the usage scenario.

Both can be made to work, and I will defer to you.

ATM here is what I am suggesting the page hierarchy look like. I am backing off from my approach in the playground page as I am concerned that the various technologies for expanding and collapsing sections do not support titles. This makes it hard to save, forward, share links directly to the content in other uses (ie forum posts), so I am back to thinking separate pages are more functional.

I am still hoping to have a simple procedure that works for newcomers who own "routers" (still the most frequent use case by far...)

But I am reaching the point where I don't care how the QSG and Flashing Instructions evolve, because it feels as if we want to explain how to handle every variation of equipment, all on the main page.

I have pushed so hard on this because I saw LEDE as our (one) opportunity to fix a major failing of the OpenWrt Wiki - the fact that it's widely acknowledged to be newcomer-hostile.

On the old wiki, there are dozens of pages that explain flashing the router. Most have a grain of truth to them, but they run on and on, mixing critical steps with unrelated (or wrong) information.

In addition, each device page has its own "take" on the proper ways to configure the router. These again mix good and bad information in ways that is difficult for newcomers to understand and get right.

I was hoping that we could "get it right" with LEDE.

Not quite... I have been suggesting a QSG page that contains only instructions for a limited (but very frequent) set of people who want to flash a Release build, on a router, with a web gui, that's going to be plugged into the ISP's equipment. If the reader's situation does not match those prerequisites, I was suggesting that the QSG intro offer links to pages that handle those cases (not a router, no web gui, installing Development build, etc).

GIven that we agree that the most common use case is those prerequisites (Release build, on a router, with a web gui, that's going to be plugged into the ISP's equipment), I wanted the first page of the QSG to tell those (most numerous) people what to do.

As an alternative: The QSG could be a short page that does not provide instructions, but instead provides a decision tree, so that people can follow a link for:

  • Release build, on a router, with a web gui, that's going to be plugged into the ISP's equipment
  • Development build...
  • Command-line install
  • Non-router
  • etc...

I don't like this nearly as much, because it exposes newcomers to all the complexity of the LEDE environment/ecosystem. They have to make these fine distinctions (with hardly any information, or familiarity with the project) when "all they wanted to do" was flash LEDE onto their router.

I tried to follow the Quick Start Guide, but got stuck at Step 5. I don't know whether I have a client device or a router.

That's a person with reading issues, as I have explained what is a client with examples, also what is a router and what is a gateway in the guide.
Client If you want to connect your device to an existing network to provide additional functions (for example, you just want to use the Wi-Fi network it provides, or the device is a NAS serving files over the network, or a mini-server offering whatever other service).

I keep seeing something about 'using the command line'. I don't know what that is. Do I need this? Where do I find it?

This has to be fixed eventually, I also called the web gui "Luci" which is not something a newbie would recognize.

My preferred alternative is to set limits on what the QSG covers,

Dropping usecases will make it pointless. Sure we won't start to describe advanced stuff in there, but reducing the QSG to only GUI and only router-like devices will mean everyone else with different devices is left out in the cold.

As I said I'm Ok with having a "landing QSG page" that will then send people over to the QSG for their usecase, but having only one that does not cover all devices LEDE supports is wrong imho.

[quote="RangerZ, post:34, topic:966, full:true"]While I believe that for this audience the Modem is still the primary device, Alberto does not agree, but he is on another continent.[/quote]Actually I was not disagreeing. I'm just stating how it is here on the other side, here DSL modems were dumb PC peripherals, not standalone devices. These things have pretty much all been replaced by modem/gateway devices long ago (mostly to get rid of the PC dependency). Older stuff lacks wifi, but is still acting like a gateway, so the instructions given in the original QSG are not working in the most common situation in EU.

I also said that if you want a true LEDE gateway setup you need to find a way to have a modem that supports the upstream protocol used by your ISP and that supports bridging so your downstream LEDE device can be the gateway and control the modem for DSL (or not control the modem for Cable).

[quote]All but Verizon offer some type of BYOD program which can still get one a Modem. This site summarizes authorized devices by carrier in the US. I expect the trend to lean towards Gateway (Modem Rotuers).[/quote]These are modem/gateways/wifi/whatever using DOCSIS protocol which is an industry standard, AFAIK there are no limitations other than technical (some modems like more some type of lines or dislike more some type of interferences, some are just cheap garbage, DOCSIS has different revisions and older devices don't support them all, and so on). Just google "docsis modem" and you'll find many such devices.

That site you posted states that they gathered feedback from people and ISPs to give you a list of products that will work well, they don't say that other devices using same DOCSIS protocol will not work because there is a whitelist or something.

For example, Comcast Xfinity requires a modem supporting DOCSIS 3.0, according to Comcast, (not just the one in that site).
They give a list of "recommended devices", they call "approved" but it's a recommendation http://mynewmodem.comcast.net/
"To ensure that your modem can take advantage of all that XFINITY Internet has to offer and avoid any service interruptions, you will need to replace your current modem with a DOCSIS 3.0 modem."

By googling it seems many DOCSIS modem/gateways still support bridge mode so it should be possible to get them covered with some instructions to get the ISP device to switch to bridge mode, to still give best effect.

But again, I don't know much about US networking and ISPs, and I cannot really check, this will have to be done by someone else on that side.

[quote]my playground version. [/quote]I like that. Good job. :slight_smile:

The "Understand Your Current Hardware, Firmware And LAN IP" might need better descriptions (also maybe screenshots of some devices) for the WAN and LAN ports.
The "Replace Your Existing Hardware With Your New LEDE Router" will need some change to work with people on a DSL (so that is using gateway device from ISP) as that part will work like that only for people on Cable (that is using a "cable modem" without gateway functions).

Also the "repeater bridge" and "travel router" could be joined as "wifi client device" because they are both basically using one of their radios to connect to a wifi network and will probably also want to generate another wifi for sharing the connection.

[quote]At this point I do not think the Repeater Bridge and Cellular methods (post 23) are easily accomplished. [/quote]I think repeater should be relatively easy, connecting to a wifi as a client isn't that hard with GUI (never tried with command line), see here RE450 as a repeater
But it is probably better to having just a link to a dedicated paragraph dealing with that in the "configure wifi in LEDE" page as any device can be set for that, not just those sold as repeaters.

Cellular should just link to other documentation or tell to go look in the device's own page (for devices that have an integrated cellular modem, as that is not core functionality.

EDIT: are we sure that there isn't also (many) people in the US that are not using Cable internet but some DSL variant? Because by googling I get tons of ISPs in the US that are not Cable providers (say AT&T) that offer DSL, not DOCSIS stuff.