From wiliGear wiki

Contents 1 WILI-S Configuration File 2 Network Configuration 2.1 Interface 2.2 The Bridge 2.3 DHCP 2.3.1 DHCP Client 2.3.2 DHCP Server 2.3.3 DHCP Relay 2.4 DNS 2.5 DNS Forwarder 2.6 Dynamic DNS 2.7 VLAN 2.8 Routing 2.8.1 Static Source Routing 2.8.2 Selective Source Routing 2.8.3 Dynamic Routing 2.9 IPsec 2.10 IPsec Racoon 2.11 GRE 2.12 VTun Tunneling 2.13 PPPoE 3 Wireless Settings 3.1 Wireless Radio 3.2 Wireless Interface 3.3 AutoLock WLAN 3.4 VSSID 3.5 WDS 3.6 Wireless ACL 3.7 Wireless Client Bridge 3.8 Station Supervision 4 Network Access Configuration 4.1 AAA (Authentication Authorization and Accounting) 4.1.1 Network Access Server (NAS) 4.1.2 RADIUS Authentication Servers 4.1.3 RADIUS Accounting Servers 4.1.4 RADIUS Domains (WISPs) 4.1.5 Universal Access Method (UAM) 4.1.6 Dynamic WEP Security Profile 4.1.7 WPA/WPA2 Security Profile 4.1.8 RADIUS Proxy 4.1.9 WPA/802.1x Supplicant 4.1.10 802.1x Supplicant 4.2 IP Firewall 4.2.1 Rules Configuration 4.2.2 Rule Matches 4.2.2.1 Implicit matches 4.2.2.2 ICMP matches 4.2.2.3 Explicit matches 4.2.2.4 IPP2P 4.2.3 Rule Targets 4.2.3.1 ACCEPT target 4.2.3.2 DNAT target 4.2.3.3 DROP target 4.2.3.4 LOG target 4.2.3.5 MARK target 4.2.3.6 MASQUERADE target 4.2.3.7 QUEUE target 4.2.3.8 REDIRECT target 4.2.3.9 REJECT target 4.2.3.10 RETURN target 4.2.3.11 SNAT target 4.2.3.12 TOS target 4.2.3.13 TTL target 4.2.3.14 ULOG target 4.2.3.15 NAS_MARK target 4.2.4 Another Firelwall Rule Definition Method 4.3 Bridging Firewall 4.3.1 Rules Configuration 4.3.2 Rule Matches 4.3.3 Match Extensions 4.3.3.1 802.3 matches 4.3.3.2 ARP matches 4.3.3.3 IP matches 4.3.3.4 Mark matches 4.3.3.5 Packet type matches 4.3.3.6 STP matches 4.3.3.7 VLAN matches 4.3.4 Watcher Extensions 4.3.4.1 LOG 4.3.5 Target Extensions 4.3.5.1 arpreply 4.3.5.2 dnat 4.3.5.3 mark 4.3.5.4 redirect 4.3.5.5 snat 4.3.5.6 arpnat 4.3.5.7 macvlan 4.4 SMTP Redirection 4.5 White/Black List 4.6 Static Bandwidth Control 5 Management Access Configuration 5.1 Skins 5.2 SSH Server 5.3 HTTP(S) Server 5.4 SNMP Agent 5.5 System Users 5.6 User Authentication 5.7 RCMS Client 5.8 Network Usage Statistics 5.9 IP Multicasting Based Device Discovery 6 System Services Configuration 6.1 Manual Clock regulation 6.2 NTP Client 6.3 Trace System 6.4 Syslog 6.5 IP Logging 6.6 Forker Daemon 6.7 Sysctl Plugin 6.8 System Modules 7 MESH 7.1 WILI Scout

WILI-S Configuration File

The keys of the configuration file in this manual are provided for WILI-S 5.00 firmware version and later therefore they may differ from the keys of 3.54 firmware and former versions.

The WILI configuration file is a text file consisting of <key>=<value> assignments, one assignment per line. Modified configuration will become active after device reboot. The keys are case sensitive. Whitespace around keys and values is insignificant and it will be removed automatically after reboot. If duplicate keys are found, the first one is left and all the others are removed irrespective of the value assigned to those keys.

If the first character after whitespace on line is a "#" character, text between that character and the end of the same line is a comment. Comment lines and blank lines are ignored and may be added to make the file easier to read.

Example:

  # this line is a comment
  netconf.1.devname=ixp1
  netconf.1.ip=192.168.2.5
  netconf.1.netmask=255.255.255.0

In the example above keys have index “1” and describe the settings of ixp1 interface. The index indicates functionally similar items and it will be specified as <index> in the configuration file descriptions, eg., netconf.<index>.devname, netconf.<index>.ip, netconf.<index>.netmask.

The configuration file location on local WILI file system is /tmp/system.cfg. The configuration file can be changed or a new file can be uploaded using Web interface. It is also possible to manually update device configuration. Follow these steps:

• make sure that SSH server is running (see section SSH Server below for details)

• login to device with secure SFTP client

• upload new configuration file to /tmp/system.cfg

• login through SSH, type shell command to exit to shell (see document CLI Access)

• execute sysconf –w

• reboot the device.

Some keys can have default values, others can be unused or have to be explicitly specified for some feature to work correctly. These keys and their values will be printed through local syslog facility to a system log file. The system log file on WILI is /var/log/messages. Logging can be redirected to a remote host (see section Syslog Configuration).

Example: An excerpt from default system log file:

 Jan 1 00:00:06 sysconf[89]: Using default value: 'disabled' for non existing bool key: 'aaa.nas.1.verbose'
 Jan 1 00:00:06 sysconf[89]: Unused key: netconf.1.type=Ethernet

Network Configuration

This section describes settings of physical and logical network interfaces. This includes physical LAN and WAN interface settings, DNS settings, DHCP settings, AAA settings, tunnels and wireless interface settings.

Interface

The physical network interfaces can be configured to work as either local area network (LAN) or wide area network (WAN) interfaces. LAN is used to connect hubs, switches, Access Points and other devices on a subscriber side, while the WAN port connects to the Internet service provider’s (ISP) network.

All available keys of the network interface configuration are listed below:

netconf.status – specify the interface configuration feature status [enabled/disabled]. In general this key should always be specified and set to enabled.

netconf.<index>.status – specify current network interface status [enabled/disabled].

netconf.<index>.devname – specify the interface name [lo/ixp0/ixp1/ath0/logical interface name]. The physical interface names are:

• lo – local loopback interface
• ixp0 – LAN interface
• ixp1 – WAN interface
• ath0 – wireless interface

Logical interface names will be described in the following sections.

netconf.<index>.type – specify the interface type [loopback/wireless/ethernet/bridge/gre].

netconf.<index>.mode – specify the interface mode [lan/wan].

netconf.<index>.up – specify the interface status [enabled/disabled]. This value causes the interface to be activated, or the driver for this interface to be shut down.

netconf.<index>.ip – specify the interface IP address, eg. 192.168.5.1.

netconf.<index>.netmask – specify the interface subnet mask, eg. 192.168.5.0.

netconf.<index>.broadcast – specify the interface broadcast IP address, eg. 192.168.5.255.

netconf.<index>.alias.status – specify the interface alias functionality status [enabled/disabled]. This enables/disables all interface aliases. Default: disabled.

netconf.<index>.alias.<index>.status – specify current alias status [enabled/disabled].

netconf.<index>.alias.<index>.ip – specify the IP address for the interface alias. This key may be used as aliased IP range start, used together with netconf.<index>.alias.<index>.ip_range_end key.

netconf.<index>.alias.<index>.ip_range_end – specify the aliased IP range end. This key is used with netconf.<index>.alias.<index>.ip which means the aliased IP range start.

netconf.<index>.alias.<index>.netmask – specify the subnet mask for the interface alias, eg. 192.168.6.0.

netconf.<index>.alias.<index>.broadcast – specify the broadcast IP address for the interface alias, eg. 192.168.6.255.

netconf.<index>.mcast.status – specify the multicast address status [enabled/disabled]. Default: disabled. The multicast keys are used to attach a static link layer multicast address to listen on the interface. They only manage link layer addresses.

netconf.<index>.mcast.<index>.lladdress – specify the multicast link layer address.

netconf.<index>.mcast.<index>.address – specify the multicast IPv4 address, will be remapped by plugin to link layer.

netconf.2.mcast.status=enabled 
netconf.2.mcast.1.address=01:00:5e:00:00:0a
netconf.2.mcast.1.address=224.192.16.1  

netconf.<index>.allmulti - specify the status of all-multicast mode [enabled(default)|disabled]. default: disabled. If enabled, all multicast packets on the network will be received by the interface.

netconf.<index>.mac – specify the interface MAC address [colon separated 6 hexadecimal value pairs, eg. 03:FA:45:10:BA:44].

netconf.<index>.promisc – specify the promiscuous mode status [enabled/disabled]. If enabled, all packets on the network will be received by this interface.

netconf.<index>.mtu – specify the MTU size in B [integer]. Default: 1500. MTU is the largest physical packet size, measured in bytes, that a network can transmit. Any messages larger than the MTU are divided into smaller packets before being sent.

The following keys autoneg, advertise, speed and duplex in netconf.* section applies to Ethernet devices only. These keys allows you to control at what speed and duplexity device Ethernet is allowed to be connected in the network.

netconf.<index>.autoneg – specify status of auto negotiating [enabled/disabled]. Default: enabled.

netconf.<index>.advertise – specify advertise [auto/number]. Default: auto. This key is usable when autoneg key is enabled.

• 0x001 – 10baseT-HD'
• 0x002 – 10baseT-FD'
• 0x003 – 10baseT'
• 0x004 – 100baseTx-HD'
• 0x008 – 100baseTx-FD'
• 0x00C – 100baseTx'
• 0x010 – 1000baseTx-HD'
• 0x020 – 1000baseTx-FD'
• 0x030 – 1000baseTx'
• 0x03F – auto (combination of all above)

netconf.<index>.speed – specify Ethernet link speed between switch and WILI device in Mbps [10/100/1000].

netconf.<index>.duplex – specify duplexity of the Ethernet link [half/full].

Example 1:

 netconf.1.autoneg = disabled
 netconf.1.advertise = auto
 netconf.1.speed = 10
 netconf.1.duplex = half

Ethernet is allowed to connected at fixed 10Mbps speed, duplex will be set to half. The advertise makes no sense when auto negotiation (autoneg key) is disabled.

Example 2:

 netconf.1.autoneg = enabled
 netconf.1.advertise = auto
 netconf.1.speed = 10
 netconf.1.duplex = half

Ethernet is allowed to negotiate best speed and duplexity. Parameters speed and duplex will be ignored when autoneg is enabled. It is up to Ethernet driver to decide which exactly speed , duplexity must be used, according advertise

• 10baseT/Half
• 10baseT/Full
• 100baseT/Half
• 100baseT/Full

Speed and duplexity chosen depends on link partner capabilities in this case.

Example:

 netconf.1.devname=ixp1
 netconf.1.netmask=255.255.255.0
 netconf.1.ip=192.168.2.220
 netconf.1.up=enabled
 netconf.1.mode=wan
 netconf.1.type=Ethernet
 netconf.1.promisc=disabled
 netconf.1.alias.status=enabled
 netconf.1.alias.1.status=enabled
 netconf.1.alias.1.ip=192.168.2.16
 netconf.1.alias.2.status=enabled
 netconf.1.alias.2.ip=192.168.2.17
 netconf.1.alias.3.status=enabled
 netconf.1.alias.3.ip=192.168.2.200
 netconf.1.alias.3.ip_range_end=192.168.2.210

The configuration in example means, that there will ixp1 interface configured to have 192.168.2.220 as a primary IP address on interface, netmask is set 255.255.255.0, default gateway 192.168.2.1, interface is up. Also, see alias, this tells to configure ixp1 to have such ip addresses as well (aliased IP addresses):

• 192.168.2.16
• 192.168.2.17
• 192.168.2.200-192.168.2.210, range starting 200 and ending 210 (11 IP addresses)

Alias IP addresses are added with 32 bit netmask(255.255.255.255). It is user's responsibility to define routes for these addresses in configuration file.

The Bridge

A bridge transparently relays traffic between multiple network interfaces. Bridge is identified by a custom interface name. It is basically a container for other interfaces.

There are some restrictions for bridge management that shall be taken into account:

• It is not possible to add a device to multiple bridges.
• The WAN interface cannot be added into a bridge.
• VLANs cannot be created on bridge interfaces they can only be added to them.
• A bridge cannot be included into another bridge.

All available keys of the bridge configuration are listed below:

bridge.status – specify the bridge feature status [enabled/disabled]. Default: disabled.

bridge.<index>.status – specify current entry status [enabled/disabled]. Default: enabled.

bridge.<index>.devname – specify the bridge interface name [custom string up to 15 characters in length, eg. br0, mandatory].

bridge.<index>.stp.status – define the STP (Spanning Tree Protocol) status [enabled/disabled]. Default: disabled.

If you are running multiple or redundant bridges, then you need to enable the Spanning Tree Protocol (STP) to optimize multiple hops and avoid bridging loops. Normally redundant bridges would result in duplicated packets which would saturate the connected networks. Bridges configured to use STP negotiate the shortest possible link between the connected networks and disable all other possible links. If a link fails STP recalculates the links and can enable a workaround for the failed link. For the bridge to take part in this negotiation, the STP must be enabled. It is disabled by default when creating the bridge.

Each bridge has a relative priority and cost. Each interface is associated with a port (number) in the STP code. The priority and cost are used to decide which is the shortest path to forward a packet. The lowest cost path is always used unless the other path is down. If you have multiple bridges and interfaces you may need to adjust the priorities to achieve optimum performance.

If your bridge is not the only bridge on the LAN, or if there are loops in the LAN topology, STP is strongly recommended.

The STP protocol first elects a root bridge. The root bridge is the bridge with the lowest priority in the network. If several bridges have the same priority assigned the bridge with the lowest MAC address is chosen. The root bridge is the "central" bridge in the spanning tree.

It is recommended not to use more than one VLAN or VSSID in the bridge, otherwise in some network topologies (using switches) the bridge may not work as expected.

bridge.<index>.priority – specify the bridge priority [0-65535]. Default: 32768.

bridge.<index>.fd – specify the forwarding delay time [0-65535]. Forwarding delay time is the time spent in each of the listening and learning states before the forwarding state is entered. Default: 15.

bridge.<index>.hello – specify the interval between hello packets in seconds [0-65535]. Hello packets are used to communicate information about the topology throughout the entire bridged LAN. Default: 2.

bridge.<index>.ageing – define the interface hardware (MAC) address ageing time, in seconds [0-65535]. The ageing time is the number of seconds a MAC address will be kept in the forwarding database after receiving a packet from this MAC address. The entries in the forwarding database are periodically timed out to ensure that old ones do not persist in the database. Default: 300.

bridge.<index>.maxage – specify the maximum bridge message age in seconds [0-65535]. If the last received hello packet is more than this value, the bridge in question will initiate the root bridge election procedure. Default: 20.

bridge.<index>.port.<index>.status – specify current bridge port status [enabled/disabled]. Default: disabled.

bridge.<index>.port.<index>.devname – specify the interface name to be added into bridge (physical interface, VLAN or GRE tunnel).

bridge.<index>.port.<index>.path.cost – specify the port’s path cost on this interface [0-65535]. This metric is used in the designated port and root port selection algorithms. Default: 100.

bridge.<index>.port.<index>.priority – specify the priority of ports with equal cost [0-255]. You can use this to control which port gets used when there are redundant paths. Default: 128.

bridge.arptables – if enabled it will pass bridged ARP traffic to arptables' FORWARD chain [enabled/disabled]. Default: enabled.

bridge.iptables – if enabled it will pass bridged IPv4 traffic to iptables' chains [enabled/disabled]. Default: enabled.

bridge.ip6tables – if enabled it will pass bridged IPv6 traffic to ip6tables' chains [enabled/disabled]. Default: enabled.

bridge.vlan – if enabled it will pass bridged vlan-tagged ARP/IP/IPv6 traffic to {arp,ip,ip6}tables [enabled/disabled]. Default: enabled.

Example:

 # create bridge br0 with ixp0 and ath0 interfaces
 bridge.status=enabled
 bridge.1.status=enabled
 bridge.1.ageing=300
 bridge.1.devname=br0
 bridge.1.fd=1
 bridge.1.hello=20
 bridge.1.maxage=300
 bridge.1.port.1.status=enabled
 bridge.1.port.1.devname=ixp0
 bridge.1.port.2.status=enabled
 bridge.1.port.2.devname=ath0
 bridge.1.priority=2
 bridge.1.stp.status=disabled

DHCP

The WILI device can act as DHCP (Dynamic Host Configuration Protocol) client, DHCP server and/or as a DHCP relay gateway. The DHCP service is supported on both physical and logical interfaces.

DHCP Client

Configured DHCP client will try to get an IP lease immediately on WILI startup.

All available keys of the DHCP client are listed below:

dhcpc.status – specify the service status [enabled/disabled]. Default: disabled.

dhcpc.background – allows to enable the device not to wait for IP address and start a boot process [enabled/disabled]. Default: disabled.

In case the key dhcpc.background is enabled and the device starts the boot process without IP address, the following services will not be started: NTP server Static Routing feature DNS Forwarder Dynamic DNS Syslog Wireless Client Bridge Station Supervision AAA AutoLock WLAN

dhcpc.<index>.status – specify the DHCP client status [enabled/disabled]. Default: enabled.

dhcpc.<index>.devname – specify the interface on which you want to enable the DHCP client.

Example:

  # enable DHCP client on ixp1 interface 
 dhcpc.status=enabled
 dhcpc.background=disabled
 dhcpc.1.status=enabled
 dhcpc.1.devname=ixp1

DHCP Server

The DHCP server assigns clients on the LAN dynamic IP addresses. The server is supported on physical and logical LAN interfaces. Each LAN interface runs a separate DHCP server instance.

All available keys of the DHCP server are listed below:

dhcpd.status – specify the feature status [enabled/disabled]. Default: disabled.

dhcpd.<index>.status – specify the DHCP server status [enabled/disabled]. Default: enabled.

dhcpd.<index>.devname – specify the name of interface on which you want to configure the DHCP service [interface name, mandatory].

dhcpd.<index>.start – specify the starting IP address of the DHCP address pool [IP address, mandatory].

dhcpd.<index>.end – specify the ending IP address of DHCP address pool [IP address, mandatory].

dhcpd.<index>.gateway – specify the gateway IP address.

dhcpd.<index>.netmask – specify the netmask.

dhcpd.<index>.dns.1.status – specify the primary DNS server status [enabled/disabled]. Default: enabled.

dhcpd.<index>.dns.1.server – specify the primary DNS server IP address.

dhcpd.<index>.dns.2.status – specify the secondary DNS server status [enabled/disabled]. Default: enabled.

dhcpd.<index>.dns.2.server – specify the secondary DNS server IP address.

dhcpd.<index>.lease_time – specify the IP address lease interval in seconds [1-4294967295]. Default: 864000.

dhcpd.<index>.wins – specify WINS server IP address.

dhcpd.<index>.domain – specify the DHCP domain name [1-128 character string].

Example:

# configure the DHCP server:
dhcpd.status = enabled
dhcpd.1.devname = ixp1
dhcpd.1.start = 192.168.4.2
dhcpd.1.end = 192.168.4.254
dhcpd.1.gateway = 192.168.4.1
dhcpd.1.netmask = 255.255.255.0
dhcpd.1.dns.1.server = 212.59.0.1
dhcpd.1.lease_time = 10000

DHCP Relay

The DHCP relay forwards DHCP messages between subnets with different sublayer broadcast domains.

In public access or large-scale enterprise wireless networks where two or more gateways (APs/NASs) may be used to connect wireless clients to LAN there is a need to have one centralized DHCP server. DHCP server may be used to serve IP addresses, DNS server addresses and other relevant information for large LAN based network and/or for NAT'ing to allow clients to reach Internet. One or more APs may be used as relays to pass DHCP requests to the central DHCP server and send DHCP server responses back to clients.

DHCP relay won’t work if there is a DHCP server or client started on the same LAN interface.

Depending on your network configuration, you may need to add firewall rules to allow clients unrestricted access to DHCP service ports on DHCP servers. This is needed because after negotiating a DHCP lease, a client talks to DHCP server directly and not through DHCP relay. See section IP Firewall Configuration for details.

The available keys of the DHCP Relay feature are listed below:

dhcp-fwd.status – specify the DHCP relay service status [enabled/disabled]. Default: disabled

dhcp-fwd.server.<index>.status – specify current service status [enabled/disabled]. Default: enabled.

dhcp-fwd.server.<index>.devname – specify the WAN interface name through which the DHCP server could be reached [string, interface name].

dhcp-fwd.server.<index>.ip – specify the DHCP server IP address [IP address or string “bcast”]. Specifying “bcast” allows broadcasting DHCP request on WAN when no unicast server address is known.

dhcp-fwd.client.<index>.status – specify the status of client interface [enabled/disabled]. Default: enabled.

dhcp-fwd.client.<index>.devname – specify the client interface name. This parameter defines a LAN interface where DHCP clients reside. A few interfaces may be defined.

dhcp-fwd.client.<index>.circuit_id – specify the client circuit id [string]. Every client interface (LAN) may have their unique identifier. As the circuit id could be used NAS-ID, NAS-MAC or NAS-IP. Refer to section AAA Configuration for details about NAS settings. The DHCP servers can provide IP addresses from different address pools depending on a circuit id. Please refer to RFC 3046 for details.

Example 1:

# simple configuration with one client interface (LAN) and one server
# interface (WAN):
dhcp-fwd.status=enabled
dhcp-fwd.server.1.status=enabled
dhcp-fwd.server.1.devname=ixp1
dhcp-fwd.server.1.ip=bcast
dhcp-fwd.client.1.status=enabled
dhcp-fwd.client.1.devname=ath0

Example 2:

 # configuration to show all the possible features:
dhcp-fwd.status=enabled
dhcp-fwd.server.1.status=enabled
dhcp-fwd.server.1.devname=ixp1
dhcp-fwd.server.1.ip=192.168.2.125
dhcp-fwd.server.2.status=enabled
dhcp-fwd.server.2.devname=ixp2
dhcp-fwd.server.2.ip=bcast
dhcp-fwd.client.1.status=enabled
dhcp-fwd.client.1.devname=ath0
dhcp-fwd.client.1.circuit_id=MY_NAS_ID_1
dhcp-fwd.client.2.status=enabled
dhcp-fwd.client.2.devname=ixp0
dhcp-fwd.client.2.circuit_id=MY_NAS_ID_2

To successfully setup DHCP relay on a router it is necessary to make DHCP Server possible of reaching addresses which are sent in 'giaddr' (Relay agent IP address) field of DHCP packets. This allows routing server to reply back to clients through gateway which is of course DHCP relay as well.

E.g, on DHCP server machine:

 route add -net <client_subnet> netmask <client_netmask> gw <relay_ip>

On a router with AAA enabled a firewall rule is necessary which allows clients to send/receive DHCP packets unrestricted. This is needed because after negotiating a lease from a DHCP client talks to DHCP server directly and not through DHCP relay.

DNS

Maximum 3 name servers and 6 domain search entries can be specified.

Setup the DNS (Domain Name Service) service that translates Internet host names into their IP addresses.

All available keys of the DNS configuration are listed below:

resolv.status – specify the DNS status [enabled/disabled].

resolv.nameserver.<index>.status – specify current DNS server status [enabled/disabled]. Default: enabled.

resolv.nameserver.<index>.ip – specify the IP address of the DNS server [IP address, mandatory].

resolv.search.<index>.status – specify the status [enabled/disabled]. Default: enabled.

resolv.search.<index>.domain – specify the domain name to use for DNS lookups when no domain is specified [domain name, eg. mycompany.net]. Specified domains will be checked in turn until a match is found.

resolv.host.<index>.status – specify current host entry status [enabled/disabled]. Default: enabled.

resolv.host.<index>.ip – specify the IP address of the hostname [IP address, mandatory].

resolv.host.<index>.name – specify the canonical hostname [hostname string, mandatory].

resolv.host.<index>.alias.<index>.status – specify the parameter status [enabled/disabled]. Default: enabled.

resolv.host.<index>.alias.<index>.name – specify the alias [hostname string]. Aliases are used for name changes, alternate spellings, shorter hostnames, or generic hostnames (eg., localhost).

Example:

 resolv.status=enabled
resolv.nameserver.1.ip=204.74.112.1
resolv.nameserver.2.ip=204.74.112.2
resolv.search.1.domain=domain1.net
resolv.search.2.domain=domain2.net
resolv.host.1.ip=127.0.0.1
resolv.host.1.name=host.domain1.net
resolv.host.1.alias.1.name=fireball
resolv.host.1.alias.2.name=localhost.localdomain
resolv.host.1.alias.3.name=localhost

DNS Forwarder

DNS request forwarder, called DNSMASQ, intercepts all DNS requests from wireless/LAN clients and forwards them to a particular DNS server(s) which may be defined in the system configuration file or dynamically obtained through DHCP lease (forwarder will check for changes to system’s DNS settings on every DNS request). Forwarder has a cache which speeds up DNS requests and reduces network traffic. It listens on the standard DNS TCP and UDP ports 53 on interfaces specified in the configuration file. Two firewall rules are required for forwarder to function correctly.

The available keys of the DNS forwarder feature are listed below:

dnsmasq.status – specify the DNSMASQ feature status [enabled/disabled].

dnsmasq.<index>.status – specify current DNSMASQ entry status [enabled/disabled].

dnsmasq.<index>.devname – specify the input interface name.

The example below shows setup of the firewall configuration specific to DNSMASQ. Refer to section IP Firewall Configuration for further firewall configuration details.

Example:

# configure DNSMASQ on ath0 interface
# first configure redirection of DNS ports
firewall.status=enabled
firewall.rule.1.table=nat
firewall.rule.1.chain=PREROUTING
firewall.rule.1.protocol=TCP
firewall.rule.1.in=ath0
firewall.rule.1.dport=53
firewall.rule.1.target=REDIRECT
firewall.rule.2.table=nat
firewall.rule.2.chain=PREROUTING
firewall.rule.2.protocol=UDP
firewall.rule.2.in=ath0
firewall.rule.2.dport=53
firewall.rule.2.target=REDIRECT
# enable DNSMASQ on ath0
dnsmasq.status=enabled
dnsmasq.1.devname=ath0

Dynamic DNS

The DNS client maintains the IP address of a host name. It periodically checks whether the IP address of the current machine (the external visible IP address of the machine that runs INADYN) has changed. If yes it performs an update in the dynamic dns server.

Following configuration keys are used by inadyn:

inadyn.status – specify status of dynamic DNS [enabled/disabled]. Default: disabled.

inadyn.username – specify the username [string].

inadyn.password – specify the password [password].

inadyn.alias.<index>.value – specify the host name alias, for example system.dyndns.org [string].

inadyn.update_period – specify the update period in seconds, max is 10 days = 10 * 24 * 3600 [integer]. Default 60 sec.

inadyn.system – specify the DYNDNS service type [string]. Default: dyndns@dyndns.org. Possible service types are:

• for dyndns.org: dyndns@dyndns.org OR statdns@dyndns.org OR customdns@dyndns.org
• for freedns.afraid.org: default@freedns.afraid.org
• for zoneedit.com: default@zoneedit.com
• for no-ip.com: default@no-ip.com
• for easydns.com: default@easydns.com
• for 3322.org: dyndns@3322.org

Example:

inadyn.status=enabled
inadyn.username=myusername
inadyn.password=mypassword
inadyn.update_period=180
inadyn.system=dyndns@dyndns.org
inadyn.alias.1.value=3gear.dyndns.org

For this example inadyn sysconf plugin will generate /etc/inadyn.conf file containing:

username myusername 
password mypassword 
alias 3gear.dyndns.org 
update_period_sec 180 
dyndns_system dyndns@dyndns.org 
syslog

VLAN

Up to 4094 VLANs can be created on the system.

Virtual Local Area Networks (VLANs) are logical groupings of network resources, eg. public access users can be separated from company Intranet users using VLANs on the ethernet interface. Access control policies can be applied on a per-VLAN basis. VLANs are uniquely identified by VLAN id number. Setting up VLAN on physical interface will create virtual network interface named like physical interface with dot and VLAN id appended, eg. setting VLAN with id 10 on interface ixp0 will create virtual interface called ixp0.10.

All available keys for VLAN configuration are listed below:

vlan.status – specify the VLAN feature status [enabled/disabled]. Default: disabled.

vlan.<index>.status – specify the VLAN status [enabled/disabled]. Default: enabled.

vlan.<index>.parent – specify the LAN interface name to make VLAN on.

vlan.<index>.id – assign ID for your VLAN network [2-4095]. Devices configured with the same ID (eg. access points) are logically grouped into this VLAN.

Per-VLAN QoS offers differentiated quality of services to individual VLANs on a trunk port. A per-VLAN service policy can be separately applied to either ingress or egress traffic.

vlan.<index>.priority_in – specify either manual or auto mappings for ingress packets will be set [auto/manual]. Default: manual.

vlan.<index>.priority_out – specify either manual or auto mappings for egress packets will be set [auto/manual] Default: manual.

The ingress mapping - maps VLAN QoS field (3bits) to local packet priority field (32bits).

vlan.<index>.prio_in_map.<index>.vlan_qos – specify the ingress VLAN priority in bits [0..7].

vlan.<index>.prio_in_map.<index>.pkt_prio – specify the ingress packet priority in bits [0..0x7fffffff].

The egress mapping - maps local packet priority field to VLAN QoS field:

vlan.<index>.prio_out_map.<index>.vlan_qos – specify the egress VLAN priority in bits [0..7].

vlan.<index>.prio_out_map.<index>.pkt_prio – specify the egress packet priority in bits [0..0x7fffffff].

If vlan.<index>.priority_in/out=manual, user configured mappings for ingress/regress packets will be set. If no mapping found, will map to 0 (same as default without any mappings); if vlan.<index>.priority_in =auto, 0:0, 1:1,..7:7 mappings will be generated.

Example:

# configure VLAN id 10 on ixp0
vlan.status=enabled
vlan.1.parent=ixp0
vlan.1.id=10

Routing

This sysconf plugin manipulates the kernel's IP routing tables. Its primary use is to set up static routes to specific hosts or networks via an interface after it has been configured. That is IP address, netmask and broadcast addresses are assinged to an interface. Interfaces must be up, otherwise any attempt to install routing entries will be rejected by the kernel.

Kernel consults routing entries, when deciding which interface to use to dispatch the packet. Route entries are scanned using packet's destination IP address. If none matched, kernel dispatches packet through a default route (to a next known gateway which must be reachable and on the same LAN network as device). If routing decision is made based on source IP address that would be a source routing instead, read Source Routing section below.

Available Keys:

route.status - specify general status of routing service on a device [enabled/disabled]. Default: disabled.

route.ip_forward - specify IP Forwarding status [enabled/disabled]. If disabled, no routing or bridging will take place. Packet received on one interface will not be forwarded via another interface.

route.<index>.status - specify status of the particular routing entry [enabled/disabled]. Default: enabled. If enabled, the following routing entry will be installed in the routing stack, otherwise entry is omitted.

route.<index>.devname - specify interface name of an existing network interface on device [interface name].

route.<index>.gateway - specify gateway IP address [ip address]. This value is optional if gateway is not used. When specifying gateway prefer numeric IP address instead of FQDN (it is bad to assume that DNS service is configured correctly or interfaces are already configured and DNS server is reachable).

route.<index>.ip - specify Target IP address [ip address]. Ip address can be a network address or host ip address. The difference between two is that netmask length.

route.<index>.netmask - specify Target netmask in bits, e.g. 24 [netmask]. Optional if host route.

Example: creates the following routing entries : IP addresses 192.168.4.0/24 are reachable on interface ixp0 (LAN). IP addresses 192.168.2.0/24 are reachable on interface ixp1 (WAN). Creates a host route to 192.168.3.3 via 192.168.2.3 as a gateway. Adds '192.168.2.1' as a default gateway.

route.<index>.type - specify route type [unicast/local/broadcast/multicast/throw/unreachable/prohibit/blackhole].

• unicast - the route entry describes real paths to the destinations covered by the route prefix.

• unreachable - these destinations are unreachable. Packets are discarded and the ICMP message host unreachable is generated. The local senders get an EHOSTUNREACH error.

• blackhole - these destinations are unreachable. Packets are discarded silently. The local senders get an EINVAL error.

• prohibit - these destinations are unreachable. Packets are discarded and the ICMP message communication administratively prohibited is generated. The local senders get an EACCES error.

• local - the destinations are assigned to this host. The packets are looped back and delivered locally.

• broadcast - the destinations are broadcast addresses. The packets are sent as link broadcasts.

• throw - a special control route used together with policy rules. If such a route is selected, lookup in this table is terminated pretending that no route was found. Without policy rout‐ ing it is equivalent to the absence of the route in the routing table. The packets are dropped and the ICMP message net unreachable is generated. The local senders get an ENETUNREACH

• multicast - a special type used for multicast routing. It is not present in normal routing tables.

route.status = enabled
route.ip_forward = enabled
route.1.ip = 192.168.4.0    # network address
route.1.netmask = 24        # 255.255.255.0
route.1.devname = ixp0 
route.2.ip = 192.168.2.0    # network address
route.2.netmask = 24        # 255.255.255.0
route.2.devname = ixp1 
...
# disabled entry, host route tells the 192.168.3.3 is reacable via 192.168.2.3 gw
route.12.status = disabled
route.12.ip = 192.168.3.3   # host ip address
route.12.netmask = 32       # or can be omitted entirely.
route.12.gateway = 192.168.2.3
...
# default route :
route.20.ip = 0.0.0.0
route.20.netmask = 0
route.20.devname = ixp1
route.20.gateway = 192.168.2.1

Static Source Routing

Classic routing algorithms used in the Internet make routing decisions based only on the destination address of packets (and in theory, but not in practice, on the TOS field).

In some circumstances we want to route packets differently depending not only on destination addresses, but also on other packet fields: source address, IP protocol, transport protocol ports or even packet payload. This task is called 'policy routing'.

To solve this task, the conventional destination based routing table, ordered according to the longest match rule, is replaced with a 'routing policy database' (or RPDB), which selects routes by executing some set of rules.

Each policy routing rule consists of a selector and an action predicate. The RPDB is scanned in the order of increasing priority. The selector of each rule is applied to {source address, destination address, incoming interface, tos, fwmark} and, if the selector matches the packet, the action is performed. The action predicate may return with success. In this case, it will either give a route or failure indication and the RPDB lookup is terminated. Otherwise, the RPDB program continues on the next rule.

Semantically, natural action is to select the nexthop and the output device.

At startup time the kernel configures the default RPDB consisting of three rules:

1. Priority: 0, Selector: match anything, Action: lookup routing table local (ID 255). The local table is a special routing table containing high priority control routes for local and broadcast addresses.

Rule 0 is special. It cannot be deleted or overridden.

2. Priority: 32766, Selector: match anything, Action: lookup routing table main (ID 254). The main table is the normal routing table containing all non-policy routes. This rule may be deleted and/or overridden with other ones by the administrator.

3. Priority: 32767, Selector: match anything, Action: lookup routing table default (ID 253). The default table is empty. It is reserved for some post-processing if no previous default rules selected the packet. This rule may also be deleted.

Each RPDB entry has additional attributes. F.e. each rule has a pointer to some routing table. NAT and masquerading rules have an attribute to select new IP address to translate/masquerade. Besides that, rules have some optional attributes, which routes have, namely realms. These values do not override those contained in the routing tables. They are only used if the route did not select any attributes.

Source Routing tables can be defined using the following keys:

route.table.<index>.status – specify the table entry status [enabled/disabled]. Default: enabled.

route.table.<index>.id – specify the table number [0-255]. The table numbers 0, 253-255 are reserved.

We strongly recommend not to use the reserved table numbers. In case of misuse, the device can become unreachable and therefore it will need to be reset to factory defaults.

route.table.<index>.name – specify the table name [string without spaces].

Example:

route.table.1.id=101
route.table.1.name=wisp1
route.table.2.id=102
route.table.2.name=wisp2-noc
route.table.3.id=103
route.table.3.name=wisp3
...

These entries are transformed to file located at /etc/iproute2/rt_tables :

#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
101     wisp1
102     wisp2-noc
103     wisp3

route.<index>.table – specify the table number or name [0-255 or string without spaces]. Reserved numbers are 255 - local table, 254 - main table, 253 default table and 0 for unspecified table. Please refrain from using these table numbers - unless you are sure what are you doing. As a result of missue device can become unreachable and therefore it will need to be reset to factory defaults in order to restore device. Alternatively route-table-name (and this is a prefered way) use the symbolic table name instead of number. As in example given above, specify wisp1 instead of 101 as a number.

Example: The same as above, only that routes are installed in particular routing table.

route.status = enabled
route.ip_forward = true
# network address
route.1.ip = 192.168.4.0    
# netmask: 255.255.255.0, 24 bits set to 1
route.1.netmask = 24        
# install entry to table no. 101/ or name 'wisp1'
route.1.devname = ixp0 
route.1.table = wisp1
# alternatively:
# route.1.table = 100 
# disabled entry, host route tells the 192.168.3.3 is reacable via 192.168.2.3 gw
route.12.status = disabled
# host ip address
route.12.ip = 192.168.3.3   
# if netmask = 32 it can be omitted entirely.
route.12.netmask = 32
route.12.gateway = 192.168.2.3
route.12.table = wisp1
...
# default route :
route.20.ip = 0.0.0.0
route.20.netmask = 0
route.20.devname = ixp1
route.20.gateway = 192.168.4.1
route.20.table = wisp1 
...

By default, kernel looks up 'local' table first (for a local communications using IPv4 protocol stack). If packets destination/source ip address has no matches in the table, kernel routing stack proceeds with next table, main table. If not found, default table is looked up.

All the static source routing rules should be defined in Routing rules section or by using the key:

route.rule.<index>.status – specify the rule status [enabled/disabled]. Default: enabled.

route.rule.<index>.ip – specify the packet source IP address [IP address].

route.rule.<index>.netmask – specify the netmask length in bits [bitmask number, eg. 24].

route.rule.<index>.table – specify the existing table number or name for current rule [0-255 or string without spaces]. route.rule.<index>.fwmark - <number>

route.rule.<index>.prio – specify the rule priority [0-32767]. By default local table lookup priority is 0, main - 32766, and default - 32767. By default local table lookup priority is zero, main - 32766, and default - 32767, as shown in example below. Priority allows to control the performed matching order (priorities are testing starting lowest to the highest until match is found).

$ ip rule
0:      from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default

route.rule.<index>.ip≤address> and route.rule.<index>.netmask≤netmask> defines a packet source IP address, if matched to lookup table route.rule.<index>.prio≤number>.

For example:

# tells routing stack that 10.0.0.0/24 are reachable on ixp0
# and packets must be routed according routing entries in table 110
route.10.ip = 10.0.0.0
route.10.netmask = 24
route.10.devname = ixp0
route.10.table = 110
# add default route - to route via GRE tunnel
route.11.ip = 0.0.0.0
route.11.netmask = 0
route.11.gateway = 192.168.8.2
route.11.devname = gre1
route.11.table = 110
...
route.rule.3.ip=10.0.0.0
route.rule.3.netmask=24
route.rule.3.table=110
route.rule.3.prio=20000

Results in something like this:

$ ip rule show 
0:      from all lookup local 
20000:  from 10.0.0.0/24 lookup 110 
32766:  from all lookup main 
32767:  from all lookup default

$ ip route show table 110
10.0.0.0/24 dev ixp0  scope link 
default via 192.168.8.2 dev gre1

Whichs tells the kernel routing stack, route 10.0.0.0/24 IP addresses via table 110. If packet destination is any address in 10.0.0.0/24, send packet back on ixp0 (where 10.0.0.0/24 network resides), otherwise packet is sent via GRE tunnel. Note: without 10.0.0.0/24 dev ixp0 scope link route installed in table 110, all packets will be sent via GRE tunnel immediately ! (thus - it might happen so, that packet never reaches the destination !).

Sample Configuration

Example 1.

route.1.devname = ixp1
route.1.ip = 192.168.55.0
route.1.netmask = 24

Example 2.

LAN interface has IP addresses 192.168.55.0/24. There is a GRE tunnel, gre0001, with an IP address 10.0.0.2/24 set.  The following rules creates
routing setup in which 192.168.55.0/24 LAN stations are routed via GRE tunnel.
# Creates route entries in the table. 
# ip route add $(route.%d.ip)/$route.%d.netmask \
#          dev $(route.%d.interface) \
#          table $(route.%d.table)
#
route.1.devname = ixp0
route.1.ip = 192.168.55.0
route.1.netmask = 24
route.1.table = 100
#
# Creates a default route :
# ip route add $(route.%d.ip)/$(route.%d.netmask) \
#          via $(route.%d.gateway)  \
#          dev $(route.%d.interface) \
#          table wisp1
#
# Note: 
# 'wisp1' must be defined as:
#   route.table.1.id = 100
#   route.table.1.name = wisp1 
#
# without these entries - source route will not be installed as
# device doesn't know how to map wisp1 to a particular number (in
# this case it is 100).
#
#
route.2.devname = gre0001
route.2.ip = 0.0.0.0
route.2.netmask = 0
route.2.gateway = 10.0.0.2  # GRE tunnel ip address.
route.2.table = wisp1
#
# Makes a routing stack to use table 100 hen making decision how to route packet:
#
# ip rule add from $(route.rule.%d.ip)/$(route.rule.%d.netmask) \
#             table $(route.rule.%d.table) \ 
#             prio $(route.rule.%d.prio)
#
route.rule.1.ip = 192.168.55.0
route.rule.1.netmask = 24
route.rule.1.table = 100
route.rule.1.prio = 100

Example 3.

LAN interface has IP addresses 192.168.73.1/24. There is a GRE tunnel, netb, with an IP address 10.10.1.1/29 set.  WAN interface has IP address
192.168.1.61/24. This interface is default gateway for users connected to LAN interface. Marked packets, goes to routing table 121 and are routed via
GRE tunnel. The following rules creates routing setup in which all marked traffic from LAN stations are routed via GRE tunnel.
#
# Creates a default route:
#
# ip route add $(route.%d.ip)/$(route.%d.netmask) \
#          via $(route.%d.gateway)  \
#          dev $(route.%d.interface)
#
route.1.devname=ixp1
route.1.gateway=192.168.1.10
route.1.ip=0.0.0.0
route.1.netmask=0
route.1.status=enabled
#
# Makes a routing stack to use table 121 when making decision how to route packet:
#
# ip rule add fwmark $(route.rule.%d.fwmark) \
#             table $(route.rule.%d.table)
#
# Note: 
# 'marked_traffic' must be defined as:
#   route.table.1.status=enabled
#   route.table.1.id=121
#   route.table.1.name=marked_traffic
#
# without these entries - source route will not be installed as
# device doesn't know how to map marked_traffic to a particular number (in
# this case it is 121).
#
route.rule.1.status=enabled
route.rule.1.fwmark=100
route.rule.1.table=marked_traffic
#
# Creates route entries in the marked_traffic table. 
#
# ip route add $(route.%d.ip)/$(route.%d.netmask) \
#          via $(route.%d.gateway) \
#          table $(route.%d.table)
#
route.2.status=enabled
route.2.gateway=10.10.1.2
route.2.ip=0.0.0.0
route.2.netmask=0
route.2.table=121

Selective Source Routing

Selective Source Routing is referring to a dynamic routing capability. In particular, client station traffic will be routed according RADIUS authentication request response. The system routing mechanism works in the same manner as the static source routing, except the fact that the routing rules will be defined automatically during the authorization routines.

Each routing table is dedicated for separate tunnel (IPsec, GRE, VSSID or VLAN interface) while having the unique name, which is used as Tunnel-ID.

Selection of the route successful only if there exist Tunnel-ID which corresponds to the “Tunnel-Assignment-ID” attribute provided by RADIUS on Access-Accept.

The same Tunnel-Assignment-ID RADIUS attribute value should be used in all the RADIUS accounting requests if it was available in the RADIUS Access-Accept packet.

In the provided example, the device should have configured tunnels while each of them should have assigned Tunnel-ID. If there is no existing tunnel with corresponding Tunnel-ID, the authentication will fail and client station will be denied any network access beyond the NAS device.

With source routing enabled, administrator must make sure that all source routing keys route.rule.<index>.prio values are in 10000-20000 range. The system authenticator will create dynamically source routes with priority in range 900-1000.

If there will be few Tunnel-Assignment-ID alternatives matching available Tunnel-ID's on a device the first matching Assigned Tunnel ID will be selected with the lowest Tunnel-Preference RADIUS attribute value for the client source routing.

The default routing rules will be applied for the clients, which will get empty or no Tunnel-Assignment-ID on RADIUS Access-Accept packet.

Example 1:

Clients are coming on LAN interface, which has DHCP server configured to lease IP addresses in range 192.168.3.0/24. By default clients have 192.168.3.1 assigned as a default gateway. WAN interface ixp1 has 192.168.2.110 IP address. Also, there are a couple GRE tunnel devices configured on device configured like this:

# WISP#1, creates tunnel interface 'GRE1'
tunnel.gre.1.status=enabled
tunnel.gre.1.remote.ip=192.168.2.253
tunnel.gre.1.ttl=64
# WISP#2, creates tunnel interface 'GRE2'
tunnel.gre.2.status=enabled
tunnel.gre.2.remote.ip=192.168.2.252
tunnel.gre.2.ttl=64
#Configure GRE1 and GRE2 interfaces:
#  192.168.2.110 (ixp1) <------ GRE tunnel ------> 192.168.2.252 (WISP#1-remote) -- / --- > (WISP#1 NOC)
#  10.0.1.2 (gre1) <---------------> (greX 10.0.1.1) 
#  so 192.168.3.x particular IP address is routed via 10.0.1.2 (which is default gateway in case of selective routing)
# assign gre1 and gre2 ip addresses 
netconf.dev.1.name=gre1
netconf.dev.1.type=tunnel
netconf.dev.1.mode=wan
netconf.dev.1.state=up
netconf.dev.1.ip=10.0.1.2
netconf.dev.1.netmask=255.255.255.0
netconf.dev.1.broadcast=10.0.1.255
netconf.dev.2.name=gre2
netconf.dev.2.type=tunnel
netconf.dev.2.mode=wan
netconf.dev.2.state=up
netconf.dev.2.ip=10.0.2.2
netconf.dev.2.netmask=255.255.255.0
netconf.dev.2.broadcast=10.0.2.255

Install a default route in each source routing table. Use a GRE tunnel’s IP address as a default gateway (so that all traffic traversing these tables is routed through GRE tunnel). The system authenticator will create particular rules per IP address that depends on tunnel-id.

route.entry.1.enabled = true
route.entry.1.ip = 0.0.0.0
route.entry.1.netmask = 0
route.entry.1.interface = gre1
route.entry.1.gateway = 10.0.1.2
#important!
route.entry.1.table = 101
route.entry.2.enabled = true
route.entry.2.ip = 0.0.0.0
route.entry.2.netmask = 0
route.entry.2.interface = gre2
route.entry.2.gateway = 10.0.2.2
#important!
route.entry.2.table = 102
route.table.1.id=101
route.table.1.name=WISP1
route.table.1.id=102
route.table.1.name=WISP2

This creates GRE1 tunnel from 192.168.2.110 <-> 192.168.2.253 for a WISP1 clients traffic to transport. The same goes for GRE2 (192.168.2.110 <-> 192.168.2.252) for a WISP2 clients to transport. While client attempts to authenticate, RADIUS server reports tunnel-id "WISP1". Assuming that interface is present on device and configured properly, system authenticator adds the route on WISP1 table. When client is gone, system authenticator deletes the route automatically.

Example 2:

Enabled WAN interface gre0001 has Assigned Tunnel ID (table name) set to "WISP1". Other WAN's have empty Tunnel-ID. Assume that client has provided valid login credentials and RADIUS server is responding with Access-Accept.

Received RADIUS Access-Accept contains Tunnel-Assignment-ID:

• with value "WISP1" and client is successfully authenticated;

• source route for that client is created through routing table named "WISP1";

• all client traffic is routed through gre0001 interface using routing table "WISP1";

• RADIUS accounting packets for that client include Tunnel-Assignment-ID attribute which contains the same value as it was in the Access-Accept: "WISP1";

• after client session end source-route is removed;

• with value "BadWISP" and such routing table does not exist:

• client authorization is refused and no source route is set up;

• client session ends immediately.

Dynamic Routing

WILI-S software can be configured to use Quagga routing suite.

zebra.status - enable the Quagga daemon zebra [enabled/disabled]. Default: disabled.

ospfd.status - enable the OSPFv2 protocol daemon [enabled/disabled]. Default: disabled.

ripd.status - enable the RIP v1 and V2 protocol daemon [enabled/disabled]. Default: disabled.

bgpd.status - enable the BGPv4+ protocol daemon [enabled/disabled]. Default: disabled.

IPsec

The IPsec protocol client enables the WILI-S device to establish a secure connection to an IPsec peer via the Internet. IPsec is supported in two modes - transport and tunnel. Transport mode creates secure point to point channel between two hosts, eg. AP and client. Tunnel mode can be used to build a secure connection between two remote LANs serving as a VPN solution. A number of independent secure channels of either mode may be established simultaneously.

The IPsec feature is not supported on the Wistron CA8-4, Wistron RDAT-81, Compex WP54AG/WP54G platforms due to HW specific restrictions.

IPsec can be configured using the following keys:

ipsec.status – specify the IPsec service status [enabled/disabled].

ipsec.<index>.status – specify the IPsec entry status [enabled/disabled]. Default: disabled.

ipsec.<index>.mode – specify the IPsec operating mode for this entry [transport/tunnel].

ipsec.<index>.point_src.ip – specify the source IP address.

ipsec.<index>.point_dst.ip – specify the destination IP address.

ipsec.<index>.ah.in.spi – specify the inbound security parameter index [256-65535].

ipsec.<index>.ah.out.spi – specify the outbound security parameter index [256-65535].

ipsec.<index>.ah.algo – specify the authentication algorithm [hmac-md5/hmac-sha1/keyed-md5/keyed-sha1/null/hmac-sha2-256/hmac-sha2-384/hmac-sha2-512/hmac-ripemd160/aes-xcbc-mac].

ipsec.<index>.ah.secret – specify the authentication secret [string]. Secret’s length depends on selected algorithm, eg. 128 bit long secret is 16 characters in length, 128 bits / 8 bits (one character) = 16. The algorithm key lengths in bits are:

• hmac-md5 - 128
• hmac-sha1 - 160
• keyed-md5 - 128
• keyed-sha1 - 160
• null - 0 to 2048
• hmac-sha2-256 - 256
• hmac-sha2-384 - 384
• hmac-sha2-512 - 512
• hmac-ripemd160 - 160
• aes-xcbc-mac - 128

ipsec.<index>.esp.in.spi – specify the inbound compression [256-65535].

ipsec.<index>.esp.out.spi – specify the outbound compression [256-65535].

ipsec.<index>.esp.auth.algo – specify the ESP authentication algorithm [hmac-md5/hmac-sha1/keyed-md5/keyed-sha1/null/hmac-sha2-256/hmac-sha2-384/hmac-sha2-512/hmac-ripemd160/aes-xcbc-mac].

ipsec.<index>.esp.auth.secret – specify the ESP authentication secret [string]. Secret’s length depends on selected algorithm, eg. 128 bit long secret is 16 characters in length, 128 bits / 8 bits (one character) = 16. The algorithm key lengths in bits are:

• des-cbc - 64
• null - 0 to 2048
• blowfish-cbc - 40 to 448
• cast128-cbc - 40 to 128
• des-deriv - 64
• 3des-deriv - 192
• rijndael-cbc -128/192/256

v* twofish-cbc - 0 to 256

• aes-ctr - 160/224/288

ipsec.<index>.esp.enc.algo – specify the ESP encryption algorithm [des-cbc/3des-cbc/null/blowfish-cbc/cast128-cbc/des-deriv/3des-deriv/rijndael-cbc/twofish-cbc/aes-ctr].

ipsec.<index>.esp.enc.secret – specify the ESP encryption secret [string]. Secret’s length depends on selected algorithm, eg. 128 bit long secret is 16 characters in length, 128 bits / 8 bits (one character) = 16. The algorithm key lengths in bits are:

• des-cbc - 64
• null - 0 to 2048
• blowfish-cbc - 40 to 448
• cast128-cbc - 40 to 128
• des-deriv - 64
• 3des-deriv - 192
• rijndael-cbc -128/192/256
• twofish-cbc - 0 to 256
• aes-ctr - 160/224/288

ipsec.<index>.ipcomp.in.spi – specify the inbound compression [256-65535].

ipsec.<index>.ipcomp.out.spi – specify the outbound compression [256-65535].

ipsec.<index>.ipcomp.compression – specify the compression mode [deflate/oui/lzs].

ipsec.<index>.spd.<index>.status – specify current SPD (security policy database) entry status [enabled/disabled].

ipsec.<index>.spd.<index>.src.ip – specify the SPD source IP address.

ipsec.<index>.spd.<index>.src.netmask – specify the source netmask bit-count [0-32].

ipsec.<index>.spd.<index>.dst.ip – specify the SPD destination IP address.

ipsec.<index>.spd.<index>.dst.netmask – specify the destination netmask bit-count [0-32].

ipsec.<index>.spd.<index>.protocol.<index>.status – specify current SPD protocol entry status [enabled/disabled]. Default: enabled.

ipsec.<index>.spd.<index>.protocol.<index>.name – specify the SPD protocol name [esp/ah/ipcomp]. The SPD protocol name is mandatory parameter.

ipsec.<index>.spd.<index>.protocol.<index>.level – specify the level [default/use/require/unique]. Default level "require" will be used for esp and ah protocols. Default level "use" will be added to ipcomp protocol.

Example: The sample configuration below defines a policy, which allows WILI-S device with IP address 192.168.4.8 to access stations on LAN2 (IP address range 192.168.1.0/24) behind IPsec supporting router 192.168.4.10. IPsec tunnel is set between WILI-S based device and router. Do not forget to setup routing on 192.168.4.8 so it knows that LAN2 (192.168.1.0/24) network is reachable through 192.168.4.10. Otherwise packets leaving device and destined to LAN2 will be routed through default gateway (which might not be the case in your setup, be careful).

# 192.168.4.8 (WILI) <========== LAN1 ==========> 192.168.4.10 (Router)
#                                   ^
# Station 1 (192.168.1.2) ---------  LAN2 (192.168.1.0/24) -------
#
# Station 2 (192.168.1.103) ------+
#
ipsec.status=enabled
ipsec.1.mode=tunnel
# tunnel end point IP addresses : local/remote
ipsec.1.point_src.ip=192.168.4.8
ipsec.1.point_dst.ip=192.168.4.10
#
# Security Policy Indexes (SPI) (value in HEX)
ipsec.1.esp.out.spi=0x4000
ipsec.1.esp.in.spi=0x5000
#
# authentication key 'alabrstysaaslu!e' or hexadecimal 
# 16c616272737479736161736c752165
ipsec.1.esp.auth.algo=hmac-md5
ipsec.1.esp.auth.secret=alabrstysaaslu!e
#
# encryption key 'alabrsty' or in hexadecimal 616c616272737479
ipsec.1.esp.enc.algo=des-cbc
ipsec.1.esp.enc.secret=alabrsty
#
# Security Policy Database (SPD) entries
ipsec.1.spd.1.src.ip=192.168.4.8
ipsec.1.spd.1.src.netmask=32
ipsec.1.spd.1.dst.ip=192.168.1.0
ipsec.1.spd.1.dst.netmask=24
ipsec.1.spd.1.protocol.1.name=esp
ipsec.1.spd.1.protocol.1.level=require
#
# install route telling 192.168.1.0/24 is behind 192.168.4.10
# do not forget to adjust 20 to a reasonable value
route.20.ip = 192.168.1.0
route.20.netmask = 24
route.20.devname = ixp1
route.20.gateway = 192.168.4.10

The IPSec Tunnel (VPN Gateway) should be configured at the remote router (192.168.4.10) side properly.

The valid configuration should include settings like:

• Local Secure Network (192.168.1.0/255.255.255.0)
• Remote Secure Gateway IP address (192.168.4.8)
• Key Exchange Method (Manual)
• Encryption Algorithm (DES)
• Encryption Key (value in hexadecimal is “616c616272737479”)
• Authentication Algorithm (MD5)
• Authentication Key (value in hexadecimal is “616c616272737479736161736c752165”)
• Inbound SPI (value in HEX is “4000”)
• Outbound SPI (value in HEX is “5000”)

IPsec Racoon

The IPsec feature is not supported on the Wistron CA8-4 platforms due to HW specific restrictions.

The establishment of the Security Association (IPsec-SA) between two peers is needed for IPsec communication. It can be done by using manual or automated configuration.

IPsec Racoon uses the Internet Key Exchange (IKE) for automatically keying IPsec connections.

Several parameters (Keys) are exchanged between peers in order to establish the IPsec-SA. Racoon exchange routine by using IKE has two phases: establishing SA for own communication (IKE-SA) and establishing IPsec-SA.

IPsec system maintains two databases: Security Policy Database (SPD) which defines whether to apply IPsec to a packet or not and specify which/how IPsec-SA is applied and Security Association Database (SAD), which contain Key of each IPsec-SA.

The basic mechanism of applying the IPsec-SA to a packet is the following:

• The administrator sets a policy to SPD
• System refers to SPD in order to make a decision of applying IPsec to a packet
• If IPsec is required, then system get the Key for IPsec-SA from SAD
• If it is failed, then system send a request to get the Key to IPsec Racoon
• IPsec Racoon exchange the Key by using IKE with the other to be established IPsec-SA
• IPsec Racoon put the Key into SAD
• System can send a packet applied IPsec

Racoon needs access to UDP port 500. Make sure that your firewall configuration does not block this port.

IPsec Racoon can be configured using the following keys:

racoon.status – specify the status of racoon service [enabled/disabled].

racoon.psk.<index>.status – specify current configuration entry status [enabled/disabled]. Default: enabled.

racoon.psk.<index>.identifier – specify the remote host IP address.

racoon.psk.<index>.secret – specify the secret preshared key [string].

Example:

racoon.status=enabled
racoon.psk.1.status=enabled
racoon.psk.1.identifier=192.168.2.151
racoon.psk.1.secret=VeRy$ecr3t

GRE

GRE (Generic Routing Encapsulation RFC2784) is a solution for tunneling RFC1812 private address-space traffic over an intermediate TCP/IP network such as the Internet. GRE tunneling does not use encryption it simply encapsulates data and sends it over the WAN. Administrators should therefore take care that no unencrypted private information passes through a GRE tunnel. Created GRE tunnels will appear as regular network interfaces, eg., gre1, gre4.

tunnel.gre.status – specify the GRE tunnel status [enabled/disabled]. Default: disabled.

tunnel.gre.<index>.status – specify current GRE entry status [enabled/disabled]. Default: enabled.

tunnel.gre.<index>.devname – specify custom GRE tunnel interface name [custom string up to 15 characters in length]. Bind the tunnel to the specified interface so that tunneled packets will only be routed through this interface and will not escape to another interface when the route to endpoint changes. If not specified, default interface name will be gre<index>.

tunnel.gre.<index>.local.ip – specify the fixed local IP address for tunneled packets. It must be an address of another interface of the device. Default '0.0.0.0' means that no fixed address will used for local endpoint. In this case local endpoint address for that tunnel will be automatically assigned by the routing process.

tunnel.gre.<index>.remote.ip – specify the remote tunnel endpoint IP address. Default '0.0.0.0' means accept any remote endpoint.

tunnel.gre.<index>.parent – specify the parent interface name. Bind the tunnel to the specified interface so that tunneled packets will only be routed through this interface and will not be able to escape to another interface when the route to endpoint changes.

tunnel.gre.<index>.ttl – specify the fixed time-to-live (TTL) value on tunneled packets [0-255]. The 0 is a special value meaning that packets inherit the TTL value. Default: 0.

tunnel.gre.<index>.pmtudiscovery – the Path Maximum Transmission Unit Discovery (PMTUD) status on this tunnel [enabled/disabled]. Default: enabled.

Example:

tunnel.gre.status=enabled
tunnel.gre.1.status=enabled
tunnel.gre.1.devname=gre_1
tunnel.gre.1.local.ip=192.168.2.12
tunnel.gre.1.parent=ixp1 
tunnel.gre.1.remote.ip=10.15.14.1
tunnel.gre.1.pmtudiscovery=disabled

This configuration will create a GRE tunnel with following parameters: gre_1 – remote end IP 10.15.14.1, local end will use IP address 192.168.2.12 bound to ixp1 interface (it should already be configured), TTL value will be inherited, path MTU discovery disabled.

VTun Tunneling

Use this keys to create Virtual Tunnels over TCP/IP networks traffic compression and encryption. The VTun (Virtual Tunnel) is managed using following configuration keys:

Global keys, valid for all sessions:

tunnel.vtun.status - specify VTun daemon status [enabled|disabled]. Default - disabled

tunnel.vtun.mode - specify operating mode [client/server]. This field is mandatory.

tunnel.vtun.timeout - specify connect timeout in seconds [integer]. Default: 60.

tunnel.vtun.port - specify the port number to listen(server) or send (client)[0-65535]. Default: 5000.

Local keys for particular session:

tunnel.vtun.<index>.passwd - specify password for authentication [string]. The password should be the same on client and on server.

tunnel.vtun.<index>.proto - specify protocol to operate [tcp/udp].Client ignores it. Default: udp.

tunnel.vtun.<index>.compress - [enabled/disabled/zlib/lzo]. If enabled, system will use default compression method - zlib. Client ignores it. Default: disabled..

tunnel.vtun.<index>.encrypt - specify encryption status [enabled/disabled]. Client ignores it. Default: disabled.

tunnel.vtun.<index>.remote.ip - specify server's IP address for client to connect [IP address]. Mandatory for client.

tunnel.vtun.<index>.virtual_local.ip - specify virtual IP of local machine in tunnel [IP address]. Mandatory.

tunnel.vtun.<index>.virtual_remote.ip - specify virtual IP of remote machine in tunnel [IP address]. Mandatory.

tunnel.vtun.<index>.mtu - specify maximum transfer unit [integer]. Default: 1500.

tunnel.vtun.<index>.session - specify the name of the session. Mandatory. tunnel.vtun.<index>.route.<index>.ip - specify the network IP address [IP address].

tunnel.vtun.<index>.route.<index>.netmask - specify the network mask prefix of the route

tunnel.vtun.<index>.route.<index>.table - specify the ID of the route table [0-255]. Optional. The table numbers 0, 253-255 are reserved.

Example:

#Client configuration sample 
tunnel.vtun.status=enabled
tunnel.vtun.mode=client
tunnel.vtun.port=5000
tunnel.vtun.timeout=70
tunnel.vtun.1.session=wilibox
tunnel.vtun.1.passwd=admin02
tunnel.vtun.1.local_virtual.ip=10.200.0.2
tunnel.vtun.1.remote_virtual.ip=10.200.0.1
tunnel.vtun.1.remote.ip=192.168.2.205
tunnel.vtun.1.mtu=1700
tunnel.vtun.1.route.1.ip=192.168.100.0
tunnel.vtun.1.route.1.netmask=24
tunnel.vtun.1.route.1.table=121
#
#Server configuration sample:
tunnel.vtun.status=enabled
tunnel.vtun.mode=server
tunnel.vtun.port=5000
tunnel.vtun.timeout=70
tunnel.vtun.1.session=wilibox
tunnel.vtun.1.passwd=admin02
tunnel.vtun.1.local_virtual.ip=10.200.0.1
tunnel.vtun.1.remote_virtual.ip=10.200.0.2
tunnel.vtun.1.remote.ip=192.168.2.205
tunnel.vtun.1.mtu=1700

This config will create tunnel from client side. Output from ifconfig:

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
         inet addr:10.200.0.2  P-t-P:10.200.0.1  Mask:255.255.255.255

PPPoE

PPPoE is a protocol typically used by DSL providers to manage IP addresses and authenticate users. Essentially, PPPoE provides for a PPP connection to be established not over a physical serial-line or modem, but over a logical connection between two unique MAC addresses on an Ethernet network.

pppoe.status – specify the status of the PPPoE [enabled/disabled]. Default: disabled.

pppoe.<index>.status – specify the status of the particular PPPoE profile [enabled/disabled].

pppoe.<index>.name – specify name of the PPPoE profile [string]

pppoe.<index>.devname – specify name of the interface peer can be connected through [string]. The interface should be "up" before you start PPPoE, but should not be configured to have an IP address (refer to the section Interface for detailed information on interface configuration).

pppoe.<index>.user – specify name which will be used for authenticating the local system to the peer [string].

pppoe.<index>.password – specify the password for the user authentication [string].

pppoe.<index>.service_name – specify the service name set on the access concentrator [string]. PPPoE will only initiate sessions with access concentrators which can provide the specified service.

pppoe.<index>.ac_name – specify the desired access concentrator name [string]. PPPoE will only initiate sessions with the specified access concentrator.

pppoe.<index>.maxfail – terminate after n consecutive failed connection attempts [integer]. Default: 0 (no limit).

pppoe.<index>.mtu – specify the Maximum Transmission Unit [integer]. Default: 1500.

pppoe.<index>.mru – specify the Maximum Received Unit [integer]. Default: 1500.

pppoe.<index>.add_default_route – specify enabled to add a default route to the system routing tables using the peer as the gateway, when IPCP negotiation is successfully completed [enabled/disabled]. Default: enabled.

pppoe.<index>.use_peer_dns – specify status whether use peer’s DNS servers [enabled/disabled] Default: enabled.

pppoe.<index>.lcp_echo_failure – specify the number of LCP echo-requests that will be sent without receiving a valid LCP echo-reply at which the pppd will consider the peer to be dead [integer]. If this happens, pppd will terminate the connection. Use of this option requires a non-zero value for the lcp-echo-interval parameter. This option can be used to enable pppd to terminate after the physical connection has been broken (e.g., the modem has hung up) in situations where no hardware modem control lines are available.

pppoe.<index>.lcp_echo_interval – Specify the time interval in seconds at which an LCP echo-request frame will be sent by the pppd to the peer [integer]. Normally the peer should respond to the echo-request by sending an echo-reply. This option can be used with the lcp-echo-failure option to detect that the peer is no longer connected.

pppoe.<index>.persist - do not exit after a connection is terminated; instead try to reopen the connection.[enabled|disabled]. Default: enabled. The maxfail option still has an effect on persistent connections.

pppoe.<index>.holdoff - specify how many seconds to wait before re-initiating the link after it terminates [integer, time in seconds]. This option only has any effect if the persist or demand option is used. The holdoff period is not applied if the link was terminated because it was idle.

pppoe.<index>.debug – specify connection debugging status [enabled/disabled]. Default: disabled]. If this option is given, pppd will log the contents of all control packets sent or received in a readable form. The packets are logged through syslog with facility daemon and level debug.

Example:

pppoe.status=enabled
pppoe.1.status=enabled
pppoe.1.name=pppoe
pppoe.1.user=user_name
pppoe.1.password=user_password
pppoe.1.devname=ixp0
pppoe.1.mtu=1460
pppoe.1.mru=1460

Wireless Settings

This section describes radio hardware (Wireless Radio) and wireless interface settings (Wireless Interface), WLAN locking, VSSID, wireless access control list (ACL), client bridge, station supervision settings.

Wireless Radio

This section provides the description of the general parameters of the radio hardware such as:

• Country code
• IEEE mode
• Auto channel selection
• Radio operating mode
• Turbo mode
• Data transfer rate
• Automatic data transfer rate
• Fragmentation
• ACK timeout
• RTS
• Transmit power (dBm)
• RX/TX antenna diversity
• Half and quarter rate channel support (available from WILI-S 5.00)
• FCC security band support (available from WILI-S 5.00)

All available keys of the radio hardware configuration are listed below:

radio.status – specify the radio module status [enabled/disabled]. Default: disabled.

radio.countrycode – specify the device’s country code. Refer to ISO Country Codes for syntax of your country code. The country code can be specified as 2 or 3 letters or number code.

radio.outdoor – specify the operation mode [0/1]. 0 is indoor, 1 is outdoor. Default: 0.

radio.xchanmode – specify the extended channel mode status [0/1]. 0 is disabled, 1 - enabled. Default: 1.

radio.<index>.status – specify current radio configuration entry status [enabled/disabled].

radio.<index>.devname – specify current wireless interface name.

radio.<index>.parent – the hardware wireless interface name, eg. wifi0, wifi1 [string].

radio.<index>.mode – specify the operating mode of the device [Managed/Master]. The device mode depends on the network topology.

• Managed. In this mode node connects to a network composed of many access points with roaming.

• Master. In this mode node is the synchronization master or acts as an access point.

radio.<index>.channel – specify the wireless channel [number, depends on country code settings and operation mode]. Multiple channels are available to avoid interference between nearby access points. If you wish to operate more than one access point in overlapping coverage areas, we recommend a distance of at least four channels between the chosen channels. The list of available channels is in the table Regulatory Domain/Channels.

For master operating mode the WILI-S has the auto channel function. It is used to find the best channel for client-access point communication (either an unused channel or if all are in use the least occupied one - that with the lowest measured signal strength). The channel list to select channels from can be specified for auto channel.

radio.<index>.autochannel.status – specify the auto channel status [enabled/disabled].

radio.<index>.autochannel.<index>.status – specify current auto channel entry status [enabled/disabled].

radio.<index>.autochannel.<index>.channel – specify one channel from auto channel list [number, depends on country code settings and operation mode]. The list of available channels is in the table Regulatory Domain/Channels.

radio.<index>.rate.max – specify the wireless transmission speed (in bits/sec, by default). Real data transmission speed will be lower due to distance, obstacles in wireless signal path and wireless protocol overhead. You may append the suffix k, M or G to the value (decimal multiplier: 10^3, 10^6 and 10^9 bits/s), or add enough zeros.

Wireless Network Mode	The Bit-Rates (Mbps)
B	1Mbps 2Mbps 5.5Mbps 11Mbps
G	1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
A	6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps

radio.<index>.rate.auto – specify the automatic bit-rate mode status [enabled/disabled]. Default: enabled. This setting sets automatic bit-rate mode with fallback to lower rate on noisy channels, which is the default for most cards. If you specify a bit-rate value (radio.<index>.rate.max) and set auto to enabled, the driver will use all bit-rates lower or equal to this value.

radio.<index>.frag – specify the fragmentation threshold (in bytes), which determines whether data frames will be fragmented and at what size [256-2346/off]. On a 802.11 wireless LAN, frames exceeding the fragmentation threshold will be fragmented, i.e., split into smaller units suitable for the circuit size. Data frames smaller than the specified fragmentation threshold value are not fragmented. Default: off.

Setting a lower fragmentation threshold value can help improve connection reliability in noisy environments (where radio interference is present). This mechanism does add overhead and therefore reduces effective throughput.

radio.<index>.rts – specify the maximum packet size beyond which the wireless LAN card invokes it’s RTS/CTS mechanism [0-2347/off]. Packets that exceed the specified RTS threshold trigger the RTS/CTS mechanism. The card transmits packets smaller than this threshold without using RTS/CTS. Default: off.

Setting a lower RTS threshold value can improve connection reliability and throughput in crowded wireless LAN environments (where many clients are trying to communicate simultaneously). It adds a certain amount of overhead, but can compensate for this by reducing bandwidth lost due to collisions.

radio.<index>.txpower – specify the wireless card transmission power in dBm [off/number].

radio.<index>.ieee_mode – specify the wireless network mode [auto/A/B/G/PUREG/AST]. Default: auto.

Meaning of auto depends on operating mode (radio.<index>.mode). If operating mode is Master then A mode will be set. For B/G-only radios, G mode will be set. If operating mode is Managed, radio will begin searching for AP starting with A mode and then switching to B and G until it finds an AP to associate to. PUREG mode means accepting only G clients (aka G-only mode). AST means 802.11a Static Turbo mode.

Check with your country regulations before setting Static Turbo mode.

radio.<index>.turbo – specify the status of dynamic turbo mode [enabled/disabled]. Default: disabled. Set dynamic turbo mode with combination of throughput enhancement functionality (see: wireless.<index>.fastframes, wireless.<index>.frameburst, wireless.<index>.compression keys description in next section Wireless interface)

Turbo mode is available only for 802.11a and 802.11g.

radio.<index>.rx_antenna – specify antenna for receiving [1/2]. Default: 1.

radio.<index>.rx_antenna_diversity – specify receiving antenna diversity status [enabled/disabled]. Default: enabled. Antenna diversity controls the signal strength on each antenna and switches to the one with better strength. This works if radio.<index>.rx_antenna is set to 2.

radio.<index>.tx_antenna – specify antenna for transmitting [1/2]. Default: 1.

radio.<index>.tx_antenna_diversity – specify the transmitting antenna diversity status [enabled/disabled]. Default: enabled. Antenna diversity controls the signal strength on each antenna and switches to the one with better strength. This works if radio.<index>.tx_antenna is set to 2.

radio.<index>.ani - specify status for controlling interference mitigation/Ambient Noise Immunity (ANI) [enabled/disabled].

radio.<index>.acktimeout – specify the ACK timeout value [numeric value].

radio.<index>.chanattr.<index>.status – specify the status of special channel attribute usage: channel bandwidth [enabled/disabled] . Default: enabled.

radio.<index>.chanattr.<index>.channel – specify one channel number on which bandwidth narrowing (half/quarter) will be set [channel].

radio.<index>.chanattr.<index>.bw – specify desirable channel bandwidth for specified channel [full/half/quarter]. Default: full. Default channel bandwidth for 802.11 radio is 20MHz for 11a mode and 22 MHz for 11g mode (for turbo modes they double). But it is possible to narrow it 2x or 4x times. Though this will drop data transfer rates accordingly, but it will increase power density and may help to achieve greater operation distances.

Do not use channel bandwidth narrowing in turbo modes.

radio.<index>.chanattr.<index>.freq - specify frequency, e.g. 2412 [integer].

radio.<index>.ctstimeout – specify the CTS timing value [numeric].

radio.<index>.slottime – specify the Slot time value [numeric].

Example:

radio.status=enabled
radio.1.status=enabled
radio.1.acktimeout=48
radio.1.autochannel.status=enabled
radio.1.autochannel.1.status=enabled
radio.1.autochannel.1.channel=3
radio.1.autochannel.2.status=enabled
radio.1.autochannel.2.channel=6
radio.1.autochannel.3.status=enabled
radio.1.autochannel.3.channel=8
radio.1.devname=ath0
radio.1.frag=off
radio.1.ieee_mode=G
radio.1.mode=master
radio.1.rate.auto=enabled
radio.1.rate.max=54M
radio.1.rts=off
radio.1.rx_antenna=1
radio.1.rx_antenna_diversity=disabled
radio.1.tx_antenna=1
radio.1.tx_antenna_diversity=disabled
radio.1.txpower=auto

Wireless Interface

This section provides the description of the general wireless LAN interface parameters. The administrator is able to setup using this section:

• WEP encryption
• SSID
• SSID broadcasting suppression
• Maximum number of clients
• Country element (IEEE 802.11d)
• Power constrain and channel switch for IEEE 802.11h
• Layer 2 isolation
• Throughput enhancements (fast frames, packet bursting, compression) (available from WILI-S 5.00)
• WMM (available from WILI-S 5.00)

All available wireless interface configuration keys are listed below:

wireless.status – specify the wireless interface function status [enabled/disabled]. Default: disabled.

wireless.<index>.status – specify the wireless interface entry status [enabled/disabled]. Default: enabled.

wireless.<index>.devname – specify the wireless interface name. The value for this key should be “ath0”.

wireless.<index>.ssid – specify a unique name for your wireless network. The string is case sensitive and up to 32 characters in length [printable characters and spaces, no control characters, mandatory].

wireless.<index>.ssid_broadcast – specify the master operating mode SSID broadcasting status [enabled/disabled]. When disabled, the AP’s SSID will not show up in the network list when a client scans for available networks. By default SSID broadcasting is enabled. Do not use this feature as a security measure.

wireless.<index>.l2_isolation – specify the layer 2 wireless client separation status [enabled/disabled]. Layer 2 isolation blocks the wireless clients from communicating with each other.

wireless.<index>.max_clients – specify the maximum number of connected clients [0-2147483647]. Default: 64.

wireless.<index>.security – specify the Wired Equivalent Privacy (WEP) encryption method [wep64/wep128/none]. Default mode is: none.

wireless.<index>.security.mode – specify the security mode [restricted/open]. The default mode is restricted.

• Restricted. In this mode clients can connect only with WEP encryption configured.
• Open. This mode allows clients with WEP security or without any security to connect.

wireless.<index>.security.<index>.key – specify the WEP security keys. WEP keys should be entered as a series of colon-separated hexadecimal (0-9, A-F, and a-f) pairs:

• 5 pairs for 64-bit WEP security (eg. 00:AC:01:35:FF)
• 13 pairs for 128-bit WEP security (eg. 00:11:22:33:44:55:66:77:88:99:AA:BB:CC)

You can configure up to 4 security keys.

wireless.<index>.security.default_key – specify the index of the default key, used to encrypt the data before it is transmitted [1-4].

The same key value must also be entered in the WLAN card configuration for each of the wireless clients.

wireless.<index>.authmode – specify the authentication mode of the AP [1/2/4]. Default: 4.

• 1 – Open system. This setting allows any device, regardless of its WEP keys, to authenticate and attempt to associate.
• 2 – Shared key. This setting tells the AP to send a plain-text, shared key query to any device that attempts to associate with the AP.
• 4 – Auto. This setting uses both modes (Open system and Shared key).

wireless.<index>.country_element – specify the country element status [enabled/disabled]. Default: disabled. With this key enabled, system adds Country Element to beacons and probe responses according to IEEE 802.11d.

wireless.<index>.power_constrain – specify the power constrain status [enabled/disabled]. Default: disabled. With this key enabled, system adds Power Constrain to beacons and probe responses according to IEEE 802.11h.

wireless.<index>.chanswitch – specify the channel switch status [enabled/disabled]. Default: disabled. With this key enabled, system adds Channel Switch notification to beacons according to IEEE 802.11h.

wireless. <index>.fastframes – specify the fast frame status [enabled/disabled]. Default: disabled. Frame aggregation to super frame up to 3000B, thus maximizing efficiency via less overhead. Requires AP that supports fast frame functionality.

wireless. <index>.frameburst – specify the frame burst status [enabled/disabled] . Default: disabled. This technique allows transmitting more then one data frame during each transmission opportunity before station defers access to medium. Available for any capable station.

wireless.<index>.compression – specify packet compression status [enabled, disabled]. Default: disabled. real-time hardware Lempel Ziv data compression, that increases data throughput using precompressed frames. Requires an AP that supports compression.

wireless. <index>.wmm – specify the WMM status [enabled/disabled]. Default: disabled. Wi-Fi Multimedia (WMM) is based on the IEEE 802.11e draft standard. It provides basic quality of service (QoS) features to IEEE 802.11 networks. WMM prioritizes traffic according to 4 AC (Access Categories) - voice, video, best effort, and background.

WMM does not provide guaranteed throughput. It is suitable for simple applications that require QoS, such as Wi-Fi Voice over IP (VoIP) phone.

The keys of the QoS based on the DiffServ architecture:

wireless.<index>.tos2ac.<index>.status – specify the status of QoS [enabled/disabled]. Default: enabled. Enables packet classification on TOS value in IP header and dispatching to according radio queues. AC values 1..4 corresponds BK, BE, VO, VI queues. 2 LS bits in TOS not used and are masked out. Mapping record with tos=0 will be used as default rule for packets not matching any other configured mapping.

wireless.<index>.tos2ac.<index>.tos – specify the IP header TOS value, HEX format can be used, internally this value is masked with 0xfc, thus last 2 bits not used [HEX format].

wireless.<index>.tos2ac.<index>.ac – specify the queue in radio HW to select [1-4]. The queue value 4 means the highest priority.

wireless.<index>.tos2ac.<index>.drop – specify drop probability [0-2]. The value 2 means highest drop probability when queue getting full.

wireless. <index>.ap – specify the MAC address of the device to which the particular device will connect to [MAC address].

wireless.<index>.igmp_snooping – specify the IGMP snooping status [enabled/disabled]. Default: disabled. When enabled, AP will passively snoop on IGMP Report and Leave packets transferred between it's clients and IP Multicast hosts. It checks IGMP packets passing through it, picks out the group registration information and generates internal L2 MAC forwarding table. Then it forwards multicast traffic using unicast packets directed according to forwarding table.

Example:

 wireless.status = enabled
wireless.1.status = enabled
wireless.1.devname = ath0
wireless.1.ssid = my ssid
wireless.1.max_clients = 100
wireless.1.security = wep64
wireless.1.security.1.key = 00:AC:01:25:F2
wireless.1.security.2.key = 00:AC:01:35:F3
wireless.1.security.3.key = 00:AC:01:55:F5
wireless.1.security.default_key = 2

AutoLock WLAN

The AutoLock WLAN keys of the configuration file in this manual are provided for WILI-S 5.00 firmware version and later therefore they may differ from the keys of 3.54 firmware and former versions.

The WILI-S based device has possibility to lock the WLAN. This feature checks (using ICMP echo request, like ping utility) if specific hosts are accessible on the network. When network goes down - wireless service will be disabled. When network is up again - wireless service will be re-enabled. In the firmware version 4.00 and later the additional keys were implemented.

All available keys of the AutoLock WLAN feature are listed below:

autolock.status – specify the autolock feature status [enabled/disabled]. Default: disabled.

autolock.interval – specify the monitoring time period in seconds [number]. Default: 300 (5 min.).

autolock.retry_count – specify the number of failed reach ability checks, after which the wireless service will be disabled [0-3]. Default: 3.

autolock.verbose – specify verbose status [enabled/disabled].

autolock.<index>.status – specify current server entry status [enabled/disabled]. Default: enabled.

autolock.<index>.server – specify the IP address to be checked.

autolock.lock.action – specify the action on the lock event [none/down/up/kick/reboot]. Default: down.

• none – no action will be applied on the interface
• down – bring the interface down
• up – bring the interface up
• kick – kick all wireless clients
• reboot – reboot the device

autolock.unlock.action – specify the action when connection to the network re-established [none|down|up|kick|reboot]. Default: reboot.

• none – no action will be applied on the interface
• down – bring the interface down
• up – bring the interface up
• kick – kick all wireless clients
• reboot – reboot the device

autolock.control.<index>.status – specify the status of the wireless interface control [enabled/disabled]. Default: enabled.

autolock.control.<index>.devname – specify the name of interface for control. If the interface is not specified, all wireless interfaces will be used from the file /proc/net/wireless.

AutoLock has no influence on routes. As soon as interfaces are brought down the routes will be deleted.

Example:

autolock.status = enabled
autolock.interval = 600
autolock.retry_count = 3
autolock.1.status = enabled
autolock.1.server = 213.29.25.154 
autolock.2.status = enabled
autolock.2.server = 213.29.25.33
autolock.3.status = disabled
autolock.3.server = 212.22.99.66
autolock.4.status = enabled
autolock.4.server = 212.25.19.6
autolock.lock.action = down
autolock.unlock.action = reboot
autolock.control.1.status = enabled
autolock.control.1.devname = ath0
autolock.control.2.status = enabled
autolock.control.2.devname = ath1

In this configuration 3 servers are pinged at every 10 minutes (600s). One server checking is disabled. When at least one server does not respond 3 times - wireless interfaces ath0 and ath1 are brought down and wireless service will be disabled. When service becomes available again - the device will be rebooted.

VSSID

The master SSID should be preconfigured before adding VSSID.

The SSID defines a logical wireless network, and the WILI-S can be configured to provide another 15 wireless networks in addition to that defined by the primary SSID. Each additional SSID may be configured for different security settings (SSID, encryption, SSID broadcasting, layer 2 isolation, client limitation per SSID). All the SSIDs may be active at the same time meaning that client devices can associate to the access point using any of the SSIDs. In order to add/delete VSSID, wireless card must be in master mode and VSSID interfaces must be created before configuring them.

vssid.status – specify the VSSID feature status [enabled/disabled].

vssid.<index>.status – specify current VSSID entry status [enabled/disabled].

vssid.<index>.parent – specify the master interface on which the VSSID will be created. The value for this key should be “ath0”.

vssid.<index>.devname – specify the VSSID interface name [custom string up to 15 characters in length]. If not specified, default interface name will be ath0_<index>.

vssid.<index>.mode – specify the VSSID wireless mode [managed/master]. If this key is not specified, the VSSID will inherit the mode of the parent SSID. If you are planning to use vssids with different modes (STA and AP) on the same physical radio, first interface must be configured in AP mode.

The key vssid.<index>.mode affects the wireless throughput therefore this key must be used only if you are aware of the key use.

Example:

# create 2 new virtual wireless devices
vssid.status = enabled
vssid.1.status = enabled
vssid.1.parent = ath0
vssid.1.devname = ath0.v1
vssid.2.status = enabled
vssid.2.parent = ath0
vssid.2.devname = ath0.v2

WDS

The WDS keys of the configuration file in this manual are provided for WILI-S 4.00 and later firmware version therefore they may differ from the keys of 3.54 firmware and former versions.

A WDS (Wireless Distribution System) allow you to create a wireless network infrastructure. Normally the access points must be connected to a wired network (LAN), which is generally an Ethernet. Once connected, these access points create wireless cells allowing wireless connection to the wired network. The WDS feature allows the access points to be wireless connected to another access point, eliminating the need for a wired connection between them.

Use the following tips when configuring WDS:

• WDS mode can be enabled on each wireless interface (including virtual interface: VSSID)
• In order for WDS peers to communicate, all the WDS network peers must operate on the same channel (frequency) and have the same security settings
• Both sides have to be connected (AP-STA infrastructure) prior to turning WDS mode on
• If you need only to bridge two wired networks, use Wireless ACL configuration to prevent undesired association of other clients

In case you don’t use a WPA security, create an ACL rules to prevent undesired other clients association to the WDS.

All available keys of the WDS feature are listed below:

wds.status – specify the WDS feature status [enabled/disabled].

wds.<index>.status – specify the status of the particular WDS link [enabled/disabled].

wds.<index>.parent – specify the interface name on which the WDS will be created [string].

Example:

# Enable WDS mode on ath0 interface
wds.status = enabled
wds.1.status = enabled
wds.1.parent = ath0

Wireless ACL

Use the wireless access control list (ACL) service to control default access to the wireless network interfaces (ath0 and VSSIDs) or to define special access rules for wireless clients.

All available keys of the wireless ACL feature are listed below:

wacl.status – specify the ACL service status [enabled/disabled].

wacl.<index>.status – specify current ACL rule status [enabled/disabled]. Default: enabled.

wacl.<index>.devname – specify the wireless interface name on which the wireless interface rules will be assigned.

wacl.<index>.policy – specify the policy for wacl.<index>.acl.<index>.mac entries [open/allow/deny]. Default: open.

• open – policy means that no ACL will be used and ACL MAC entries will be ignored.
• allow – policy means that all client