- User
supplied DNS (you have to disable "Use Peer DNS"
on the ISP connection page)
- Default date/time is
set on boot-up to the date/time that
the firmware was built
- NAT and
memory
optimisations
- Support for routers
with ATMEL
flash chips
(e.g., some DLink G604T/G624T). Note that these DLinks use an
incompatible
switch. This means that
you will be unable to configure the ethernet switch manually from
software. The switch will operate in automatic mode
and the firmware will still work properly. Most users will never need
to configure their router's ethernet switch manually, so this is not a
major issue.
- Support for the
wireless routers using
the TNETW1350A wireless chip. This requires a different firmware image
from the normal wireless routers.
- Facility to choose
between different DSP modem driver
versions (for wireless
routers
and routers with 4mb flash and 16 mb RAM only (by setting the
appropriate value for a new bootloader environment variable, "dsp_ver"))
- e.g., running: setenv
dsp_ver dsp70A && /sbin/reboot would
select
DSP v7.00, AnnexA. Choices are between dsp70A/71A/75A,
and dsp70B/71B/75B
(i.e., AnnexB).
Note also that all
these are case-sensitive. The normal default is dsp75A.
For the TNETW1350A firmware, the default is dsp71A. From v2.9 onwards, there are
separate firmware images for Annex A and Annex B.
- Facility to choose between different
versions of the LED
configuration file. - e.g., running: setenv
led_conf led.sar600 && /sbin/reboot would
select the LED file for the Solwise/Aztech 600E* series. The
default is led.generic.
Some batch files are supplied in the "led" directory for Windows users
to be able to do this by just executing the appropriate batch file.
This will run the (supplied) telnet scripter to update the router's
environment as appropriate.
- Functional DDNS (with no-ip
support)
- USB support (see
the "RT
Configurations" menu).
- Auto execution of shell scripts at bootup. This
requires
entries in the bootloader environment. If there is any entry in the
bootloader environment that points to a shell script (i.e., ending with
the
extension ".sh") that shell script will be executed everytime the
router boots up. There is a default "autoexec.sh" provided,
which
just runs any commands passed to it (there are also autoexec1.sh to
autoexec7.sh, which do the same thing)
- Several extra commands. See the rt_commands.html for
details. Some of them can be used for the auto execution feature
- The "System" menu is easily accessible from
the top
menu bar
- Detailed information on the startup page
- Date/time stamps in the system log
- A functional
SNTP (under the "Advanced" menu) - this allows your router
to synchronise its date/time from public NTP servers - NOTE
that the router will often detect a significant time difference when
the date/time
is corrected, and will log you out from the web interface if you are
logged in - you will need to log in again
- Another method for updating the system date/time from a
remote time server - the "netdate"
command (this uses the
RFC868 protocol; not all time servers like this protocol, most
preferring NTP). This needs to be run manually from the command line.
The "setdate"
script provides an easy means of using this facility. It uses a default
list
of time servers (in /etc/netdate.conf),
but you can specify your own (separated by spaces) in the "time_servers" environment
variable. Use the environment variable - setdate_enable (set to 1)
for the system to run "setdate" automatically each time
it gets a WAN connection. This will also create a cron job for setdate
to be run every 4 hours or, if a second parameter is given to
setdate_enable, uses the value in that parameter - e.g., "setenv
setdate_enable 1 3"
will enable setdate, and will set the cron job to run every 3 hours).
The valid range for the second parameter is between 1 and 23
(default=4). No
error-ckecking of the value is done, so it is important to get it
right. This
feature is a low
resource alternative to msntp,
because it is not running all the time. If msntp is enabled,
then this feature is redundant. The time zone can be set
manually with the "TZ"
environment variable.
- DNS
configuration (under the "Setup" menu) - this allows you
to specify your ISP's DNS servers manually
- IPAccount
(enabled under
the "Advanced" menu, and observable under the "Status" menu) - this
allows you to see who is using all your bandwidth!
- System
Diagnostics (under the "Tools" menu) - this
gives you very detailed information about what is going on
inside your router
- Optimise
RAM
(under the "Tools" menu) - this attempts to recover RAM lost due to
memory fragmentation and leakage
- Run Command
(under the
"Tools" menu) - this allows you to run from the web configuration
interface almost any command that you can run from the login shell. Use this feature
with
CAUTION. You could easily trash your router with it. YOU HAVE BEEN WARNED!
- The ability for the router to monitor (at specified hourly
intervals) whether the external (WAN) connection is active,
and to reboot itself it it has lost its sync upon a check being made.
This feature is experimental and is only for those who know what they
are doing. The feature is enabled by making an entry for "checksync.sh"
in the bootloader environment. Entering the following command
(only once)
from the command prompt in a telnet or ssh session, and then rebooting
the router, will do the job: setenv checksync.sh
6 (this
means "do the
sync checks every 6 hours" - you can specify any number
between 1 and 24 - and if you want to turn it off, run: unsetenv checksync.sh
). See the "RT
Configurations" menu.
The test for an external connection is done by trying to ping
google.com. If you wish to change the external site being pinged from
google, then set PING_URL
in the router's environment to point to the desired external site.
- Removed the
user
"isp" and password "isp" from the
default config.xml.
The presence
of these settings in the default config.xml was a serious security
risk,
in that it meant that anyone with access to your PC can login to the
router as "isp, isp" and the begin to wreak havoc with your settings!
- Default
settings provided for several UK ISPs
- Remote
web
access
- WEP
turned on by default, and 4 default keys supplied (which should be
changed - but it does mean that the router starts with some level of
wireless security enabled)
- Extra
settings
("Channel Range", "Hairy Configuration",
and "Production 1")
added to the "Wireless"
menu - use with extreme caution!
Non-1350A firmwares only
- Extra
features
added to the "Tools"
menu ("Log Settings",
"Gateway
System Information")
- A full
ftp client
("ftp" -
for wireless routers only).
This allows you when you telnet or ssh to the router, to
ftp files in and out
- The
"small ftp server" ("sft"). This
allows you to upload files direct from your PC (via a client-side
"sft") to the router's "/var/" directory (ram disk) without having to
install an ftp server on your PC
- Scheduling programs/commands
to run at
specified times, via "cron"
(the crontab file is: "/root_cron"). You can add entries to that file
manually (in
"crontab" format) to do your scheduling, or you can use the
built-in commands: cronjob.sh
or cronjob-env.sh.
The latter makes the scheduled jobs persist between reboots of the
router. Run the scripts with no parameter to see the syntax. External
programs being run via cron must be given with their full path names.
- A "wakelan"
command - to wake up PCs on a LAN (also, "ether-wake" does a
similar thing). "wol_forward"
does the same thing, but from outside the network. "wol_forward" is
accessed by the wol_forward
environment variable - e.g., setenv wol_forward
"ppp0 br0 7" -
the parameters in double quotes are passed directly to the wol_forward
application, and contain the external interface, internal interface,
and port number.
- Extra
features enabled in Busybox applets
- No "manager_get_defaults
- !node"
bug .
- Bandwidth
throttling via the "rshaper"
feature. This allows you to limit the bandwidth by IP addresses/ranges
- plus a command to configure
it: "rshaperctl"
- e.g., "rshaperctl 192.168.1.6 32768"
(will
limit the bandwidth of the computer at 192.168.1.6 to 32kbps)
The rshaper module is NOT loaded by default. You need to enable it in
the "RT Configurations" menu.
- Bandwidth throttling
via the alternative
"netshaper"
feature (experimental
- and only for wireless firmwares). This
allows you to limit the bandwidth by IP addresses/ranges
- plus a command to configure
it: "netshaper"
e.g., "netshaper -d 192.168.1.6 32768"
(will
limit the bandwidth of the computer at 192.168.1.6 to 32kbps)
The netshaper
module is NOT loaded by default. Run this command to
enable
it: setenv
"netshaper_enable 1" && /sbin/reboot
NOTE that the
netshaper facility CANNOT be used in conjunction with rshaper. You have
to choose one or the other. Run "netshaper" without
any arguments to see the syntax.
- Facility
for executing commands on bootup - by "RT_cmd_x"
entries in the environment ("x") stands for a number or some other distinguishing
letter/number: e.g.,
setenv RT_cmd_1
"rshaperctl 192.168.1.6 32768" (will execute "rshaperctl
192.168.1.6 32768" during bootup - at the tail end of the boot process)
- Facility
for executing commands at the earliest stages of bootup - by "RT_init_x"
entries in the environment ("x") stands for a number or some other distinguishing
letter/number: e.g.,
setenv RT_init_1 "mount -t
minix /dev/mtdblock/5 /nvram" (will execute
"mount -t
minix /dev/mtdblock/5 /nvram" very early in
the boot process - and long before the commands loaded
via RT_cmd_x)
- Friendly text editor - "easyedit" (renamed "edit" in the
firmware) (for wireless
routers and non-wireless routers with 4mb flash and 16mb RAM)
- scp support -
allows you to use WinSCP
or other scp clients to upload/download files to/from the
router (for
wireless routers and non-wireless routers with 4mb flash and 16mb RAM).
Note that ssh is not supplied, so there is a limit to what can be done
with scp.
- For
wireless routers and non-wireless routers with 4mb flash and 16mb
RAM: SMBFS
support - with the command "smbmount".
This allows you to mount shared network drives on your router.
There is a ready-made mountpoint "/smbfs" that can be
used for mounting
Syntax:
smbmount //<server_ipaddress>/<share_name> <mountpoint> -o
username=MyWindowsLoginName,password=MyWindowsPassword
Example:
smbmount //192.168.1.3/scratch_drive /smbfs -o
username=freddy,password=ddyfre
This will give you read/write access (at
"/smbfs/")
to
the shared directory "192.168.1.3/scratch_drive"
WARNING: You
MUST unmount any shared drive before any attempt to upgrade a firmware,
and before turning off your router.
- For
wireless routers and non-wireless routers with 4mb flash and 16mb RAM: ftpfs support
added. This allows you to mount directories from an
ftp server onto the router. There is a
ready-made mountpoint "/ftpfs"
that can be used for mounting. Enable the ftpfs support by
running "insmod
ftpfs.o"
at a telnet/ssh login prompt and then running "ftpmount"
to do the mounting. You'd better have a decent bandwidth with your ftp
server, otherwise performance will suck.
Syntax:
ftpmount [user[:password]@]hostname[:port
][/root_dir] mount_point [-own]
[-uid=id] [-gid=id] [-fmask=mask]
[-dmask=mask] [-active]
Example:
insmod ftpfs.o
ftpmount
root:password@myftp.com/root/export /ftpfs
This will give you read/write access (at "/ftpfs/") to the
directory: directory "/root/export"
on the ftp server "myftp.com"
It is generally a good idea not to supply your password as a
parameter, since ftpmount will ask for it.
WARNING:
You
MUST unmount the ftpfs mount before any attempt to upgrade a firmware,
and before turning off your router.
- For
wireless routers and non-wireless routers with 4mb flash and 16mb
RAM: Minix
(read/write)
filesystem support. This allows you to
create read/write Minix partitions on the router.
There is a ready-made mountpoint "/nvram"
that can be
used for mounting. The makemtd.sh
command can (if you use the "auto_minix"
parameter) help you to create a minix filesystem automatically (e.g.,
"makemtd.sh
mtd5 256
auto_minix").
If you wish to create the minix filesystem manually,
then do the following:
A. create
a new mtd partition, in kilobytes - multiples of 64kb. The only valid
sizes are: 64; 128; 192; 256; 320; 384; 448; 512; 576; 640; 704; 768;
832; 896 (e.g., "makemtd.sh
mtd5 128")
B. reboot
the router
C.
convert it to minix (e.g., "mkfs.minix
/dev/mtdblock/5")
D. mount
it (e.g., "mount -t
minix /dev/mtdblock/5 /nvram")
After this, you can write/read from/to "/nvram"
E. If you
want this to be mounted
automatically during bootup, use the "RT_cmd_x" functionality
e.g. setenv RT_cmd_minix1 "mount -t
minix
/dev/mtdblock/5 /nvram"
F. The
system will look for "/nvram/startup.sh"
upon boot up, and will execute it if it is found
G. Always
unmount the partition
before rebooting, turning off the router, or flashing a new firmware
(e.g., "umount /nvram") otherwise you WILL
lose data.
DIRE WARNINGS:
1. This feature works okay in our tests
- but your mileage may vary. Do NOT
use
this feature unless you are very familiar with unbricking
bricked
routers. Most importantly, ensure that there is enough free space on
your router's flash for the partition that you want to create, or you
will get a VERY BIG crash!
2. You MUST
unmount any minix partition before rebooting or turning off the router,
and before any attempt to upgrade a firmware,
otherwise the upgrade will NOT happen!!!!!
- For
wireless routers and non-wireless routers with 4mb flash and 16mb
RAM: commands for minix filesystem support:
mkfs.minix -
create a new minix filesystem
fsck.minix -
check a minix filesystem
- Experimental
half-bridge support (see
pppHB.sh). See
here
for details and a FAQ.
- New upnp daemon based
on miniupnpd
(see readme.upnp.txt)
- Experimental script to
enable "WAN IP local NAT Loopback" (localnat.sh)
Usage: "localnat.sh
UP" to setup/refresh; "localnat.sh
init" to install and update on each ppp-up event; "localnat.sh exit"
de-installs.
- User writable /etc/ppp/ip-up
and /etc/ppp/ip-down
scripts,
currently used by half-bridge, localnat and upnp, but can be added to.
- darkstat -
(non-wireless routers with 4mb flash only) captures
network traffic, calculates statistics about usage, and serves reports
over HTTP (e.g., "darkstat -i
ppp0"). In order to see the output of darkstat, point your
brower to http://192.168.1.1:667
(or click on "Darkstat"
in the "Status" menu in the router's WEB interface). For
wireless routers, because the (closed source) wireless AP driver is
incompatible with some tcpdump packets, packets (out interface) will
get dropped, and so the stats on that interface will show zero bytes
transferred. This problem does not
exist with non-wireless firmwares. Unfortunately, since we do not have
the sources for the wireless AP driver, we cannot fix the problem with
wireless routers. Wireless routers and routers with 2mb flash can run
the fetch_ds
command. This will download darkstat from the
repository,
extract it, and run it (this will need to be done each time the router
is rebooted). The web interface to view the darkstat statistics is kept
for all firmwares.
- Support for siproxd
(wireless routers only). If the "siproxd_enable"
environment variable is set to 1, this will trigger automatic
execution of siproxd each time the router boots
up, using a default configuration file (/etc/siproxd.conf).
Its password configuration file is /etc/siproxd_passwd.cfg.
Both configuration files are extracted to the /var/tmp/ directory, and
must be fully prepared before the siproxd binary is started. You can
prepare these files with the RT_init_x
or RT_cmd_x
or autoexec.sh
commands (all these run before the siproxd binary is executed). See
also mjproxy
- a very small proxy for SIP, which uses md5 hashes.
- Support for defragmenting the router's environment from
with the firmware. All of this must be done from a telnet/ssh login session
- NOT
from the firmware's "Run Command" feature. The relevant command is: setenv DEFRAG DEFRAG
(note the capitals). The shell script auto_defragenv.sh
can be used as a shell for this. It defragments the
environment
after the fragmentation level has passed a specified threshold (default
30 for Adam2,
and 50 for PSPboot).
This can be changed by supplying "--threshold=<number>"
at the command line, or by setting
the new environment variable "DEFRAG_THRESHOLD"
to the desired number
(where "number"
stands for a positive whole number). The number should not normally be
less than 20 nor exceed 40 (Adam2)
or 60 (PSPboot).
Note that no check is done as to whether the number is sensible. The
defaults are sensible, and should normally left well alone. The command
line parameters take precedence over any value in "DEFRAG_THRESHOLD".
Example: auto_defragenv.sh
--threshold=35
These
commands must only be run as a last
resort.
As with any low-level operation that writes to the router's flash chip,
things can go badly wrong. The recommended way to defragment
the
Adam2 bootloader environment is to run "fixenv" from the
bootloader command prompt. The recommended way to defragment
the PSP bootloader environment is to run "defragenv" from the
bootloader command prompt. You will need a serial console to run
commands from the bootloader command prompt.
- Support for resetting the router's configuration to
defaults from the firmware's linux command line (with the reset-config.sh
command).
- Relaying multicast UDP traffic to a
client's TCP (HTTP) connection (unicast) through udpxy. This allows you to
use IP TV
(UDP multicast) services via wifi.
- Ad blocking, through adblock.sh
and adblock_multi.sh.
For this purpose, adblock.sh
downloads
and converts one of a number of common internet resources ("small",
"medium", "large", or "xlarge") of ad servers
to be blocked. The largest of these uses a lot of cpu cycles on the
router (about 20%) - but since the
router's cpu is largely idle most of the time, this is not a
major issue. The smallest consumes only about 5% cpu cycles. Run adblock.sh with no
parameters to see the syntax. adblock_multi.sh
is a shell to adblock.sh,
allowing it to download more than one of the internet lists at once
(e.g., "adblock_multi.sh exit small large").
Note that, for routers with low memory (i.e., 8mb RAM), you should never
use "large" or "xlarge". In fact, "small" is the only one that
such routers will be able to cope with. If you try to download
more
lists than your free memory can cope with, your router WILL crash!
NOTE:
you MUST
always run "adblock.sh exit"
to remove the adblock features from memory, before any attempt to
upgrade the firmware.
- pixelserv
- a tiny webserver that serves up a single pixel to any request. It is
useful for blocking adverts in conjunction with adblock.sh.
- dnsmasq
- its dns caching functions only (not
LAN dhcp). The code has been patched, to
reduce size by disabling unused options and functions, to ignore
command line
parameters, and to do all configuration by configuration file.
Additional conf files can be added to /tmp/dns.d/. dnsmasq supports
many options and enables additional functions such as auto selection of
the fastest responding dns server from all configured, and domain
blocking - exploited by the adblock
functions.
- A hook to run a user-supplied script (/var/tmp/onclose.sh)
when before rebooting or shutting down the router via the reboot or shutdown commands. When
either command is executed, it will first search for "/var/tmp/onclose.sh",
and, if it is found, it will be executed immediately. After this, the
normal house-cleaning on reboot/shutdown will continue.
- Support for adding extra DNS servers from a selection ("All",
"OpenDNS",
"FamilyShield",
"Google",
"UltraDNS",
"DNSResolvers",
or "BT")
in
dnsmasq format. You can set the "extra_dns"
environment variable to any of these, to a combination of them, or to
"All", and you can use
either their full names, or the first letter of their names - e.g., setenv extra_dns "F
U D B" -
will select DNS servers from OpenDNS Family Shield, UltraDNS,
DNSResolvers, and BT; setenv
extra_dns "A" or setenv extra_dns "1"
will select all of them.
- Support for adding all the extra DNS servers listed above, in
resolv.conf format through the environment variable: extra_resolvers. These
servers are prepended to /etc/resolv.conf. In the TWNETW1350A
firmware, only the first three will be used.
- Support for static DNS servers in DHCP connections (as
opposed to pppoa/pppoe connection), via the environment variable: static_dns. Set it to 1 to prevent the dhcp
server from
overwriting your static DNS entries.
- Support for blocking a large number of "bad" sites (porn,
weapons, etc.) via the block_baddies.sh
command, using OpenDNS "Family
Shield" and the adblock features. This command must be run
from a telnet/ssh login session. If the parameter "--block_thumbs"
is supplied, then thumbnails from google image searches will also be
blocked. This command only needs to be run ONCE. After that, it will
run by itself on every bootup. To remove the blocks, run "block_baddies_undo.sh" (see
below).
- Support for OpenVPN (wireless
and 4mb-flash non-wireless firmwares only). See "openvpn.sh"
below, and OpenVPN RouterTech HowTo.pdf.
- Support for pptp-based VPNs (wireless
and 4mb-flash non-wireless firmwares only). This comes via the "pptpd" command. This version is based on Poptop.
- Protection from DNS rebind attacks, using the block_rebind.sh script or by using the http_addr environment variable.
- Experimental support for using a swap file via smbfs. See the swapfile.sh script below.