|
Wiana
|
Description
|
|
Register nodes
|
 | For
manual registration follow this link and enter the hardware key of the
machine. |
 | Alternatively run
wianaregister at the command line of the node.
|
|
|
XX registered
|
·
Click here to see the list of nodes and check in status
|
|
Realm manager
|
·
Use the realm
manager to setup and maintain
users on the network
|
|
Node details
|
|
|
Hardware
Key
:
|
 | This
32 character value identifies your node uniquely. To find the hardware
key of a mesh node that you are logged into type
the command hardwarekey
at the command prompt Version: 0 - Build: 24 |
 | Major
releases of the MeshAP software are counted in "builds".
This value reports the current build installed on this node |
|
|
Wiana
certified IP
:
|
·
1.214.163.220
 | Each
node has a wireless IP number. These start off as random 10.x.x.x
numbers. Once registered WIANA assigns fixed 1.x.x numbers |
 | Node
certificate live or Node
certificate ready - hit Make Changes
|
 | Each node has a
digital certificate. Once they are live they are used to drive the
encryption and authentication checks between nodes.
|
|
|
Node configuration
|
 | Set
the primary wireless communication parameters in this section |
 | Node
name: |
 | Wiana
reports
will show this node name, which can be easier to remember than the
hardwarekey or IP number
|
|
|
ESSID
:
|
·
Set the ESSID
of the wireless network here.
|
|
Captive portal
:
|
 | The
captive portal controls access to services by clients using the
network. Turning it off lets users go straight in to the network
without first reaching a login page. |
 | The Old System
setting is a compatibility function for legacy installations. Not
needed in normal circumstances.
|
|
|
Portal mode
:
|
 | Fine-tune
the captive portal settings. Both lets guests in freely, and is useful
for early stages, |
 | Both
Auth and Open - Allow logins by recognized users and guests |
 | Auth
Only - stops guest access. |
 | Guest
Access open - Everyone’s a guest? |
 | No Access - Node is
closed - e.g. use this for maintenance periods
|
|
|
Portal timeout
(hours):
|
 | Set
the time that each login session lasts for. |
 | Portal
style: There are a variety of kinds of portal that you can set
here: |
·
WIANA based
·
nocatsplash
·
ticketed
·
remote
|
|
Ticket timeout
:
|
·
When using single use tickets, set the time they give on the
network here in minutes
|
|
GUI
:
|
·
Turn the internal graphical user interface on the MeshAP
on or off here. Turning this off preserves system resources.
|
|
PCMCIA support
:
|
·
Use this option for installation with a PCMCIA wireless
card; turn it off to save loading unnecessary drivers
|
|
Atmel support
:
|
 | Use
this option for to load the Atmel USB
drivers, turn it off to
save unnecessary loading faster boot up: |
 | This option skips
some checks during booting, saving about 10 seconds
|
|
|
First interface Wireless mode
:
|
·
Set the mode between adhoc and infrastructure. Beware that a
node on one mode can't talk to a node on the other mode, so change with
care, and work from the outer reaches of the network back to the centre
when making changes.
|
|
First interface Wireless Channel:
|
·
Set the channel carefully and ensure that there are other
machines within range that can communicate on this channel too.
|
|
WEP
:
|
·
Infrastructure
mode can support WEP
, but ad-hoc mode does not. This is currently supported on Prism adapters
only.
|
|
WEP
key:
|
·
The WEP
key must be shared with other clients using this cell
|
|
Second
interface Wireless mode
:
|
·
Secondary interface settings apply to twin radio nodes.
Beware that a node on one mode can't talk to a node on the other node, so
change with care, and work from the outer reaches of the network back to
the centre.
|
|
Secondary ESSID
:
|
·
Set the ESSID
of the second wireless network here.
|
|
Second interface Wireless Channel
:
|
·
Set the channel carefully and ensure that there are other
machines within range that can communicate on this channel too.
|
|
WEP
:
|
·
Infrastructure
mode can support WEP
, but ad-hoc mode does not. Currently supported on Prism adapters only
|
|
WEP
key:
|
 | The
WEP
key must be shared with
other clients using this cell |
 | Extra
features |
 | Additional
functions are set here. |
 | Hybrid
protocol: |
 | Set to YES allows the
take up of additional protocols as they become available.
|
|
|
Band extension
:
|
·
Recommended set to NO. On some networks setting YES will
allow seamless roaming between nodes.
|
|
Bandwidth revenue
:
|
·
Will enable future features for brokering traffic between
other nodes.
|
|
CTV USB
web cam:
|
|
|
Max wired clients:
|
·
Limit the number of local clients that can connect via the
Ethernet interface
|
|
Max wireless clients:
|
·
Limit the number of local clients that can connect via the
wireless network interface
|
|
Mesh nodes to use:
|
·
Limit the number of other mesh nodes that this node will
talk to within one hop.
|
|
DHCP
services:
|
·
Defaults to YES. Set to "NO" to stop offering DHCP
services. Use this setting on a machine that is only working
as a repeater.
|
|
DHCP
NAK
wrong nets:
|
·
Use NO on ad hoc networks that are overlapping their
wireless DHCP
services and giving confused DHCP leases. Otherwise leave as
YES
|
|
DNS
services:
|
·
Defaults to YES. Set to NO to stop offering DNS
services over the network. Normally matched with the DHCP
service
|
|
IPSEC
:
|
·
This option turns the IP Security
between nodes on and off.
|
|
Always mesh IPSEC
:
|
·
Setting this to YES stops the mesh talking to
un-certificated nodes; this can make it hard to get new nodes on the
network, but makes the security tighter.
|
|
Radius
only local:
|
·
Defaults to YES. When YES the local radius realm
is used as set below.
|
|
Radius
local prefix:
|
 | This
value is set by the system and should not be changed in normal
circumstances. |
 | Lock
to realm
prefix: |
 | Select a local realm
, as defined in the realm manager that
this node will use for authentication
|
|
|
Minimum cell signal
:
|
·
To avoid poor quality links through marginal connections,
set this value above zero. The exact value to use will depend upon your
network characteristics. Observe signal strengths on the Mesh Monitor (on
drop down menu in GUI
).
|
|
Mesh watchdog
:
|
·
The mesh watchdog is only suitable for use in well-saturated
networks, where the node should expect to see a lot of neighbors. If no
other mesh nodes can be seen the watchdog assumes that connectivity is
lost, and goes into a network search, to try to re-establish a connection
as a client, so that it can download its settings and get back on the
mesh.
|
|
Internal
watchdog
:
|
·
Set to YES this watchdog will reboot the machine if
processes lock-up.
|
|
Wireless sensitivity
:
|
·
Adjusts the sensitivity value for receiving on supported
network cards.
|
|
Wormhole capable
:
|
·
Wormholes are VPNs that link meshes together over the
internet. See Wormhole
Hubs
.
|
|
Wormhole hub address
:
|
·
Enter the Wiana
IP or private LAN address of the hub here
|
|
Wormhole key
:
|
·
Each node needs to enter the shared key here
|
|
Wormhole type
:
|
·
Internet wormholes use the Wiana
IP, LAN wormholes go over a private network. P2P not
supported yet.
|
|
Wormhole transport
:
|
·
Use UDP
unless your network blocks it, in which case use TCP
|
|
Traffic Shaping
|
 | Shaping
values set here define the parameters for managing bandwidth at the
node. |
 | Mesh traffic is the
data passed through this node from carried on behalf of other nodes in
the mesh. Routing traffic is the data sent between nodes to establish
routes.
|
|
|
enable shaping
:
|
·
Turn Shaping on or off
|
|
optimize traffic
:
|
·
Optimization should improve performance
|
|
eth
bandwidth
:
|
·
Define the speed of the Ethernet network
|
|
wlan0 bandwidth
:
|
·
Define the speed of the wireless network
|
|
mesh down: mesh up: mesh down burst: mesh up burst:
|
·
Mesh upload and download rates are set here, they can be
exceeded up to the value of the burst limit if there is spare capacity
available on the network.
|
|
routing down: routing up: routing down burst: routing
up burst:
|
·
Routing bandwidth settings are important to ensure that the
network can remain intact.
|
|
Client
Shaping
|
 | Client
shaping defines the rules that are used to deliver bandwidth to users
of the mesh. |
 | Users
can have one of four classes, Owner, Public, Member, and Unknown.
These values relate to the class defined in their Realm user settings. |
 | Client
shaping rules are applied on a per user basis. |
 | Each class of user
has rules for their bandwidth rights, defined separately for upload
and download. In addition to their regular bandwidth they can also use
a limited number of "burst" events, where they request data
at a higher rate for a short period. This improves interactive
response without giving away too much bandwidth on an ongoing basis.
|
|
|
Burst settings
allow greater bandwidth use if spare capacity is available.
|
 | unknown down:
|
 | unknown up:
|
 | unknown down burst:
|
 | unknown up burst:
|
 | public down:
|
 | public up:
|
 | public down burst:
|
 | public up burst:
|
 | member down:
|
 | member up:
|
 | member down burst:
|
 | member up burst:
|
 | owner down:
|
 | owner up:
|
 | owner down burst:
|
 | owner up burst:
|
|
|
Firewalling
|
 | Firewall
settings are applied in relation to user class. By default higher
classes of users don't get blocked. |
|
|
Apply
block to Owner users:
Apply block to Member users:
Apply block to Public users:
Allow FTP port 21:
Allow SSH port 22:
Allow TELNET port 23:
Allow SMTP port 25:
Allow HTTP port 80:
Allow POP3 port 110:
Allow RPC port 111:
Allow HTTPS port 443:
|
|
|
Total
block on incoming wired:
|
·
This locks down a wired LAN that is connected via the mesh,
to make a high security fire walled connection.
|
|
Root password
:
.
|
·
Set the root password here.
·
Privacy cipher:
·
You can use this value to secure the data on your mesh
|
|
Mesh Port
mappings:
|
·
These options will allow port mappings - not yet
implemented
|
|
Bluetooth
.
|
·
These features apply to the Bluetooth
meshing functions, which are available as a separate
commercial module
|
|
Bluetooth
:
|
·
Enables the Bluetooth
functions
|
|
Bluetooth
data:
|
|
|
offer mesh as
modem:
|
|
|
GPRS
backhaul:
|
·
Provides internet connectivity using a GPRS
equipped phone
|
|
GSM
backhaul:
|
·
Provides internet connectivity using a GSM
modem
|
|
Bluetooth
Options:
|
|
|
Bluetooth
fileserver:
|
|
|
Bluetooth
audio:
|
|
|
Bluetooth
mp3/ogg stream:
|
|
|
Bluetooth
phone emulation:
|
|
|
PSTN phone handoff:
|
|
|
Bluetooth
web cam:
|
|
|
Bluetooth
admin:
|
|
|
admin auto notify:
|
|
|
root presence lock:
|
|
|
Admin MAC
:
|
|
|
Bluetooth
Cell ID:
|
|
|
Bluetooth
meshing:
|
|
|
Bluetooth
SMS emulation:
|
|
|
GSM
SMS handoff:
|
|
|
|
|
|
Dialup
settings
|
 | Use
these settings to configure a dial-up Internet connection on the MeshAP.
These can be used for demonstrations or backups, but are unlikely to
be the primary Internet connection for the mesh. Email mailto:support@locustworld.com
for more information on these settings if you need them. |
 | Dialup
back
haul: Dial
on
|
|
|
demand:
|
|
|
Dialup
type
:
|
|
|
Dialup
port:
|
 | Serial
port 1 |
 | Serial
port 2 |
 | Internal
card |
|
|
Phone
number:
|
|
|
ISP
username:
|
|
|
ISP
password:
|
|
|
Auth type
:
|
|
|
Core settings
|
·
These settings define the hardware configuration of the node
|
|
Flash type
:
|
 | Enter
the memory capacity of the boot device used in the node. For hard disc
use "Other". |
 | These
settings should not normally need to be changed. |
|
|
Preserve settings:
|
 | When
set to YES the machine's custom settings will be maintained during a
software upgrade. When set to NO the machine will come up on standard
settings after a software upgrade, and it will need to check in to
download them again and re-certify. |
|
|
VGA
mode
:
|
 | Defines
the resolution of the GUI
|
 | 800x600x16 |
 | 1024x768x8 |
 | 1024x768x16 |
 | 640x480x24 |
 | 640x480x16 |
|
|
Soft Booting
:
|
·
Suitable for the ISO
CD image
|
|
External radius
:
|
 | Enter
the IP number of the remote radius server |
|
|
static
eth
addr:
|
·
If the node is on a LAN without DHCP
set the IP number that it should have here. Should match
settings in /etc/static
|
|
static
eth
net mask:
|
·
If the node is on a LAN without DHCP
set the net mask that it should have here
|
|
static
eth
gateway:
|
·
If the node is on a LAN without DHCP
set the IP number of the gateway machine here
|
|
static
eth
DNS
:
|
 | If
the node is on a LAN without DHCP
set the IP number of the
DNS
server here |
|
|
Cell ID 1
:
|
 | Each
node maintains two cells. The first cell is used for the DHCP
services on WLAN0 and the
inter-node VPN cell number in IP gateway tunnel mode. |
|
|
Cell ID 2
:
|
·
This second cell id is used for twin radio installations
|
|
Gateway
tunnel
:
|
 | PPP |
 | IP |
- PPP
tunneling gives more capacity for VPNs than IP tunnels, which are
more suited for smaller meshes.
|
|
Hostmapping
|
 | Host
mapping allows you to map a public internet address (or LAN address)
from your gateway point to a remote wireless or wired device connected
to a remote MeshAP anywhere on the mesh.
|
 | Setting
up host mapping is intended as something done as an installation.
That is to say that the configuration doesn't change that
frequently. Hostmapping
is
intended for advanced users.
|
 | What
you need to know:
|
- Remote
server's LAN side IP address. It is recommended to set it to a
static
IP
in the top end of the range 192.168.X.220-240 in the range of the DHCP
that
the MeshAP it is connected to is giving out.
·
The
first cell ID of the node it is connected to
- The
public / LAN address you want to map.
 | Checklist:
Hostmapping
is
only supported in tobuild25dev42 onwards.
|
 | Remote
node gateway type
is
IP and not PPP Cell IP does not conflict with any others (Wiana
will
warn you) Local wired side of the remote MeshAP does not conflict with
elsewhere on the mesh. It can be changed to a specific range, changing
the "X" quoted above.
|
 | Ranges
should be 1-120 for that part of the subnet. - this only applies if
the remote device is connected via the remote MeshAP Ethernet or if an
AP is connected to that Ethernet that the remote device is then
connected to wirelessly.
|
 | Note:
You can technically have overlapping wired cells but this could cause
confusion later. You can also overlap them with the LAN range of the
network that the gateway is attached, but this makes the remapped IP's
unreachable from the gateway as it thinks they are remote IP’s on
the mesh. In short - not recommended but possible in large networks if
you get short of cell ranges.
|
 | Check
that the IP you are redirecting is in the same subnet as the gateway,
it is possible to map addresses not in that range, but this requires a
special net mask setting not covered here.
|
 | So
for example. Our remote server is 192.168.5.220 set to static
IP
on a direct-wired Ethernet on a remote MeshAP. The first cell id of
that MeshAP is 210. The remote internet address we're mapping to it is
12.34.56.78
|
 | Enable
port mappings and host mappings (if displayed) in the Wiana
management
page. In the Hostmapping
specification,
enter a line, which reads as follows.
|
 | 12.34.56.78 210 192.168.5.220
|
 | These
are: Public IP - Cell ID - Remote address.
|
 | Update
the node and it should then start remapping. You must make sure the
remote device is authenticated or traffic cannot flow - use of an
automac is recommended for this and of course the automac can
represent a user and a traffic class, so you can traffic shape remote
servers if required. |
|
|
Protocol
support
:
|
 | Not
all protocols are supported yet; web email etc and any TCP
/UDP
based
service should run fine. I'm not sure what will happen if the remote
mapped box is also a NAT
gateway
itself.
|
 | For
windows file sharing, it’s possible to enter the IP address URL,
into windows and it will connect directly to the file share. This
should work outbound from any mesh client already, even without host
mapping.
|
 | With
a host mapped host you can access it's file share simply by typing its
IP into the address bar of windows explorer preceded by \ e.g.:
\12.34.56.78
|
 | Note
that host map is a 1:1 IP mapping between the hosts, so Hostmapping
opens
up security implications for the remotely attached device.
|
 | The
host map also only runs when the remote node has internet gateway
connectivity, if this link breaks the connectivity to the host mapped
device will also be broken until the link is re-established. |
|
|
Splash page
customization HTML insert:
|
 | Allows
the captive portal page to be customized. The HTML is added at the top
of the page. |
 | Example |
<B>Welcome to
Feeed<br>
Serving Hastings and St.Leonards</B><br><br>
Visit <a href="http://www.feeed.com>www.feeed.com</a>
|
|
Make Changes
:
|
 | Click
here to schedule an update. Once clicked, the next time the node check
in it will download these settings and apply them. A message will
appear in red at the bottom of the reloaded page to indicate you have
a scheduled operation. |
|
|
Ticketing
|
 | To
utilize one time ticketed passwords follow the procedure below: |
 | Create
a new realm
on your Wiana
account called TICKETED |
 | Edit
this realm
and use the "Create
Tickets" button to produce tickets as required for the various
login classes. |
 | Click
"Email all passwords" button to receive a copy of all the
passwords for the realm
via email. |
 | On
the nodes concerned, manage their settings and ensure that the
following options are in place: |
·
Captive Portal = capture ON
·
Portal Mode = Auth Only
·
Portal Style = Wiana
based
·
Ticket Timeout = time you want each ticket to last in
minutes
·
Radius
only Local = YES
·
Lock to realm
prefix = Ticketed
·
Click update for the node and after next check-in it should
allow access once for each ticket. Tickets are removed live from Wiana
, so it is easy to track progress and to receive an updated mailing of
remaining tickets.
|
While
the mesh is encrypted
end-to-end, wireless end-user clients connect over an
unencrypted connection to their local cell.
To
provide a secure and robust authentication a VPN protocol is used. At this time,
the MeshAP software supports PPTP VPNs, which are typical of Microsoft Windows
computers and implementations exist for many other platforms as well.
VPN
users work within a realm
; using the realm manager you must first have created your realm and user within
that realm. Select VPN as the type
for the user. Note that VPN logins
can only be used with VPN connections.
Make
sure your local node is set to "Radius
only Local" and Lock to realm
of the realm you wish to utilize on
the local cell.
MS-CHAP
v2 authentication require encrypted
connection - disconnect if none Server host name / address is:
vpnhost. Compression off
Note
the full stop / period mark at the end of vpnhost - this is important for it to
work on all platforms.
The
username and password are those from the username/password of the realm
user.
This
has been successfully tested with Windows 2000 and Windows XP; reports are
welcomed from other platforms.
Connect
using Internet Connect. Under File you will see the option New
VPN Connection Window. Under Server Host put in "vpnhost."
Under username and password put in the username and password created under your
realm
for VPN clients. Click connect.
Wormholes
link networks of nodes together through other network links. Typically
non-wireless but delivered over IP. Such as the Internet, a local LAN or a
point-to-point
connection such as an eps9 circuit.
This
facility allows you to join together geographically distributed meshes into a
single unified network.
With
Internet connections, some MeshAP may be behind NAT
and so cannot accept incoming connections. Typically a
"wormhole hub" is used to link NATed connections like this together.
Designate
one machine, which has full IP connectivity as the hub. Set the Wiana
"Wormhole key
" to a secure password, which your hub connected, machines will share.
Select the appropriate Wormhole type
, e.g. "Internet"
Update
the settings on the wormhole hub machine. Nothing is entered in the "hub
address" field for the hub machine.
On
all the other machines, which you wish to connect in to the hub, manage their
Wiana
settings and enter the same key and wormhole type
. On these "wormhole client" machines, set the wormhole hub address as
the literal Wiana IP address of the hub node. e.g., 1.96.23.121
Update
the settings and you should find that in time, you could simply ping one network
from another. Interconnections between the networks will expand the routing
tables, but connecting to a host will open the route up.
The
wormholes use blowfish encryption and compression on every packet. Intramesh
communications over the wormhole also use individually negotiated host
encryption ensuring privacy even over shared managed mesh links.
If
your node, which is connecting in to a hub, cannot support UDP
via a NAT
proxy or firewall, then switch the
mode to TCP
. Likewise if your hub is behind a firewall, then you need to port redirect port
51010 with both UDP and TCP if possible. If you can't redirect UDP then all the
nodes connecting in to the hub should be set to TCP mode.
Wormhole
hubs can currently only be used in infrastructure mode. This may change in the
future.
- Register
at wiana.org
to receive an encryption key
and management of nodes.
- Email
Wiana
login name to nodes@ultramesh.com.
·
- Node
will be transferred to your account.
- Nodes
are set up for Infrastructure
mode with the ESSID
of Ultramesh
and DHCP
client on the Ethernet
interface.
If
your DHCP
server does not hand out an address
due to an incompatibility, use the following instructions to set a static
IP on the box.
Connect
wirelessly and obtain an address. From
there, using SSH, log into the unit using the gateway address on the laptop you
are using. The login username is
root and the password terra7. From
there, enter the following commands:
vi
/etc/STATIC <ENTER>
Then
edit the file as follows:
Hit
<INS> key and enter
192.x.x.x
255.x.x.x
192.x.x.1
Where
the ip address you want on the unit is the first 192.x.x.x, the subnet is the
255.x.x.x and the gateway is 192.x.x.1. Change
those values to whatever makes sense for your network.
Then
hit <ESC> and then :wq <ENTER>.
Type
reboot <ENTER> and start a ping to see if the box is communicating via the
Ethernet port.
IEEE
802.11b
Frequency Band 2.4 – 2.438 GHz
Modulation DSSS
(CCK, DQPSK, DPPSK
TX power 100mW
Media Access Protocol
CSMA/CA with ACK
RX Sensitivity -94 dBm (1 Mbps)
Data rates supported 11.5.5,2,1 Mbps
128/40 bit WEB
Impedance: 50 ohms
Antenna
connection RS-SMA
DHCP
server
DHCP
relay
TCP
and VPN session persistent roaming without client software
Full VPN Compatibility
Full 802.11b Client compatibility
SNMP
V2
HTTPS to on board management tools
Secure local and remote management tools via HTTPS
Web-based management tool
Configuration
save and restore via WIANA.ORG
Full VPN compatibility
VPN filtering – rejects non-VPN traffic
Mac address access control lists
HTTPS to on board management tools
AES encryption of wireless control protocol
NAT
support with port forwarding
128/40 bit WEP
HTTPS element management security
Mesh node
digital certification
2048 bit encryption for inter node communications
Operating temperature 0°
C to 50° C
Humidity 95% non-condensing
FCC CFR47 Part 15, Class A
UL/cUL Listed
UL 60950
Plenum rated
CAN/CSA -C22 No 60950
Ultramesh
Power adaptor
Hardware installation guide
Quick start guide
Antennae sold separately
Auto sending 10/100BaseT Ethernet
Auto sending Bluetooth
2 USB
Power Input options
External wall plug-in AC power supply 120-140 AC
Power over Ethernet 802.3af
Dimensions:
Weight without antenna
Indoor
17.25 cm 1.5dBi omni
directional antenna
Maximum indoor range 100M
cm
5.0dBi omni
Maximum outdoor
range