Difference between revisions of "Openwrt"

From Steak Wiki
Jump to navigationJump to search
 
(15 intermediate revisions by the same user not shown)
Line 38: Line 38:
 
===include /etc/firewall.user===
 
===include /etc/firewall.user===
 
This was changed, with the move to nft. The syntax for this has a few more options.
 
This was changed, with the move to nft. The syntax for this has a few more options.
−
Note that it now expects nft syntax.
+
Note that it now expects nft syntax.  
 
{{cat|/etc/config/firewall|config include
 
{{cat|/etc/config/firewall|config include
 
         option  enabled        1
 
         option  enabled        1
Line 45: Line 45:
 
         option  fw4_compatible  1
 
         option  fw4_compatible  1
 
#make sure this goes at the 'end' of /etc/config/firewall.
 
#make sure this goes at the 'end' of /etc/config/firewall.
 +
#and add /etc/firewall.user to /etc/sysupgrade.conf
 
}}
 
}}
 +
Be aware of the traps with the move to nft (see port forwarding section below), compared to iptables.
  
 
===open port===
 
===open port===
Line 74: Line 76:
 
Note that this is handled in nft, in the prerouting chain, before the input table, so you can't just add an input table src block.
 
Note that this is handled in nft, in the prerouting chain, before the input table, so you can't just add an input table src block.
 
This is a potential trap, because services like SSH which are on the firewall, you can put blocks in the input chain - and they will work. However, any redirects must be handled separately. Ipsets can not be used with redirect and fw4 according to the wiki, 2/2/23.
 
This is a potential trap, because services like SSH which are on the firewall, you can put blocks in the input chain - and they will work. However, any redirects must be handled separately. Ipsets can not be used with redirect and fw4 according to the wiki, 2/2/23.
 +
 +
====Trap from iptables fw4 to nft fw4====
 +
Beware with NFT. The behavior is different. Review the following:
 +
<pre>
 +
#redirects here show up in dstnat_wan
 +
config redirect
 +
      option name 'computer2'
 +
      option src 'wan'
 +
      option proto 'tcp'
 +
      option src_ip '<allowediphere>'
 +
      option src_dport '222'
 +
      option dest_port '222'
 +
      option dest_ip '10.0.0.233'
 +
      option target 'DNAT'
 +
      option dest 'lan'
 +
 +
config redirect
 +
      option name 'laptop'
 +
      option src 'wan'
 +
      option proto 'tcp'
 +
      option src_dport '224'
 +
      option dest_port '224'
 +
      option dest_ip '10.0.0.139'
 +
      option target 'DNAT'
 +
      option dest 'lan'
 +
 +
chain dstnat_wan {
 +
                ip saddr <yourhomeiphere> tcp dport 222 counter packets 1 bytes 60 dnat ip to 10.0.0.233:222
 +
                meta nfproto ipv4 udp dport 224 counter packets 2 bytes 352 dnat ip to 10.0.0.139:224
 +
        }
 +
</pre>
 +
adding a nft block or allow in /etc/firewall.user such as:
 +
nft insert rule inet fw4 input tcp dport 224 counter reject
 +
and an equivalent src ip allow in the input table
 +
will NOT work. it used to in iptables, but nft has different
 +
behavior. The dstnat_wan chain/table is the one to look at.
 +
When in doubt, always run a test on the ports from two ips.
 +
 +
Know that you can use nft allows/blocks in the /etc/firewall.user script for
 +
the input table, however they are primarily for services on the router (although
 +
snat for wireguard can be put there). Although you could probably put rules in the
 +
dstnat_wan table/chain instead of input (though it's not as graceful as iptables was).
 +
 +
Is this a good idea? I would expect inputs go in the inputs, and not in inputs AND
 +
dstnat_wan.
  
 
===reserved ip / static lease===
 
===reserved ip / static lease===
Line 84: Line 131:
 
I tried to add this to the wiki, but someone (https://openwrt.org/docs/guide-user/base-system/dhcp_configuration?rev=1596434574) decided to replace my simple solution with a scriptable yet obfuscated one that requires uci commands. So instead, it will remain here.
 
I tried to add this to the wiki, but someone (https://openwrt.org/docs/guide-user/base-system/dhcp_configuration?rev=1596434574) decided to replace my simple solution with a scriptable yet obfuscated one that requires uci commands. So instead, it will remain here.
 
EDIT: I added it back. See how long that lasts...
 
EDIT: I added it back. See how long that lasts...
 +
 +
===route===
 +
This can be useful if you want to bypass a VPN.
 +
{{cat|/etc/config/network|
 +
config route 'clientname'
 +
        option interface 'lan'
 +
        option target 'remoteipaddress'
 +
        option netmask '255.255.255.255'
 +
        option gateway 'yourvpn_or_waninterface'}}
  
 
===openvpn===
 
===openvpn===
Line 115: Line 171:
 
Trap: Again on balanced connections. Balanced internet doesn't necessarily work properly with mwan3, as connections can hop between interfaces which means an existing session will jump to a different interface and be half in one and half in the other. I learned to not use balanced, and just use the priority options, i.e. use wan1 only, and wan2 if wan1 goes offline, but DON'T try to use both at once. It didn't work right for me.
 
Trap: Again on balanced connections. Balanced internet doesn't necessarily work properly with mwan3, as connections can hop between interfaces which means an existing session will jump to a different interface and be half in one and half in the other. I learned to not use balanced, and just use the priority options, i.e. use wan1 only, and wan2 if wan1 goes offline, but DON'T try to use both at once. It didn't work right for me.
 
There may be simpler solutions than mwan3. See for example https://github.com/GTANAdam/openwrt-wan-failover-script  
 
There may be simpler solutions than mwan3. See for example https://github.com/GTANAdam/openwrt-wan-failover-script  
−
One thing is certain, mwan3 is complex.
+
One thing is certain, mwan3 is complex. It has lots of features (good) but it may be more than what you need, if you only need failover.
  
−
Also beware of mwan3 in 21 or 22. There may or may not be compatibility issues with iptables changing over to nft. See the wiki page for full details (I think you have to install iptables-nft).
+
Again, see Tips Page: [[Mwan3_On_Openwrt]]
 +
I think I've been bitten by the firewall part multiple times. Ugh.
  
 
===iptables vs fw3===
 
===iptables vs fw3===
Line 264: Line 321:
 
initramfs in the name. The resulting image can be loaded in the device
 
initramfs in the name. The resulting image can be loaded in the device
 
through the bootloader's tftp function and should boot to a prompt
 
through the bootloader's tftp function and should boot to a prompt
−
without relying on flash/filesystem support.
+
without relying on flash/filesystem support. This way, if you brick
 +
something, it's only on the RAM, and you can reboot the device.
  
 
===MTD Partitions data===
 
===MTD Partitions data===
Line 293: Line 351:
 
root@OpenWrt:/etc/config#
 
root@OpenWrt:/etc/config#
 
</pre>
 
</pre>
 +
 +
===Programs to install upon start===
 +
less (less is included, but this package contains the / search), tcpdump,
 +
nano-plus (includes nanorc functionality for emacs like ctrl-b, ctrl-f), htop.
 +
for nano-plus put in /etc/nanorc:
 +
<pre>
 +
bind ^B back all
 +
bind ^f forward all
 +
</pre>
 +
opkg update && opkg install less tcpdump nano-plus htop
  
 
===various links i found interesting===
 
===various links i found interesting===

Latest revision as of 09:45, 20 October 2024

Recommended Router

Current:

high traffic: x86 PC

low traffic: ARM / MIPS with the following: 

* uboot bootloader
* doesn't require multiple hoops to install (i.e. no 'two different' serial speeds on the same UART. moron ubiquiti...)
* promotes FOSS and is ok with LEDE/openwrt

Compiling

See developers guide - build system usage.

Also pay attention to this note: 

Using official build config

Compile OpenWrt in a way that it gets the same packages as the default official image:

For example if you are flashing for the archer_c7 you can locate on its wiki page the factory firmware URL https://downloads.openwrt.org/releases/21.02.1/targets/ath79/generic/openwrt-21.02.1-ath79-generic-tplink_archer-c7-v2-squashfs-factory.bin

'ath79' tells you the Target, 'generic' tells you the Subtarget while 'archer-c7-v2' tells you the Target profile for the very specific device.

Download the config by removing everything up to the subtarget 'generic' and adding 'config.buildinfo':

# OpenWrt 19.07 and later
wget https://downloads.openwrt.org/releases/21.02.1/targets/ath79/generic/config.buildinfo -O .config
 
# OpenWrt 18.06 and before
wget https://downloads.openwrt.org/releases/18.06.0/targets/ramips/mt7621/config.seed -O .config

When using this configuration the correct defaults will be already selected for the Target and Subtarget but not for the Target profile so you will have to tailor it for the specific device if you want to build only that one.

Double check you have the right tag.

Tips

include /etc/firewall.user

This was changed, with the move to nft. The syntax for this has a few more options. Note that it now expects nft syntax.

Contents of /etc/config/firewall

config include option enabled 1 option type 'script' option path '/etc/firewall.user' option fw4_compatible 1 #make sure this goes at the 'end' of /etc/config/firewall. #and add /etc/firewall.user to /etc/sysupgrade.conf

Be aware of the traps with the move to nft (see port forwarding section below), compared to iptables.

open port

Contents of /etc/config/firewall

config rule option src 'wan' option proto 'tcp' option dest_port '80' option target 'ACCEPT' option src_ip '123.123.123.123'

port forwarding

Port forwarding is one step:

  1. redirect port from outside to internal (prerouting chain, before input)

Contents of /etc/config/firewall

config redirect option name 'PassthroughformyServer' option src 'wan' option proto 'tcp' option src_dport '80' option dest_ip '192.168.1.100' option dest_port '80' option target 'DNAT' option dest 'lan' option src_ip '123.123.123.123'

Note: Proto can be 'tcp' OR 'tcpudp' OR 'udp'. If you have multiple src allows, make multiple. See: https://forum.openwrt.org/t/port-forward-for-two-source-addresses/24067/2 Note that this is handled in nft, in the prerouting chain, before the input table, so you can't just add an input table src block. This is a potential trap, because services like SSH which are on the firewall, you can put blocks in the input chain - and they will work. However, any redirects must be handled separately. Ipsets can not be used with redirect and fw4 according to the wiki, 2/2/23.

Trap from iptables fw4 to nft fw4

Beware with NFT. The behavior is different. Review the following: 

#redirects here show up in dstnat_wan
config redirect
       option name 'computer2'
       option src 'wan'
       option proto 'tcp'
       option src_ip '<allowediphere>'
       option src_dport '222'
       option dest_port '222'
       option dest_ip '10.0.0.233'
       option target 'DNAT'
       option dest 'lan'

config redirect
       option name 'laptop'
       option src 'wan'
       option proto 'tcp'
       option src_dport '224'
       option dest_port '224'
       option dest_ip '10.0.0.139'
       option target 'DNAT'
       option dest 'lan'

chain dstnat_wan {
                ip saddr <yourhomeiphere> tcp dport 222 counter packets 1 bytes 60 dnat ip to 10.0.0.233:222
                meta nfproto ipv4 udp dport 224 counter packets 2 bytes 352 dnat ip to 10.0.0.139:224
        }

adding a nft block or allow in /etc/firewall.user such as: 

nft insert rule inet fw4 input tcp dport 224 counter reject

and an equivalent src ip allow in the input table will NOT work. it used to in iptables, but nft has different behavior. The dstnat_wan chain/table is the one to look at. When in doubt, always run a test on the ports from two ips.

Know that you can use nft allows/blocks in the /etc/firewall.user script for the input table, however they are primarily for services on the router (although snat for wireguard can be put there). Although you could probably put rules in the dstnat_wan table/chain instead of input (though it's not as graceful as iptables was).

Is this a good idea? I would expect inputs go in the inputs, and not in inputs AND dstnat_wan.

reserved ip / static lease

Contents of /etc/config/dhcp

config host option ip 192.168.1.122 option mac c2:44:32:18:cd:ab option name reservedipcomputer

ref: https://openwrt.org/docs/guide-user/base-system/dhcp_configuration#static_leases

I tried to add this to the wiki, but someone (https://openwrt.org/docs/guide-user/base-system/dhcp_configuration?rev=1596434574) decided to replace my simple solution with a scriptable yet obfuscated one that requires uci commands. So instead, it will remain here. EDIT: I added it back. See how long that lasts...

route

This can be useful if you want to bypass a VPN.

Contents of /etc/config/network

config route 'clientname' option interface 'lan' option target 'remoteipaddress' option netmask '255.255.255.255' option gateway 'yourvpn_or_waninterface'

openvpn

opkg install openvpn-openssl

Contents of /etc/config/openvpn

config openvpn 'custom_config' option config '/etc/openvpn/myconfigfile.ovpn'

And your .ovpn in /etc/openvpn/.

aliases

Put in /etc/profile. e.g. 

export TERM=xterm
alias vpnme= 'openvpn --config /etc/openvpn/myconfigfile.ovpn & ./script.sh &'

mwan3

Mwan3 can be tricky. The wiki lacks a quick start*. The following files get edited: 

/etc/config/network
/etc/config/mwan3
/etc/config/firewall

Tips Page: Mwan3_On_Openwrt

If you add a new WAN interface, (e.g. wanb or wan2) you must add wanb to the existing wan firewall zone for outgoing comms. How this is handled differs from 17 to 19.*2

Balanced policies can have issues with connections jumping from one wan to another.

* the current mwan3 page is a lengthy multi-page behemoth (which has grown over time) that expects no less of you than to understand all functional and architectural details of how the failover works. It's a lot for someone that just wants to setup backup internet. But mwan3 can and does work.

  • 2 ctrl-f for firewall comes up with half a dozen mentions of firewall masking (something done automatically) and one easily missable note, for GUI setup only, about adding the new wan2 to the firewall zone. An absolutely required step.

Trap: Again on balanced connections. Balanced internet doesn't necessarily work properly with mwan3, as connections can hop between interfaces which means an existing session will jump to a different interface and be half in one and half in the other. I learned to not use balanced, and just use the priority options, i.e. use wan1 only, and wan2 if wan1 goes offline, but DON'T try to use both at once. It didn't work right for me. There may be simpler solutions than mwan3. See for example https://github.com/GTANAdam/openwrt-wan-failover-script One thing is certain, mwan3 is complex. It has lots of features (good) but it may be more than what you need, if you only need failover.

Again, see Tips Page: Mwan3_On_Openwrt I think I've been bitten by the firewall part multiple times. Ugh.

iptables vs fw3

In the firewall: 

iptables -L

will list current rules, but the iptables rule generator is fw3. 

fw3 print

Will display iptables commands that make up the firewall. fw3 script is described in firewall pages on official wiki. Please review that. 22 now uses nft. 

nft list tables

less with / search

The stock 'less' command does not include '/' search. 

opkg install less

To get forward slash search https://dev.archive.openwrt.org/ticket/7132

remove poweroff command

cd /sbin/
rm ./poweroff

Now to power off, you must type 

busybox poweroff

This will keep you from accidentally shutting down a router.

misc

start wifi 

wifi up  
wifi status

transfer files using nc / scp on lean embedded devices

Logging

display (RAM based) logs (note that this is not in /var/log/messages...) 

logread

https://openwrt.org/docs/guide-user/perf_and_log/start e.g. https://openwrt.org/docs/guide-user/perf_and_log/statistic.custom and https://openwrt.org/docs/guide-user/perf_and_log/log.messages

Blink LEDs

If you poke around the Linux Kernel you will come across core Netfilter configuration. It's not in an obvious place, but in 5.4 here: 

Location:                                                                                                                            │
  │     -> Networking support (NET [=y])                                                                                                   │
  │       -> Networking options                                                                                                            │
  │         -> Network packet filtering framework (Netfilter) (NETFILTER [=y])                                                             │
  │           -> Core Netfilter Configuration                                                                                              │
  │             -> Netfilter Xtables support (required for ip_tables) (NETFILTER_XTABLES [=y])

Why am I poking around xtables support? Wireguard needs it for <5.6. But, in this page, you will find some familiar sights: REDIRECT,MASQUERADE,DROP,LOG, etc... All parameters for iptables. Here you will learn what the difference between REDIRECT and MASQUERADE is (one is input, one is output)(which is interesting, because it might be a thing people commonly get wrong, on online tips for using iptables, or if you don't know which does what, you won't know what to look for). Forget about that, there's one named LED. Hey that sounds interesting. That means I can control a LED from the firewall?

Does this work with Openwrt? No idea, but from here I went to the official owrt docs 

https://openwrt.org/docs/guide-user/base-system/led_configuration

And you may already know the leds are there, but here's how to configure them. Some of them require modules. e.g. 

The LED flashes with link status and/or send and receive activity on the configured interface. If not installed already, install it with: 
 opkg install kmod-ledtrig-netdev

will enable netdev, which will enable led activity on any NIC. so it requires that module and some configuration... e.g. 

#:/sys/devices/platform/leds/leds/:green:wan# ls
brightness      device_name     link            rx              trigger         uevent
device          interval        max_brightness  subsystem       tx
#:/sys/devices/platform/leds/leds/:green:wan# cat *
0
cat: read error: Is a directory
eth0.2
50
0
255
1
cat: read error: Is a directory
none switch0 timer default-on [netdev] phy0rx phy0tx phy0assoc phy0radio phy0tpt
0
OF_NAME=wan
OF_FULLNAME=/leds/wan
OF_COMPATIBLE_N=0

I had to set rx or tx to 1 (only 1 of them). and also needed to set device_name (not device like docs say) to eth0.2

Just set a ping, then tweak the knobs; should start blinking.

"But what if I want to blink more LEDs from userspace?" See Arduino for ulisp.


Periodic Reboot

One of my routers had DHCP fail after 60 days. It's not common, but a good idea might be a periodic reboot. This is taken from the owrt site.

  1. Reboot at 4:30am every day
  2. Note: To avoid infinite reboot loop, wait 70 seconds
  3. and touch a file in /etc so clock will be set
  4. properly to 4:31 on reboot before cron starts.

30 4 * * * sleep 70 && touch /etc/banner && reboot

NOTE: I've never had issues with reboot, but above looks like a good idea.

Run Script on Boot / etc hotplug.d

You can use rc.local, however sometimes you need more control.

It's also possible to put scripts in /etc/hotplug.d that run after certain events. (e.g. [1])

Here are two examples.

1) Run an iptables firewall command only after DNS is active. 

#!/bin/sh
logger -t hotplug "Starting firewall_DNS.sh"  
[ "$ACTION" == "ifup" ] && [ "$INTERFACE" == "wan" ] &&  /etc/firewall_DNS.sh

/etc/hotplug.d/iface/99-iptables_dns_lookup

2) Assign a shell script to a button. 

#logger "the button was ${BUTTON} and the action was ${ACTION}"
logger -t netiface "reset network button pressed"
[ "$BUTTON" == "BTN_0" ] && [ "$ACTION" == "pressed" ] &&  /etc/restart_net.sh
[ "$BUTTON" == "BTN_0" ] && [ "$ACTION" == "released" ] &&  /etc/restart_net.sh

/etc/hotplug.d/buttons/buttons

This latter one should be tested to remove the redundant command, but I didn't use it in practice. It's left unfinished as a reference.

Packages are Located in Multiple Places

This is something that confused me as a user (not a developer) of owrt. The packages are in different places. There are the kernel modules, and some programs, then there may be a different path for the application programs. Pay attention to where opkg searches in /etc/opkg/ e.g. 

src/gz openwrt_core https://downloads.openwrt.org/releases/####/targets/processor/generic/packages
src/gz openwrt_packages https://downloads.openwrt.org/releases/####/packages/maybe different processor/packages

Always test with RAM only images

Test firmware images without writing them to flash by using ramdisk images.

In make menuconfig select Target Images and then you can select the ramdisk option.

This will create an image with kernel + initramfs, that will have initramfs in the name. The resulting image can be loaded in the device through the bootloader's tftp function and should boot to a prompt without relying on flash/filesystem support. This way, if you brick something, it's only on the RAM, and you can reboot the device.

MTD Partitions data

You can run lsblk, but it won't show the descriptions for the mtd partitions. That is in /proc/mtd. See: 

root@OpenWrt:/etc/config# lsblk
NAME      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda         8:0    0 149.1G  0 disk 
└─sda1      8:1    0   149G  0 part 
mtdblock0  31:0    0   256K  1 disk 
mtdblock1  31:1    0  31.3M  0 disk 
mtdblock2  31:2    0     3M  0 disk 
mtdblock3  31:3    0  28.3M  0 disk /rom
mtdblock4  31:4    0  23.4M  0 disk /overlay
mtdblock5  31:5    0   256K  1 disk 
mtdblock6  31:6    0   128K  1 disk 
mtdblock7  31:7    0   128K  1 disk 
root@OpenWrt:/etc/config# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00040000 00020000 "Boatlooter"
mtd1: 01f40000 00020000 "firmware"
mtd2: 00300000 00020000 "kernel"
mtd3: 01c40000 00020000 "rootfs"
mtd4: 01760000 00020000 "rootfs_data"
mtd5: 00040000 00020000 "rgdb"
mtd6: 00020000 00020000 "nvram"
mtd7: 00020000 00020000 "LangPack"
root@OpenWrt:/etc/config#

Programs to install upon start

less (less is included, but this package contains the / search), tcpdump, nano-plus (includes nanorc functionality for emacs like ctrl-b, ctrl-f), htop. for nano-plus put in /etc/nanorc: 

bind ^B back all
bind ^f forward all

opkg update && opkg install less tcpdump nano-plus htop

various links i found interesting

  • https://openwrt.org/docs/techref/start - Technical Reference. Has some informative dives into various aspects of low power routers. As an example see this link on flash: https://openwrt.org/docs/techref/flash IME, flash is built in obsolescence. usb drives, sd cards, and onboard flash tend to last much less than advertised. not recommended. SD and SSDs are a trap. from this: even 'reading' flash can cause bad blocks. that's right, even reading. therefore flash is guaranteed to fail. tech companies love it.


GNU\Linux
Programs
Other
Distributions
Politics
Retrieved from "http://steakwiki.com/index.php?title=Openwrt&oldid=1607"