Updating Standard LEDE Installation/Quick Start page

Talk about Documentation
35

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.

36

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.

QSG Hierarcy.png577×678 13.5 KB

37

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.

38

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.

39

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.

40

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

41

If I understand the implications of last two posts, am I correct that the QSG, as originally written, will only work for the user with a cable (DOCSIS) modem and not a DSL modem, as we also need to consider the WAN protocol selection for even the basic Router case (Network=>Interfaces=> WAN=> General Setup=> Protocol) in configuration?

42

Good question. All DSL modems that I have ever seen have LAN Ethernet ports, so we can treat DSL Modems the same way as we would treat a cable modem. (That is, leave the LEDE WAN port in DHCP mode, connect an Ethernet between them, and it'll "just work".)

I view setting up PPPoE as a (very) advanced topic, since you have to a) configure the DSL modem to act as a bridge, and b) make sure you have the right PPPoE credentials... I have done both here on my DSL line, and don't think there's much difference between the two settings (DHCP or PPPoE), either for efficiency/throughput or for security.

Leaving the DSL modem in DHCP mode makes for slightly easier administration, since I can always point my browser to the DSL modem's IP address and see its stats: signal and noise readings, link speeds, DSL link uptime, etc. to see if my ISP is "doing it right".

43

[quote="RangerZ, post:41, topic:966, full:true"]If I understand the implications of last two posts, am I correct that the QSG, as originally written, will only work for the user with a cable (DOCSIS) modem and not a DSL modem,[/quote]Yes. I don't know how it works with cable modems as I've never seen them where I live, but the device you usually have if you have a DSL line (I assume this isn't different in the US) is a gateway with LAN (and wifi if it is new enough), usually set at 192.168.1.1 so the original QSG can't work on it or if it does work it is a bad choice (double NAT).

[quote]we also need to consider the WAN protocol selection for even the basic Router case (Network=>Interfaces=> WAN=> General Setup=> Protocol) in configuration?[/quote]Kinda, but it is more complex (at least in my experience). That's why I was pushing on Client (or "Dumb AP" as you call it).

AFAIK you can do that only if the DSL device given from ISP is capable of at least half-bridging (I don't know how many can, I'll need to ask around friends and family) or full bridging and if the upstream DSL line is using PPPoE protocol.
If upstream DSL line is using PPPoA protocol (common in Italy, and also in the UK and AU and NZ from what I read, as it works better on crappier lines or something like that) your only choice is using a LEDE device with integrated modem or buy a specific modem (draytek vigor-120 that converts PPPoA in PPPoE transparently so it allows to use any other router in bridging over it (the whole selling point of that device is this rare ability, it's otherwise a pretty unremarkable and very weak modem/gateway device like many others).

44

[quote="richb-hanover, post:42, topic:966, full:true"]
Good question. All DSL modems that I have ever seen have LAN Ethernet ports, so we can treat DSL Modems the same way as we would treat a cable modem. (That is, leave the LEDE WAN port in DHCP mode, connect an Ethernet between them, and it'll "just work".)[/quote]Yeah, if the LAN IP address in LEDE is different from the LAN IP address in the DSL modem/gateway device, that is.
Usually they don't so things don't work unless you add a line to tell people to change their LEDE device's LAN IP.

Also this solution has the backside that all devices must be connected to the LEDE device to see each other, and that double NAT will break some things or cause issues or add latency (increase ping for games), like gaming or other programs that need to open ports in the router or need to know the WAN's IP, they will open them in the LEDE device (that is their "router") or they will know LEDE device's WAN IP, so the ports will still be blocked upstream, or the IP will differ.
This will cause random issues that will be annoying to troubleshoot if you don't know beforehand where to look (and they won't).
If they need to have the LEDE device accessible from the Itnernet (they run VPN servers, or any kind of server) it's even funnier as you need to add port forwardings or set up DMZs, so you are going to complicate things quite a bit.

Please don't do this. If people can't set up a bridging (itn's not hard per-se, it's 3 clicks in LEDE interface panels to set it, the hard part is getting the info and devices that actually work the way you wanted to, this forges character), have them set the LEDE device as Client or Dumb AP.

EDIT: what I want to say is that while a double NAT setup is ok for people that only need access to Internet, people on LEDE will have more chances to want to try features that will be hampered or made more complex by a double NAT setup, so I don't think this should go in the QSG as it will make any other tutorial more complex.

45

Hello,i have router,but working as switch,installed ddwrt,but now trying install lede,but no success still stuck with ddwrt full router model is Buffalo WHR-HP-G300N v1.2 with Atheros AR7240,i know that is in supported devices,via wegbui first i install with lede-17.01.0-rc2-r3131-42f3c1f-ar71xx-generic-whr-hp-g300n-squashfs-factory after that lede-17.01.0-rc2-r3131-42f3c1f-ar71xx-generic-whr-hp-g300n-squashfs-sysupgrade where i doing mistake,because LEDE working fine on other my tp-link router.In final result i still have ddwrt on this device.:unamused: how correctly install and ridoff that ddwrt?

46

@dratas, lucky you... maybe. Had one of these, did this about 2 years ago. I have some very cyptic notes. Not sure where they came from or that they are accurate\complete.

It appears to take you through refreshing the router, connecting it behind your LAN, getting into the G300 shell, downloading the firmware directly to the device and then flashing from the CLI. The putty fatal error I think is not an issue. After the firmware flashes one can expect the SSH session to die.

Good luck.

Enable LAN on PC
Connect PC LAN to Router LAN
Connect router WAN to a LAN port on your primary router

reset Router via DD-WRT 30\30\30
Reboot router
Enter new user and password

Access router and enable SSH under Services=>Services
No other config is needed.

Verify router has a WAN address. If not release\renew IP from Status=>WAN or reboot router.

Access router via putty at 192.168.11.1 (port 22)
NOTE: a warning will be presented alerting user about security. => YES

User: root
Pass: password set after router reset\reboot
NOTE: username is not the user set after reset\reboot

cd /tmp
wget http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/openwrt-ar71xx-generic-wzr-hp-g300nh-squashfs-sysupgrade.bin
You will see a progress bar indicating the status of the download

mtd -r write openwrt-ar71xx-generic-wzr-hp-g300nh-squashfs-sysupgrade.bin linux
You will see a message "Unlocking Linux
Followed by
Writing from "file name" ... [w]

Putty fatal Error
Server unexpectedly closed network connection

Router lite flashes
After a few minutes the light will turn solid

CMD
ipconfig
ipconfig /release
ipconfig /renew

Clear Browser cache
NOTE: IP will have changed

Open browser and enter 192.168.1.1
LuCi should open
User: root
Pass: [blank]

I would like to know if this works and if you can "freshen it up" with more details. This has been asked a few times, but I just found this.

No clue why I uses the sysupgrade over the factory, but the DD-WRT was not the true Buffalo factory firmware.

47

I flashed to ddwrt without any issues,btw buffalo also have two firmwares one for user friendly(factory stock) and other based on ddwrt(for pro users)hmm,maybe try flash to openwrt and from openwrt to lede.:relieved:

48

I always have had a cable modem, so it's the only tech I really know. Simple box with a COAX in and WAN out. Mine also has VOIP in it (any relevance?). I have no configuration access to the device. Other than the firmware default being DHCP client for protocol and it worked, I never had a need to really question it being right or wrong.

I think I started this, but we may want to loose the term Gateway, which I used to refer to Modem-Routers. Reading the Wikipedia article it is basically the entire family of connection devices. I think that Modem (devices with WAN ports) and Modem-Router (devices with LAN ports) are probably better terms for our use as the type of connection will, at least in part, determine recommended usage scenarios. Please confirm.

Most of the "bridging" discussion is above my skill set. Are you saying that we want to bridge the WAN to the LAN so we can get a pipe straight through the device and among other things avoid double NAT and better support Port forwarding for VPN and services?

I think we all want to get this right

Can we agree that "Flashing" a device and "Configuring a Flashed Device" are two independent tasks? If so can we agree to document them separately? I think it will make referencing them cleaner in the future.

I do not think that we can stop people from writing wikis, but if we get ahead of the problem with the handful of major usage scenarios that work then maybe we can minimize the issue. I hope that we can also lock the pages to a select few.

For configuration I think the goal would be to do the minimum to get the device functional on the internet with wireless working for a usage scenario. We can debate Time zone and wireless Country Code. No USB, no alt DNS configs, no Guest LAN. Last line in the config instructions should point to the user guide for additional config and features.

I updated my playground today with what I see as the "other" flashing scenarios (4 total) and the Travel Router config (Should be called WISP as it will work for most any router) .

There will still need to be device specific docs for some devices (removable media, x86, other?) that are not mainstream. I think we should acknowledge these up front (prerequisites etc) and drive users to the Device Pages.

Maybe we need a Poll to validate the accuracy this is. If the most frequent use case is 80% of the users it's one thing, if it's 35% of the users, it's something else.

What is the method that you use to connect your primary LEDE device to the internet?

ADSL\VDSL Modem
ADSL\VDSL Modem-Router
Cable Modem
Cable Modem-Router
WISP\Hotspot
3G\4G
Other

49

Not clear what your saying. The Buffalo factory to DD-WRT and back was a feature offered by Buffalo. The help I offered assumes you are using the Buffalo DD-WRT version. It should not matter if you use the older OpenWrt or the newer LEDE files. All I am saying is my notes indicated that I used the SYSUPGRADE, nit the FACTORY upgrade.

Your first note indicates you flashed the LEDE Factory first and then LEDE sysupgrade from DD-WRT, but you are not clear on where you were when you installed the LEDE sysupgrade (LEDE or DD-WRT)

Have you tried the above?

I assume you could try reverting to the Buffalo Factory and then install using the LEDE Factory Upgrade version.

I do not expect you can upgrade from DD-WRT version using the DD-WRT firmware Upgrade GUI tool with the LEDE Factory or Sysupgrade firmware.

While we may need to address this type of upgrade, if you require additional help please create a new post in the Installing and Using LEDE forum section. You will get more visibility and your post will help others better in the future.

50

ok to be clear i can explain what happens,so in router is installed simple DDWRT not from Buffalo,but from ddwrt,when i trying install LEDE router shows that Upgrade succes,but still ddwrt stays as is and no LEDE in router so how to succes remove DDwrt and install LEDE?:relieved:

51

@Dratas would you now please open a new posting about your problem as already advised 3 times? Thank you.

52

Holy hot damn, my ISP is both NATthing and firewalling me.

For the sake of adding documentation to the quickstart (and because I want to have more control over my new line) I've been testing various bridging options.

-bridge mode is available in the ISP device's firmware but does not seem to work (the WAN port in the LEDE router isn't getting the IP from the ISP as advertised in the device's manual).

-"poor man's bridge mode" (using a DMZ to get around the double NAT) still fails because it seems my ISP is NATting and firewalling all its customers upstream anyway, so whatever I do (adding DMZs, port forwardings and whatever) I can't access my LEDE router from outside. "WAN IP" as shown in the ISP's gateway differs from the IP I get if I use websites that tell me my public IP and let me check ports.

I've added a tutorial for the "poor man's bridge mode" here, and will make one also for more conventional bridging.

I'll try to ask nicely to my ISP if I can get something resembling a public IP and they can stop firewalling me like that, but I suspect that it's not possible and I won't be able to test the above tutorial(s) in any way.

So if someone can try it out and report back, it would be highly appreciated.

53

Ok, I've written the info and tutorials about integrating the LEDE device in an existing network.
https://lede-project.org/docs/user-guide/start#integrating_a_lede_network_device_in_your_existing_network

Can I get a few lines of from people that have Cable Internet so the article covers these types of users too?

Then I'll have a look at hooking this into the quick start guide.

54

Not sure exactly what you want for where.

I have a cable modem service from RCN (US Based, Boston MA, www.rcn.com)

I have an Arris TM822 Modem, which is included in my bundled service. I could purchase this separately, but there is no savings. The COAX input from RCN is split with one segment serving video and the other going to the Cable Modem.

The Arris Cable Modem has a Coax input and both an Ethernet connector which goes to my router and two RJ-11 connectors for VOIP telephone services. I get a DHCP WAN IP from RCN. I have no user access to the Arris cable modem. I do not need to supply any credentials for network access.

I get a DHCP IP address assigned and it appears that unless I loose power for more than 24 hours (and not sure if it's longer) that I keep the IP for a given MAC. If I change the router, I will get a new IP. I do not recall what happens if I change the router back to the original. I used to have to ask to have the device provisioned (older modem), but with this device I do not. I also get DNS servers supplied by RCN.

The Arris (now owned by Surfboard) quick start guide can be found here: http://surfboard.com/wp-content/uploads/2014/07/ARRIS_SURFboard_TM822_Quick_Start_Guide.pdf

RCN Allows users to purchase devices of thier own: http://www.rcn.com/hub/help/bring-your-own-modem/
There is not a list with specific part numbers however this third party link suggest alternatives: http://www.approvedmodems.com/rcn.html All these devices are Cable Modem only (No VOIP) and there are no "Modem-Router" combinations on the third party list.

Let me know what other info you may want.