[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Review Wiki page for TP-Link W8970(B)

Hello,
A few days ago I got an TD-W8970B and flashed it succesfully with OpenWrt 18.06.1 .
I was a little bit struggling with the Wiki Page of the router.
One hand there is a huge amount of information.
Other hand it seems some of the information is outdated and spread of to the 3 router types 8970/8980/9980.
Because I am new to this router and also not an OpenWrt pro (only a user for some years on 1043nd) I don't want to change the info in the Wiki (or at least not without confirmation)
What I have noticed:
The "danger field" with the information not to upgrade to 12.10.2013 or newer of the TP-Link firmware:
Even if you get a router with such an antiquated FW version, there exists no factory image for this router to flash via the webinterface.
I would delete this info.
Hardware Highlights:
I have counted the Gbit ports again and again, I found only 4.
Only if you count also the CPU port it has 5. I don't think this is correct at this point.
Also the info about the modem is confusing:
ADSL2+ is correct with stock FW, but with OpenWrt it is VDSL. Only I am not sure how to show this on device page ...
Installation without opening the case (Web Interface Hack)
SSID Config Injection
I don't know what is meant by "newer firmwares".
In my case I tested version 141008,150526 and 160808 for W8970B without success.
Maybe someone could tell with which FW version this procedure is working on W8970(B) .
Or maybe this works only with W8980/W9980?
StatPost (old)
Opposed to the info in the wiki, with this procedure I was able to get a root shell on my W8970B with FW version 160808.
Installation via telnet/root shell:
I think it is mandatory to use OpenWrt 15.05 for flashing via telnet. After this you can upgrade to 17.01/18.06.
Something seems to have changed in partition layout of 17.01/18.06, and if you use these versions for first OpenWrt flash (via telnet, not serial) your router will brick and you need to use a serial connection to debrick.
Maybe I am wrong, because there is the sentence: "Rumours are that with the recent OpenWrt that you need to take care that the image you write to mtd2 needs to be extended with 0xff characters to the end of the partition"
Only, I don't wanted to test this because of "rumours", I don't wanted to have a bricked router afterwards...
Also I would like to copy the whole "telnet procedure" to wiki of W8970. At the moment it is described only on wiki for 9980 and in the old forum.
Switch
it is described the ethernet ports would act like a hub.
To me that seems to be wrong with 18.06.
Specific Configuration:
information about "VDSL.BIN" and "DSL Settings" is only for 15.05 and has changed in 17.01/18.06 .
Not sure if there should be any information about xDSL FW and configuration at this page,
because FW file and settings are the same for at least all Lantiq based devices.
Only, I found no page about FW files in the Wiki (actual info only in the forum?)
Ok, now I have produced a forum post that is at least as confusing as the wiki pages for this router...
Maybe someone could confirm and/or add information (e.g. about stock FW used for Installation without opening the case) and I would change the Wiki page.
Regards
Azmuth

3 Replies
2

[Assistant]
Probably
@bobafetthotmail
or someone else from the documentation team might chime in. You can also open a 'talk' page in the wiki linked to the page you'd like to edit. I don't know which of the two methods may get the relevant attention more quickly.

1 Reply

I'll also summon
@tmomas
as he is the man for hardware pages.
I think you are talking of this article, correct? https://openwrt.org/toh/tp-link/td-w8970_v1
The "danger field"
This might be interesting info to place below in the "Web Interface Hack", I would move it there. Drop the wrap "danger" box as it's not really very important information anymore.
Kids these days, scared by setting up a serial to flash a router.
Hardware Highlights:
yeah it's kind of obvious that this device has 4 Gbit ports and one port for ADSL cable thing.
Hardware info is loaded by this device's entry in the Table of Hardware
OpenWrt Wiki – 19 Jan 16
Table of Hardware
Table of Hardware This is the main Table of Hardware, listing all devices that are supported by OpenWrt. ---------- Using the Table of Hardware * Sort the columns by clicking the column header * Enter your filter criteria in the white...
and this is its page/entry https://openwrt.org/toh/hwdata/tp-link/tp-link_td-w8970_v1
Edit it to correct what is wrong. For the ADSL+ / VDSL thing I would correct that too, as that is what the hardware is actually capable of and working in OpenWrt.
Installation without opening the case (Web Interface Hack)
Remove mention to "newer firmwares" and the "old" from the title, write the firmware versions you tested and the results, with a date. People will at least know what worked and what did not, at what point in time.
Don't delete things, maybe there are other versions of the firmware (in many cases there is a US and a EU version) that are susceptible to different expoits.
Installation via telnet/root shell
lol, "rumors", some people can't be serious even if their life depended on it.
This person is telling you to add hexadecimal "FF" as padding up to the size of mtd2 to the second part of the firmware image you split, and it can be done with dd the same way as you split the image file https://superuser.com/questions/274972/how-to-pad-a-file-with-ff-using-dd
I quite frankly don't know why it asks you that, but it won't hurt per-se.
Anyway, it seems strange to me that you need a specific OpenWrt version. From what i understand of installation instructions you are just splitting a firmware image over mtd1 and mtd2, and afaik OpenWrt will (on its own) erase and use mtd partitions 3, 4 and 5 too.
I'll look at the source code this evening and see if something has indeed changed or not in the partitions or sysupgrade.
Only, I don't wanted to test this because of "rumours", I don't wanted to have a bricked router afterwards...
If you have serial access with a TTL dongle (the pinout and how to reach the U-boot console is in the article under Serial) you will be able to recover from it. As long as you don't delete mtd0 (the U-boot bootloader, which is the software you will be talking to through the serial console) or mtd6 (radio firmware, necessary for wifi operation) you can do all tests you want.
The "serial install instructions" and the "serial recovery to original firmware" steps, are done through U-Boot bootloader in mtd0.
it is described the ethernet ports would act like a hub.
If you have the means to test this (i.e. set up a VLAN or use wireshark) and confirm that it's not the case, add this information after that line, something like "VLAN in switch working in 18.06"
information about "VDSL.BIN" and "DSL Settings" is only for 15.05 and has changed in 17.01/18.06 .
Not sure if there should be any information about xDSL FW and configuration at this page,
because FW file and settings are the same for at least all Lantiq based devices.
Yeah it would make more sense to have all info about Lantiq modem setup in a single article (which would just be linked if needed) and dump all the redundancy and outdated info from hardware pages.
I can't do that because I lack the hardware and the ADSL line to test it. And also because I hate modems.
If you want to do that though you're welcome.

1 Reply

afaik the "talk" functionality in the wiki was disabled as redundant, all discussions should happen through the forum. Mentioning me or tmomas with the @ will get us notified that someone needs us.


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: A bigger picture

A bigger picture for device documentation
Over the last years I've been talking every now and then with
@tmomas
and other OpenWrt members about "user experiences" when handling firmware. After I suggested some radical changes in device documentation and firmware selection he asked me for a bigger picture. Here we go
This document tries to offer a status report on the user facing resources when
interacting with OpenWrt. It should be seen as a work in progress and suggestion
for extension and clarification are very welcome! Parts may be written in a mean sounding way, this is with no intention and will be changed once I'm aware of it. I highly value the work of the Wiki team!
Motivation is to improve things as both new and long-time users complained about
parts of the current implementation. The ideal outcome of a reworked
documentation and user experience would be:
Non tech-savvy router users feel confident in flashing OpenWrt on their devices,
resulting in a more secure Internet.
It then tries to determine requirements needed for this goal eventually propose
solutions, resulting in concrete To-dos.
Status
The following tries to summarize important user facing resources.
Downloading an image
Finding the router specific firmware is difficult for new and inconvenient for long-term users. The Downloads page first link clicked by a user forwards to the releases overview, which is confusing to say the least. If the user figures out that 19.07.3 is the latest release, which is not stated on the previous Downloads page, they end up at a the target overview. Again, confusing for someone new.
At this point whoever likely uses a search engine to end up at a device specific page.
As a random example, searching for a Archer C7 brings one to this page, which stores the link in one of multiple tables, combines with other similar devices. Overall are the information on the website likely overwhelming for non developers. The specific SoC or WLAN Hardware or CPU MHz are unlikely of direct interest for a common user.
As the page contains information for multiple devices at one, it is not trivial to parse which information is important for which device. Important information are likely missed due to the amount of information.
When choosing a random other device page, the article structure is likely different, either in amount of devices covered in the page or amount of in-depth information.
Keeping software up to date
OpenWrt tries to, but does not yet fully follow a 6 month upgrade cycle. This means, unlike for other distributions like Ubuntu, there is unlikely a feel for there must be a upgrade soon. Due to the lack of a announcement mailing list, regular users may miss new (service) releases and keep running outdated (and probably vulnerable) software on an Internet facing device.
The upgrade process itself involves again the identification of the correct image. Which means a X-Mas flashed router isn't trivially updated by its later users.
Software overview
OpenWrt offers a package overview both within the Wiki as well via CSV files. It show the package version within the latest release, no snapshot versions are covered.
Hardware suggestions
The table of hardware suggest to avoid devices with only 4MB of storage and 32MB of RAM. Consumer relevant information like dual-band, USB ports or WiFi standard (ac, ax, etc) are not easily visible. Looking at the per device overview gives a lot of information which is partly relevant for developers only, empty or wrong.
While there is a list of recommended device no complex search masks are available. The table size requires a lot vertical scrolling.
Device specifications
As mentioned before a per device view exists while a more complete overview exists at wikidevi.com or it's mirror/clone wikidevi.wi-cat.ru/Main_Page. These information are valuable but not embed-able in our views due to a lack of API. If all wikidevi clones die, all these information are lost.
Requirements
This sections tries to write requirements for a better user experience.
Data availability in machine readable formats
All stored data should be available in machine readable formats to allow downstream projects to develop their own tooling. This includes device information, package information as well as image/artifact information.
The data should be available in JSON and CSV if applicable.
Community edit and reviewable
All data shouldn't be maintained by a small group of people with privileged access, but everyone in the community. To allow a transparent process changes should be reviewable like Git Pull Requests on GitHub/GitLab.
Solution proposals
Here is a list of possible solutions, none of them is complete. Also the combination of the solution is point of discussion.
Firmware wizard

@mwarning
is currently building a firmware wizards with a clean interface to easily find firmware images. Additional information could be shown, either hardware specs or installation steps.
OpenWrt JSON
The openwrt-json repository downloads available packages and stores them in JSON format, allowing tools like the firmware wizard to load package lists. The files manifest.json contains all information as provided by the current OpenWrt package overview. These JSON information could therefore also be rendered to a static website.
OpenWrt devices
The openwrt-devices repository converted the OpenWrt table of hardware to YAML files. These files are both human and machine readble and could be rendered to a Wiki like device overview. By using templates we can be DRY (don't repeat yourself), meaning we don't write 50 times the same 5 steps for installing TP-Link devices, but put it into a template. The page could look like the following screenshot, which is a recycling of the LineageOS website. We would obviously use something else, but it should give the idea.
Automatic upgrade selection
A proof of concept script automatically downloads multiple JSON files containing information to existing upgrades and images. This would allow a LuCI integrate where the user installs an upgrade via a single click.
To-do
Please share your thoughts. I'll update this post with a changelog.

1 Reply
15

[Assistant]
Since we are proposing new feature something to get official announcement based on the firmware (affected vulnerability, new update, improvement of the device in the new version) would be very useful since the router would be connected to internet anyway.

1

@aparcar
,
@mwarning
-- Loving the download wizard, it does look very much LineageOS-like! I'd make a suggestion to display "What's a snapshot" explanation if the Snapshot is selected from the left drop-down.
I also support
@Ansuel
's suggestion, I understand some people would prefer to turn off the "phone home for update" feature, but would be nice to have new release notification integrated into SSH banner and WebUI. Maybe make it a separate package because it would most likely require SSL support. I don't know enough about the backend, but the client side would probably be trivial.

1

We all so need a news ticker on the OpenWrt home page to highlight packages or mager changes to OpenWrt like the jump from ar71xx to ath79. Or in bed the OpenWrt twitter feed.

1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: RFC pkgs.staging.openwrt.org

Hey all,
tl;dr checkout https://pkgs.staging.openwrt.org/
As some may experienced, openwrt.org is slow an one (of many reasons) is that it stores and renders tables with all packages.
Based on feedback the experience is neither convincing nor does it perform well within a DokuWiki.
After asking our fellow friends from Alpine Linux1 respectively postmarketOS2 I got an okay to fork and deploy the tool apkbrowser, which is now pkgbrowser3 since it currently handles OPKG packages.
I’ll refactor and commit the update-script later, essentially it polls our buildbots and whenever a build is completed, the database is updated. For that reason some packages are still missing. With more time missing packages/archs are added.
The tool nor server are tested under load but I fell quite positive it’s more fun than our wiki implementation.
If this turns out to fly, I’ll link it in the wiki, move it to pkgs.openwrt.org and remove all package functionality from the wiki.
Thanks to Carlo Landmeter et al for implementing such a handy and adoptable tool!
Best,
Paul

1 Reply
9

[Assistant]
As long as web crawlers can pick up the details and it becomes searchable from Google that’s fantastic.
99% of the time I reach package pages by googling “pkgname openwrt” and it’s usually the top result.

1

aparcar:
tl;dr checkout https://pkgs.staging.openwrt.org/
This looks great, thank you!
I have used Alpine's package searching UI quite extensively and so would benefit from having OpenWrt's use a similar interface.
It does feel more responsive then the current wiki version.

Outstanding! Looking forward for when it's released, so we could send a curl search page to the curl project so that they could scrape it and fetch and show version of curl available for OpenWrt!


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: OpenWrt on VMware / Virtualbox HowTo: Still up-to-date?

OpenWrt on VMware HowTo
Still links to 14.07 / 15.05 images
Has anybody sucessfully tried the linked How To with a more recent OpenWrt version, e.g. 17.01, 18.06, or even the upcoming 19.07?
If Yes: Can you please review the page for correctness and update it where necessary?
OpenWrt on VirtualBox HowTo
Seeing the change history, it seems to be reasonably up-to date
Links to snapshots instead of stable release
Any reason for chosing snapshots, not stable release?
I guess the instructions are also applicable to stable release, right? If yes, a short note on the linked page would be nice.

1

[Assistant]
Disclaimer, I haven't used virtualbox in ~10 years and never had any access to VMware; I'm quite actively using qemu-kvm, mostly for non-OpenWrt, but occasionally also for quick OpenWrt tests.
Is there a particular reason why either of them directly links to a specific image at all, rather than just referring to the normal x86/ x86_64 images? If the hypervisor can't cope with the current version, there'd be a serious problem (most likely on the hypervisor side, as OpenWrt is 'just another linux distro')[0].
In general there shouldn't be anything OpenWrt specific in virtualizing it, the user just has to be proficient to configure their hypervisor of choice. Getting the hypervisor side networking obviously isn't as easy as for normal client operating systems, given that two independent (virtual or bridged) interfaces are needed, depending on the requirements with direct access to the wired network in order to provide networking services to real iron.
--
[0] yes, choosing the correct emulation types, virtio drivers where possible, etc. are somewhat hypervisor specific. but in general, the virtual hardware is just another x86 system - and OpenWrt should work with any default environment, perhaps not in an optimal way, but it should work.

1 Reply
3

Use virtualbox. it's relatively up to date.... forking the lower network stuff to another page might help to cleanup the page and keep subjective hypervisor specifics differentiated..... ( don't have the wifi-fu to do that )
disk expansion / conversion can be tweaked/clarified a little...
( i think SNAPSHOT was referenced because RELEASE is a moving target... aka... docs will soon be stale.... needs a dyno-tag for the current release? )

1

Hello,
Just a couple of quick observations about the VirtualBox install. There are several errors there – I suggest not making any more small changes until the whole process is checked.
The Snapshot and Stable files are a completely different size (with and without Luci, for a start). The instruction to resize to 128 MB is very out of date as even the Snapshot image is already bigger than 128 MB, so trying to shrink it will produce an error. I guess that resizing is to allow room to install Luci, so may not be necessary for a Stable image anyway.
The name of the image to download is not consistent. Sometime it is referred to as combined-squashfs, sometimes as combined-ext4. The difference between those two files should be explained and which file should be used for which situation. If the choice of image depends on the OS of the VBox host machine, then it's probably better to separate the first part (obtaining and preparing the image) into sections for Windows hosts and Linux hosts.
I will try to go through the whole procedure in the next days, but I only have Linux hosts for VBox.

1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Table of Hardware: Updating device availability

A lot of devices in the Table of Hardware have an outdated / non-existing availability status. In order to keep the ToH usefull for users searching for a new device to buy, the availability data should be updated regularly.
Current status
Available 2017 (80)
Available 2018 (61)
Available 2019 (310)
unknown 2018 (192)
unknown 2019 (51)
unknown 2020 (22)
=> more than 700 devices with outdated status
Task
Check commercial availability of the devices listed at https://openwrt.org/toh/views/toh_admin_available
Make sure you have read the instructions Before updating availability status
Click on the links to filter the table for the respective availability status:
Update availability of a device by clicking on “View/Edit data” in the last column, then follow the instructions on the dataentry page
If you can buy a device in 2020 -> Available 2020
If you can not buy a device in 2020 -> Discontinued (bonus points if you know in which year)
Do not enter Available < year in the past >. We have 2020 and we want to know if this device can be bought today, i.e. in 2020. We do not want to know when the device first was commercially available.
Click Preview to check your edit for correctness.
Click Save to permanently save your edit.
Your help is needed
The OpenWrt wiki and Table of Hardware are from the community and for the community.
The more the community contributes, the better for the community.
Do you see any device in https://openwrt.org/toh/views/toh_admin_available that you know has been discontinued by the OEM? Great, then you can help to keep our data up to date! See above how you can contribute directly.
If you do not have an account for the OpenWrt wiki (and you don't want to create one only for this task), just let me know your input here in this topic, and I will update the data accordingly.
Thanks for your contribution to the OpenWrt wiki!

1 Reply
5

[Assistant]
I'll start tagging here whoever complains that wiki sucks

6

Device availability might be difference from country to another.
I think we need some definition of "availability" and its boundaries.
(please pardon my bad english)
-Han-

From https://openwrt.org/toh/views/toh_admin_available
Don't care about “sold only in US/EU/CN/…”. If the device is available $somewhere, it is available.

2


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: The confusion surrounding upgrading x86 openwrt

As of 2023.10.29, the wiki page on x86 openwrt states the following about upgrading:
Use sysupgrade: this is default upgrading procedure but the least recommended option for x86 machines. Proceed to Sysupgrade for details.
Seach the forum and the internet, it is not difficult to find people asking what to do with x86 openwrt. I believe the reason people are asking is larglely cause by the above statement.
In particular, the wiki page gives no details about why this simpliest option of using sysupgrade is the least recommonded option.
Before someone jumps in, let's be clear that there is another universal option of upgrading x86 and non-x86 devices, and that is the Attended SysUpgrade (ASU) .
What many come to the forum to search for, and the topic of this post, is the more tranditional approach of flashing a common firmware, while checking the option of preserving configurations.
It is understandable that people who extensively modifed their x86 installations may have to think of more complicated approaches of upgrading, and potentially may need to find a way to automate their configuration.
But for the majority of users, whose configuration may mainly be about static IP leases and a couple of port forwards, I wonder whether it is correct to recommond the usual sysupgrade GUI interface? For all the experts out there, please comment.

1 Reply
4

[Assistant]
umggc:
Before someone jumps in
I jump !
I use sysupgrade for x86 on a regular basis, and see no side effect or cons. That being said, it depends a lot of the use of the machine, the partition scheme, presence of extra partitions with data. There is no universal case on the matter like with conventional router.

1

This is also what I found. I just went from 19.07 to 21.02, then to 22.03. The only extra step was when reaching 21.02, I was asked for an automatic conversion of configuration format, and the automatic conversion seems to generate no issue.
Sure, if someone bothers to alter patitions, then extra steps are needed. But in my case, I am just leaving everthing untouched, because all I need are some static DHCP entries and port forwards.
Mine is virtualized. Essentiall many other things people try to put into openwrt, I have several VMs doing them. Thus my openwrt setup ends up being very simple.

1 Reply

And on top of that, wiki option 3 and option 4 are both rewriting their root partitions. I can't see how they are useful in any way for those who didn't have extra partitions.
For someone who only enlarges the root partition, a sysupgrade flash is perfectly fine when coupled with a subsequent manual partition resize.

1 Reply
1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Load balancing SMP/IRQs

The R4S thread has been discussing SMP and IRQs for better load balancing and i was looking to improve the wiki details on this as it is applicable to many devices.
NanoPi R4S-RK3399 is a great new OpenWrt device
For Developers
If you use either oficial openwrt or anaelorlinski build or immortal wrt, then by default their cpu affinity is throwing everything on cores 4 and 5 that are the 72 cores, since cores 0 to 4 are the a53 ones! As you can see here: They are setting up the irq of each eth on cores 4 and 5 with hex 10 and 20 respectively and are not setting up the queues with anything, which makes openwrt use hex 00 by default for the queues of both eth after booting and the result is that openwrt will throw t…
The wiki entry for it is here - https://openwrt.org/toh/friendlyarm/nanopi_r4s_v1#cpu_management
However after a few searches and some hunting i was unable to find a existing wiki entry for this.
So i created the following page and am populating it with a more generalised set of explanations and details to enable others to use on other routers.
OpenWrt Wiki – 2 Jun 22
How to Load Balance OpenWrt
How to Load Balance OpenWrt Introduction This guide explains about how to manually load balance OpenWrt by fixing IRQs for specific ethernet ports and assigning one or more CPU cores for the networking queues. SMP IRQ affinity and bitmask setting
@tmomas
I hope that is a reasonable place for the topic?

Solved by mercygroundabyss in post #7
Ok. I've finally finished and would appreciate a lookover if you dont mind?
@moeller0
@walmartshopper
@xShARkx
@tmomas
i hope that is in right place and fits with the wiki? (edit - fixed my titles. i'd left my introduction at top and thus wrongly titled it)
1 Reply
3

[Assistant]
mercygroundabyss:
The R4S thread has been discussing SMP and IRQs for better load balancing and i was looking to improve the wiki details on this as it is applicable to many devices.
This, btw, indicates that heterogeneous SoCs are not automatically a good fit for generic routers... Setting affinities by hand is IMHO not something that should be required (let alone push all essential router duties onto two of 6 cores), but a direct consequence of big-little designs. The raspberry pi4B for all its warts, does not have that specific issue (nor does the R5S) in that it sports just one type of CPU cores.

4

maybe just better defaults required for some routers?
I'd assumed that most routers would be set to use all cores automatically. As i found out with my BT Hub 5 this is obviously not the case, and the multitude of threads I've seen shows some are in need of some tweaking.
But that means analysing and coming up with best defaults across the entire range that OpenWrt supports. Thats not something i'd like to have to do. Thus my reasoning for doing a manual tweak page and referring to IRQ Balance for a more automated catch all.

3

mercygroundabyss:
maybe just better defaults required for some routers?
But such defaults are considerably simpler for equal cores... depending on what your router does putting interrupt processing on the big might be worse than putting it on the little cores...
mercygroundabyss:
I'd assumed that most routers would be set to use all cores automatically.
Yes, the default is still geared towards low storage single core SoCs, were even adding irqbalance to the default builds is considered wasteful. Not a call I would make nowadays (not that I am asked), but certainly one that makes sense given OpenWrt's history, no?
mercygroundabyss:
Thus my reasoning for doing a manual tweak page and referring to IRQ Balance for a more automated catch all.
+1; these are two orthogonal things and given that "better defaults" seem rather more involved (if possible at all) "arming" users to make/test changes themselves is a great way forward!

2


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: LEDE/OpenWrt Merger thoughts?

There is an interesting thread on the lede-adm mailing list discussing the possibility of merging LEDE and OpenWrt. I was especially intrigued to see Daniel Golle's comment at: http://lists.infradead.org/pipermail/lede-adm/2017-March/000424.html
It suggests leaving the "LEDE" name for the overall project, while leaving OpenWrt for routers.
I know the many readers of this list would have thoughts, so I point out this thread, and encourage your response here, or on the lede-adm list.

1

[Assistant]
Thank you for linking this discussion
@richb-hanover
!
Great points across the board, however we should be wary of letting people "who couldn't care less" about the brand name be in charge of picking the brand name.
Unless Daniel's idea of LEDE being umbrella and OpenWrt being a sub-project focused on network devices lives, I'd argue that OpenWrt brand and domain (but not necessarily its current content) should be used exclusively after the merge for the following reasons:
Established brand name recognition: OpenWrt has been around for a while, a lot more people know the OpenWrt name.
Existing base of links and more importantly mentions of OpenWrt on 3rd party web-sites: that's mostly reviews/posts on specific models favouring those which are OpenWrt-compatible.
Google-ability and SEO aspect: OpenWrt is clearly a better brand than LEDE.
All of that, assuming that I understand correctly what the merge means -- that the infrastructure, management and ownership issues with everything OpenWrt-related have been or could be resolved. If they haven't and we're talking about LEDE absorbing current OpenWrt development efforts only, then it's a whole different subject.
PS. I do agree that OpenWrt name reminds of/implies a specific vendor and series of products, however it hasn't been a strong enough reason to change the name in the past, and with both OpenWRT and DD-WRT supporting multitude of different vendors/devices for many years now I don't think it creates any confusion.

All of that, assuming that I understand correctly what the merge means -- that
the infrastructure, management and ownership issues with everything
OpenWrt-related have been or could be resolved. If they haven't and we're
talking about LEDE absorbing current OpenWrt development efforts only, then
it's a whole different subject.
The plan is that LEDE will absorb all of the OpenWRT infrastructure, there are
still issues to be worked out (copy from LEDE wiki to OpenWRT wiki or
vice-versa, which forum software to use), but the biggest stumbling block right
now is the name.
PS. I do agree that OpenWrt name reminds of/implies a specific vendor and
series of products, however it hasn't been a strong enough reason to change
the name in the past, and with both OpenWRT and DD-WRT supporting multitude of
different vendors/devices for many years now I don't think it creates any
confusion.
I agree, WRT has referred to things other than WRT routers for long enough
that being worried about this isn't reasonable.
The other concern some have voiced is that the OpenWRT name reminds them of the
bad management experiences that they had as developers in a project with that
name.
Personally, I think the google history and the number of third party websites
that refer to OpenWRT are significant enough that even if the project changes
it's name, it's going to need to maintain pages at the openwrt.org name, with
redirections and explinations of the name change for at least a decade.
As an advocate, I cringe at the fact that I would have to explain to people that
LEDE is the replacement for OpenWRT, and then be faced with the problem of
trying to answer "why did they do that" without dredging up the dirty laundry
again.
We saw these sorts of problems with gcc -> egcs (before they combined back into
gcc) and still suffer it to some extent with OpenOffice vs LibreOffice. I'm sure
many other examples can be raised.
David Lang

Besides naming I would make a big vote for Discourse as forum software.


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Clarifying IPv6 LuCI terminology: NDP-Proxy, ULA-Prefix, server mode, relay mode, hybrid mode

Hello,
I've had a hard time configuring IPv6 on my router because the words used to describe the settings in LuCI don't seem to be documented anywhere.
I think I have it figured out now, and I would like to help add this information to the wiki, however I am not a networking expert and would like to discuss my edits before I make them, to avoid spreading disinformation. So here is what I got:
Native IPv6 can be autoconfigured in three ways: SLAAC or DHCPv6 or both.
SLAAC is "relay mode" in the interface and uses a collection of ICMPv6 messages to detect the layout of the network and autoconfigure routing accordingly. NDP (Neighbor Discovery Protocol) is a subset of ICMPv6 messages and RA (Router Advertisement) messages represent a subset of NDP.
RA is commonly used in native IPv6 networks to properly configure default gateways. If the setting "NDP-Proxy" is set to "disabled" the router will filter ICMPv6 messages and SLAAC will not function, most notably without RAs the configured default gateway may not be recognized as a gateway and traffic to it will not work.
In SLAAC, IP addresses to client devices are automatically allocated from the "routed prefix" aka the subnet for your client devices assigned to you by your ISP.
DHCPv6 is "server mode" in the interface and uses a DHCPv6 server running on the router, to assign IP addresses and configure DNS settings. DCHPv6 does not configure routing. DHCPv6 is recommended for environments where more control over the network is required (aka corporate networks).
"Hybrid mode" obviously represents a combination of "server mode" and "relay mode".
The setting "IPv6 ULA-Prefix" in the LuCI Interfaces screen represents a subnet of local addresses that are used for private networking in the same manner as "192.168.x.x" is in IPv4. To be compliant with the protocol, the prefix must be set to a subnet within "fc00::/7" aka "fc__:" and "fd__:", though the standard recommends that you use "fd__:" with a "/48" size subnet. The other numbers in the address are random.
The address and gateway in this "ULA-Prefix" range will be added alongside to your IPv6 settings (on the router and the client devices in the "Global" scope), but will not interfere with the public IPv6 address routing. The assignment of these addresses is required by the protocol.
If you have a static IPv6 address, select "Static address" as the Protocol in the WAN6 interface, then skip the IPv4 settings and only enter the IPv6 address, gateway and routed prefix.
When entering the address, also enter the subnet size at the end of it (for example "/126"). This is the network between the WAN side of your router and the default gateway, also sometimes referred to a "connecting segment". On some networking devices (Mikrotik) the connecting segment address must be entered, but OpenWRT calculates it from the address and subnet automatically.
The gateway is entered as-is without a subnet size.
The routed prefix is provided by your ISP and contains both the prefix itself and the subnet size. This is the subnet that contains your client devices behind your router.
I think this is all that is needed. I was thinking of adding this to the current IPv6 page, which currently mainly contains outdated information on using IPv6 on OpenWRT with a tunnel provider.
LP,
Jure

Solved by systemcrash in post #28
See the PR for final strings.
1 Reply
9

[Assistant]
dustwolf:
SLAAC is "relay mode" in the interface
sounds wrong.
Relay mode is for the (supposedly rare) cases, where the ISP does not give out more than a /64 prefix, so that the same prefix needs to be used for both wan and lan.
EDIT:
relaying is explaining pretty ok in the current wiki:
e class="onebox allowlistedgeneric" data-onebox-src="https://openwrt.org/docs/guide-user/network/ipv6/start#router_advertisement_dhcpv6">
OpenWrt Wiki – 30 Oct 16
IPv6
IPv6

2 Replies
4

Can you give some example of this so that I have any idea what you're talking about?
The documentation you link has no information on anything present in the LuCI interface for IPv6. No offence but I don't see how a section of documentation can be "pretty good" when it only contains a sample config file with no context and no explanation on what the settings are even supposed to do or in what circumstances do they work.
I'm sure those settings worked in your case but they are absolutely meaningless to me as my ISP uses a different IPv6 setup and those settings do not work for me.

3

dustwolf:
The documentation you link has no information on anything present in the LuCI interface for IPv6.
Not quite sure what you mean.
The options for IPv6 addressing in downstream LAN use pretty much the same terminology in LuCI (master, relay), as in wiki.
For upstream WAN side, the earlier part of the wiki page is relevant.

1 Reply


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Wireguard performance

FYI - I have created https://openwrt.org/inbox/wireguard_performance (similar to https://openwrt.org/inbox/openvpn_performance).
Feel free to add more data, it's easy.

4

[Assistant]
Cool!
Question: Up/Down, does this denote bidirectional saturating traffic, or the "uni-directiona"l maximum for each direction? With "uni-directional" I accept that there is required reverse traffic (ACKs and such) but that there is no considerable data traffic in the reverse direction.

1 Reply
1

Despite a fair amount of knowledge of networking, I was never able to set up WireGuard. The interface gets RX but no actual traffic happens.

1 Reply

Same as in the OpenVPN performance page: unidirectional

1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: [FAQ] OpenWrt upgrade: Keep settings or not?

Ever so often I see questions like
I'm coming from OpenWrt release 'A' and want to upgrade to release 'B'.
Can I check the "Keep settings box or not?
Would it make sense to show the "keep/don't keep" in a table like this one?
Your input to this table is appreciated.
[Table removed to avoid false interpretations]

1 Reply
2

[Assistant]
Two thoughts:
As the config "API" is hopefully constant within a given release, as well as that I don't think we should be suggesting anyone upgrade to anything but the latest, maintained releases, this probably could be simplified to just from the major versions, 12, 14, 15, 17, and 18, then to 17 and 18. Labeling the older releases with their names seems valuable as well.
There are some subtle changes I've seen, such as key and sae_key in /etc/config/wireless. Assuming those changes could be catalogued, noting those exceptions would be valuable.
Commits around that specific change include:
d88934aa5aa9b61ec66a6f7ae0fb61d1ef889884
eba3b028e46dbfe54f1208e9edf47bb0c6f73ac8

1

I also consider this upgrade matrix to be slightly overkill. As mentioned by jeff, upgrading within a given stable release (e.g. 17.01.n --> 17.01.m) should always be safe with keeping settings. So far 17.01.x --> 18.06 also seems to be fine in general. Upgrading by keeping configuration files older than that (15.05.x or older) can not be considered safe in a large number of cases (because of changed switch/ vlan configurations, containing dnsmasq to its dedicated system user, etc. while there are mitigations in place, there is a high risk for soft-bricking the device in practice).
Providing any assumptions for even older releases (12.09, 14.07, etc.) -or for upgrades between versions of already long-unsupported releases- feels rather challenging, more than 4 years after every security conscious person has forgotten about them and the details required for upgrading them. Obviously their settings are not safe to be kept for upgrading to current (17.01.x/ 18.06.x).
This matrix might also transport the semblance of being able to avoid these compatibility issues by upgrading in stages, e.g. coming from 12.09 that you'd just have to upgrade to 14.07 first, before installing 15.05.x and 17.01.x by keeping the configuration files and never touching them - this is not going to help. sysupgrades in general don't 'migrate' config files during the upgrade, while the file list might be pruned slightly, the files are usually kept verbatim (yes, there are some upgrade scripts in place, attempting a config migration for targetted issues, like e.g. making sure to create a dnsmasq system user, but we've already established that these aren't always working). If your configuration has been created by firmware versions older than 17.01.x, it's not generally safe to retain them (and trying to restore an old configuration tarball would be even more fatal, as the existing/ incomplete migration scripts won't run in that case at all), even if it might work in some cases (depending on the chosen configuration and the devices in question).
Currently there are no (major) issues to be expected with upgrading from 17.01.0 or later, but there are always exceptions (e.g. lantiq changing the name of the dsl device) - and there will continue to be such issues (e.g. migrating targets to the dsa switch driver architecture).
As the issue has come up a few times recently, I'd like to add that restoring a configuration tarball made on an older router on newer/ different hardware is not possible, as very crucial and basic configuration settings are hardware dependent (switch and vlan configuration, LED/ GPIO settings, WLAN config (device paths), etc.).

2

I largely agree with slh.
My main points:
talking about safe sysupgrades from older than 17.01 is worthless. If somebody is running older stuff, 15.05.1 or even older, settings should always be re-created. Too many subtle changes in core settings or defaults.
Example: default PATH is in /etc/profile included in the backup and sets in practice the precedence of certain alternative apps. PATH was changed after 15.05 (and backported to 15.05.1). Later releases expect to have the new default path, so old configs originally created before 15.05.1 may be problematic. It is not even a question of the firmware you now sysupgrade from, but about when /etc/profile was originally created.
sysupgrade between minor versions should be safe. No need to have them in table.
restoring an old config (like 15.05.1) from backup after sysupgrade (to 18.06) is unsafe, as it renders the possible transition scripts worthless (as they are often uci-defaults that run once after flash, so they would never see the restored configs later)
talking about sysupgrading to version less than 18.06 is not very useful. Yes, there are old routers that do not survive 18.06 or even 17.01, but those are exceptions. In general, the advice should be targeting "into 18.06".
In nutshell, when upgrading to 18.06.x:
from 15.05 or earlier: always re-create config, never restore backup (except manually for reference)
from 17.01: Usually ok. Sysupgrading with "keep settings" will enable possible transition scripts after flashing, while restoring old settings later might bypass the transition scripts. However, it might still be better in the long run to let the system to create new default config.
restoring old config from previous or earlier major version is always risky

1 Reply
1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: High voltage warning

Continuing the discussion from Howto install OpenWrt on Asus RP-N53:
Howto install OpenWrt on Asus RP-N53
if this device contains full AC within it as it appears to... there are some serious safety issues involved here documenting hardware modifications without warnings... ( or at all )... death or serious injury can result from poking around in such areas... and i'm sure we don't want to be responsible for this happening to our userbase?
First of all, Linux expects the user to know what he is doing. The same is true for electricity.
As we see almost every day in the forum, users oftentimes do not know what they are doing.
A warning seems advisable.
Proposals for an infobox which can be included on all 80 devices which are listed as mains powered:
Which one do you like better?
Is the text clear enough for everybody to understand the risks involved?
Comments are welcome!

7

[Assistant]
thanks
@tmomas
for your swift and collaborative action on this concern...
2c...
i'd be happy with the red one... with a picture of a skeleton getting lit-up
and perhaps a small line about it also possibly being illegal(check the laws and regulations in your region)
suppose would be consistent/prudent to also attempt to implement a similar warning within the forum... either one by one per posts as noticed ( header? ) or perhaps a pinned topic in hardware?

I agree that the first one looks more intimidating.

Some playing around:
ISO 7010 W012 Warning sign added
different background colors

6


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Offline Documentation

Hi. I am new to the forum. Hello.
As many people have likely experienced we are not able to read the full website documentation available at https://openwrt.org/docs/ offline via often used methods such as from the device webserver page, via a software plugin ( opkg install 'documentation'), or as a standalone pdf. The openwrt documentation is excellent. For most openwrt users and developers, the documentation not only effectively describes how to operate our openwrt devices, but is also an excellent reference for a good number of networking and security topics.
I would like to know if we can programmatically download the website documentation html pages and convert them into pdf. Obviously the resulting pdf will be for personal use only. I know I can do this, at least in a technical sense, but do the maintainers and owners of openwrt allow this?
This query is directed to other users on the forum, and especially the forum administrators.

3

[Assistant]
the documentation won't fit in the device flash memory, that's why it's not included.
Yes you can freely download openwrt wiki contents and make a pdf, the information there is shared freely under this Creative Commons license (you can find a link to it at the bottom of each page) https://creativecommons.org/licenses/by-sa/4.0/deed.en

You know, this is an interesting thing to consider - I’m not sure how much value it would have, but if someone could download basically the entire site documentation (or subsections) as a package to their computer, that could be good for when they are planning to be offline due to router swaps / maintenance / configuration.
Probably not all that necessary given that many users will have at least a mobile device for access while their home connection is down, but I wonder if anyone would use such a feature and how it would be implemented.

1

for windows there are applications that do that, and can be done from a linux/mac/windows system with wget commandline
wget --mirror --page-requisites --convert-links --adjust-extension --compression=auto --reject-regex "/search|/rss" --no-check-certificate --user-agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36" --wait 1s --restrict-file-names=windows openwrt.org
I'm doing some tests to see if it works and I can implement this in the wiki server itself to provide a package users can download and browse offline with their web browser.
1-Jan-2025
Admin note: Please do not use this procedure on our Wiki site. It does not work and it overloads the server unnecessarily.

2


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: OPKG upgrade / package upgrade warning

On another topic
opkg upgrade warning
Hmmm... a rather short one. Do we have 2..3 explanatory words for this?
https://openwrt.org/meta/infobox/upgrade_packages_warning
Ok.... here's a stab at what we can put in this warning (maybe it can be in the main warning page with a sentence or two excerpted for the canned response.... feedback welcome.
The use of opkg upgrade is very highly discouraged, and should be avoided in almost all circumstances. This is also distinctly different from the sysupgrade path for upgrading both major versions and maintenance upgrades of OpenWrt -- the two are not equivalent.
Just because there is an updated version of a given package does not mean it should be installed or that it will function properly.
Unlike the 'big distros' of Linux, OpenWrt is optimized to run on systems with limited resources. This includes the opkg package manager, which does not have built-in ABI (Application Binary Interface) compatibility and kernel version dependencies verification. Although sometimes there may be no issues, there is no guarantee and the ugprade can result in various types of incompatibilities that can range from minor to severe, and it may be very difficult to troubleshoot. In addition, the opkg upgrade process will consume flash storage space and as it does not overwrite the original (stored in ROM), but stores it in the r/w overlay.
In the vast majority of cases, any security patches of significant importance/risk will be rapidly released in an official stable maintenance release to be upgraded using the sysupgrade system. This is the recommended method for keeping up-to-date.
Those looking to be on the bleeding edge can consider using the snapshot releases, but should be mindful of the differences between stable and snapshot. The remaining users who still want to use opkg upgrade should only do so with individual packages (do not blindly update) and they should be aware that problems may occur that could necessitate a complete reset-to-defaults to resolve.
If you're already having issues, or wish to 'undo' the upgraded packages: create a backup (optional; can be restored after the reset is complete) and then perform a reset to defaults (firstboot).

1

[Assistant]
If the team is good with my proposal for the opkg upgrade warning, I can edit the wiki accordingly and then make a very quick revision to the canned reply. Any thoughts?

I agree as long as the canned reply is not that long and discourages the user to read it all. Keep a TL:DR in the canned reply and the rest as a hyperlink to the wiki.

2

Agreed. Canned reply should be short, details see wiki.

1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: New LEDE Project Home Page

We have been working to revise the LEDE Project home page.
Draft home page: https://lede-project.org/playground/start2
Draft Showcase Page (detailed list of LEDE features, linked from new home page): https://lede-project.org/playground/why_use_lede_full_list
Please leave comments for this draft here. Thanks!

1

[Assistant]
LEDE has reduced latency/lag and increased network throughput via bufferbloat control algorithms.
Wi-Fi improvements support higher data rates and airtime fairness between stations.
LEDE supports various Quality of Service implementations improving internet quality for connected devices.
Items 1 and 3 (bufferbloat control & QoS implementations) refer pretty much to the same thing, They might be combined.
To my knowledge, item 2 "airtime fairness" only concerns ath9k driver (mostly older routers), but not mvebu, ath10h or mtxxxx drivers (newer routers). So you might specify the wifi driver there.

1 Reply

I like the summary contained in the "Why use LEDE" section. It might be further improved by hyperlinking more of the statements to anchors within the "why_use_lede_full_list" document. It was not immediately apparent to me that there was more to read about security, for example.
The security section in particular should be more strongly backed by the "why_use_lede_full_list" document. I do not think the statement "thanks to its Linux OS which is unaffected by many common attacks" has much merit. The security community continuously finds many vulnerabilities both in the Linux kernel and its user-space software. I would like to see more details. How does LEDE mitigate zero-day vulnerabilities both in the kernel and user space? Does LEDE favor type-safe languages? Is ASLR is on? Stack canaries? Does LEDE prefer software packages whose designs include careful security considerations (e.g., qmail/postifx vs. sendmail)? What does LEDE do better than other Linux firmwares or other firmwares in general? What does LEDE do to encourage the proper configuration of the software it provides, to include strong authentication and encryption?
"LEDE is actively updated" could link to a description of how users can ensure their LEDE installs stay up-to-date.

1

I think one of the main things that the homepage should have is a link to the status of the OpenWRT/LEDE merge. I'm running LEDE now, and I've seen a discussion about merging back with OpenWRT, but I am confused whether I should now look at the LEDE project or OpenWRT for the merged project (well I guess one will point to the other eventually), and I'm also confused that both projects did/are doing a new release just now. Will the merge happen after these 2 releases are done?


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: [SOLVED] OpenWrt Project: WireGuard server

openwrt.org
OpenWrt Project: WireGuard server
Hello,
I think there are typing inversions in the guides:
WireGuard server:
2. Key management
Client public key
WG_PUB = "$ (cat wgclient.pub)"
instead of
Server public key
WG_PUB = "$ (cat wgserver.pub)"
And in the guide
openwrt.org
OpenWrt Project: WireGuard client
WireGuard client:
2. Key management
Server public key
WG_PUB = "$ (cat wgserver.pub)"
instead of
Client public key
WG_PUB = "$ (cat wgclient.pub)"
By the way, when I install WireGuard server, as a home server on my TP-Link router, Archer C7 AC1750 v4 firmware 19.07.4 all works.
When I install WireGuard client on my router, wireguard-vpn is displayed instead of vpn. In IPV4 vpn route disappeared, the Wiregard interface no longer has a public key.
In network, vpn interface, general parameters the IP address of the server 192.168.9.1/24 is replaced by the IP address of the client 192.168.9.2/24.
I followed these configurations to the letter. Maybe I shouldn't install WireGuard server and WireGuard client on the same router because it doesn't work.
What I want: to have WireGuard server as a home server to connect to the internet without an external VPN.
Thank you for being accommodating and have a nice day

Solved by vgaetera in post #23
Unfortunately, yes, 172.16.0.0-172.31.255.255. Actually, I have a similar problem and have to use VPN via VPS to reach my home network.
3 Replies
1

[Assistant]
Please, read the description carefully:
WireGuard server
Exchange the keys between the server and the client using file transfer or copy-paste.
WireGuard
WireGuard generally relies on public-key cryptography. This means you should generate private keys on the respective peers and exchange only their public keys. In addition for better security, you can also generate and exchange a pre-shared key. Each 2 peers should use a common pre-shared key.

1 Reply
2

97gerard_216:
Maybe I shouldn't install WireGuard server and WireGuard client on the same router because it doesn't work.
You probably don't need two separate WG interfaces. Please copy the output of the following commands and post it here using the "Preformatted text </> " button:

Remember to redact passwords, MAC addresses and any public IP addresses you may have
ubus call system board; \
uci export network; uci export firewall; \
head -n -0 /etc/firewall.user; \
iptables-save -c; \
ip -4 addr; ip -4 ro li tab all; ip -4 ru; \
wg

2 Replies
2

In fact, I wanted to test the server wireguard and the client wireguard of the wiki which has changed. In client wireguard I put WG_SERV = 192.168.9.1
When you install wireguard client, the LuCI → Status → WireGuard Status menu displays "the interface does not have a public key"
For three months, I only installed wireguard server with its interface and the peer, without installing client wireguard, then I manually added my 6 devices in the peers, I have the handshakes. I installed the no-ip.com ddns. I configured the Fai modem and everything works. However, I cannot connect to my home server from the outside with my smartphone, there are no handshakes.
I will open a new post on this subject in the installation section.

1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Table of hardware: add new fields for 2.5 GBit ports and outdoor devices

Hi!
I like to propose adding two more fields to the table of hardware to make it easier to search for specific hardware:
a field for 2.5 GBit ethernet ports as seen in newer devices (e.g. WAX206 - https://github.com/openwrt/openwrt/pull/11363)
a field to mark outdoor devices (e.g. ZyXEL NWA55AXE, TP-Link CPE210/CPE510/...)
For the outdoor devices it might also be nice to have a field to specify the IP rating. In addition it might be useful to add fileds to specify the PoE standard supported by the device, which is also useful for a lot of indoor APs.
@tmomas
can we add those fields?

2

[Assistant]
2.5Gbit
Yeah, the whole network port stuff needs to be changed to reflect current hardware possibilities, i.e. multi-Gig ethernet and SFP.
I had a discussion with
@Borromini
quite some time ago (sorry, didn't have time to attack this in depth), during which I had created a mockup: https://openwrt.org/playground/toh/hwdata/d-link/d-link_dir-505_testing_only
Please take a look and report back any issues, concerns, or change proposals.
Outdoor devices
Some prior discussion about outdoor devices in the ToH: Techdata: add new dropdown value: "Routerboard" - #2 by tmomas
Techdata: add new dropdown value: "Routerboard"
Shall we, and if yes, how can we show that a device is suitable for outdoor use?
e.g. via devicetype “Wifi AP outdoor” (do other, non-AP outdoor devices exist?) → easiest to implement
e.g. via separate datafield “Outdoor” [yes|no] → most general usage, independant of devicetype
From the implementation point of view, the solution via devicetype is really the easiest to implement.
Current devicetypes: WiFi AP, WiFi Router, Router, Travel Router, Travel Router - Battery powered, Range Extender, Powerline Adapter, Single Board Computer, SFP module, Switch, Modem, NAS, Camera, Emulator, unknown, other
Which of those would need to be outdoor? Do outdoor travel routers exist?-)
IP Rating
Why is the IP rating important, if you already know that it is specified for outdoor use? Does it really matter if it is IPX5/IPX6?
PoE
PoE is already specified in the Power supply datafield, see https://openwrt.org/toh/views/toh_poe-powered

2

2.5Gbit
I had a look at the proposal and I like the compactness, but fear errors when data is entered. Unless you can validate input, I would personally go for separate fields for different port speeds to reduce errors and to keep is well-structured. Compact fields could then be computed/filled from the structured data to generate better views for users.
Outdoor devices
From looking at your device type list I think you would need to add an outdoor suffix to multiple categories: WiFi AP, Camera, Switch, Powerline Adapter
Outdoor often means that they are rated for harsh conditions e.g. sub-zero temperatures, some outdoor components still need to be put in an outdoor enclosure.
However, while there are specialized outdoor devices in those categories available, it does not mean that OpenWRT would ever support them.
I think it would be best to just add it via a separate data field “Outdoor” [yes|no]
IP Rating
Some devices can withstand water, others are just sealed off against dust. So depending on the location of the device you would require different ratings. The list of outdoor devices might however not be that long, so probably an IP rating field is not that important.
PoE
I just missed that one. Thanks for pointing it out!

2 Replies

I am in agreement with Noki that a separate Outdoor Y/N would be preferable. The IP Rating would be a bonus, but perhaps we should determine how many actual outdoor devices are supported first.

1 Reply
1


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Pointer on “Timeout waiting for PADO packets”

Hi *,
I used to have the following problem like many others in the community (source: No PPPoE connection) with my Telekom VDSL50 internet connection:
daemon.warn pppd[2652]: Timeout waiting for PADO packets
daemon.err pppd[2652]: Unable to complete PPPoE Discovery
And, I looked up every possible page, but couldn't find any problem with my "/etc/config/network" file on the TD-W8970 with LEDE 17.01.2 (r3435-65eec8bd5f):
config interface 'loopback'
 option ifname 'lo'
 option proto 'static'
 option ipaddr '127.0.0.1'
 option netmask '255.0.0.0'

config globals 'globals'
 option ula_prefix 'fdfa:768b:94d9::/48'

config atm-bridge 'atm'
 option vpi '1'
 option vci '32'
 option encaps 'llc'
 option payload 'bridged'

config dsl 'dsl'
 option xfer_mode 'ptm'
 option annex 'b'

config interface 'lan'
 option type 'bridge'
 option ifname 'eth0.1'
 option proto 'static'
 option netmask '255.255.255.0'
 option ipaddr '192.168.0.1'
 option ip6assign '64'

config interface 'wan'
 option proto 'pppoe'
 option ipv6 'auto'
 option _orig_ifname 'ptm0'
 option _orig_bridge 'false'
 option ifname 'ptm0.7'
 option username 'XXXXX'
 option password 'XXXXX'
 option keepalive '3 2'
 option persist '1'
 option holdoff '5'

config device 'wan_dev'
 option name 'ptm0'
 option macaddr 'XX:XX:XX:XX:XX:XX'

config interface 'wan6'
 option ifname 'pppoe-wan'
 option proto 'dhcpv6'

config switch
 option name 'switch0'
 option reset '1'
 option enable_vlan '1'

config switch_vlan
 option device 'switch0'
 option vlan '1'
 option vid '1'
 option ports '0 2 4 5 6t'
The Telekom technicians took care of the telephone cabling and setting up the telephone system "Octopus E". As we are now using only the mobile phone, I spent some time yesterday, turned off the telefone system, changed the telephone cabling and connected my TD-W8970 on ground floor directly with the splitter in the basement. The devices are connected now that way:
"First TAE-outlet" <---> splitter <---> TD-W8970
My DSL connection is now online for 18 hours. Previously, it disconnected with the log message "Timeout waiting for PADO packets" after every 2-3 hours and I had to reboot the router. AFAIK, It seems that my telephone system somehow interfered with my DSL connection. I am not quite sure.
If you are using a telephone system like the "Octopus E" and connecting the router to the first TAE-outlet doesn't help, my scripts that I have used previously might be helpful:
root@LEDE:~# cat /etc/hotplug.d/net/99-check_wan
#!/bin/sh
if [ "$ACTION" = "remove" ] && [ "$INTERFACE" = "pppoe-wan" ]; then
   (/root/check_wan.sh >/dev/null 2>&1) &
fi
Above code is called by hotplug after your wan device, which holds the wan ip address, is turned off.
The code below checks the logs for five minutes for the message "Timeout waiting for PADO packets" once every second. If such a message exists and this message has been created within the last 5 minutes, the device is rebooted.
root@LEDE:~# ls -l /root/check_wan.sh
-rwxr-xr-x    1 root     root           410 Sep 17 18:04 /root/check_wan.sh
root@LEDE:~# cat /root/check_wan.sh
#!/bin/sh
START_TIME="$(/bin/date +%s)"
while [ $(($(/bin/date +%s) - START_TIME)) -lt 300 ]; do
   PADO_LOG_TIME="$(/sbin/logread -t | /bin/grep "Timeout waiting for PADO packets" | /usr/bin/tail -n 1 | /usr/bin/awk -F"[" '{print $2}' | /usr/bin/awk -F"." '{print $1}')"
   if [ ! -z "$PADO_LOG_TIME" ] && [ $(($(/bin/date +%s) - PADO_LOG_TIME)) -lt 300 ]; then
      /sbin/reboot
   fi
   /bin/sleep 1s
done
Don't forget to make the 2nd script executable, change the wan device in the 1st script as needed and use them at your own risk.
Best regards,
dasa123

[Assistant]
Are you sure that you still need the splitter (obviously you do in case of PSTN or ISDN)? It's possible for older/ existing contracts, but DTAG is moving towards splitterless VoIP setups, often combined with vectoring (even for slower, sub-100-MBit/s contracts which wouldn't need it).

@slh
:
Thanks for the hint. The TD-W8970 works perfectly without the splitter using annex B. I'll keep an eye on the DSL connection stability.

Like slh said, DSL "splitters" are used to remove the DSL signal from the conventional PSTN or POTS analog phone service that may be provided on the same line. DSL activity sounds like loud high-frequency noise on phone calls if it is not filtered out. Since the intent of the filter is to block DSL frequencies, connecting the modem on the wrong side of the splitter will cause a poor or no connection.
If you don't have analog phone service, connect the DSL modem directly to the line using a straight run of cat3 or cat5 wiring. Have no branches at all is best.
If you do have analog phone service, branch off once through your splitter, then connect all the existing phone wiring and phones onto the downstream side of the splitter. This way there is no DSL signal on the old wires, which can load it down.


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Donations page

tmomas:
See https://openwrt.org/about
Donations can be done via SPI. Donations can be bound to a specific project, e.g. OpenWrt.
https://www.spi-inc.org/projects/services/
https://www.spi-inc.org/projects/openwrt/
------- ORIGINAL POST -------
I have found out that the project is financially supported by just two contributors and I think that:
It's still a financial burden (however insignificant it may be for those guys) and there's no reason for it not to be shared.
There should be an option for people to donate financially if they want to support the project but are unable to do it any other way.
Probably nobody would want to just accumulate a pile of money, so donations should be directly tied to the current infrastructure costs with the option to raise money for special spendings and more importantly the option to stop accepting donations once the goal is reached.
So the requirements would be:
Actual donation page where you can send money to cover project costs.
Target amount status/progress page.
Automatically stop accepting donations when the target is reached.
Automatically reactivate annually.
Ideally, automatically pay out infrastructure costs when the target is reached.
Just a single "donate" button probably won't cut it. I've looked into a few donation/crowdfunding platforms and nothing really stood out. Crowdfunding sites are usually kickstarter-like in a way that they best support one-time collection of the money (vs annual collections) and a lot of platforms which automate donations charge fees almost equal to an annual infrastructure spending and/or require the official recognition of the non-profit status (to shave fees off).
So two questions I have:
Does anyone have experience with crowdfunding/donations platforms which might be suitable for LEDE?
Since these platforms do require e-mail/password to login -- how could shared ownership of this information between a number of project leaders be organized?

3

[Assistant]
I would very much like to see a donation option, I don't know how far the re-integration talks with OpenWrt have progressed though, that might play a role as well.

Patreon
Best way for artists and creators to get sustainable income and connect with...
Patreon is a membership platform that makes it easy for artists and creators to get paid. Join over 100,000 creators earning salaries from over 2 million monthly patrons.

2 Replies

komawoyo:
Patreon.com
Sadly, on their community guidelines page it says: Patreon is for artists, creators, and people who bring ideas... Not sure how suitable it is for LEDE from this standpoint.
Do you personally have experience with it as a creator? Can it stop accepting donations once the goal is reached (and resume it every month/year)?

1 Reply


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: (Better and faster) Table of Hardware

While the TOH (Table of Hardware) is a fantastic resource, I often find myself wrestling with frustration as I use it. The loading times are painfully slow, and the columns displayed rarely match what I’m actually looking for.
So, I've created a new TOH that pulls data directly from the OpenWRT site. This revamped version promises to be much faster and more user-friendly... At least, that’s the goal!
Try it (live) at:
Enhanced OpenWrt Table Of Hardware -- Production
Enhanced OpenWrt Table Of Hardware -- Development
Your feedback would be appreciated! If enough of you find it useful, I’d love to propose it for inclusion on the official OpenWRT site. After all, who doesn’t want a TOH that actually works?
[Admin edit 2025-April-3: removed deprecated link, added both production and development TOH links]

2 Replies
29

[Assistant]
wxop:
Your feedback would be appreciated!
replace the "At least 8MB Flash and 64MB RAM" buttons with 16/128MB.
8MB devices will be dropped after 23.05.
the "available" filter is kind of pointless, since availability could vary with location.

2 Replies
1

Hi
@frollic
, thank you for your feedback
I will implement your suggestions ASAP!
Regarding Filter presets & features, I've tried to mimic some of the current TOH filters (listed here).
As stated in this GH issue, we have to first implements most current filters, then add some addtionals interesting ones.
If you've have a GH account, and some basic JS syntax skill, this can easely added by just creating the filter definition here:
github.com
soif/OpenWrtTOH/blob/master/src/www/static/js/toh_conf.js#L462
 links: [
  ...colViewGroups.base.fields,
  ...colViewGroups.links.fields,
 ],
 misc: [
  ...colViewGroups.base.fields,
  ...colViewGroups.misc.fields,
 ],
};
// Columns Filter Presets ###############################################################################################################
// implements from: https://openwrt.org/toh/views/start
let colFilterFeatures={
 // normal features -------
 antennas:{
  title:  "Antennas",
  description:"with detachable antennas",
  type:  "normal",
  filters:[
   {field: "detachableantennas",  type:">", value:''},

1

wxop:
If you've have a GH account, and some basic JS syntax skill,
got an account, but no skills


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: LEDE Table of Packages: Good or bad?

(spin off of Toward a good "Flashing LEDE instructions" page)
Currently LEDE does not allow easy access to what packages are available and what they do if you don't have a LEDE system on-hand to run opkg to list packages/descriptions.
So the most straightforward way to show newcomers what we have in LEDE is to tell people "install LEDE (on a device or in Virtualbox) and then see what packages there are", which is a bit backwards.
The only alternative is looking at the package names in the folders of the download server, or downloading the package lists, uncompress them and read a long and boring list. Not cool.
I was thinking about having a Table of Packages too in the wiki, something similar to the ToH but loaded with basic information about packages (automatically, by a script, I can make the script).
It might also link to package-specific articles if needed.
I'll be honest though: I usually spend my time on the wiki to add content in the user guide and documentation so that is probably yet more work for tmomas or someone else that likes the idea. I can make the script to update the system though.
(looks around and then runs away stealthily)

2 Replies
1

[Assistant]
I highly doubt that an automatic long list / database of all available packages would be useful for newcomers. There are thousands of packages/variants/modules, many of which have only short and non-descriptive titles & descriptions, while others have long "advertising-style" descriptions. So, the data that can be automatically collected, would be non-uniform. The availability of the packages varies somewhat by the architecture/platform, which also causes complexity to the possible database/script.
Some of the packages can be useful for most users (e.g. USB storage support, router statistics, QoS, ...), while some (e.g. programming tools for a specific rare microcontroller) are really niche tools and will be used by less than 0.01% of the user population. So, dumbly listing all packages with equal importance would not be really useful for newcomers.
I think that a categorized "Top picks" list for 20-50 interesting topics would offer more value to the beginners than a large searchable package database.
Page could be something like "Extend the device's functionalities with add-on packages". It could have maybe 20-50 categories (USB storage, statistics, web proxy, adblocking, VPN, QoS, P2P, USB modems, file server, home media server, multimedia etc.) and each category could have a link to a possible "How-to" recipe/topic page of that topic (if such page exists) and a list of 1-5 most widely used / most useful packages for that topic.
Something like an improved version of the (rather well hidden) Openwrt wiki how-to front page https://wiki.openwrt.org/doc/howto/start and the how-to index https://wiki.openwrt.org/doc/howto/index.by.subject
Note that the Openwrt how-to pages are also a bad mix of high-level topic pages & really niche router hardware config advice, so they are not perfect at all.

2 Replies

[quote="hnyman, post:2, topic:123, full:true"]I highly doubt that an automatic long list / database of all available packages would be useful for newcomers.[/quote]The ToH's database system main use is making many tables (called "views") where the content of the same large database is already filtered heavily to show only X or only Y.
The monstrously huge table is mostly for mantainers or people testing their massive multiscreen setup.
If you want to make a table in a wiki article showing only USB, basic routing, whatever, you write like 5 lines to summon the data plugin and tell it what you need there, and the plugin does the leg work in reading the database, fetching the right information according to your filters and showing it.
And this is kept updated automatically, you just update the central database, and every other table downstream will be up-to-date.
[quote]There are thousands of packages/variants/modules, many of which have only short and non-descriptive titles & descriptions, while others have long "advertising-style" descriptions. So, the data that can be automatically collected, would be non-uniform.[/quote]Having a way to show package descriptions like that will encourage better descriptions from the package mantainer, and normal people might start sending "improved description" PRs through Github's webinterface.
[quote]The availability of the packages varies somewhat by the architecture/platform, which also causes complexity to the possible database/script.[/quote]Architecture would just be another field in the database (shown or not depending on need, surely used for filters).
It might be necessary to read the makefiles in the source instead than the actually downloadable package lists to get that info faster, though. (I assume that if it works for the build system it will work for a script loading a database too)
[quote]Page could be something like "Extend the device's functionalities with add-on packages". It could have maybe 20-50 categories (USB storage, statistics, web proxy, adblocking, VPN, QoS, P2P, USB modems, file server, home media server, multimedia etc.) and each category could have a link to a possible "How-to" recipe/topic page of that topic (if such page exists) and a list of 1-5 most widely used / most useful packages for that topic. [/quote]Yes, I was thinking about making something like this, with different pages for different categories. Just that the tables in the articles would be auto-generated according to my filters.
Having the packages in a database would allow also to automate the "most used" selection. Just add a field in the database to mark the package as "most-used" and you can auto-build and maintain tables with only "most-used" packages, reducing the need for manual editing.
The same can be done to packages "marked-for-deletion", or "from-a-third-party-repo" or "LEDE-trunk" or "LEDE-first-release-branch" or "LEDE-second-release-branch" or for whatever reason.
The goal is to get something like most PC Linux distros have, like for example Debian, https://packages.debian.org/stable/
(Debian has a relatively simple system with large lists of packages, but you should note the basic features of a webpage showing packages)

bobafetthotmail:
I usually spend my time on the wiki to add content in the user guide and documentation so that is probably yet more work for tmomas or someone else that likes the idea. I can make the script to update the system though.
The input for a Table of packages would be simple .txt files per package that reside in /pkgdata/
_pkg-category, _pkg-arch and _lede-release define all possible values for these dropdowns.
If you can provide the package dataentries according the below example, this can be set up in almost no time. Feel free to modify the example as needed, it is just a quick proposal.

3 Replies


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: LEDE Table of Hardware: Styling

The raw bootstrap template shows the datatables (e.g. toh:start) in an unsightly way, i.e. w/o hor/vert lines.
I added some CSS to improve this:
Borders added
Zebra-striping added
Table headers colored differently than the rest of the table
Let me know what you think about this or if you have any improvement proposals.
https://wiki.lede-project.org/toh:start
https://wiki.lede-project.org/toh:views:toh_extended_all

1 Reply

[Assistant]
tmomas:
I added some CSS to improve this:
Borders added
Zebra-striping added
Table headers colored differently than the rest of the table
This looks really good! I tested with Firefox (Win10 & OSX), Safari (OSX), Edge (Win10), and Chrome (Win10) (Update: Control-Reload flushed the cache on Chrome/OSX. It looks good everywhere.)
I have forgotten how to update the of the page - currently my browser tab says, "toh:start [LEDE Wiki]" It would be good to have it say, "Table of Hardware [LEDE Wiki]"
Other thoughts about appearance/screen space:
It would be good to make the Versions, Current LEDE Release, Current OWRT Release columns much narrower, to preserve horizontal screen space.
Could the input boxes at the head of each column be smaller as well (both vertically and horizontally) so they take up less space?
The table's bounding border looks good. What would it look like if the interior grid lines (between rows, and between columns) were gone?
Do we even need a "Current LEDE Release" column? What data would it contain now/soon/in two years?
Thanks!

richb-hanover:
I have forgotten how to update the of the page - currently my browser tab says, "toh:start [LEDE Wiki]" It would be good to have it say, "Table of Hardware [LEDE Wiki]"
I tried to achieve that, but to no avail. Tricky...[quote="richb-hanover, post:2, topic:51"]
Other thoughts about appearance/screen space:
It would be good to make the Versions, Current LEDE Release, Current OWRT Release columns much narrower, to preserve horizontal screen space.
Could the input boxes at the head of each column be smaller as well (both vertically and horizontally) so they take up less space?
[/quote]
I already tried to influence the width of the input boxes, but didn't succeed at all. Do we have someone out there with more than basic CSS skills?
richb-hanover:
The table's bounding border looks good. What would it look like if the interior grid lines (between rows, and between columns) were gone?
Take a look: https://wiki.lede-project.org/toh/start
I like it better with grid.
richb-hanover:
Do we even need a "Current LEDE Release" column? What data would it contain now/soon/in two years?
The current LEDE release, same as in OpenWrt ToH.
Sidenote #1: List items are not preserved in quotings.
Sidenote #2 Damn, we have the same shitty problem as in the OpenWrt Wiki: Double dataentries.
Yesterday: 1133 devices in the ToH
Now: 1137 devices -> 3com + 4g systems are doubled. Damn!!!11 (sorry, but this is getting really annoying. I hoped that in a brand new wiki we wouldn't run into the same problem again )

Scrolling like that is awful, and you know it. Admit it already.
For the very least you need to place a scrollbar on the top of the table too.
Best would be to have the table in its own box with its own scrollbars, I know it was hard, I read the forum topic in Owrt forum.
Also, I think the horizontal space between cells could be kept smaller, like this most entries are lone words swimming in an empty sea. Also zooming does not change, everything is smaller but the proportions are the same.
Like in CPU mhz, it's a number then like "_______" of wasted space for lulz.
All full-length links are pointless, shorten them at once.
I'd like to see more things shortened up with symbols (example in the device type field, or the brand name with brand logo), or in a USB field you can show USB symbols for each port (different symbols for usb 1.1 2.0 or 3.0, maybe a small image of USB's actual symbol) instead of text, same for Ethernet ports (so you can shrink two fields in one, btw)
This forum only has these dumb icons for sound, so you get an example with them showing the amount of fictional "sound ports" on our devices:
one low sound port:
one loud sound port:
four low sound ports: or 4x
four loud sound ports: or 4x
some of each: or 2x / 2x
Yes these icons aren't the best as they are not different enough to make sure you don't read them wrong, as I said they are dumb icons, in the table we should use better ones.
All Yes/No/(weird upside down question mark, wat is dat anyway?) in the table would look much better (and waste less space) with icons like these
Note that I'm talking of turning a moon-sized database table in a pretty and easily-readable visual representation of the toh for human consumption, in a perfect world where adding what I ask is easy, fast and painless. So don't take it as an order or something, it's just a suggestion.
But yeah, the main takeaway is that while the actual database is ok, throwing a huuuge database table around (or even just a smaller table) isn't the best way to show information at people. Use text ONLY where you can't use an image instead.
Also, I take the occasion to state a probably known issue.
The USB field is inconsistent, you have some devices stating 1xusb2.0 and some devices stating "yes". Which is a bit weird. "Yes" what? 2.0? 1.1?


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: [SOLVED] Image Files Download Counts

When checking out the download page for target image files either snapshot or release, there is no column indicating how popular each image is.
In the case of snapshots it could be useful to have a download count. An image that has had many downloads and no issues reported back may indicate a good confidence level with the image.

1 Reply
1

[Assistant]
Problem is that the snapshot image change every day so that counter would reset every time...

1

I think this makes good sense for release product and packages.
It would tell users what is popular and dev what boxes are no longer of interest.

2

Or simply something like awstats that parses webserver config for downloads.openwrt.org.
With that it would also be possible to count downloads of snapshot images.
I mean only parse the the requested files and no ip´s, user agents or something else...


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: Table Of Hardware Is Exceptionally Annoying

Not sure when it happened, but at some point, someone edit the Table of Hardware to make it less useful. In particular, one has to scroll too much to the right to get to hyperlinks for devices. Also, it would be a simple matter of having a columns with a single icons such as (?) for the other hyperlinks. There is no reason whatsoever for the current format. It is almost as if someone did this deliberately to frustrate the reader. The older format was much simpler. The entire point of hyper-linking is to hyper-link the test: Putting the hyper-links in separate columns so that one has to scroll makes no sense. One has to wonder what the motivation was behind this.

1 Reply
2

[Assistant]
Quadrature:
The older format was much simpler.
What older format are you talking about?

Hallo Thomas,
I am not sure. I cannot seem to find the original page. It was several years ago.
This format found by Google is closer to what it was.
What happened in my case was that I wanted to see list of all routers that had 802.11/AC. When I saw some, I noticed that I would have to scroll to the right to get to the information. But if I did that, the list of 802.11/AC would scroll of the page. It is better to have all of the information on a single page that does not have to be scrolled horizontally, IMO.
Here are a few ideas for improvement (IMO):
Make sure all data fits on one page without horizontal scrolling.
Eliminate "OEM Device HomePage" and just hyperlink "Brand"
Eliminate column for "Device Page" and just hyperlink "Model"
Use images to denote "Single Board Computer" /"WiFi Router" (nice to have, more compact)
Wow.. .No offense meant to you. I know that you do a lot of good work on the site, but even now, it is sooo annoying to scroll...I can see the veins popping out of my hand as I scroll back and forth in Chrome trying to get to the information.

1 Reply

First of all: The ToH contains a lot of data. Since it is too much to display in a single table, we have specialized versions of the ToH, focusing on specific topics, containing only what is needed for the job.
In your case, https://openwrt.org/toh/views/toh_available_864_ac-wifi might be a tiny bit better in terms of visibility of AC wifi (but not regarding devicepage / dataentry page).
Alternative views with better visibility:
https://openwrt.org/toh/views/toh_admin_wlandriver
https://openwrt.org/toh/views/toh_admin_modem_wlan
You can see all the different "views" on the data on the overview page https://openwrt.org/toh/views/start
Maybe that was where you found what you are refering to as "older format".
Alternative solution proposals:
Get a monitor with higher x-resolution
OK, not a real serious proposal I have 2560 pixels in x available and toh_available_864 fits comfortably into the fullscreen browser window.
There are 32:9 monitors out there, 5120 pixels wide, but I guess that's still not wide enough for all the data.
Use your browsers zoom function to display more columns on the screen.
70% is the smallest fontsize acceptable for me. Compared with 100%, 4 more columns fit onto the screen.
Use the CSV export of the ToH and view the full data in the spreadsheet application of your choice. Remove columns that are not of interest to you, pull ahead columns that are more important to you, zoom in/out and filter as you like etc.
https://openwrt.org/_media/toh_dump_tab_separated_csv.zip
Apart from that: Thanks for pointing me again on this subject!
I recognized that we have still columns in the table that are not used any longer (LEDE forum topic; datafield doesn't exist any more in the dataentries). I have removed this column now in 2 datatables and will check the others too. A little space gained again

2 Replies
5


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: What should we call the current builds?

Both
@hnyman
and
@bobafetthotmail
mentioned (in these postings: LEDE Table of Packages: Good or bad? and LEDE Table of Packages: Good or bad?) that "trunk" isn't a good name for the current set of builds.
They also suggest using the name "nightly" or "snapshot" to talk about these current builds.
I prefer "nightly" because it says what people would be getting: the result of a rapidly changing process that's becoming ever-better.
Once we get a release plan in place, people will be able to choose between a "nightly" build, with the latest stuff, or a "stable" version that has considerable testing.
Thoughts?

[Assistant]
We already use "snapshots" name in the download path:
https://downloads.lede-project.org/snapshots/targets/
Also "trunk" makes no sense at all, we don't use svn anymore. Is this even mentioned anywhere? I don't think it should.
I don't see much gain from renaming "snapshots" to "daily" or "nightly".

2 Replies

[quote="rmilecki, post:2, topic:261, full:true"]Also "trunk" makes no sense at all, we don't use svn anymore. Is this even mentioned anywhere? I don't think it should.[/quote]Mostly on documentation coming from OpenWRT wiki where "trunk" is still the name for OpenWRT snapshots, I will replace it with "snapshot".
[quote]I don't see much gain from renaming "snapshots" to "daily" or "nightly".[/quote]"snapshots" name by itself does not describe that these are from development branch (master), at least imho.
I know it's bike-shedding.

The reason I am attracted to "daily" or "nightly" is that it immediately conveys the "timeliness" of the image. You intuitively grok that it's today's version, and there will likely be a new one tomorrow.
For me, "snapshot" conveys an important saved state. I have snapshots of my VMs, snapshots of a website at a particular time, etc. Those snapshots preserve something that I might, someday, wish to return to.
So I'd lobby for the word "daily" or "nightly", and then lobby that we apply it everywhere - in the wiki, the forum, and the name of the directory on the download server.


[System] You are an OpenWrt support assistant; use the following forum posts as background but remember they may be incomplete or outdated—if you’re unsure, flag the uncertainty and point the user to the official OpenWrt documentation.

[User]
Title: LEDE Showcase page

I've been reflecting on a few subjects mentioned in the forums -- who uses LEDE and who is LEDE for, as well as a separate subject on expanding exposure for LEDE packages and I came with the idea of LEDE Showcase.
As most of people don't think in terms of packages, but in terms of outcomes, it would be a great benefit to provide a manually written (once tho) page which would showcase benefits of using LEDE, but not in terms "it does openvpn" but in terms of:
Allow secure access to home network while away
Secure your connection to the outside world
Things like guest wifi network, adblocking, time-based WiFi and/or parental controls and other things which would appeal to broad audiences should be showcased.
Each of these should have short description (think elevator pitch), link to the appropriate recipe, as well as some basic information on pre-requisites (hardware, as well as user skills).
PS. Ideally, there should be packages with luci-based companions for most basic things (for example why Guest WiFi can't be turned into a package easy to set up thru Luci?) -- for those who can't/don't want to use CLI. And speaking of openvpn, LEDE should encourage commercial VPN providers to maintain their specific packages, only requiring minimal user input (think login/password).

[Assistant]
I hate to be "that guy" but I think it is good to state this:
I think it is necessary to focus the brainstorming on what you/others-like-you can do for LEDE than on what would be good to have in general, because good ideas are sure good, but opensource projects live off contributions.

@stangri
I think this is a great idea, and I concur with
@bobafetthotmail
that you should take a stab at writing this.
It belongs on the wiki home page. I propose its heading should be something like, "Why should I use LEDE?" and that it appear above the "LEDE Wants You" section.
List the important bullet points that you care about. I think we should have a one-two sentence description with "More..." as a link to a detail page. e.g.,
Allow secure access to home network while away More...
... etc...
Don't think too hard. Just write up 3 (or 5, or more) bullet points that make LEDE important for you. Post 'em here, and others can chime in. Once we have a decent "elevator pitch", we will add them to the home page. Thanks!

[quote="richb-hanover, post:3, topic:270, full:true"]Don't think too hard. Just write up 3 (or 5, or more) bullet points that make LEDE important for you. Post 'em here, and others can chime in. Once we have a decent "elevator pitch", we will add them to the home page. Thanks![/quote]This.
Also it will be a good idea to list what "most basic things" need a luci interfaces, or other minor but annoying lack of something, so it can be added to a "newbie contributor's jobs list" page for those that want to get their feet wet in LEDE development and need some ideas.