README Merlin
README Merlin
README Merlin
57 (24-Dec-2015)
===========================================
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-AC5300
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_1031 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
- Policy routing for the OpenVPN client (based on source or
destination IPs), sometimes referred to as "selective routing")
- DNSSEC support
Web interface:
- Optionally save traffic stats to disk (USB or JFFS partition)
- Enhanced traffic monitoring: added monthly, as well as per IP
monitoring
- Name field on the DHCP reservation list and Wireless ACL list
- 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:
- 64K NVRAM for the RT-N66U
- HTTPS webui
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
** 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
torrc (for the Tor config file)
vsftpd.conf
upnp (for miniupnpd)
Also, you can put OpenVPN ccd files in the following directories:
/jffs/configs/openvpn/ccd1/
/jffs/configs/openvpn/ccd2/
The content of these will be copied to their respective
server instance's ccd directory when the server is started.
** Postconf scripts **
A lot of the configuration files used by the router services
(such as dnsmasq) are dynamically generated by the firmware. This
makes it hard for advanced users to apply modifications to these, short
of entirely replacing the config file.
Postconf scripts are the solution to that. Those scripts are
executed after the router has generated a configuration script, but
before the related service gets started. This means you can use those
scripts to manipulate the configuration script, using tools such as
"sed" for example.
Postconf scripts must be stored in /jffs/scripts/ . JFFS must be
enabled, as well as the option to use custom scripts and configs.
This can be configured under Administration -> System.
The path/filename of the target config file is passed as argument to
the postconf script.
The list of available postconf scripts is:
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
** 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.
should be routed through the tunnel, rather than having all of your
traffic automatically routed through it.
On the OpenVPN Clients page, set "Redirect Internet traffic" to
"Policy Rules". A new section will appear below, where you can
add routing rules. The "Source IP" is your local client, while
"Destination" is the remote server on the Internet. The field can be
left empty (or set to 0.0.0.0) to signify "any IP". You can also
specify a whole subnet, in CIDR notation (for example, 74.125.226.112/30).
The Iface field lets you determine if matching traffic should be sent
through the VPN tunnel or through your regular Internet access (WAN).
This allows you to define exceptions (WAN rules being processed
before the VPN rules).
Here are a few examples.
To have all your clients use the VPN tunnel when trying to
access an IP from this block that belongs to Google:
RouteGoogle
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: http://asuswrt.lostrealm.ca/
Github: https://github.com/RMerl/asuswrt-merlin
Email: [email protected]
Twitter: https://twitter.com/RMerlinDev
IRC: #asuswrt on DALnet
Download: http://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.
For support questions, please use the SmallNetBuilder forums whenever
possible. There's a dedicated Asuswrt-Merlin sub-forum there, under
the Asus Wireless section.
Drop me a note if you are using this firmware and are enjoying it. If
you really like it and want to give more than a simple "Thank you",
there is also a Paypal donation button on my website.
I want to give my special thanks to Asus for showing an interest in
this project, and also providing me with support and development
devices when needed. I also want to thank everyone that has
donated through Paypal. Much appreciated!
Finally, special thanks to r00t4rd3d for designing the Asuswrt-Merlin
logo.
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