Configuring OpenWRT

[soldar]

In an earlier thread I flashed a router with OpenWRT so I now have a (TP-Link TL-WR841N/ND v9, Firmware Version OpenWrt Chaos Calmer 15.05.1 / LuCI 15.05-149) router running OpenWRT.

At present I am using it as a switch and not using the WAN side. It has WIFi plus four LAN Ethernet ports, one of which goes to the router and the WAN is not connected.

I realize it is a big field so I want to start slowly learning the ropes. I think I understand the basics of the routing tables but I have tried blocking some IP addresses and it doesn't work.

Question the first: As the device is working as a switch and not router, can I still block outside global IPs? Or does the routing table only come in when the traffic is between LAN and WAN?

Question the second: Not that I really need it but could I configure the WAN Ethernet port as one more LAN port?

[Nominal Animal]

Note that on the OpenWrt TL-WR841ND page, the download links at the middle of the page are to Chaos Chalmer, but if you scroll a bit further down, to the Installation section, you have links to the current stable version (18.06.4, as of this writing).

I shall also assume you are asking whether things can be done on the command line, and not whether there is a ready Luci web interface for them.

I think I understand the basics of the routing tables but I have tried blocking some IP addresses and it doesn't work.

Tried how? "it doesn't work" only applies to the method(s) you tried.  That is, that only says you tried something that didn't work.  (If you just meant that in the sense that you're not asking theoretical questions, but doing this in real life, ignore this point.)

As the device is working as a switch and not router, can I still block outside global IPs? Or does the routing table only come in when the traffic is between LAN and WAN?

The Linux kernel will see every packet entering the device, and can drop/filter each packet in every case.
The configuration (especially if bridging) does affect exactly how/where the rules are applied, though.

When "working as a switch", the four ports are bridged together, so any filtering must be applied to the bridge device (br-lan, usually).  The bridging firewall might be disabled in default configuration; you might need to install/enable some packages (bridge firewall kernel modules).

You can also put each LAN port in a separate VLAN, too, and filter packets between VLANs.  It is common to split LAN1..LAN4 into two VLANs, "LAN" (say LAN1..LAN3) and "DMZ" (LAN4 port), so that a local server can be put in "DMZ", and different rules used between LAN-DMZ, LAN-WAN, and DMZ-WAN.)

Not that I really need it but could I configure the WAN Ethernet port as one more LAN port?

Yes.

[soldar]

Wow, so much to chew on!

Note that on the OpenWrt TL-WR841ND page, the download links at the middle of the page are to Chaos Chalmer, but if you scroll a bit further down, to the Installation section, you have links to the current stable version (18.06.4, as of this writing).

Installing what I have was quite an adventure and I don't know that I want to upgrade unless there is a good reason. Would you recommend it? And if so, why? Will it add capabilities?  I am afraid to find out something was made worse.

I shall also assume you are asking whether things can be done on the command line, and not whether there is a ready Luci web interface for them.

I did not even know there was a command line I could use. How do I get to it?

Tried how? "it doesn't work" only applies to the method(s) you tried.  That is, that only says you tried something that didn't work.  (If you just meant that in the sense that you're not asking theoretical questions, but doing this in real life, ignore this point.)

Yes, I tried putting a line redirecting packets with a specific destination IP address to 127.0.0.1 but it made no difference. I am beginning to realize this is more complex than I thought. i am somewhat familiar with the Windows routing table which is simpler.

The Linux kernel will see every packet entering the device, and can drop/filter each packet in every case.
The configuration (especially if bridging) does affect exactly how/where the rules are applied, though.

When "working as a switch", the four ports are bridged together, so any filtering must be applied to the bridge device (br-lan, usually).  The bridging firewall might be disabled in default configuration; you might need to install/enable some packages (bridge firewall kernel modules).

You can also put each LAN port in a separate VLAN, too, and filter packets between VLANs.  It is common to split LAN1..LAN4 into two VLANs, "LAN" (say LAN1..LAN3) and "DMZ" (LAN4 port), so that a local server can be put in "DMZ", and different rules used between LAN-DMZ, LAN-WAN, and DMZ-WAN.)

This is way over my head. Rather than trying to do anything useful my objective is to learn so let's do something simple. How can I have it drop packets addressed to a certain, external IP address?

[Nominal Animal]

Installing what I have was quite an adventure and I don't know that I want to upgrade unless there is a good reason.

Yes, I agree.  I am currently trying to create a firmware image of 18.06.4 but with a few patches to the mt76 driver, as snapshots contain support for 5 GHz on my Asus RT-AC51U, but 18.06.4 from June does not.  I think.

Would you recommend it? And if so, why? Will it add capabilities?  I am afraid to find out something was made worse.

It will be supported up to version 19.07, but not later versions, because it has only 4MB of Flash.

Let's see, by looking at what others who have the same board have said, at the OpenWrt forum.  No, I don't see any issues speaking against using 18.06.

18.06 was released after the OpenWrt-LEDE merge, and includes a much newer kernel and many security-related fixes.  So yes, I do recommend updating to 18.06.

I did not even know there was a command line I could use. How do I get to it?

When you configure the router, enable SSH.  Then, you can connect using SSH to a command line shell on the device.

Yes, I tried putting a line redirecting packets with a specific destination IP address to 127.0.0.1 but it made no difference. I am beginning to realize this is more complex than I thought. i am somewhat familiar with the Windows routing table which is simpler.

Unfortunately, I'm not at all familiar with LuCI, barely having ever used it..

Please remember that the complexity is not just asininity on behalf of the developers, but is a direct result of the wildly varying hardware.  The same system works across several completely different architectures, and supports who knows many different chipsets; complexity is to be expected.  LuCI itself is even a separate project just shared under the OpenWrt umbrella..

(As an example, in newer upstream Linux kernels, switches (like the LAN1-LAN4 ports on your TP-Link) are exposed as individual ethernet devices, instead of as a switch device -- this is called DSA, distributed switch architecture.  However, OpenWrt is based on older kernels where most switches are exposed as a switch device (controlled by different utilities compared to normal ethernet ports; swconfig instead of ifconfig on the command line).  OpenWrt firmware images cannot jump from one type of driver to the other as it would break existing configurations (all the custom rules users have set), so typically the older switch device is used.)
 
(For me, the current hurdle is getting to know the OpenWrt build system better, because I don't just want to recompile an existing firmware image, but modify part of the kernel it uses, while keeping the rest of it compatible with updates.  I could use a snapshot instead, but I cannot decide which one to use, as I really would prefer just 18.06 but with slightly newer mt76 driver; and all monolithic, not modular. Yes, I am being difficult...  )

This is way over my head. Rather than trying to do anything useful my objective is to learn so let's do something simple.

Have you read the OpenWrt quick start or user guides?

How can I have it drop packets addressed to a certain, external IP address?

Note that a route describes how a packet is transmitted, but a filter or rule determines what is done with a packet.  You want rules/filters, not routes.

The LuCI Firewall > Traffic rules interface only defines rules between zones (LAN or WAN) by default, AFAIK.  It is an user interface choice, I believe, by the LuCI developers.  I'm not sure if it supports adding rules to bridges.

If we look at how current (18.06.4) OpenWrt/LuCI works on an TP-Link TL-WR841N, it seems quite different; perhaps it would be better if you first moved to 18.06.4 firmware?

In particular, if you want to filter traffic within a zone, you'll need kmod-br-netfilter and kmod-ipt-physdev packages, as each multi-port zone is a bridge, I think.

Or, you could configure a different zone for each physical port on the device, so you can use the web interface to define the rules, as the standard interface limits rules to those that apply packets between zones, not within a zone.  (If you have a switch downstream from the TP-Link, and two machines are connected to that switch, they can always see each other, as the packages no longer go through the TP-Link; so, the zone configuration reflects real world pretty well then.)
I suppose this zone-per-port is the simplest, most straightforward way to get to exploring how the filtering works, however.


I am afraid that this is one of those cases where previous Windows knowledge may be a hindrance, and not very helpful.  The fact that you know about IP addresses and TCP and UDP ports helps; but the structure and operation of the filtering and tables themselves...  Be prepared to be annoyed at things working differently than what would feel intuitive to you!

[Jeroen3]

I used to break my head around OpenWrt and DDWRT as well. Now I just buy a router from Mikrotik and have all the things OpenWRT is also capable of. But only now it works as expected.

[soldar]

So yes, I do recommend updating to 18.06.

Done. And thanks so much for your valuable advice. OpenWrt 18.06.4 r7808-ef686b7292 / LuCI openwrt-18.06 branch (git-19.170.32094-4d6d8bc)

When you configure the router, enable SSH.  Then, you can connect using SSH to a command line shell on the device.

It took a while but I finally managed to log in from the computer using PUTTY. I have also found I can do it directly from a terminal window in a Linux machine. Now I will have to learn the commands and how to use them.

Note that a route describes how a packet is transmitted, but a filter or rule determines what is done with a packet.  You want rules/filters, not routes.

I have a lot to study and learn. It may be more complicated for me than it is worth. I will get started.  Where can I start learning the configuration and commands?

[amspire]

You get more value from going to OpenWRT if you take the opportunity to double the RAM to 64M and quadruple ROM to 16M. You can do it for under $5 in total and it makes a really big difference.

The RAM is easy - OpenWRT just detects the extra RAM and uses it, and you can often get the RAM free. A compatible 64M RAM chip was used on many of the 8 chip 512M DDR1 PC Ram boards. Anyone with old 333MHz ram lying around is probably willing to give it away, and you get eight 64M RAM chips for free. See the OpenWRT page for the router for details.

A 64M EPROM chip only costs a dollar from Aliexpress.

In theory, you are meant to recompile the uboot partition, but in practice you do not need to. You need a programmer, like the $3 CH341 programmer board (https://www.aliexpress.com/item/33017484898.html), and an adapter (https://www.aliexpress.com/item/32825882447.html - I think it is the right one).

Just pull the 4M eprom chip off the board, read it.

With a binary editor like HxD, make a new blank 16M rom space ( 0 hex to FFFFFF Hex). Copy the first 128Kbytes of the old rom to the new rom space. Copy the last 64K of the old 4M rom to the last 64K of the new rom space (FF0000 Hex). Copy the factory.bin image you want so that it starts right after the 128K you put at 00000 Hex - ie at 20000 hex. Save it and write to the 16M eprom, and then solder the 16M eprom to the board.

Openwrt automatically detects the rom space, so when you put the 4M factory.bin on a 16M rom, it automatically uses all the Rom space up to 16M minus 64K for the Art partition at the top of the Rom.

All you loose by not recompiling the uboot, is you cannot use the uboot console to recover the 16M rom since it only thinks the rom is 4M. However, other then recovery, everything else works perfectly. If you are able to desolder the eprom and read it on a programmer, you can live without uboot recovery.

In theory, you can still compile 19.07 for the old 4M devices (with a few tweaks needed - they have removed the option from the menus), but I think that sticking to 18.06 is more reliable, as the 19.07 is no longer tested on the old hardware.

Richard.

[soldar]

When you configure the router, enable SSH.  Then, you can connect using SSH to a command line shell on the device.

I have been messing with this s little and I think I am better off trying to use LuCI GUI until I find its limits and only then move on to command line. It's still good to know it is the next step.

You get more value from going to OpenWRT if you take the opportunity to double the RAM to 64M and quadruple ROM to 16M. You can do it for under $5 in total and it makes a really big difference.

Thanks for the suggestion but it is not something I want to get into. If I get to that point I think I would be better off just getting a newer router. 

In fact, looking around I see I have an unused Mitrastar HGW-2501GN-R2 sitting around. Searching for the model number it looks like it was made specifically for the Spanish phone company Telefonica and I cannot find specs. It has the usual 4 LAN ports plus one WAN ethernet port plus one phone RJ10 port (VOIP). Opening the case I can see the following ICs:
- RT63368F (Processor?)
- Samsung K4T1G164QG-BCF7 - 1Gb DDR2 SDRAM
- RTL8368MB, LAYER 2 MANAGED 5+3-PORT 10/100/1000M SWITCH CONTROLLER
- RT5392L - WIFI

It does have a 4-pin header which I assume is serial. One pin is clearly gnd but the other 3 show 3 V so I would have to figure them out.

Any possibility of pushing OpenWRT into it?

[amspire]

In fact, looking around I see I have an unused Mitrastar HGW-2501GN-R2 sitting around.
Any possibility of pushing OpenWRT into it?

If it is not listed on the OpenWRT website, then probably not. The only chance would be if there is another brand on the list that is actually the same circuit. It does happen, but usually only with simpler generic devices. For example, there is a whole host of devices based on the TPlink wr703N architecture, and so it not that hard getting OpenWRT on any of these similar clones.

[soldar]

That's too bad because it looks like good hardware. I also have several Chinese TP-Link routers for which I cannot find suitable firmware.

[Nominal Animal]

Nice info, amspire!

Someone else also asked about OpenWrt support for HGW-2501GN-R2, with no responses, so probably not.  I don't speak Spanish, but it looks like it runs Linux already anyway.

I was going to write a long set of suggestions for command line usage, but you are probably right; for most use cases the LuCI interface works just fine.
If you want to experiment with filtering in it, do consider using the VLAN/zone configuration (splitting LAN into two or more zones/VLANs, so you can create filter rules controlling access between them, and between them and WAN).

[amspire]

I was going to write a long set of suggestions for command line usage, but you are probably right; for most use cases the LuCI interface works just fine.
If you want to experiment with filtering in it, do consider using the VLAN/zone configuration (splitting LAN into two or more zones/VLANs, so you can create filter rules controlling access between them, and between them and WAN).

One of the main reason I use OpenWRT is for the SSH command line. I use Luci for the major configuration as it is quick, and it is self documenting. If I want to set up OpenVPN, I often prefer to just use my own config files rather then trying to work through the Luci interface. You also get the full power of the cron scheduling if you need it.

One of the other things I often use SSH on OpenWRT devices is that it can be an easy way to get a tunnel inside a network. As long as you can SSH to an OpenWRT device, you can also set up tunnels - say a port forwarding to a local web page on another machine. Perhaps RDP or a VNC tunnel to another machine on the lan without having to expose the RDP or VNC port to the internet.

Running Wake On Lan on the OnenWRT devices is a good way to turn on PC's at a remote site.

All of this can be done on a tiny device like the WR703N or the GL.Inet upgraded clones which are probably only using about 2W of power.

Richard

[soldar]

I have a TL-WR702n lying around but I see OpenWRT says it does not have enough memory so I'll forget about it.

Getting back to my TL-WR841N, I have spent wasted some hours and got nowhere. As I mentioned, I am not using the WAN port, only the LAN ports and the router is connected to one of them. So in reality it is working as a switch, not router.

I tried using it as a router but the WAN port is non-responsive. The lights at both ends say there is a connection. The WAN port is (say) 192.168.5.5 but if I ping that address from the LAN side I get no response from that IP nor from the other device connected at the other end.

It may be that I somehow disabled the WAN port as I was not using it but now I do not remember. It seems to me everything is OK.

What can I do to test the WAN port?

ETA: Never mind. My stupid mistake. Mis-configured my computer's connection. All is well now.

[Nominal Animal]

I backported relevant (non-mt7615, non-cleanup) patches, by hand, from current mt76 master to stock 18.04.6, and compiled and rebuilt a new image (non-LuCI; I can install that later if I want to).  Now, on to testing!  This Asus RT-AC51U has 16 MiB flash and 64 MiB RAM, by the way.  It's not a bad device, considering its under-50€ price here, assuming I got the 5 GHz to work.  Otherwise, one needs to use a later version of OpenWrt for this one (so either snapshot, or wait).

[soldar]

I have not made any progress because I have put it aside for now and I have been working on something else.

Pardon my ignorance but it seems many routers are not prepared for OpenWRT although they are running Linux internally. I take it this is because nobody has taken the trouble of adapting OpenWRT to that specific router but, in my limited understanding, this should not be difficult, more or less like installing an OS in a computer and letting it detect the configuration. Right? Maybe it would detect some IC for which it does not have driver but otherwise it would "autoconfigure".  Why not?

Is there any easy way of adapting OpenWRT to a specific router for which there is not a version in the repository?

[Nominal Animal]

Pardon my ignorance but it seems many routers are not prepared for OpenWRT although they are running Linux internally. I take it this is because nobody has taken the trouble of adapting OpenWRT to that specific router but, in my limited understanding, this should not be difficult, more or less like installing an OS in a computer and letting it detect the configuration. Right?

Good question, but no.

These are embedded devices, whose internal structure varies a lot. A major part of the configuration is Device Tree, which describes how the processor/microcontroller accesses its integrated parts.  For example, on Asus RT-AC51U, the device tree is described in source form as RT-AC51U.dts:

Code: [Select]

/dts-v1/;

 #include "mt7620a.dtsi"

 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/input/input.h>

/ {
compatible = "asus,rt-ac51u", "ralink,mt7620a-soc";
model = "Asus RT-AC51U";

gpio-leds {
compatible = "gpio-leds";

power {
label = "rt-ac51u:blue:power";
gpios = <&gpio0 9 GPIO_ACTIVE_LOW>;
};

usb {
label = "rt-ac51u:blue:usb";
gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
};

wifi {
label = "rt-ac51u:blue:wifi";
gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
};
};

gpio-keys-polled {
compatible = "gpio-keys-polled";
#address-cells = <1>;
#size-cells = <0>;
poll-interval = <20>;

reset {
label = "reset";
gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
linux,code = <KEY_RESTART>;
};

wps {
label = "wps";
gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
linux,code = <KEY_WPS_BUTTON>;
};
};

gpio_export {
compatible = "gpio-export";
#size-cells = <0>;

enable-leds {
gpio-export,name = "enable-leds";
gpio-export,output = <1>;
gpios = <&gpio0 10 GPIO_ACTIVE_HIGH>;
};
};
};

&spi0 {
status = "okay";

m25p80@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <10000000>;

partition@0 {
label = "u-boot";
reg = <0x0 0x30000>;
read-only;
};

partition@30000 {
label = "u-boot-env";
reg = <0x30000 0x10000>;
read-only;
};

factory: partition@40000 {
label = "factory";
reg = <0x40000 0x10000>;
read-only;
};

partition@50000 {
label = "firmware";
reg = <0x50000 0xfb0000>;
};
};
};

&ehci {
status = "okay";
};

&ohci {
status = "okay";
};

&gpio3 {
status = "okay";
};

&ethernet {
status = "okay";
mtd-mac-address = <&factory 0x4>;
mediatek,portmap = "wllll";
};

&wmac {
ralink,mtd-eeprom = <&factory 0>;
};

&pinctrl {
state_default: pinctrl0 {
gpio {
ralink,group = "i2c", "wled", "uartf";
ralink,function = "gpio";
};
};
};

You'll see that it uses JEDEC/SPI-NOR flash at max. 10 MHz, with four partitions. spi0 itself is defined in the include file mt7620a.dts, which contains the device tree internal to the processor/microcontroller used (Mediatek MT7620a):

Code: [Select]

/ {
#address-cells = <1>;
#size-cells = <1>;
compatible = "ralink,mt7620a-soc";

cpus {
cpu@0 {
compatible = "mips,mips24KEc";
};
};

chosen {
bootargs = "console=ttyS0,57600";
};

cpuintc: cpuintc@0 {
#address-cells = <0>;
-cells = <1>;
interrupt-controller;
compatible = "mti,cpu-interrupt-controller";
};

aliases {
spi0 = &spi0;
spi1 = &spi1;
serial0 = &uartlite;
};

palmbus: palmbus@10000000 {
compatible = "palmbus";
reg = <0x10000000 0x200000>;
ranges = <0x0 0x10000000 0x1FFFFF>;

#address-cells = <1>;
#size-cells = <1>;

sysc: sysc@0 {
compatible = "ralink,mt7620a-sysc", "ralink,rt3050-sysc", "syscon";
reg = <0x0 0x100>;
};

timer: timer@100 {
compatible = "ralink,mt7620a-timer", "ralink,rt2880-timer";
reg = <0x100 0x20>;

interrupt-parent = <&intc>;
interrupts = <1>;
};

watchdog: watchdog@120 {
compatible = "ralink,mt7620a-wdt", "ralink,rt2880-wdt";
reg = <0x120 0x10>;

resets = <&rstctrl 8>;
reset-names = "wdt";

interrupt-parent = <&intc>;
interrupts = <1>;
};

intc: intc@200 {
compatible = "ralink,mt7620a-intc", "ralink,rt2880-intc";
reg = <0x200 0x100>;

resets = <&rstctrl 19>;
reset-names = "intc";

interrupt-controller;
-cells = <1>;

interrupt-parent = <&cpuintc>;
interrupts = <2>;
};

memc: memc@300 {
compatible = "ralink,mt7620a-memc", "ralink,rt3050-memc";
reg = <0x300 0x100>;

resets = <&rstctrl 20>;
reset-names = "mc";

interrupt-parent = <&intc>;
interrupts = <3>;
};

uart: uart@500 {
compatible = "ralink,mt7620a-uart", "ralink,rt2880-uart", "ns16550a";
reg = <0x500 0x100>;

resets = <&rstctrl 12>;
reset-names = "uart";

interrupt-parent = <&intc>;
interrupts = <5>;

reg-shift = <2>;

status = "disabled";
};

gpio0: gpio@600 {
compatible = "ralink,mt7620a-gpio", "ralink,rt2880-gpio";
reg = <0x600 0x34>;

resets = <&rstctrl 13>;
reset-names = "pio";

interrupt-parent = <&intc>;
interrupts = <6>;

gpio-controller;
-cells = <2>;

ralink,gpio-base = <0>;
ralink,num-gpios = <24>;
ralink,register-map = [ 00 04 08 0c
20 24 28 2c
30 34 ];
};

gpio1: gpio@638 {
compatible = "ralink,mt7620a-gpio", "ralink,rt2880-gpio";
reg = <0x638 0x24>;

interrupt-parent = <&intc>;
interrupts = <6>;

gpio-controller;
-cells = <2>;

ralink,gpio-base = <24>;
ralink,num-gpios = <16>;
ralink,register-map = [ 00 04 08 0c
10 14 18 1c
20 24 ];

status = "disabled";
};

gpio2: gpio@660 {
compatible = "ralink,mt7620a-gpio", "ralink,rt2880-gpio";
reg = <0x660 0x24>;

interrupt-parent = <&intc>;
interrupts = <6>;

gpio-controller;
-cells = <2>;

ralink,gpio-base = <40>;
ralink,num-gpios = <32>;
ralink,register-map = [ 00 04 08 0c
10 14 18 1c
20 24 ];

status = "disabled";
};

gpio3: gpio@688 {
compatible = "ralink,mt7620a-gpio", "ralink,rt2880-gpio";
reg = <0x688 0x24>;

interrupt-parent = <&intc>;
interrupts = <6>;

gpio-controller;
-cells = <2>;

ralink,gpio-base = <72>;
ralink,num-gpios = <1>;
ralink,register-map = [ 00 04 08 0c
10 14 18 1c
20 24 ];

status = "disabled";
};

i2c: i2c@900 {
compatible = "ralink,rt2880-i2c";
reg = <0x900 0x100>;

resets = <&rstctrl 16>;
reset-names = "i2c";

#address-cells = <1>;
#size-cells = <0>;

status = "disabled";

pinctrl-names = "default";
pinctrl-0 = <&i2c_pins>;
};

i2s: i2s@a00 {
compatible = "mediatek,mt7620-i2s";
reg = <0xa00 0x100>;

resets = <&rstctrl 17>;
reset-names = "i2s";

interrupt-parent = <&intc>;
interrupts = <10>;

txdma-req = <2>;
rxdma-req = <3>;

dmas = <&gdma 4>,
<&gdma 6>;
dma-names = "tx", "rx";

status = "disabled";
};

spi0: spi@b00 {
compatible = "ralink,mt7620a-spi", "ralink,rt2880-spi";
reg = <0xb00 0x40>;

resets = <&rstctrl 18>;
reset-names = "spi";

#address-cells = <1>;
#size-cells = <0>;

status = "disabled";

pinctrl-names = "default";
pinctrl-0 = <&spi_pins>;
};

spi1: spi@b40 {
compatible = "ralink,rt2880-spi";
reg = <0xb40 0x60>;

resets = <&rstctrl 18>;
reset-names = "spi";

#address-cells = <1>;
#size-cells = <0>;

status = "disabled";

pinctrl-names = "default";
pinctrl-0 = <&spi_cs1>;
};

uartlite: uartlite@c00 {
compatible = "ralink,mt7620a-uart", "ralink,rt2880-uart", "ns16550a";
reg = <0xc00 0x100>;

resets = <&rstctrl 19>;
reset-names = "uartl";

interrupt-parent = <&intc>;
interrupts = <12>;

reg-shift = <2>;

pinctrl-names = "default";
pinctrl-0 = <&uartlite_pins>;
};

systick: systick@d00 {
compatible = "ralink,mt7620a-systick", "ralink,cevt-systick";
reg = <0xd00 0x10>;

resets = <&rstctrl 28>;
reset-names = "intc";

interrupt-parent = <&cpuintc>;
interrupts = <7>;
};

pcm: pcm@2000 {
compatible = "ralink,mt7620a-pcm";
reg = <0x2000 0x800>;

resets = <&rstctrl 11>;
reset-names = "pcm";

interrupt-parent = <&intc>;
interrupts = <4>;

status = "disabled";
};

gdma: gdma@2800 {
compatible = "ralink,mt7620a-gdma", "ralink,rt3883-gdma";
reg = <0x2800 0x800>;

resets = <&rstctrl 14>;
reset-names = "dma";

interrupt-parent = <&intc>;
interrupts = <7>;

-cells = <1>;
-channels = <16>;
-requests = <16>;

status = "disabled";
};
};

pinctrl: pinctrl {
compatible = "ralink,rt2880-pinmux";
pinctrl-names = "default";
pinctrl-0 = <&state_default>;

state_default: pinctrl0 {
};

pcm_i2s_pins: pcm_i2s {
pcm_i2s {
ralink,group = "uartf";
ralink,function = "pcm i2s";
};
};

uartf_gpio_pins: uartf_gpio {
uartf_gpio {
ralink,group = "uartf";
ralink,function = "gpio uartf";
};
};

gpio_i2s_pins: gpio_i2s {
gpio_i2s {
ralink,group = "uartf";
ralink,function = "gpio i2s";
};
};

spi_pins: spi {
spi {
ralink,group = "spi";
ralink,function = "spi";
};
};

spi_cs1: spi1 {
spi1 {
ralink,group = "spi_cs1";
ralink,function = "spi_cs1";
};
};

i2c_pins: i2c {
i2c {
ralink,group = "i2c";
ralink,function = "i2c";
};
};

uartlite_pins: uartlite {
uart {
ralink,group = "uartlite";
ralink,function = "uartlite";
};
};

mdio_pins: mdio {
mdio {
ralink,group = "mdio";
ralink,function = "mdio";
};
};

mdio_refclk_pins: mdio_refclk {
mdio_refclk {
ralink,group = "mdio";
ralink,function = "refclk";
};
};

ephy_pins: ephy {
ephy {
ralink,group = "ephy";
ralink,function = "ephy";
};
};

wled_pins: wled {
wled {
ralink,group = "wled";
ralink,function = "wled";
};
};

rgmii1_pins: rgmii1 {
rgmii1 {
ralink,group = "rgmii1";
ralink,function = "rgmii1";
};
};

rgmii2_pins: rgmii2 {
rgmii2 {
ralink,group = "rgmii2";
ralink,function = "rgmii2";
};
};

pcie_pins: pcie {
pcie {
ralink,group = "pcie";
ralink,function = "pcie rst";
};
};

pa_pins: pa {
pa {
ralink,group = "pa";
ralink,function = "pa";
};
};
};

rstctrl: rstctrl {
compatible = "ralink,mt7620a-reset", "ralink,rt2880-reset";
-cells = <1>;
};

clkctrl: clkctrl {
compatible = "ralink,rt2880-clock";
-cells = <1>;
};

usbphy: usbphy {
compatible = "mediatek,mt7620-usbphy";
-cells = <0>;

ralink,sysctl = <&sysc>;
resets = <&rstctrl 22 &rstctrl 25>;
reset-names = "host", "device";

clocks = <&clkctrl 22 &clkctrl 25>;
clock-names = "host", "device";
};

ethernet: ethernet@10100000 {
compatible = "mediatek,mt7620-eth";
reg = <0x10100000 0x10000>;

#address-cells = <1>;
#size-cells = <0>;

interrupt-parent = <&cpuintc>;
interrupts = <5>;

resets = <&rstctrl 21 &rstctrl 23>;
reset-names = "fe", "esw";

mediatek,switch = <&gsw>;

port@4 {
compatible = "mediatek,mt7620a-gsw-port", "mediatek,eth-port";
reg = <4>;

status = "disabled";
};

port@5 {
compatible = "mediatek,mt7620a-gsw-port", "mediatek,eth-port";
reg = <5>;

status = "disabled";
};

mdio-bus {
#address-cells = <1>;
#size-cells = <0>;

status = "disabled";
};
};

gsw: gsw@10110000 {
compatible = "mediatek,mt7620-gsw";
reg = <0x10110000 0x8000>;

resets = <&rstctrl 23>;
reset-names = "esw";

interrupt-parent = <&intc>;
interrupts = <17>;
};

sdhci: sdhci@10130000 {
compatible = "ralink,mt7620-sdhci";
reg = <0x10130000 0x4000>;

interrupt-parent = <&intc>;
interrupts = <14>;

status = "disabled";
};

ehci: ehci@101c0000 {
compatible = "generic-ehci";
reg = <0x101c0000 0x1000>;

interrupt-parent = <&intc>;
interrupts = <18>;

phys = <&usbphy>;
phy-names = "usb";

status = "disabled";
};

ohci: ohci@101c1000 {
compatible = "generic-ohci";
reg = <0x101c1000 0x1000>;

interrupt-parent = <&intc>;
interrupts = <18>;

phys = <&usbphy>;
phy-names = "usb";

status = "disabled";
};

pcie: pcie@10140000 {
compatible = "mediatek,mt7620-pci";
reg = <0x10140000 0x100
0x10142000 0x100>;

#address-cells = <3>;
#size-cells = <2>;

resets = <&rstctrl 26>;
reset-names = "pcie0";

clocks = <&clkctrl 26>;
clock-names = "pcie0";

interrupt-parent = <&cpuintc>;
interrupts = <4>;

pinctrl-names = "default";
pinctrl-0 = <&pcie_pins>;

device_type = "pci";

bus-range = <0 255>;
ranges = <
0x02000000 0 0x00000000 0x20000000 0 0x10000000 /* pci memory */
0x01000000 0 0x00000000 0x10160000 0 0x00010000 /* io space */
>;

status = "disabled";

pcie-bridge {
reg = <0x0000 0 0 0 0>;

#address-cells = <3>;
#size-cells = <2>;

device_type = "pci";
};
};

wmac: wmac@10180000 {
compatible = "ralink,rt7620-wmac", "ralink,rt2880-wmac";
reg = <0x10180000 0x40000>;

interrupt-parent = <&cpuintc>;
interrupts = <6>;

ralink,eeprom = "soc_wmac.eeprom";
};
};


Edited to add: Some of the above lines are garbled (-cells:), because Dave feels HASHTAG support is more important than reproducing code in code snippets correctly.  Way to go, @dave! 
Edited to add further: You cannot even post hashtag-hashtag; the forum software silently eats it.  Nice!

The device tree system was designed exactly because it is not possible to autodetect these features (and system integrators started to bake-in these settings to the source code, which would have bloated the kernel itself to unmanageable sizes very, very fast).

Note that you cannot see the contents of device tree source files in the firmware images (or ramdisk images), because they are compiled to binary (.dtb) form. (The device tree compiler package includes a decompiler, fdtdump, though.)

Maybe it would detect some IC for which it does not have driver but otherwise it would "autoconfigure".  Why not?

These things do not have any sort of detection mechanisms.  There is no way to detect that spi0 is connected to the flash, that it works reliably at up to 10 MHz SPI clock rates.

Even if you manage to create a kernel that does autodetect all these features reliably, it would be too large to fit in the typical 8 MiB flash most current routers have, much less the 4 MiB on your TP-Link router.

Is there any easy way of adapting OpenWRT to a specific router for which there is not a version in the repository?

Define "easy".

Many routers are just OEM models rebadged and re-enclosured, with basically the same circuit inside.  Sometimes they have slightly newer external chips or ethernet PHYs, but an existing router firmware image for the same device works, except for some features.  Then, it is a matter of finding how to support the unsupported parts.  For very new system-on-chips, you may need to backport device support from the vanilla (kernel.org) kernels to support that processor.  (Processor manufacturers are nowadays pretty good at pushing the support into upstream Linux; it just makes sense, because it reduces the effort and time needed to get support on the market.  Though, there are still vendors who insist on forking a specific version of Linux, and creating their own "SDK" on top of it, which means they're frozen in time at that point, and won't get support for new devices (radios and such) unless the vendor backports the support -- and they won't.)

(Conversely, many routers may completely change their hardware between minor revisions! Usually the revision is shown on some sticker at the bottom of the device, but otherwise may look exactly the same -- but internally, are completely different devices.)

If the router already runs some variant of Linux, it may have a device tree representation in the official firmware image.  Decompiling those, one can examine how the subsystems are wired; then, it is just a matter of finding the proper kernel device drivers to use.  It is a lot of work, but relatively straightforward; mostly searching and verification.

Most routers have an UART on the board configured as a serial console, providing the kernel messages.  (This is useful for development, and debugging malfunctioning units, so it makes sense to leave it enabled.)  These messages provide helpful information about the subsystems and drivers used.

Physical examination of the chips on the board can tell where to start; this is why you can find board images of many routers.

[soldar]

I have several Chinese routers with all the configuration menus in Chinese. Navigating menus in Chinese seems much easier to me than trying to flash firmware in English so I guess I will leave them as they are.