Professional Documents
Culture Documents
59 (10-May-2016)
===========================================
About
----Asuswrt is the name of the common
for their various router models.
Tomato, it has since grown into a
some more technical features that
also adding new original features
Supported Devices
----------------Supported devices are:
* RT-N66U
* RT-AC66U
* RT-AC56U
* RT-AC68U
* RT-AC68P
* RT-AC87U
* RT-AC3200
* RT-AC88U
* RT-AC3100
* RT-AC5300U
Devices that are no longer officially supported (but forked builds might
exist from other developers):
* RT-N16
NOTE: all the "R" versions (for example RT-N66R) are the same as their
"U" counterparts, they are just different packages aimed at large
retailers. The firmware is 100% compatible with both U and R versions
of the routers. Same with the "W" variants that are simply white.
Features
-------Here is a list of features that Asuswrt-merlin adds over the original
firmware:
System:
- Based on 3.0.0.4.380_2697 source code from Asus
sharing:
Enable/disable the use of shorter share names
Disk spindown after user-configurable inactivity timeout
NFS sharing (through webui)
Allow or disable WAN access to the FTP server
Updated Samba version (3.6)
Networking:
- Force acting as a Master Browser
- Act as a WINS server
- Allows tweaking TCP/UDP connection tracking timeouts
- CIFS client support (for mounting remote SMB share on the router)
- Layer7 iptables matching (N66/AC66 only)
- User-defined options for WAN DHCP queries (required by some ISPs)
- Advanced OpenVPN client and server support
- Netfilter ipset module, for efficient blacklist implementation
- Configurable min/max UPNP ports
- IPSec kernel support (N66/AC66 only)
- DNS-based Filtering, can be applied globally or per client
- Custom DDNS (through a user script)
- Advanced NAT loopback (as an alternative to the default one)
- TOR support, individual client control (based on experimental code
from Asus)
- Policy routing for the OpenVPN client (based on source or
destination IPs), sometimes referred to as "selective routing")
- DNSSEC support
- Experimental support for fq_codel in Traditionnal QoS
(ARM-based models only)
Web interface:
- Optionally save traffic stats to disk (USB or JFFS partition)
- Enhanced traffic monitoring: added monthly, as well as per IP
monitoring
- Hostname field on the DHCP reservation page
- System info summary page
- Wifi icon reports the state of both radios
- Display the Ethernet port states
- Wireless site survey
- Advanced Wireless client list display, including automated refresh
- Redesigned layout of the various System Log sections
- Editable fields for some pages
A few features that first appeared in Asuswrt-Merlin have since been
integrated/enabled/re-implemented in the official firmware:
Installation
-----------Simply flash it like any regular update. You should not need to
reset to factory defaults (see note below for exceptions).
You can revert back to an original Asus firmware at any time just
by flashing a firmware downloaded from Asus's website.
NOTE: resetting to factory default after flashing is
strongly recommended for the following cases:
- Updating from a firmware version that is more than 3 releases older
- Switching from a Tomato/DD-WRT/OpenWRT firmware
If upgrading from anything older and you experience issues, then
consider doing a factory default reset then as well.
Always read the changelog, as mandatory resets will be mentionned
there when they are necessary.
In all of these cases, do NOT load a saved copy of your settings!
This would be the same thing as NOT resetting at all, as you will
simply re-enter any invalid setting you wanted to get rid of. Make
sure to create a new backup of your settings after reconfiguring.
Usage
----** JFFS **
JFFS is a writeable section of the flash memory which will allow you to
store small files (such as scripts) inside the router without needing
to have a USB disk plugged in. This space will survive reboots (but it
*MIGHT NOT survive firmware flashing*, so back it up first before
flashing!). It will also be available fairly early at boot (before
USB disks).
On that page you will also find an option called "Enable custom
scripts and configs". If you intend to use custom scripts or
config files, then you need to enable this option. This is not
enabled by default so if you create a broken config/script that
prevents the router from booting, you will still be able to regain
access by doing a factory default reset.
Try to avoid doing too frequent writes to this partition, as it will
prematuraly wear out the flash storage. This is a good place to put
files that are written once like scripts or kernel modules, or that
rarely get written to. Storing files that constantly get written
to (like very busy logfiles) is NOT recommended - use a
USB disk for that.
You can backup and restore the content of the JFFS2 partition,
from the same page you can backup/restore the router configuration.
** User scripts **
These are shell scripts that you can create, and which will be run when
certain events occur. Those scripts must be saved in /jffs/scripts/ ,
so, JFFS must be enabled, as well as the option to use custom
scripts and configs. This can be configured under Administration -> System.
Available scripts:
* ddns-start: Script called at the end of a DDNS update process.
This script is also called when setting the DDNS type
to "Custom". The script gets passed the WAN IP as
an argument.
When handling a "Custom" DDNS, this script is also
responsible for reporting the success or failure
of the update process. See the Custom DDNS section
below for more information.
* dhcpc-event: Called whenever a DHCP event occurs on the WAN
interface. The type of event (bound, release, etc...)
is passed as an argument.
* firewall-start: Firewall is started (filter rules have been applied)
The WAN interface will be passed as argument (for
example. "eth0")
* init-start: Right after jffs is mounted, before any of the services
get started
* nat-start: nat rules (i.e. port forwards and such) have been applied
(nat table)
* openvpn-event: Called whenever an OpenVPN server gets
started/stopped, or an OpenVPN client connects to a
remote server. Uses the same syntax/parameters as
the "up" and "down" scripts in OpenVPN.
* post-mount: Just after a partition is mounted
* pre-mount: Just before a partition is mounted. Be careful with
this script. This is run in a blocking call and will
block the mounting of the partition for which it is
invoked till its execution is complete. This is done so
that it can be used for things like running e2fsck on the
partition before mounting. This script is also passed the
device path being mounted as an argument which can be
used in the script using $1.
* qos-start: Called after both the iptables rules and tc configuration
are completed for QoS. This script will be passed an
argument, which will be "init" (when QoS is being
initialized and it has setup the tc classes) or
"rules" (when the iptables rules are being setup).
* services-start: Initial service start at boot
** SSHD **
The router can be accessed over SSH (through Dropbear). Password-based
login will use the same username and password as telnet/web access.
You can also optionally insert a RSA or ECDSA public key there for
keypair-based authentication. Finally, there is also an option to
make SSH access available over WAN.
** Crond **
Crond will automatically start at boot time. You can put your cron
tasks in /var/spool/cron/crontabs/ . The file must be named "admin" as
this is the name of the system user. Note that this location resides in
RAM, so you would have to put your cron script somewhere such as in the
jffs partition, and at boot time copy it to /var/spool/cron/crontabs/
using an init-start user script.
A simple way to manage your cron jobs is through the included "cru"
command. Just run "cru" to see the usage information. You can then
put your "cru" commands inside a user script to re-generate your cron
jobs at boot time.
adisk.service
afpd.service
avahi-daemon.conf
dhcp6s.conf
dnsmasq.conf
exports (only exports.add supported)
fstab (only fstab supported, remember to create mount point
through init-start first if it doesn't exist!)
group, gshadow, passwd, shadow (only .add versions supported)
hosts (for /etc/hosts)
igmpproxy.conf
minidlna.conf
mt-daap.service
pptpd.conf
profile (shell profile, only profile.add suypported)
radvd.conf
smb.conf
snmpd.conf
** NFS Exports **
IMPORTANT: NFS sharing is still a bit unstable.
In addition to SMB and FTP, you can now also share any plugged
hard disk through NFS. The NFS Exports interface can be accessed
from the USB Applications section, under Servers Center. Click on the
NFS Exports tab.
Select the folder you wish to export by clicking on the Path field.
Under Access List you can enter IPs/Networks to which you wish to give
access. A few examples:
192.168.1.0/24 - will give access to the whole local network
192.168.1.10 192.168.1.11 - will give access to the two IPs (separate with spa
ces)
Entering nothing will allow anyone to access the export.
Under options you can enter the export options, separated by a comma.
For example:
rw,sync
For more info, search the web for documentation on the format of the
/etc/exports file. The same syntax for the access list and the options
is used by the webui.
You can also manually generate an exports file by creating a file named
/jffs/configs/exports.add , and entering your standard exports there.
They will be added to any exports configured on the webui.
Note that by default, only NFSv3 is supported. You can also enable
NFSv2 support from that page, but this is not recommended, unless you
are using an old NFS client that doesn't support V3. NFSv2 has various
filesystem-level limitations.
** DNSFilter **
Under Parental Control there is a tab called DNSFilter. On this
page you can force the use of a DNS service that provides
security/parental filtering. This can be done globally, or on a
per device basis. Each of them can have a different type of filtering
applied. For example, you can have your LAN use OpenDNS's server to
provide basic filtering, but force your children's devices to use
Yandex's family DNS server that filters out malicious and adult
content.
If using a global filter, then specific devices can be told to
bypass the global filter, by creating a client rule for these,
and setting it to "No Filtering".
DNSFilter also lets you define up to three custom nameservers, for
use in filtering rules. This will let you use any unsupported
filtering nameserver.
You
use
you
the
** Custom DDNS **
If you set the DDNS (dynamic DNS) service to "Custom", then you will be
able to fully control the update process through a ddns-start user
script. That script could launch a custom DDNS update client, or run a
simple "wget" on a provider's update URL. The ddns-start script will
be passed the WAN IP as an argument.
Note that the script will also be responsible for notifying the firmware
on the success or failure of the process. To do this you must simply
run the following command:
/sbin/ddns_custom_updated 0|1
0 = failure, 1 = successful update
If you cannot determine the success or failure, then report it as a
success to ensure that the firmware won't continuously try to
force an update.
Here is a working example, for afraid.org's free DDNS (you must update
the URL to use your private API key from afraid.org):
----#!/bin/sh
wget -q http://freedns.afraid.org/dynamic/update.php?your-private-key-goes-h
ere -O - >/dev/null
if [ $? -eq 0 ]; then
/sbin/ddns_custom_updated 1
else
/sbin/ddns_custom_updated 0
fi
----Finally, like all custom scripts, the option to support custom scripts and
config files must be enabled under Administration -> System.
0.0.0.0
74.125.0.0/16
VPN
Or, to have a computer routed through the tunnel except for requests sent
to your ISP's SMTP server (assuming a fictious IP of 10.10.10.10 for your
ISP's SMTP server):
PC1
PC1-bypass
192.168.1.100
192.168.1.100
0.0.0.0
10.10.10.10
VPN
WAN
Source code
----------The source code with all my modifications can be found on Github, at:
https://github.com/RMerl/asuswrt-merlin
Contact information
------------------SmallNetBuilder forums (preferred method: http://www.snbforums.com/forums/asuswr
t-merlin.42/ as RMerlin)
Website: https://asuswrt.lostrealm.ca/
Github: https://github.com/RMerl/asuswrt-merlin
Email: rmerl@lostrealm.ca
Twitter: https://twitter.com/RMerlinDev
IRC: #asuswrt on DALnet
Download: https://asuswrt.lostrealm.ca/download
Development news will be posted on Twitter. You can also keep a closer
eye on development as it happens through the Github site.
Disclaimer
---------This is the part where you usually put a lot of legalese stuff that nobody
reads. I'm not a lawyer, so I'll just make it simple, using my own words
rather than some pre-crafted text that will bore you to death and that
nobody but a highly paid lawyer would even understand anyway:
I take no responsibility for issues caused by this project. I do my best to
ensure that everything works fine. If something goes wrong, my apologies.
Copyrights belong to the appropriate individuals/entities, under the appropriate
licences. GPL code is covered by GPL, proprietary code is (c)Copyright their
respective owners, yadda yadda.
I try my best to honor the licences (as far as I can understand them, as a
normal human being). Anything GPL or otherwise open-sourced that I modify
will see my changes published to Github at some point. A release might get
delayed if I'm working using pre-release code. If it's GPL, it will eventually
be published - no need to send a volley of legal threats at me.
In any other cases not covered, Common Sense prevails, and I shall also make use
of Good Will.
Concerning privacy:
This firmware does not contact me back in any way whatsoever. Not even through
any update checker - the only update code there is Asus's.
--Eric Sauvageau