Cross Compile a missing package (fping) for OpenWRT/LEDE Reboot 17.01.04

Sadly in LEDE Reboot 17.01.4 (latest OpenWRT release) the package fping is missing. It was already included in previous releases, but it’s missing in this stable. It’s already readded to the master branch for future releases. But if you need the fping binary now, it is not available in the opkg installer for 17.01.4. So we have to build it manually.

Download SDK

OpenWRT provides for each router target with the firmware downloads also the Software Development Kit with an already prepared Cross Compile Toolchain. It’s of course possible to create own Cross Compile ToolChain explained explained int the Build System Documentation. But the SDK is already available, so i’ll just use it.

You can find the SDK at the end of the Firmware Download Pages, precompiled and ready to use.

In my case i use at the moment a TP-Link WDR4300 (N750) which contains an Atheros AR9344 CPU @560MHz with MIPS 74Kc Instruction Set, 8 MB NAND Flash, 128MB RAM, Serial, 5x GigE Ports, VLAN capable.

The Firmware can be obtained from https://downloads.openwrt.org/releases/17.01.4/targets./ar71xx/generic/. The SDK Download is at the end and named https://downloads.openwrt.org/releases/17.01.4/targets/ar71xx/generic/lede-sdk-17.01.4-ar71xx-generic_gcc-5.4.0_musl-1.1.16.Linux-x86_64.tar.xz.

Prerequisites and Dependencies

To use the SDK, the same tools must be available as when the Cross compile Toolchain is created. Check the instructions from Install Buildsystem Documentation.

For Debian following installation procedure should be enough:

  • Debian 7 Wheezy:

    apt-get install libncurses5-dev zlib1g-dev gawk
  • Debian 8 Jessie:

    sudo apt-get install build-essential libncurses5-dev gawk git subversion libssl-dev gettext unzip zlib1g-dev file python
  • Debian 9.3 Stretch:

    sudo apt install build-essential libncurses5-dev gawk git subversion libssl-dev gettext zlib1g-dev

     

Locate FPing on Master Branch

The FPing packages is available in the master Branch here: https://github.com/openwrt/packages/tree/master/net/fping

Cross Compile

Documentation on Using the SDK to cross compile packages for a specific target without compiling the whole system from scratch.

  • Extract the SDK on your system.

Package Feeds

After decompressing the SDK archive, edit the feeds.conf.default file to add your packages, by default it has LEDE feeds, and you can add your own feeds, local or remote.

For example, you can add all packages you have in a local folder by adding this line

src-link custom /full/path/to/the/local/folder

Load package lists

./scripts/feeds update -a command will refresh the package lists. It will download from github the LEDE feeds, and then it will also download from github or read from your local folder the packages you have loaded in the Package Feeds step above.

cave@laptop:~/openwrt/sdk/lede-sdk-17.01.4-ar71xx-generic_gcc-5.4.0_musl-1.1.16.Linux-x86_64$ ./scripts/feeds update -a
Updating feed 'base' from 'https://git.lede-project.org/source.git;v17.01.4' ...
Cloning into './feeds/base'...
remote: Counting objects: 8382, done.
remote: Compressing objects: 100% (7378/7378), done.
remote: Total 8382 (delta 1034), reused 4265 (delta 360)
Receiving objects: 100% (8382/8382), 10.76 MiB | 3.45 MiB/s, done.
Resolving deltas: 100% (1034/1034), done.
Checking connectivity... done.
Note: checking out '444add156f2a6d92fc15005c5ade2208a978966c'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

git checkout -b new_branch_name

Create index file './feeds/base.index' 
Collecting package info: feeds/base/package/firmware/lantiq/dsl-vrx200-firmware-Collecting package info: done
Collecting target info: done
Updating feed 'packages' from 'https://git.lede-project.org/feed/packages.git^cd5c448758f30868770b9ebf8b656c1a4211a240' ...
Cloning into './feeds/packages'...
remote: Counting objects: 57751, done.
remote: Compressing objects: 100% (25080/25080), done.
remote: Total 57751 (delta 31196), reused 55736 (delta 29454)
Receiving objects: 100% (57751/57751), 13.89 MiB | 3.49 MiB/s, done.
Resolving deltas: 100% (31196/31196), done.
Checking connectivity... done.
Switched to a new branch 'cd5c448758f30868770b9ebf8b656c1a4211a240'
/home/cave/openwrt/sdk/lede-sdk-17.01.4-ar71xx-generic_gcc-5.4.0_musl-1.1.16.Linux-x86_64
Create index file './feeds/packages.index' 
Collecting package info: done
Collecting target info: done
Updating feed 'luci' from 'https://git.lede-project.org/project/luci.git^d3f0685d63c1291359dc5dd089c82fa1e150e0c6' ...
Cloning into './feeds/luci'...
remote: Counting objects: 104191, done.
remote: Compressing objects: 100% (29395/29395), done.
remote: Total 104191 (delta 61227), reused 101632 (delta 59436)
Receiving objects: 100% (104191/104191), 25.29 MiB | 3.85 MiB/s, done.
Resolving deltas: 100% (61227/61227), done.
Checking connectivity... done.
Switched to a new branch 'd3f0685d63c1291359dc5dd089c82fa1e150e0c6'
/home/cave/openwrt/sdk/lede-sdk-17.01.4-ar71xx-generic_gcc-5.4.0_musl-1.1.16.Linux-x86_64
Create index file './feeds/luci.index' 
Collecting package info: done
Collecting target info: done
Updating feed 'routing' from 'https://git.lede-project.org/feed/routing.git^d11075cd40a88602bf4ba2b275f72100ddcb4767' ...
Cloning into './feeds/routing'...
remote: Counting objects: 6622, done.
remote: Compressing objects: 100% (4253/4253), done.
remote: Total 6622 (delta 2668), reused 5194 (delta 1977)
Receiving objects: 100% (6622/6622), 1.60 MiB | 2.59 MiB/s, done.
Resolving deltas: 100% (2668/2668), done.
Checking connectivity... done.
Switched to a new branch 'd11075cd40a88602bf4ba2b275f72100ddcb4767'
/home/cave/openwrt/sdk/lede-sdk-17.01.4-ar71xx-generic_gcc-5.4.0_musl-1.1.16.Linux-x86_64
Create index file './feeds/routing.index' 
Collecting package info: done
Collecting target info: done
Updating feed 'telephony' from 'https://git.lede-project.org/feed/telephony.git^ac6415e61f147a6892fd2785337aec93ddc68fa9' ...
Cloning into './feeds/telephony'...
remote: Counting objects: 6939, done.
remote: Compressing objects: 100% (4836/4836), done.
remote: Total 6939 (delta 3808), reused 3734 (delta 1921)
Receiving objects: 100% (6939/6939), 1.31 MiB | 0 bytes/s, done.
Resolving deltas: 100% (3808/3808), done.
Checking connectivity... done.
Switched to a new branch 'ac6415e61f147a6892fd2785337aec93ddc68fa9'
/home/cave/openwrt/sdk/lede-sdk-17.01.4-ar71xx-generic_gcc-5.4.0_musl-1.1.16.Linux-x86_64
Create index file './feeds/telephony.index' 
Collecting package info: done
Collecting target info: done

I have not used custom src-link in the feeds.conf.default file. I just added the package from master to the downloaded feed.

I added the parts from https://github.com/openwrt/packages/tree/master/net/fping to the path ./feeds/packages/net in the sdk directory.

Select Packages

./scripts/feeds install <packagename> will load the package and its dependencies in the SDK

Then open the SDK menu again, find the package you want to build and select it by pressing “m”, this will also select all the dependencies, and you will see that they are all tagged with “<M>” in the menu.

cave@laptop:~/openwrt/sdk/lede-sdk-17.01.4-ar71xx-generic_gcc-5.4.0_musl-1.1.16.Linux-x86_64$ ./scripts/feeds install fping
Installing package 'fping' from packages

Compile Package

Before we compile, let’s check make menuconfig.

cave@laptop:~/openwrt/sdk/lede-sdk-17.01.4-ar71xx-generic_gcc-5.4.0_musl-1.1.16.Linux-x86_64$ make menuconfig

*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.

Now let’s build the package fping.

cave@laptop:~/openwrt/sdk/lede-sdk-17.01.4-ar71xx-generic_gcc-5.4.0_musl-1.1.16.Linux-x86_64$ make -j7
...
#
# configuration written to .config
#
 make[1] world
 make[2] package/compile
 make[3] -C package/toolchain compile
 make[3] -C package/linux compile
 make[3] -C feeds/packages/net/fping compile
 make[2] package/index
...

Package and Install

In ./bin/packages/mips_24kc/packages in the sdk directory should be the compiled output.

cave@laptop:~/openwrt/sdk/lede-sdk-17.01.4-ar71xx-generic_gcc-5.4.0_musl-1.1.16.Linux-x86_64$ ls -lh ./bin/packages/mips_24kc/packages 
total 28K
-rw-r--r-- 1 cave cave 15K Mar 25 20:47 fping_4.0-2_mips_24kc.ipk
-rw-r--r-- 1 cave cave 719 Mar 25 20:48 Packages
-rw-r--r-- 1 cave cave 473 Mar 25 20:48 Packages.gz
-rw-r--r-- 1 cave cave 822 Mar 25 20:48 Packages.manifest

scp the package to your openwrt device and install with opkg install ./fping_4.0-2_mips_24kc.ipk

root@openwrt:~# opkg install ./fping_4.0-2_mips_24kc.ipk 
Installing fping (4.0-2) to root...
Configuring fping.

 

OpenVPN Routed Client Config for OpenWRT

In this case i want to access a remote network where also an OpenWRT Router is in use as the OpenVPN Client. This is a post in a series of OpenVPN Tutorials on this blog.

Network Topology

                    +------+
                    |      |
                    | IPv4 |
                +---+      +---+
                |   +------+   |
                |              |
+---------------+-+          +-+---------------+
| Router A        |          | Router B        |
|                 |          |                 |
| 192.168.68.0/24 |          | 192.168.34.0/24 |
| 192.168.68.1    |          | 192.168.34.1    |
+-+---------------+          +-^---------------+
  |                            |
  |                            |
+-v-------------+            +-+-------------+
| OpenVPN Tun   |            | OpenVPN Tun   |
| 172.16.0.0/29 |            | 172.16.0.0/29 |
| Server        |            | Client        |
| 172.16.0.1    |            | 172.16.0.2    |
+---------------+            +---------------+

I want to be able to reach net 192.168.34.0/24 from 192.168.68.0/24 and the other direction.

Creation of Client Certificates

See BlogPost Creation of RootCA Certificates. This Blogpost is on the ToDo list.

OpenWRT Config Settings – Routed Client

From /etc/config/openvpn

config openvpn 'cyber'
        option enabled '1'
#Protocol
        option client '1'
        option remote 'vpn.domain.tld 1194'        
        option dev_type 'tun'
        option dev 'cyber_tun0'
        option proto 'udp'        
        option topology 'subnet'
        option resolv_retry 'infinite'        
        option nobind '1'        
        option 'float' '1'
#Routes 
        option pull '1'
#Encryption
        option ca '/etc/ssl/certs/vpn.cavebeat.lan.ca-chain.cert.pem'
        option cert '/etc/ssl/certs/client1.vpn.cavebeat.lan.cert.pem'
        option key '/etc/ssl/private/client1.vpn.cavebeat.lan.key.pem'
        option tls_crypt '/etc/ssl/private/tls-auth.key'
        option cipher 'AES-256-CBC'
        option ncp-ciphers 'AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC'
        option auth 'SHA512'
        option tls_client '1'
        option tls_version_min '1.2'
        option tls_cipher 'TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-ECDH-RSA-WITH-AES-256-GCM-SHA384'
        option remote_cert_tls 'server'
        option verify_x509_name ‘vpn.domain.tld name’
#Logging
        option log '/var/log/openvpn.log'
        option status '/var/log/openvpn-status.log'
        option mute '5'
        option verb '4'
#Connection
        option compress 'lzo'
#Connection Reliability
        option persist_key '1'
        option persist_tun '1'
#Permissions
       option user 'nobody'
       option group 'nogroup'

Client Config

Most of the settings are already explained in the previous post OpenVPN Server Hardening – OpenWRT TUN Device. I’ll cover only the Client specific Settings which are new. For example the client config does not contain a DiffieHellman-Parameter setting.

--client 
  A helper directive designed to simplify the configuration of OpenVPN's client mode.  
--remote host [port] [proto] 
 Remote host name or IP address.  
 On the client, multiple --remote options may be specified for redundancy, each referring to a different OpenVPN server.  
 Specifying multiple --remote options for this purpose is a special case of the more general connection-profile feature.  
 See the <connection> documentation below. 
--resolv-retry n 
  If hostname resolve fails for --remote, retry resolve for n seconds before failing. 
  Set n to "infinite" to retry indefinitely.
--nobind 
  Do not bind to local address and port.  
  The IP stack will allocate a dynamic port for returning packets.  
  Since the value of the dynamic port could not be known in advance by a peer, this option is only suitable for peers which will be initiating connections by using the --remote option. 
--float 
 Allow remote peer to change its IP address and/or port number, such as due to DHCP (this is the default if --remote is not used). 
 --float when specified with --remote
 allows an OpenVPN session to initially connect to a peer at a known 
address, however if packets arrive from a new address and pass all 
authentication tests, the new address will take control of the session. 
 This is useful when you are connecting to a peer which holds a dynamic address such as a dial-in user or DHCP client. 
 Essentially, --float tells OpenVPN to accept authenticated packets from any address, not only the address which was specified in the --remote option. 
--pull 
  This option must be used on a client which is connecting to a multi-client server.  
  It indicates to OpenVPN that it should accept options pushed by the server, provided they are part of the legal set of pushable options (note that the --pull option is implied by --client ). 
  In particular, --pull allows the server to push routes to the client, so you should not use --pull or --client in situations where you don't trust the server to have control over the client's routing table. 
--tls-client 
  Enable TLS and assume client role during TLS handshake. 
--remote-cert-tls client|server 
  Require that peer certificate was signed with an explicit key usage and extended key usage based on RFC3280 TLS rules. 
  This is a useful security option for clients, to ensure that the host they connect to is a designated server.  
  Or the other way around; for a server to verify that only hosts with a client certificate can connect. 
--verify-x509-name name type 
  Accept connections only if a host's X.509 name is equal to name. 
  The remote host must also pass all other tests of verification. 
  Which X.509 name is compared to name depends on the setting of type. 
  type can be "subject" to match the complete subject DN (default), "name" to match a subject RDN or "name-prefix" to match a subject RDN prefix. 
  NOTE: Test against a name prefix only when you are using OpenVPN with a custom CA certificate that is under your control. 
  Never use this option with type "name-prefix" when your client certificates are signed by a third party, such as a commercial web CA. Client Config Dir on Server

CCD – Client Config Dir Settings

Client Config on Server

--client-config-dir dir 
  Specify a directory dir for custom client config files. 
  After a connecting client has been authenticated, OpenVPN will look in this directory for a file having the same name as the client's X509 common name. 
  If a matching file exists, it will be opened and parsed for client-specific configuration options. 
  If no matching file is found, OpenVPN will instead try to open and parse a default file called "DEFAULT", which may be provided but is not required. 
  Note that the configuration files must be readable by the OpenVPN process after it has dropped it's root privileges. 
  This file can specify a fixed IP address for a given client using --ifconfig-push, as well as fixed subnets owned by the client using --iroute.
  One of the useful properties of this option is that it allows client configuration files to be conveniently created, edited, or removed while the server is live, without needing to restart the server. 
  The following options are legal in a client-specific context: --push, --push-reset, --push-remove, --iroute, --ifconfig-push, and --config.
--ccd-exclusive 
  Require, as a condition of authentication, that a connecting client has a --client-config-dir file. 
On your server check the option client_config_dir ‘/etc/openvpn/ccd/’. In the defined ccd directory place a file for each client. The file must be named according to the X509 common name of the client certificate.
root@openwrt_server:~# cd /etc/openvpn/ccd/
root@openwrt_server:/etc/openvpn/ccd# ls
client1.vpn.cavebeat.lan
root@openwrt_server:/etc/openvpn/ccd# cat client1.vpn.cavebeat.lan 
ifconfig-push 172.16.10.2 255.255.255.248 
iroute 192.168.34.0 255.255.255.0

Client Config File

ifconfig-push tells the client the IP address and the netmask. iroute routes the packet from openvpn to the client in combination with route on the server.

--ifconfig-push local remote-netmask [alias]
  Push virtual IP endpoints for client tunnel, overriding the --ifconfig-pool dynamic allocation.
  The parameters local and remote-netmask are set according to the --ifconfig directive which you want to execute on the client machine to configure the remote end of the tunnel. 
  Note that the parameters local and remote-netmask are from the perspective of the client, not the server. 
  They may be DNS names rather than IP addresses, in which case they will be resolved on the server at the time of client connection.
--iroute network [netmask] 
  Generate an internal route to a specific client. 
  The netmask parameter, if omitted, defaults to 255.255.255.255. 
  This directive can be used to route a fixed subnet from the server to a particular client, regardless of where the client is connecting from.
  Remember that you must also add the route to the system routing table as well (such as by using the --route directive).
  The reason why two routes are needed is that the --route directive routes the packet from the kernel to OpenVPN. 
  Once in OpenVPN, the --iroute directive routes to the specific client. 
  This option must be specified either in a client instance config file using --client-config-dir or dynamically generated using a --client-connect script. 
  The --iroute directive also has an important interaction with --push "route ...". 
  --iroute essentially defines a subnet which is owned by a particular client (we will call this client A). 
  If you would like other clients to be able to reach A's subnet, you can use --push "route ..." together with --client-to-client to effect this.
  In order for all clients to see A's subnet, OpenVPN must push this route to all clients EXCEPT for A, since the subnet is already owned by A.
  OpenVPN accomplishes this by not not pushing a route to a client if it matches one of the client's iroutes. 

Route Settings on Server

On the server two route settings must be set. The first one is to tell the Server Router where to send packets for the client network. The push route is to tell the clients where to send packets to the server network.

option route '192.168.34.0 255.255.255.0 172.16.10.1'
list push 'route 192.168.68.0 255.255.255.0'

Firewall

For more details on this part, have also a look at my other VPN Client Tutorial.

Create Unmanaged Interface

Your /etc/config/network should contain now

root@openwrt:~# cat /etc/config/network 
config interface 'cyber_vpn'
 option proto 'none'
 option ifname 'cyber_tun0'
 option auto '1'

Firewal Zones

Your /etc/config/firewall should contain now following parts:

cat /etc/config/firewall 
config zone
 option name 'cyber_vpn'
 option input 'ACCEPT'
 option output 'ACCEPT'
 option network 'cyber_vpn'
 option forward 'ACCEPT'

config forwarding
 option dest 'lan'
 option src 'cyber_vpn'

config forwarding
 option dest 'cyber_vpn'
 option src 'lan'

Routing Table and Ping Checks

These routes should show up on Client and Server to be reach able from both ways.

Client

root@openwrt_client:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.10.0 0.0.0.0 255.255.255.248 U 0 0 0 cyber_tun0
192.168.68.0 172.16.10.1 255.255.255.0 UG 0 0 0 cyber_tun0
192.168.34.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan

Ping the Server Router from the Client Router

root@openwrt_client:~# ping -c 2 192.168.68.1
PING 192.168.96.1 (192.168.34.1): 56 data bytes
64 bytes from 192.168.34.1: seq=0 ttl=64 time=45.757 ms
64 bytes from 192.168.34.1: seq=1 ttl=64 time=37.271 ms
--- 192.168.34.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 37.271/41.514/45.757 ms

Ping the remote and local OpenVPN IP

root@openwrt_client:~# ping -c 2 172.16.10.1
PING 172.16.10.1 (172.16.10.1): 56 data bytes
64 bytes from 172.16.10.1: seq=0 ttl=64 time=49.015 ms
64 bytes from 172.16.10.1: seq=1 ttl=64 time=55.041 ms
--- 172.16.10.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 49.015/52.028/55.041 ms

root@openwrt_client:~# ping -c 2 172.16.10.2
PING 172.16.10.2 (172.16.10.2): 56 data bytes
64 bytes from 172.16.10.2: seq=0 ttl=64 time=0.289 ms
64 bytes from 172.16.10.2: seq=1 ttl=64 time=0.277 ms
--- 172.16.10.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.277/0.283/0.289 ms

Server

root@openwrt_server:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.10.0 0.0.0.0 255.255.255.248 U 0 0 0 cyber_tun0
192.168.34.0 172.16.10.1 255.255.255.0 UG 0 0 0 cyber_tun0
192.168.68.0 0.0.0.0 255.255.255.0 U 0 0 0 br-lan

Ping the Client Router from the Server Router

root@openwrt:~# ping -c 2 192.168.34.1 
PING 192.168.96.1 (192.168.68.1): 56 data bytes
64 bytes from 192.168.68.1: seq=0 ttl=64 time=43.559 ms
64 bytes from 192.168.68.1: seq=1 ttl=64 time=34.661 ms
--- 192.168.68.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 34.661/39.110/43.559 ms

Ping the local and remote OpenVPN IP

root@openwrt:~# ping -c 2 172.16.10.1
PING 172.16.10.1 (172.16.10.1): 56 data bytes
64 bytes from 172.16.10.1: seq=0 ttl=64 time=0.437 ms
64 bytes from 172.16.10.1: seq=1 ttl=64 time=0.282 ms
--- 172.16.10.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.282/0.359/0.437 ms

root@openwrt_server:~# ping -c 2 172.16.10.2
PING 172.16.10.2 (172.16.10.2): 56 data bytes
64 bytes from 172.16.10.2: seq=0 ttl=64 time=42.780 ms
64 bytes from 172.16.10.2: seq=1 ttl=64 time=33.573 ms
--- 172.16.10.2 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 33.573/38.176/42.780 ms

 

who we are and what do we want

Manifesto – who we are and what do we want

Manifesto - who we are and what do we want

To begin with, we want everything.

Our aim is to reclaim spaces on the Internet where we can discuss and work on two levels: on the one hand, the right to and need for free communication, privacy, anonymity and access to digital resources; on the other, social projects linked to reality and struggles.

Setting up an independent server seems to us to be a good point to start and reach our goals.

We believe that communication must be free - and for free - and, therefore, universally accessible.

We try to accomplish all this by offering internet services (web sites, e-mail, mailing lists, chats, instant messaging, anonymous remailing, blogs, newsletters, and more) to either individuals and collective projects agreeing to our same aims and sharing our ideals, using our best skills and knowledges to defend users privacy.

Standing outside the commercial attitude of payed services and web spaces, we happily welcome those unresting towards cultural and media censorship, towards the globalized imaginery being prepared, packed and sold us every day.

The services we provide are not intended for (directly or indirectly) commercial activities, for use by organized religion or political parties, or, in short, by anyone who already has means and resources to spread widely its ideas, or who use the concept of representation and (explicit or implicit) delegation in its day-to-day relationships and projects.

The right to and need for privacy and anonymity must be respected.

We guarantee that we keep no logs, that we won’t ask for personal data to grant access to any of our services, and that we will do everything we can to keep our anonymous remailer, anonymizer and everything else that ensures the privacy and confidentiality of your communications running and safe.

Knowledge and resources grow through sharing. That is why we encourage the systematic, organized and completely free distribution of cultural material, self-productions and documentation, and why we fight against traditional copyright and support the adoption free and open-source software and licenses.

We called ourselves Inventati because we strive to find ways to translate in the digital world issues that are part of struggles and their organizing, overcoming the limits and constraints of reality. Ie: a plenum can be made permanent and continuous through the use of a mailing list.

We called ourselves Autistici, instead, for the passion we have for understanding the technical tools and for exposing the politics implicit in the digital world; even if software is created in a virtual world it doesn’t mean it doesn’t have a political impact on reality.

Starting from the technical tools we use we came to develop a clear array of political stances, crucial to both cyber and material world and lives: privacy, anonymity, free sharing of knowledge just to mention a few.

We believe that media and communication should not be the exclusive domain of information professionals. We believe in the value of self-management: this is why we have no sponsors or funding of any kind, apart from voluntary subscriptions by those who believe that our project is important and must survive. None of us earns a cent from this project (in fact, quite the opposite).

We share collectively any decision about technical and political aspects of our servers and projects. We discuss everything through the use of mailing lists, so that all of our debates and process is available and accessible to any single person participating in the collective.

We have no coordinator, and no spokesperson, and decisions are not reached by voting.

Autism with invention generates sharing

autistici / inventati 2002

OpenVPN Server Hardening – OpenWRT TUN device

This is a tutorial for a hardened OpenVPN Server with all important settings in a paranoid TLS based setup. I have read through different other tutorials, more or less good tutorials, but most of them lacked serious settings or had just set them wrong. So i decided to read through the complete ManPage from OpenVPN to find all the important settings by myself.
This Tutorial covers OpenVPN Version v2.4 (with compatibility to v2.3.3 clients). The next OpenVPN will cover the Client Settings for different scenarios.

Network Topology

My Home Router is on the LAN Network 192.168.68.0/24 and i want to access it from other devices from different networks.

Firewall Rule

First we need to make the OpenVPN available on the WAN Port. For this we add a Firewall Rule to /etc/config/firewall.

config 'rule'
 option 'name' 'openvpn-udp'
 option 'src' 'wan' 
 option 'target' 'ACCEPT'
 option 'proto' 'udp' 
 option 'dest_port' '1194'

Generation of Certificates

Import From Future Blog Post to create your own Certificate Authority with a Root CA, different Intermediate CA’s, and Server + Client Certificates.

For this tutorial we need following Certificate and Key files:

  • RootCA (CA)
  • Intermediate CA (ICA)
  • Server Certificate
  • Server Cert & Key (+ Client Cert & Keys for Testing)
  • CRL File
  • TLS-Auth Key
  • Diffie Hellman parameters

Keysize

Regarding an ENISA – Algorithms, Key Sizes and Parameters Report keys specified to be at least ten years in use, RSA keys of 3072 bits or more are recommended.

Creation of 4096 bit RSA keys is recommended by me.

https://community.openvpn.net/openvpn/wiki/Hardening#X.509keysize

CA-Chain File

The RootCA and the ICA Certificates should be bundled into a ca-chain.cert file.

cat RootCa.pem IntermediateCA.pem > ca-chain.pem

TLS-Auth Key

Generate TLS-Auth key 
openvpn --genkey --secret openvpn/tls-auth.key
This key is available on all devices and should be kept secret.

DH Parameters

Generating DH keys takes substantial amounts of time.
openssl dhparam -out dhparam4096.pem 4096
 The DH Parameters should exceed your Server Certificate size.
  • Server Certificate 2048 bit => DH 4096 bit
  • Server Certificate 4096 bit => DH 8192 bit

Your Server Certificate should have at least 4096 bit in size.

Subnet

The VPN will create a subnet. You should choose a Net which will not overlap with any other Subnet you will possibly encounter. Stay away from 192.168.0.0/24, 192.168.0.0/24 or 10.0.0.0/24 as these nets are often seen to be used for default LAN ranges in home routers.

Multiclient

My assumption was for this tutorial a /29 net. For example any CIDR Net from a private “Class B” Address Range in between 172.16.0.0–172.31.255.255 can be choosen. Class B has not been used that often, at least it seems to me. Just try to pick a “random” net private, which has a rare chance to be unused by others.

CIDR Net Notation:  172.16.10.0/29  
Subnet Mask:        255.255.255.248 
Broadcast:          172.16.10.7
CIDR Address Range: 172.16.10.0 - 172.16.10.7 
Useable Adresses:   6 (1 Server + 5 Clients) 
Server:             172.16.10.1
Clients:            172.16.10.2 - 172.16.10.6

Point-To-Point

If the VPN is only planned for a Point-To-Point connection between two Routers or for a single Client, a /30 Net should be chosen instead. It is still a MultiClient Net, but with only two Points.

CIDR Net Notation:  172.18.25.64/30  
Subnet Mask:        255.255.255.252 
Broadcast:          172.18.25.67
CIDR Address Range: 172.18.25.64 - 172.18.25.67
Useable Adresses:   2 (1 Server + 1 Client) 
Server:             172.18.25.65
Client:             172.18.25.66

OpenWRT OpenVPN Settings

OpenVPN config for a TLS based and hardened Setup in /etc/config/openvpn
config openvpn 'cyber'
        option enabled '1'
#Protocol
        option dev_type 'tun'
        option dev 'cyber_tun0'
        option topology 'subnet'
        option proto 'udp'
        option port '1194'

#Routes 
        option server '172.16.10.0 255.255.255.248'
        option ifconfig '172.16.10.1 255.255.255.248'
        list push 'route 192.168.100.0 255.255.255.0'

#Client Config
        option ccd_exclusive '1'
        option client_config_dir '/etc/openvpn/ccd/'
        option max_clients '5'
        option client_to_client '1' 

#Encryption
        option ca '/etc/ssl/certs/vpn.cavebeat.lan.ca-chain.cert.pem'
        option cert '/etc/ssl/certs/ptree.vpn.cavebeat.lan.cert.pem'
        option key '/etc/ssl/private/ptree.vpn.cavebeat.lan.key.pem'
        option dh '/etc/ssl/dh4096.pem'
        option tls_crypt '/etc/ssl/tls-auth.key'
        option cipher 'AES-256-CBC'
        option ncp_ciphers 'AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC'
        option auth 'SHA512'
        option tls_server '1'
        option tls_version_min '1.2'
        option tls_cipher 'TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256'
        option reneg_sec '1800'
        option reneg_bytes '64000000'
        option remote_cert_tls 'client'
#        option verify_client_cert '1'

#Logging
        option log_append '/var/log/openvpn/openvpn.log'
        option status '/var/log/openvpn-status.log'
        option mute '5'
        option verb '4'

#Connection
        option keepalive '10 60'
        option compress 'lzo'
        option script_security '1'

#Connection Reliability
        option persist_key '1'
        option persist_tun '1'

#Permissions
       option  user 'nobody'
       option group 'nogroup'

The parameter verify_client_cert / –verify-client-cert is new in OpenVPN 2.4 and is replacing the deprecated parameter –client-cert-not-required. For more information on deprecated parameters check Deprecated OpenVPN Settings

The default value should require to verify the client cert given to the server. I have placed a PullRequest with a change for OpenWRT to add this setting.

Description of used Settings and Parameters

option enabled '1'

Protocol

option dev_type 'tun'
--dev-type device-type 
  Which device type are we using? device-type should be tun (OSI Layer 3) or tap (OSI Layer 2). 
  Use this option only if the TUN/TAP device used with --dev does not begin with tun or tap. 
option dev 'tun1'
--dev tunX | tapX | null
  tun devices encapsulate IPv4 or IPv6 (OSI Layer 3) while tap devices encapsulate Ethernet 802.3 (OSI Layer 2). 
option topology 'subnet'
--topology mode 
  Configure virtual addressing topology when running in --dev tun mode. 
  subnet -- Use a subnet rather than a point-to-point topology by configuring the tun interface with a local IP address and subnet mask, similar to the topology used in --dev tap and ethernet bridging mode. 
  This mode allocates a single IP address per connecting client and works on Windows as well. 
  Note: Using --topology subnet changes the interpretation of the arguments of --ifconfig to mean "address netmask", no longer "local remote". 

Routes

option server '172.16.10.0 255.255.255.248'
--server network netmask ['nopool'] 
  A helper directive designed to simplify the configuration of OpenVPN's server mode.  
  This directive will set up an OpenVPN server which will allocate addresses to clients out of the given network/netmask. 
  The server itself will take the ".1" address of the given network for use as the server-side endpoint of the local TUN/TAP interface.
option ifconfig '172.16.10.1 255.255.255.248'
--ifconfig l rn
  Set TUN/TAP adapter parameters. l is the IP address of the local VPN endpoint. 
  For TAP devices, or TUN devices used with --topology subnet,rn is the subnet mask of the virtual network segment which is being created or connected to. 
  For TAP devices, which provide the ability to create virtual ethernet segments, or TUN devices in --topology subnet mode (which create virtual "multipoint networks"), --ifconfig is used to set an IP address and subnet mask just as a physical ethernet adapter would be similarly configured.
list push 'route 192.168.100.0 255.255.255.0'
--push option 
  Push a config file option back to the client for remote execution.  
  Note that option must be enclosed in double quotes ("").

Client Config

option client_config_dir '/etc/openvpn/ccd/'
--client-config-dir dir 
  Specify a directory dir for custom client config files.  
  After a connecting client has been authenticated, OpenVPN will look in this directory for a file having the same name as the client's X509 common name.  
  If a matching file exists, it will be opened and parsed for client-specific configuration options. 
  If no matching file is found, OpenVPN will instead try to open and parse a default file called "DEFAULT", which may be provided but is not required. 
  Note that the configuration files must be readable by the OpenVPN process after it has dropped it's root privileges. 
option ccd_exclusive '1'
--ccd-exclusive 
  Require, as a condition of authentication, that a connecting client has a --client-config-dir file. 
option max_clients '5'
--max-clients n 
  Limit server to a maximum of n concurrent clients.
option client_to_client '0' 
--client-to-client 
  Because the OpenVPN server mode handles multiple clients through a single tun or tap interface, it is effectively a router.  
  The --client-to-client flag tells OpenVPN to internally route client-to-client traffic rather than pushing all client-originating traffic to the TUN/TAP interface. 

Encryption

option ca '/etc/ssl/certs/vpn.cavebeat.lan.ca-chain.cert.pem'
--ca file 
  Certificate authority (CA) file in .pem format, also referred to as the root certificate. 
option cert '/etc/ssl/certs/ptree.vpn.cavebeat.lan.cert.pem'
--cert file 
  Local peer's signed certificate in .pem format -- must be signed by a certificate authority whose certificate is in --ca file. 
  Each peer in an OpenVPN link running in TLS mode should have its own certificate and private key file.  
  In addition, each certificate should have been signed by the key of a certificate authority whose public key resides in the --ca certificate authority file. 
option key '/etc/ssl/private/ptree.vpn.cavebeat.lan.key.pem'
--key file 
  Local peer's private key in .pem format. 
option dh '/etc/ssl/dh4096.pem'
--dh file 
  File containing Diffie Hellman parameters in .pem format (required for --tls-server only). 
option tls_crypt '/etc/ssl/tls-auth.key'
--tls-auth file [direction] 
  Add an additional layer of HMAC authentication on top of the TLS control channel to mitigate DoS attacks and attacks on the TLS stack. 
  In a nutshell, --tls-auth enables a kind of "HMAC firewall" on OpenVPN's TCP/UDP port, where TLS control channel packets bearing an incorrect HMAC signature can be dropped immediately without response. 
  file (required) is a file in OpenVPN static key format which can be generated by --genkey
  
  Use --tls-crypt instead if you want to use the key file to not only authenticate, but also encrypt the TLS control channel. 
  
--tls-crypt keyfile
  Encrypt and authenticate all control channel packets with the key from keyfile. (See --tls-auth for more background.) 
  Encrypting (and authenticating) control channel packets: 
  + provides more privacy by hiding the certificate used for the TLS connection, 
  + makes it harder to identify OpenVPN traffic as such, 
  + provides "poor-man's" post-quantum security, against attackers who will never know the pre-shared key (i.e. no forward secrecy). 
  In contrast to --tls-auth, --tls-crypt does *not* require the user to set --key-direction
option cipher 'AES-256-CBC' 
  --cipher alg  
  Encrypt data channel packets with cipher algorithm alg.
  https://community.openvpn.net/openvpn/wiki/SWEET32#a1.Changetoalargerblockcipher  Of the currently supported ciphers, OpenVPN currently recommends using AES-256-CBC or AES-128-CBC.  
  OpenVPN 2.4 and newer will also support GCM.  
  For 2.4+, we recommend using AES-256-GCM or AES-128-GCM. 
option ncp-ciphers 'AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC'
--ncp-ciphers cipher_list 
  Restrict the allowed ciphers to be negotiated to the ciphers in cipher_list. 
  cipher_list is a colon-separated list of ciphers, and defaults to "AES-256-GCM:AES-128-GCM".
  For servers, the first cipher from cipher_list will be pushed to clients that support cipher negotiation. 
  If both peers support and do not disable NCP, the negotiated cipher will override the cipher specified by --cipher
option auth 'SHA512'
--auth alg 
  Authenticate data channel packets and (if enabled) tls-auth control channel packets with HMAC using message digest algorithm alg. 
  If an AEAD cipher mode (e.g. GCM) is chosen, the specified --auth algorithm is ignored for the data channel, and the authentication method of the AEAD cipher is used instead.  
  Note that alg still specifies the digest used for tls-auth. 
option tls_server '1'
--tls-server 
  Enable TLS and assume server role during TLS handshake. 

option tls_version_min '1.2'
--tls-version-min version ['or-highest'] 
  Sets the minimum TLS version we will accept from the peer (default is "1.0"). 
  Examples for version include "1.0", "1.1", or "1.2".
  https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-version-min
  Since OpenVPN 2.3.3, the --tls-version-min option is available to enforce a minimum TLS version. 
  Hardened setups should set --tls-version-min to 1.2 if possible.
  But be aware that setting tls-version-min to 1.2 will make it impossible to connect for pre-2.3.3 clients
option tls_cipher 'TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256'
--tls-cipher l 
  A list l of allowable TLS ciphers delimited by a colon (":"). 
  This setting can be used to ensure that certain cipher suites are used (or not used) for the TLS connection.
  You should use a DHE cipher-suite as well for forward-secrecy. 
  https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-cipher
  To use ECDH(E) or ECDSA cipher-suites, both client and server must be OpenVPN 2.4.0 or newer.
option reneg_sec '3600'
--reneg-sec n 
  Renegotiate data channel key after n seconds (default=3600). 
option reneg_bytes '64000000'
--reneg-bytes n 
  Renegotiate data channel key after n bytes sent or received.
option remote_cert_tls 'server'
--remote-cert-tls client|server 
  Require that peer certificate was signed with an explicit key usage and extended key usage based on RFC3280 TLS rules. 
option verify_client_cert '1'
--verify-client-cert none|optional|require 
  Specify whether the client is required to supply a valid certificate. 
  require : this is the default option. A client is required to present a certificate, otherwise VPN access is refused. 
option crl_verify ''etc/ssl/crl.pem'
--crl-verify crl ['dir'] 
  Check peer certificate against the file crl in PEM format. 
  A CRL (certificate revocation list) is used when a particular key is compromised but when the overall PKI is still intact. 
  Note: As the crl file (or directory) is read every time a peer connects, if you are dropping root privileges with --user, make sure that this user has sufficient privileges to read the file. 

Logging

option log_append '/var/log/openvpn/openvpn.log'
--log-append file 
  Append logging messages to file. If file does not exist, it will be created. 
  This option behaves exactly like --log except that it appends to rather than truncating the log file. 
--log file 
  Output logging messages to file, including output to stdout/stderr which is generated by called scripts. 
  If file already exists it will be truncated. 
option status '/var/log/openvpn-status.log'
--status file [n] 
  Write operational status to file every n seconds. 
option mute '4'
--mute n 
  Log at most n consecutive messages in the same category. 
  This is useful to limit repetitive logging of similar message types. 
option verb '4'
--verb n 
  Set output verbosity to n (default=1).  
  Each level shows all info from the previous levels. 
  Level 3 is recommended if you want a good summary of what's happening without being swamped by output. 
  - 0 -- No output except fatal errors. 
  - 1 to 4 -- Normal usage range. 

Connection

option keepalive '10 60'
--keepalive interval timeout
  A helper directive designed to simplify the expression of --ping and --ping-restart.
  This option can be used on both client and server side, but it is in enough to add this on the server side as it will push appropriate --ping and --ping-restart options to the client. 
  --ping n 
    Ping remote over the TCP/UDP control channel if no packets have been sent for at least n seconds
  --ping-restart n
    Restart after n seconds pass without reception of a ping or other packet from remote. 
    In server mode, --ping-restart, --inactive, or any other type of internally generated signal will always be applied to individual client instance objects, never to whole server itself. 
    Note also in server mode that any internally generated signal which would normally cause a restart, will cause the deletion of the client instance object instead. 
option compress 'lzo'
--compress [algorithm] Enable a compression algorithm. 
  The algorithm parameter may be "lzo", "lz4", or empty.  
  LZO and LZ4 are different compression algorithms, with LZ4 generally offering the best performance with least CPU usage. 
  For backwards compatibility with OpenVPN versions before v2.4, use "lzo" (which is identical to the older option "--comp-lzo yes"). 
option script_security '1'
--script-security level
  This directive offers policy-level control over OpenVPN's usage of external programs and scripts. 
  Lower level values are more restrictive, higher values are more permissive. 
  Settings for level:
  0 -- Strictly no calling of external programs.
  1 -- (Default) Only call built-in executables such as ifconfig, ip, route, or netsh. 
  2 -- Allow calling of built-in executables and user-defined scripts. 
  3 -- Allow passwords to be passed to scripts via environmental variables (potentially unsafe).

Connection Reliability

option persist_key '1'
--persist-key 
  Don't re-read key files across SIGUSR1 or --ping-restart. 
  This option can be combined with --user nobody to allow restarts triggered by the SIGUSR1 signal. 
  Normally if you drop root privileges in OpenVPN, the daemon cannot be restarted since it will now be unable to re-read protected key files. 
option persist_tun '1'
--persist-tun 
  Don't close and reopen TUN/TAP device or run up/down scripts across SIGUSR1 or --ping-restart restarts. 

Permissions

option  user 'nobody'
--user user 
  Change the user ID of the OpenVPN process to user after initialization, dropping privileges in the process. 
option group 'nogroup'
--group group 
  Similar to the --user option, this option changes the group ID of the OpenVPN process to group after initialization. 

reset password for matrix/synapse accounts

Sadly Matrix/Synapse still lacks a AdminUI (issue #2032) but Users still tend to forget their passwords.

Create Hash

Log on to your matrix account and download the hash_password script. Make it executeable and run it to create a new hash for a password.

root@matrix:~# ./hash_password -p trustno1 
$2b$12$TDvI.fxdmTDA64jO657mm.SFzoq6Xs4Fvf2XWQl7G8otiPrcr6s5m

Backup Database

Go to your location where your sqlite Database is located, stop the synapse server and make a backup first.

root@matrix:~# cd /var/lib/matrix-synapse
root@matrix:/var/lib/matrix-synapse# service matrix-synapse stop
root@matrix:/var/lib/matrix-synapse# cp homeserver.db homeserver.db.bkp

Set Password

Log in to your sqlite3 database.

root@matrix:/var/lib/matrix-synapse# sqlite3 homeserver.db

Have a Check of the already created users.

sqlite> select * from users;

Set the Hash for the User and exit.

sqlite> UPDATE users SET password_hash='$2b$12$TDvI.fxdmTDA64jO657mm.SFzoq6Xs4Fvf2XWQl7G8otiPrcr6s5m' 
  WHERE name='@foo:matrix.cavebeat.org';
sqlite> .exit

Restart Matrix

root@matrix:/var/lib/matrix-synapse# service matrix-synapse restart

That’s it, should be working fine.

 

VPN tunnel as a WAN Interface on OpenWRT/LEDE Router

There exists a seemingly endless number of VPN Providers with different kinds of quality, features and trustworthiness. They are not perfect and can not be considered as an anonymizer for everything, but they increase the privacy at least for specific use cases.

  • untrusted hostile network environment
  • public WiFi
  • P2P Torrent Traffic
  • ISP Data Retention
  • Censorship Circumvention

You should know when it’s time to use a VPN and when not. Depending on your threat-model this can secure your traffic.

In my case the Service Provider premiumize.me has added also a VPN Service. Though i usually use them for other services. But if it is in the basket, why not use it.

Other providers are for example, without any order:

  • https://frootvpn.com/
  • https://ipredator.se/
  • https://www.privatetunnel.com/
  • https://www.privateinternetaccess.com/
  • and many other more…

There exists a nice overview why you should not use or rely on a VPN service for anonymization. https://gist.github.com/joepie91/5a9909939e6ce7d09e29#dont-use-vpn-services

In this tutorial i’ll show how to run an OpenVPN client on your Router with OpenWRT. This makes it possible to have the connection always on, and reuse it in your network when u need it.

Install openvpn on OpenWRT

Following packages need to be installed:

 opkg update ; opkg install openvpn-openssl luci-app-openvpn openssl-util

The Service/OpenVPN section should become available in the LuCi Webinterface.

OpenVPN Luci Settings in OpenWRT

root@openwrt:~# openvpn --version
OpenVPN 2.4.4 mips-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
library versions: OpenSSL 1.0.2n 7 Dec 2017, LZO 2.10
Originally developed by James Yonan
Copyright (C) 2002-2017 OpenVPN Technologies, Inc. <sales@openvpn.net>

Obtaining VPN Provider Settings

First we need the Settings for our Provider to connect with OpenVPN. Premiumize hands out client settings and their CA.crt file.

Client Settings – .ovpn file

Premiumize.me – Netherlands.ovpn

remote vpn-nl.premiumize.me
verify-x509-name CN=vpn-nl.premiumize.me
auth-user-pass
client
dev tun
proto udp
cipher AES-256-CBC
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
<ca>
-----BEGIN CERTIFICATE-----
MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVow
PzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRcwFQYDVQQD
Ew5EU1QgUm9vdCBDQSBYMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AN+v6ZdQCINXtMxiZfaQguzH0yxrMMpb7NnDfcdAwRgUi+DoM3ZJKuM/IUmTrE4O
rz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m67XMuegwGMoOifooUMM0RoOEq
OLl5CjH9UL2AZd+3UWODyOKIYepLYYHsUmu5ouJLGiifSKOeDNoJjj4XLh7dIN9b
xiqKqy69cK3FCxolkHRyxXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOMxt+/yUFw
7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40dutolucbY38EVAjqr2m7xPi71XAicPNaD
aeQQmxkqtilX4+U9m5/wAl0CAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNV
HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMSnsaR7LHH62+FLkHX/xBVghYkQMA0GCSqG
SIb3DQEBBQUAA4IBAQCjGiybFwBcqR7uKGY3Or+Dxz9LwwmglSBd49lZRNI+DT69
ikugdB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX+5v3gTt23ADq1cEmv8uXr
AvHRAosZy5Q6XkjEGB5YGV8eAlrwDPGxrancWYaLbumR9YbK+rlmM6pZW87ipxZz
R8srzJmwN0jP41ZL9c8PDHIyh8bwRLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5
JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubSfZGL+T0yjWW06XyxV3bqxbYo
Ob8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ
-----END CERTIFICATE-----
</ca>
verb 3
reneg-sec 0

Manually test tunnel with .ovpn file

The easiest way is to use the .ovpn file directly. SCP it to your router and place it under /etc/openvpn/nl.ovpn

root@openwrt:/etc/openvpn# ls
nl.ovpn

It’s easiest possible to test the .ovpn file directly.

root@openwrt:/etc/openvpn# openvpn nl.ovpn 
Sat Feb 17 21:10:36 2018 OpenVPN 2.4.4 mips-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Sat Feb 17 21:10:36 2018 library versions: OpenSSL 1.0.2n 7 Dec 2017, LZO 2.10
Enter Auth Username:
Enter Auth Password:
...
...
...
Sat Feb 10 19:25:15 2018 Initialization Sequence Completed

When “Initialization Sequence Completed” is printed to the screen, the device /dev/tun0 should be available and the tunnel up. Test it with ifconfig, ping and traceroute.

root@openwrt:~# ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
 inet addr:10.8.0.29 P-t-P:10.8.0.29 Mask:255.255.0.0
 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
 RX packets:1 errors:0 dropped:0 overruns:0 frame:0
 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:100 
 RX bytes:48 (48.0 B) TX bytes:0 (0.0 B)

root@openwrt:~# ping -I tun0 blog.cavebeat.org
PING blog.cavebeat.org (31.220.43.64): 56 data bytes
64 bytes from 31.220.43.64: seq=0 ttl=58 time=59.759 ms
64 bytes from 31.220.43.64: seq=1 ttl=58 time=59.055 ms
64 bytes from 31.220.43.64: seq=2 ttl=58 time=59.755 ms
64 bytes from 31.220.43.64: seq=3 ttl=58 time=59.384 ms
^C
--- blog.cavebeat.org ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 59.055/59.488/59.759 ms

OpenWRT Settings with .ovpn

One can use the .ovpn directly in the OpenWRT Settings as an additional section in /etc/config/openvpn.

config openvpn 'nl_vpn' 
 option enabled '1' 
 option config "/etc/openvpn/nl.ovpn"

OpenWRT Settings with UCI/LUCI

Options from the .ovpn file are similar to VPN-Settings in OpenWRT. Though they are not exactly the same naming convention.

.ovpn OpenWRT
remote vpn-nl.premiumize.me list remote ‘vpn-nl.premiumize.me 1194’
verify-x509-name CN=vpn-nl.premiumize.me option verify_x509_name ‘vpn-nl.premiumize.me name’
auth-user-pass option auth_user_pass ‘/etc/openvpn/prem_userpass.txt’
client option client ‘1’
dev tun option dev ‘tun0’
proto udp option proto ‘udp’
cipher AES-256-CBC option cipher ‘aes-256-cbc’
resolv-retry infinite option resolv_retry ‘infinite’
nobind option nobind ‘1’
persist-key option persist_key ‘1’
persist-tun option persist_tun ‘1’
mute-replay-warnings option mute_replay_warnings ‘1’
verb 3 option verb ‘3’
reneg-sec 0 option reneg_sec ‘0’
ca option ca ‘/etc/openvpn/nl_prem_ca.crt’
option auth ‘sha1’
option enabled ‘1’

OpenVPN Setting in /etc/config/openvpn

root@openwrt:~# cat /etc/config/openvpn

config openvpn 'nl_prem'
 option verify_x509_name 'vpn-nl.premiumize.me name'
 list remote 'vpn-nl.premiumize.me 1194'
 option auth_user_pass '/etc/openvpn/prem_userpass.txt'
 option client '1'
 option dev 'tun0'
 option proto 'udp'
 option auth 'sha256'
 option cipher 'aes-256-cbc'
 option resolv_retry 'infinite'
 option nobind '1'
 option persist_key '1'
 option persist_tun '1'
 option ca '/etc/openvpn/nl_prem_ca.crt'
 option verb '3'
 option reneg_sec '0'
 option route_nopull '1'
 option mute_replay_warnings '1'
 option enabled '1'

It’s possible to add the settings also in Luci, but it’s easier to avoid this and add the settings manually via command line at the end of the file /etc/config/openvpn.

User Pass File

The setting auth_user_pass tells to use a Customer ID and PIN for authentication from a file.

I have created a file in /etc/openvpn and added in line 1 my Customer ID and in line 2 my Premiumize PIN.

root@openwrt:~# cat /etc/config/openvpn | grep auth_user_pass
 option auth_user_pass '/etc/openvpn/prem_userpass.txt'
root@openwrt:~# cat /etc/openvpn/prem_userpass.txt
1234567890
trustno1

CA – Certificate Authority

I have placed the ca parts from the nl.ovpn file under /etc/openvpn.

root@openwrt:/etc/openvpn# cat nl_prem_ca.crt 
<ca>
-----BEGIN CERTIFICATE-----
MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/
...
...
...
Ob8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ
-----END CERTIFICATE-----
</ca>

Ignoring redirect-gateway

If you are running OpenVPN as a client, and the server you use is using push “redirect-gateway” then your client redirects all internet traffic over the VPN. Sometimes clients do not want this, but they can not change the server’s configuration. In our case, we just want the OpenVPN Tunnel Available as an additional WAN Interface and not push just everything into it always.

I myself prefer to set the client option “option route_nopull ‘1’” and care and control the routing myself.

.ovpn OpenWRT
route-nopull option route_nopull ‘1’
--route-nopull
 When used with --client or --pull, accept options pushed by server EXCEPT for routes and dhcp options like DNS servers.
 When used on the client, this option effectively bars the server from adding routes to the client's routing table, however note that this option still allows the server to set the TCP/IP properties of the client's TUN/TAP interface.

from the OpenVPN Manpage about route-nopull

Settings in LUCI

In Luci it should be also available.

 

Create VPN Interface

In the Section Network/Interface create a new Interface with Protocol Unmanaged.

Interface Configuration

root@openwrt:~# cat /etc/config/network
config interface 'nl_vpn'
 option proto 'none'
 option ifname 'tun0'
 option auto '1'

Protocol: unmanaged/none

Bring Up on Boot / Auto

Connected Interface name: tun0

FireWall Zone – put it into a new Zone similar to your WAN Zone.

Firewall Zone Settings

root@openwrt:~# cat /etc/config/firewall 

config zone
 option name 'vpn'
 option output 'ACCEPT'
 option network 'nl_vpn'
 option masq '1'
 option input 'REJECT'
 option forward 'REJECT'
 option mtu_fix '1'

config forwarding
 option dest 'vpn'
 option src 'lan'

VPN-WAN Interface Checks

Check your Interface is up and available in ifconfig.

root@openwrt:~# ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
 inet addr:10.8.0.33 P-t-P:10.8.0.33 Mask:255.255.0.0
 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
 RX packets:64 errors:0 dropped:0 overruns:0 frame:0
 TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:100 
 RX bytes:5158 (5.0 KiB) TX bytes:912 (912.0 B)

Compare a traceroute with your Tunnel Interface and with your WAN Interface.

root@openwrt:~# traceroute -i tun0 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
 1 10.8.0.1 (10.8.0.1) 41.615 ms 43.000 ms 42.597 ms
 2 po-24.ce38.ams-01.nl.leaseweb.net (95.211.138.190) 42.245 ms 41.426 ms 42.694 ms
 3 te-0-5-0-10.br02.ams-01.nl.leaseweb.net (81.17.33.58) 42.514 ms xe-2-0-0.br01.ams-01.nl.leaseweb.net (81.17.33.68) 41.695 ms xe-2-1-3.br01.ams-01.nl.leaseweb.net (81.17.33.70) 41.572 ms
 4 te-0-4-0-7.bb03.ams-01.leaseweb.net (31.31.38.50) 43.000 ms te-0-0-0-7.bb03.ams-01.leaseweb.net (31.31.38.48) 42.761 ms te-0-4-0-6.bb03.ams-01.leaseweb.net (31.31.38.54) 42.602 ms
 5 unused.nl-ix.net (193.239.117.141) 43.564 ms 44.046 ms google.telecity-2-equinix-am7.nl-ix.net (193.239.117.142) 42.834 ms
 6 * * 108.170.241.193 (108.170.241.193) 44.326 ms
 7 216.239.51.171 (216.239.51.171) 44.441 ms 216.239.42.123 (216.239.42.123) 43.350 ms 108.170.230.233 (108.170.230.233) 44.816 ms
 8 google-public-dns-a.google.com (8.8.8.8) 43.820 ms 44.058 ms 44.582 ms

vs. traceroute with your WAN Interface

root@openwrt:~# traceroute -i eth0.2 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 38 byte packets
 1 10.198.64.1 (10.198.64.1) 6.240 ms 6.092 ms 5.463 ms
 2 ME36X-Manzb-01.kabsi.at (195.202.135.129) 6.701 ms 6.127 ms 7.363 ms
 3 195.202.134.82 (195.202.134.82) 8.222 ms 8.433 ms 9.342 ms
 4 te0103-asr9k-upst-inx-01.net.kabelplus.at (195.202.134.233) 18.626 ms te0011-asr9k-upst-inx-01.net.kabelplus.at (195.202.135.6) 11.888 ms 9.353 ms
 5 google.peering.cz (91.213.211.170) 15.892 ms 16.902 ms 16.608 ms
 6 108.170.245.49 (108.170.245.49) 17.024 ms 108.170.245.33 (108.170.245.33) 15.660 ms 15.917 ms
 7 216.239.63.29 (216.239.63.29) 18.292 ms 108.170.237.179 (108.170.237.179) 16.173 ms 216.239.62.183 (216.239.62.183) 18.121 ms
 8 google-public-dns-a.google.com (8.8.8.8) 15.487 ms 15.610 ms 15.236 ms

A route should be added to your tun interface

root@openwrt:~# route | grep tun0
10.8.0.0 * 255.255.0.0 U 0 0 0 tun0

Search for a line with “Initialization Sequence Completed” in your Syslog

root@openwrt:/etc/config# logread | grep openvpn | grep Seq
Sun Feb 18 17:04:21 2018 daemon.notice openvpn(nl_prem)[2752]: Initialization Sequence Completed

Usage

This new VPN-WAN Interface is now available for guest LAN/WLANs, SplitTunnel or for MultiWan Setups.

A Declaration of the Independence of Cyberspace

"I knew it’s also true that a good way to invent the future is to predict it. So I predicted Utopia, hoping to give Liberty a running start before the laws of Moore and Metcalfe delivered up what Ed Snowden now correctly calls 'turn-key totalitarianism.'”

A Declaration of the Independence of Cyberspace

Governments of the Industrial World, you weary giants of flesh and steel, I come from Cyberspace, the new home of Mind. On behalf of the future, I ask you of the past to leave us alone. You are not welcome among us. You have no sovereignty where we gather.

We have no elected government, nor are we likely to have one, so I address you with no greater authority than that with which liberty itself always speaks. I declare the global social space we are building to be naturally independent of the tyrannies you seek to impose on us. You have no moral right to rule us nor do you possess any methods of enforcement we have true reason to fear.

Governments derive their just powers from the consent of the governed. You have neither solicited nor received ours. We did not invite you. You do not know us, nor do you know our world. Cyberspace does not lie within your borders. Do not think that you can build it, as though it were a public construction project. You cannot. It is an act of nature and it grows itself through our collective actions.

You have not engaged in our great and gathering conversation, nor did you create the wealth of our marketplaces. You do not know our culture, our ethics, or the unwritten codes that already provide our society more order than could be obtained by any of your impositions.

You claim there are problems among us that you need to solve. You use this claim as an excuse to invade our precincts. Many of these problems don't exist. Where there are real conflicts, where there are wrongs, we will identify them and address them by our means. We are forming our own Social Contract. This governance will arise according to the conditions of our world, not yours. Our world is different.

Cyberspace consists of transactions, relationships, and thought itself, arrayed like a standing wave in the web of our communications. Ours is a world that is both everywhere and nowhere, but it is not where bodies live.

We are creating a world that all may enter without privilege or prejudice accorded by race, economic power, military force, or station of birth.

We are creating a world where anyone, anywhere may express his or her beliefs, no matter how singular, without fear of being coerced into silence or conformity.

Your legal concepts of property, expression, identity, movement, and context do not apply to us. They are all based on matter, and there is no matter here.

Our identities have no bodies, so, unlike you, we cannot obtain order by physical coercion. We believe that from ethics, enlightened self-interest, and the commonweal, our governance will emerge. Our identities may be distributed across many of your jurisdictions. The only law that all our constituent cultures would generally recognize is the Golden Rule. We hope we will be able to build our particular solutions on that basis. But we cannot accept the solutions you are attempting to impose.

In the United States, you have today created a law, the Telecommunications Reform Act, which repudiates your own Constitution and insults the dreams of Jefferson, Washington, Mill, Madison, DeToqueville, and Brandeis. These dreams must now be born anew in us.

You are terrified of your own children, since they are natives in a world where you will always be immigrants. Because you fear them, you entrust your bureaucracies with the parental responsibilities you are too cowardly to confront yourselves. In our world, all the sentiments and expressions of humanity, from the debasing to the angelic, are parts of a seamless whole, the global conversation of bits. We cannot separate the air that chokes from the air upon which wings beat.

In China, Germany, France, Russia, Singapore, Italy and the United States, you are trying to ward off the virus of liberty by erecting guard posts at the frontiers of Cyberspace. These may keep out the contagion for a small time, but they will not work in a world that will soon be blanketed in bit-bearing media.

Your increasingly obsolete information industries would perpetuate themselves by proposing laws, in America and elsewhere, that claim to own speech itself throughout the world. These laws would declare ideas to be another industrial product, no more noble than pig iron. In our world, whatever the human mind may create can be reproduced and distributed infinitely at no cost. The global conveyance of thought no longer requires your factories to accomplish.

These increasingly hostile and colonial measures place us in the same position as those previous lovers of freedom and self-determination who had to reject the authorities of distant, uninformed powers. We must declare our virtual selves immune to your sovereignty, even as we continue to consent to your rule over our bodies. We will spread ourselves across the Planet so that no one can arrest our thoughts.

We will create a civilization of the Mind in Cyberspace. May it be more humane and fair than the world your governments have made before.

Davos, Switzerland
February 8, 1996
by John Perry Barlow

https://www.eff.org/deeplinks/2018/02/john-perry-barlow-internet-pioneer-1947-2018

Image from EFF License CC-BY

UAP-AC-LITE serial mod – debricking

I tend to push things too far and lock me out from my Hardware from time to time.

This time i set some wrong interface settings on my new Access Point running LEDE/OpenWRT. Sadly there is no working failsave mode available to repair the network settings.

But that’s not a problem, the board is provided with a serial port.

First it’s necessary to remove the front plate which is held by 5 tabs.

This port has the pinout +3,3V – RxD – TxD – GND.I have soldered pins on it to have it easy accessible.

I use as a Serial Port on my Laptop a CP2102 UART Bridge.

root@laptop:/home/cave# dmesg | tail
[19840.798867] usbcore: registered new interface driver usbserial
[19840.798904] usbcore: registered new interface driver usbserial_generic
[19840.798932] usbserial: USB Serial support registered for generic
[19840.800388] usbcore: registered new interface driver cp210x
[19840.800404] usbserial: USB Serial support registered for cp210x
[19840.800447] cp210x 2-2:1.0: cp210x converter detected
[19840.912702] usb 2-2: reset full-speed USB device number 2 using xhci_hcd
[19841.050680] xhci_hcd 0000:03:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88009ea91388
[19841.050690] xhci_hcd 0000:03:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88009ea91340
[19841.053055] usb 2-2: cp210x converter now attached to ttyUSB0

In Linux minicom is the terminal emulation program to go. Settings are 115200 Baud, 8N1, no flow control.

The Boot Log from LEDE looks as following:

U-Boot unifi-v1.6.2.235-g1aad87ce (Jun 30 2015 - 21:30:38)

DRAM: 
sri
ath_ddr_initial_config(278): (ddr2 init)
ath_sys_frequency: cpu 775 ddr 650 ahb 258
Tap values = (0xf, 0xf, 0xf, 0xf)
128 MB
Top of RAM usable for U-Boot at: 88000000
Reserving 231k for U-Boot at: 87fc4000
Reserving 192k for malloc() at: 87f94000
Reserving 44 Bytes for Board Info at: 87f93fd4
Reserving 36 Bytes for Global Data at: 87f93fb0
Reserving 128k for boot params() at: 87f73fb0
Stack Pointer at: 87f73f98
Now running in RAM - U-Boot at: 87fc4000
Flash: 16 MB
In: serial
Out: serial
Err: serial
Net: ath_gmac_enet_initialize...
No valid address in Flash. Using fixed address
ath_gmac_enet_initialize: reset mask:c02200 
athr_mgmt_init ::done
Dragonfly ----> S17 PHY *
 ath_gmac_enet_initialize: is_s17()=0, is_ar8033()=1, phy id1=4d phy_id2=d074 
WAN AR8033 PHY init 
athrs_ar8033_reg_init: Done 111 
Max resets limit reached exiting...
athr_gmac_sgmii_setup SGMII done
: cfg1 0x80000000 cfg2 0x7114
eth0: 00:03:7f:09:0b:ad
eth0 up
eth0
Setting 0x181162c0 to 0x20402100
Board: Copyright Ubiquiti Networks Inc. 2014
Hit any key to stop autoboot: 0 
## Starting application at 0x80200020 ...
Board: Ubiquiti Networks AR956X board (e517-33.1150.0030.0040)
 0. Name = u-boot, offset = 0, start_addr=9f000000, size=393216,start_sector=0, end_sector=5 
 1. Name = u-boot-env, offset = 60000, start_addr=9f060000, size=65536,start_sector=6, end_sector=6 
 2. Name = kernel0, offset = 70000, start_addr=9f070000, size=7929856,start_sector=7, end_sector=127 
 3. Name = kernel1, offset = 800000, start_addr=9f800000, size=7929856,start_sector=128, end_sector=248 
 4. Name = bs, offset = f90000, start_addr=9ff90000, size=131072,start_sector=249, end_sector=250 
 5. Name = cfg, offset = fb0000, start_addr=9ffb0000, size=262144,start_sector=251, end_sector=254 
 6. Name = EEPROM, offset = ff0000, start_addr=9fff0000, size=65536,start_sector=255, end_sector=255 
get_mtd_params: name=bs
ubnt_flash_read: addr=8023b480, sa=9ff90000, sz=131072 
ubnt_bootsel_init: bootsel magic=a34de82b, bootsel = 1 
UBNT application initialized 
## Application terminated, rc = 0x0
## Starting application at 0x80200020 ...
keep cfg partition. 
## Application terminated, rc = 0x0
## Starting application at 0x80200020 ...
ubnt_uwrite: Nothing to flash, exiting 
## Application terminated, rc = 0x0
## Starting application at 0x80200020 ...
Number of boot partitions = 2 
get_mtd_params: name=bs
ubnt_flash_read: addr=8023b480, sa=9ff90000, sz=131072 
ubnt_get_bootsel: Boot partition selected = 1 
Loading Kernel Image @ 81000000, size = 7929856 
Verifying 'kernel1' parition:OK
## Application terminated, rc = 0x0
## Booting image at 9f800000 ...
 Image Name: MIPS LEDE Linux-4.4.92
 Created: 2017-10-17 17:46:20 UTC
 Image Type: MIPS Linux Kernel Image (lzma compressed)
 Data Size: 1258164 Bytes = 1.2 MB
 Load Address: 80060000
 Entry Point: 80060000
 Verifying Checksum at 0x9f800040 ...OK
 Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 80060000) ...
## Giving linux memsize in bytes, 134217728

Starting kernel ...

[ 0.000000] Linux version 4.4.92 (buildbot@builds-02.infra.lede-project.org) (gcc version 5.4.0 (LEDE GCC 5.4.0 r3101-bce140e) ) #0 Tue Oct 17 14:59:45 2017
[ 0.000000] bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 00019750 (MIPS 74Kc)
[ 0.000000] SoC: Qualcomm Atheros QCA956X ver 1 rev 0
[ 0.000000] Determined physical RAM map:
[ 0.000000] memory: 08000000 @ 00000000 (usable)
[ 0.000000] Initrd not found or empty - disabling initrd
[ 0.000000] No valid device tree found, continuing without
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000000000000-0x0000000007ffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x0000000007ffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
[ 0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
[ 0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
[ 0.000000] Kernel command line: board=UBNT-UF-AC-LITE mtdparts=spi0.0:384k(u-boot)ro,64k(u-boot-env)ro,7744k(firmware),7744k(ubnt-airos)ro,128k(bs)ro,256k(cfg)ro,64k(EEPROM)ro console=ttyS0,11d
[ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Writing ErrCtl register=00000000
[ 0.000000] Readback ErrCtl register=00000000
[ 0.000000] Memory: 125328K/131072K available (3076K kernel code, 160K rwdata, 412K rodata, 312K init, 205K bss, 5744K reserved, 0K cma-reserved)
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] NR_IRQS:51
[ 0.000000] Clocks: CPU:775.000MHz, DDR:650.000MHz, AHB:258.333MHz, Ref:25.000MHz
[ 0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 4932285024 ns
[ 0.000006] sched_clock: 32 bits at 387MHz, resolution 2ns, wraps every 5541893118ns
[ 0.008207] Calibrating delay loop... 385.84 BogoMIPS (lpj=1929216)
[ 0.071016] pid_max: default: 32768 minimum: 301
[ 0.075981] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.082957] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.092341] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.102742] futex hash table entries: 256 (order: -1, 3072 bytes)
[ 0.110072] NET: Registered protocol family 16
[ 0.115891] MIPS: machine is Ubiquiti UniFi-AC-LITE
[ 0.339426] registering PCI controller with io_map_base unset
[ 0.345661] Can't analyze schedule() prologue at 800670fc
[ 0.358984] PCI host bridge to bus 0000:00
[ 0.363307] pci_bus 0000:00: root bus resource [mem 0x12000000-0x13ffffff]
[ 0.370588] pci_bus 0000:00: root bus resource [io 0x0001]
[ 0.376452] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0]
[ 0.383608] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
[ 0.392012] pci 0000:00:00.0: invalid calibration data
[ 0.397797] pci 0000:00:00.0: BAR 0: assigned [mem 0x12000000-0x121fffff 64bit]
[ 0.405512] pci 0000:00:00.0: BAR 6: assigned [mem 0x12200000-0x1220ffff pref]
[ 0.413156] pci 0000:00:00.0: using irq 40 for pin 1
[ 0.418979] clocksource: Switched to clocksource MIPS
[ 0.425232] NET: Registered protocol family 2
[ 0.430583] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.437935] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.444682] TCP: Hash tables configured (established 1024 bind 1024)
[ 0.451462] UDP hash table entries: 256 (order: 0, 4096 bytes)
[ 0.457625] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[ 0.464480] NET: Registered protocol family 1
[ 0.472711] Crashlog allocated RAM at address 0x3f00000
[ 0.490033] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 0.496181] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[ 0.508521] io scheduler noop registered
[ 0.512696] io scheduler deadline registered (default)
[ 0.518282] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled
[ 0.527170] console [ttyS0] disabled
[ 0.551022] serial8250.0: ttyS0 at MMIO 0x18020000 (irq = 11, base_baud = 1562500) is a 16550A
[ 0.560121] console [ttyS0] enabled
[ 0.560121] console [ttyS0] enabled
[ 0.567662] bootconsole [early0] disabled
[ 0.567662] bootconsole [early0] disabled
[ 0.580366] m25p80 spi0.0: mx25l12805d (16384 Kbytes)
[ 0.585606] 7 cmdlinepart partitions found on MTD device spi0.0
[ 0.591759] Creating 7 MTD partitions on "spi0.0":
[ 0.596707] 0x000000000000-0x000000060000 : "u-boot"
[ 0.603635] 0x000000060000-0x000000070000 : "u-boot-env"
[ 0.610446] 0x000000070000-0x000000800000 : "firmware"
[ 0.629799] 2 uimage-fw partitions found on MTD device firmware
[ 0.635927] 0x000000070000-0x0000001b0000 : "kernel"
[ 0.642182] 0x0000001b0000-0x000000800000 : "rootfs"
[ 0.648580] mtd: device 4 (rootfs) set to be root filesystem
[ 0.654512] 1 squashfs-split partitions found on MTD device rootfs
[ 0.660909] 0x000000420000-0x000000800000 : "rootfs_data"
[ 0.667848] 0x000000800000-0x000000f90000 : "ubnt-airos"
[ 0.674680] 0x000000f90000-0x000000fb0000 : "bs"
[ 0.680842] 0x000000fb0000-0x000000ff0000 : "cfg"
[ 0.686988] 0x000000ff0000-0x000001000000 : "EEPROM"
[ 0.699934] libphy: ag71xx_mdio: probed
[ 1.370523] ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:04 [uid=004dd074, driver=Atheros 8031/8033 ethernet]
[ 1.381861] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode:SGMII
[ 1.389623] NET: Registered protocol family 10
[ 1.396970] NET: Registered protocol family 17
[ 1.401669] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this.
[ 1.414787] 8021q: 802.1Q VLAN Support v1.8
[ 1.425064] VFS: Mounted root (squashfs filesystem) readonly on device 31:4.
[ 1.434102] Freeing unused kernel memory: 312K
[ 2.242449] init: Console is alive
[ 2.246134] init: - watchdog -
[ 3.083296] kmodloader: loading kernel modules from /etc/modules-boot.d/*
[ 3.104439] kmodloader: done loading kernel modules from /etc/modules-boot.d/*
[ 3.113279] init: - preinit -
[ 3.913129] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 3.935766] random: procd: uninitialized urandom read (4 bytes read, 6 bits of entropy available)
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[ 6.521268] eth0: link up (100Mbps/Full duplex)
[ 6.525976] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 7.213159] jffs2: notice: (362) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
[ 7.230901] mount_root: switching to jffs2 overlay
[ 7.243259] urandom-seed: Seeding with /etc/urandom.seed
[ 7.340310] eth0: link down
[ 7.352452] procd: - early -
[ 7.355510] procd: - watchdog -
[ 7.966201] procd: - watchdog -
[ 7.970066] procd: - ubus -
[ 8.067457] random: ubusd: uninitialized urandom read (4 bytes read, 13 bits of entropy available)
[ 8.078176] random: ubusd: uninitialized urandom read (4 bytes read, 13 bits of entropy available)
[ 8.088227] random: ubusd: uninitialized urandom read (4 bytes read, 13 bits of entropy available)
[ 8.097567] random: ubusd: uninitialized urandom read (4 bytes read, 13 bits of entropy available)
[ 8.107182] random: ubusd: uninitialized urandom read (4 bytes read, 13 bits of entropy available)
[ 8.116514] random: ubusd: uninitialized urandom read (4 bytes read, 13 bits of entropy available)
[ 8.125980] random: ubusd: uninitialized urandom read (4 bytes read, 13 bits of entropy available)
[ 8.135784] random: ubusd: uninitialized urandom read (4 bytes read, 13 bits of entropy available)
[ 8.145437] procd: - init -
Please press Enter to activate this console.
[ 8.483520] kmodloader: loading kernel modules from /etc/modules.d/*
[ 8.506009] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 8.519402] Loading modules backported from Linux version wt-2017-01-31-0-ge882dff19e7f
[ 8.527672] Backport generated by backports.git backports-20160324-13-g24da7d3c
[ 8.587506] PCI: Enabling device 0000:00:00.0 (0000 -> 0002)
[ 8.593567] ath10k_pci 0000:00:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0
[ 8.813379] ath10k_pci 0000:00:00.0: Direct firmware load for ath10k/pre-cal-pci-0000:00:00.0.bin failed with error -2
[ 8.824471] ath10k_pci 0000:00:00.0: Falling back to user helper
[ 9.019462] firmware ath10k!pre-cal-pci-0000:00:00.0.bin: firmware_loading_store: map pages failed
[ 9.220586] ath10k_pci 0000:00:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043222ff sub 0000:0000
[ 9.230152] ath10k_pci 0000:00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
[ 9.243146] ath10k_pci 0000:00:00.0: firmware ver 10.2.4-1.0-00016 api 5 features no-p2p,raw-mode,mfp crc32 0c5668f8
[ 9.254134] ath10k_pci 0000:00:00.0: Direct firmware load for ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
[ 9.264928] ath10k_pci 0000:00:00.0: Falling back to user helper
[ 9.343343] firmware ath10k!QCA988X!hw2.0!board-2.bin: firmware_loading_store: map pages failed
[ 9.364515] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
[ 10.475587] ath10k_pci 0000:00:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1
[ 10.695182] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 10.707106] nf_conntrack version 0.5.0 (1963 buckets, 7852 max)
[ 10.740206] xt_time: kernel timezone is -0000
[ 10.765475] PPP generic driver version 2.4.2
[ 10.818507] NET: Registered protocol family 24
[ 10.852803] ieee80211 phy1: Atheros AR9561 Rev:0 mem=0xb8100000, irq=47
[ 10.866164] kmodloader: done loading kernel modules from /etc/modules.d/*
[ 11.743364] random: jshn: uninitialized urandom read (4 bytes read, 19 bits of entropy available)
[ 15.375016] device eth0 entered promiscuous mode
[ 15.390029] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
[ 17.281331] eth0: link up (100Mbps/Full duplex)
[ 17.418004] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 17.459082] br-lan: port 1(eth0) entered forwarding state
[ 17.464711] br-lan: port 1(eth0) entered forwarding state
[ 17.499544] device wlan1 entered promiscuous mode
[ 19.458989] br-lan: port 1(eth0) entered forwarding state
[ 19.646999] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 19.660881] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[ 19.689299] device wlan0 entered promiscuous mode
[ 21.179912] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
[ 21.186686] br-lan: port 2(wlan1) entered forwarding state
[ 21.192431] br-lan: port 2(wlan1) entered forwarding state
[ 23.189012] br-lan: port 2(wlan1) entered forwarding state
[ 39.059895] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 39.066638] br-lan: port 3(wlan0) entered forwarding state
[ 39.072394] br-lan: port 3(wlan0) entered forwarding state
[ 41.068994] br-lan: port 3(wlan0) entered forwarding state
[ 44.663058] random: nonblocking pool is initialized

BusyBox v1.25.1 () built-in shell (ash)

_________
 / /\ _ ___ ___ ___
 / LE / \ | | | __| \| __|
 / DE / \ | |__| _|| |) | _|
 /________/ LE \ |____|___|___/|___| lede-project.org
 \ \ DE /
 \ LE \ / -----------------------------------------------------------
 \ DE \ / Reboot (17.01.4, r3560-79f57e422d)
 \________\/ -----------------------------------------------------------

root@uap-ac-lite:/#

If you have access to the root user, you can reconfigure as much as you want and repair your settings.

If it’s better to do a factory reset, you can also boot into failsafe by pressing [ f ] when asked for it.

[ 3.935766] random: procd: uninitialized urandom read (4 bytes read, 6 bits of entropy available) 
Press the [f] key and hit [enter] to enter failsafe mode 
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level 
[ 6.521268] eth0: link up (100Mbps/Full duplex)

Install openWRT / LEDE 17.01.4 on Ubiquiti UAP-AC-LITE

The Ubiquiti UNIFI AP AC LITE is the smallest from Ubiquiti’s Access Points. At the moment it’s sold for roughly 75€.

The Access Point has the following key data:

SoC:             Qualcomm Atheros QCA9563
Bootloader:      UBoot
CPU Frq:         775 MHz
Flash:           16 MiB
RAM:             128 MiB
Gbit Ports:      1 GbE
Wi-Fi Standards: 802.11 a/b/g/n/ac
Wireless         2.4 GHz: 802.11n 6.5 Mbps to 300 Mbps (MCS0 - MCS15, HT 20/40)
Wireless         5 GHz: 802.11ac 6.5 Mbps to 867 Mbps (MCS0 - MCS9 NSS1/2, VHT 20/40/80)
Serial:          Yes, for U-Boot
PoE:             802.3af/A PoE & 24V PoE
Antennas:        2 Dual-Band Antennas, 3 dBi Each

There is more information about this device on WikiDevi, OpenWrt and LEDE.

The original Firmware on the Access Point does not have a Web Interface for configuration. But there is a Controller Software available to do mass configuration and control for many AP’s at once.

As we do not plan to use the Firmware from Ubiquiti we do not need to use this software and replace it with latest LEDE.

Happily LEDE Project and OpenWRT have merged back to a unified Project. So we can just use the newest stable LEDE 17.01.04 Release to flash the new firmware on it.

So i connected it with the PoE device to my existing Lan. It received the IP 192.168.1.57 and i connected to it with SSH. The default password is ubnt/ubnt.

cave@laptop:~$ ssh ubnt@192.168.1.57
BusyBox v1.19.4 (2017-05-08 10:00:47 PDT) built-in shell (ash)
Enter 'help' for a list of built-in commands.
BZ.v3.7.58#

The Version seems to be pretty new. Sadly Ubiquiti uses OpenWRT for their modified firmware, but refuse to allow the community to install their own firmware. So they have modified U-BOOT Bootloader (GPLv2) and included some kind of RSA checksum which prevent installation of third party firmware. This check was introduced with FW >= 3.4.14
In the release notes:

Several changes to increase robustness of firmware upgrade process

So we need to downgrade to a version without this Lockout attempt. 3.4.7 firmware.bin

So download the firmware and scp it to your device into /tmp

cave@laptop:~$ scp firmware.bin ubnt@192.168.100.57:/tmp

Log in back to your AP via SSH, go to /tmp and update the firmware.

BZ.v3.7.58# pwd
/tmp
BZ.v3.7.58# ls
default.cfg firmware.bin rc.txt running.cfg sysinit.txt system.cfg
BZ.v3.7.58# fwupdate.real -m firmware.bin 
part:fis:311326, block size:393216 
Writing 'u-boot ' to /dev/mtd0(u-boot ) ... [%100]
part:fis:6877320, block size:7929856 
Writing 'kernel0 ' to /dev/mtd3(kernel1 ) ... [%100]

When the device reboots, you will loose connection. So log back in via ssh and check if the downgrade was successful.

cave@laptop:~$ ssh ubnt@192.168.100.57
BusyBox v1.19.4 (2015-09-11 16:51:29 PDT) built-in shell (ash)
Enter 'help' for a list of built-in commands.
BZ.v3.4.7#

Bingo, Version 3.4.7 is now shown in the prompt.

BZ.v3.4.7# uname -a
Linux UBNT 3.3.8 #1 Fri Sep 11 17:02:52 PDT 2015 mips GNU/Linux
BZ.v3.4.7# cat /etc/version 
BZ.v3.4.7

Download the newest stable LEDE Firmware and copy it to the device.

cave@laptop:~$ scp lede-17.01.4-ar71xx-generic-ubnt-unifiac-lite-squashfs-sysupgrade.bin ubnt@192.168.100.57:/tmp
lede-17.01.4-ar71xx-generic-ubnt-unifiac-lite 100% 3776KB 1.8MB/s 00:02

And now do the update with the mtd command.

BZ.v3.4.7# mtd write /tmp/lede-17.01.4-ar71xx-generic-ubnt-unifiac-lite-squashfs-sysupgrade.bin kernel0
Unlocking kernel0 ...

Writing from /tmp/lede-17.01.4-ar71xx-generic-ubnt-unifiac-lite-squashfs-sysupgrade.bin to kernel0 ... 
BZ.v3.4.7# 
BZ.v3.4.7# 
BZ.v3.4.7# mtd -r write /tmp/lede-17.01.4-ar71xx-generic-ubnt-unifiac-lite-squashfs-sysupgrade.bin kernel1
Unlocking kernel1 ...

Writing from /tmp/lede-17.01.4-ar71xx-generic-ubnt-unifiac-lite-squashfs-sysupgrade.bin to kernel1 ... 
Rebooting ...
Connection to 192.168.100.57 closed by remote host.
Connection to 192.168.100.57 closed.

 

Now log in to your Device at IP 192.168.1.1 as you do with any other openWRT/LEDE Router. telnet or ssh into it and set a password.

From now on there should be also a WebInterface available for easy configuration if you dislike the CLI.