Introduction to MOXA Intelligent Routing Framework

sacktoysSoftware and s/w Development

Dec 13, 2013 (3 years and 4 months ago)

98 views




Introduction to M
OXA

Intelligent
Routing Framework






2


Table of Contents

Introduction to MOXA Intelligent Routing Framework

...............................

1

Cha
pter 1


Introducing MIRF

................................
................................
...

5

MIRF in Brief

................................
................................
.............................

5

MIRF features

................................
................................
................................

5

Deve
lopment Environment and Tools

................................
............................

5

Knowledge base to use MIRF

................................
................................
........

6

Fundamental Concepts

................................
................................
...................

6

Chapter 2


Exploring the Code

................................
................................
.

7

MIRF architectural

................................
................................
....................

7

Third
-
Party Software

................................
................................
.....................

8

Inside the framework

................................
................................
.....................

8

Controller Macro

................................
................................
..........................

12

Code Organization

................................
................................
.......................

14

Chapter 3


Running the framework

................................
........................

17

Prerequisites

................................
................................
...........................

17

MIRF Installation

................................
................................
.....................

17

Default view model


web apps

................................
................................
...

18

Chapter 4


Basic Example Creation

................................
........................

20

The project a
dd
-
on features

................................
................................
....

20

The Data Model

................................
................................
...........................

21

The Controller

................................
................................
..............................

23

Chapter 5


Mastering Intelligent Routing Core

................................
......

27

Routing Core in Brief

................................
................................
..............

27

Code architectural

................................
................................
...................

27

Making your own rule

................................
................................
..............

29

Appendix A
-

Reference

................................
................................
..........

32


http://lartc.org/

................................
................................
..............

32


http://shorewall.net/

................................
................................
......

32


http://linux
-
ip.net/html/ch
-
routing.html

................................
..........

32


http://www.moxa.com

................................
................................
...

32

Appendix B
-

License

................................
................................
..............

33



3


Figures

FIGURE 2
-
1
: ILLUSTRATES THE MI
RF ARCHITECTURAL

................................
.........................

7

FIGURE 2
-
2: ILLUSTRATES THE R
ELATIONSHIP BETWEEN
VIEW LAYER AND MODEL

LAYER, NETWORK SETTI
NG UI FOR THE EXAMPL
E.

................................
......................

9

FIGURE 2
-
3: ILLUSTRATES THE F
ILE /USR/LOCAL/BIN/M
XREGISTER.CONFIG FOR
MAT.

................................
................................
................................
................................
......................

10

FIGURE 2
-
4: ILLUSTRATES HOW T
O REGISTER YOU OWN T
ABLE & APPLICATION T
O
MXREGISTER.CONF

................................
................................
................................
................

10

FIGURE 2
-
5: INSTRUCTION TO CR
EATE YOU OWN PROPRIE
TARY CONTROL LAYER

..

11

FIGURE 2
-
6: ILLUSTRATE HOW WE

TRIGGER THE CONTROL
LAYER

...............................

11

FIGURE 2
-
7: ILLUSTRATE OVERAL
L CODE FUNCTION

................................
...........................

15

FIGURE 3
-
1:
ILLUSTRATES THE COMM
AND LINE TO VERIFY T
HE SUITABLE PLATFORM

................................
................................
................................
................................
......................

17

FIGURE 3
-
2:

ILLUSTRATES THE LINE

WHICH TURNS ON PROGR
AM AND SWITCH TO
THE DEBUGGING MODE

................................
................................
................................
........

18

FIGURE 4
-
1:

ILLUSTRATES HOW NEW
ADD
-
O
N FEATURE SHOW ON WE
B INTERFACES.
THE FIGURE

................................
................................
................................
..............................

21

FIGURE 4
-
2:

SHOWS THE INSTRUCTIO
N HOW TO CREATE NEW
TABLE

..........................

22

FIGURE 4
-
3:

ILLUSTR
ATES HOW TO ADD LINK

OUR OWN PROGRAM IN F
ILE
MXREGISTER.CONF

................................
................................
................................
................

22

FIGURE 4
-
4:

ILLUSTRATES HOW TO I
NSTALL NTP CLIENT WI
TH DEBIAN APT TOOLS

.

23

FIGURE 4
-
5:

ILLUSTRATE SIMPLE NT
P TOOL USAGE

................................
.............................

23

FIGURE 4
-
6:

SHOW THE CONTROL PRO
GRAM TO IMPLEMENT NT
P ADD
-
ON FEATURES

................................
................................
................................
................................
......................

24

FIGURE 4
-
7:

ILLUSTRATES HOW TO U
SE SQLITE3 TO SIMULA
TE VIEW MODEL

............

24

FIGURE 4
-
8:

SHOWS HOW TO UPDATE
THE TABLE VIA COMMAN
D LINE

.........................

25

FIGURE 4
-
9:

SHOWS HOW TO SIMULAT
E APPLY ACTION FROM
VIEW MODEL

..............

25

FIGURE 4
-
10:

THE RESULT AFTER TRI
GGERING THE CONTROL
LAYER

..........................

25

FIGURE 4
-
11:

THE COMPLETE CODE OF

MYNTPPROGRAM

................................
................

26

FIGURE 4
-
12:

ILLUSTRATE THE RESUL
T OF MYNTPPROGRAM

................................
..........

26

FIGURE 5
-
1:

ILLUS
TRATE BRIEF VIEW OF
THE CONTROL LAYER IN

ROUTING CORE.

28

FIGURE 5
-
2:

ILLUSTRATE FIRST STE
P ON CREATING NEW RU
LE.

................................
.....

29

FIGURE 5
-
3:

ILLUSTRATE MESSAGE P
OP UP THE LOWEST PRI
ORITY FOR YOU NEW
CREATE RULE.

................................
................................
................................
..........................

30

FIGURE 5
-
4:

ILLUSTRATE MXTOOL PO
P UP SELECT ROUTE IN
TERFACE.
.......................

31


4




5


Chapter 1



Introducing MI
RF

MIRF in Brief


MIRF is a framework designed to shorten the development of multiple
WAN wireless gateway. Basically, it contains
default
tools such as web
applications, routing cores, firewall, QOS

and network setting
. What make
s it

different is

that

MIR
F
has
already develop
ed

a platform
call
ed

“glue”
middleware
that link
s

most of the application
s

to perform
multiple WAN
wireless gateway function
s
.


MIRF
F
eatures


MIRF was
designed

to fulfill the following requirements:



Leverage the most successful open s
ource Linux distribution
packages.



Database engine
-
independent



Easy to bind your proprietary software, as long as your binary
support Linux platform.



Ready
-
to
-
run

platform where users do not
need to modify the
application
s
. The default framework
has been

a
lready
built
-
in
multiple wan wireless gateway function.



Simple architectur
e, users

are
able to bundle either
the
proprietary or open source application
s

with simple bash shell
knowledge.



Easy

to extend


Development Environment and Tools


To fulfill the req
uirements of enterprises having their own coding
guidelines and project management rules, MIRF can be entirely customized. It

6

provides, by default, several development environments and is bundled with
multiple tools that familiar to open source community.


Knowledge base to use

MIRF

MIRF is
based

on

the

Linux

operating system
.

The
developers just need

to know basic skill as below:



Bourne Again Shell



Linux network utilities


ip, route, ifconfig…



Sqlite
3

utilities



Web / Ajax programming



Linux routing skills


Fundamental Concepts

Before you get started with MIRF, you should understand Linux multip
ath

routing concepts. Feel free to skip ahead if you already know the multip
ath

routing
technologies
.

http://lartc.org/howto/



7

Chapter 2



Exploring
the

C
ode

These chapte
rs guide you where to start

and how to modify the framework
for you needs. We will also explore how to bundler your proprietary software
on it

step

by step
.

MIRF
Architecture

MIRF
is designed
as much as possible
to foll
ow the
spirit of
MVC pattern.
In MIRF framework, it
split
s

the layer
s

into 3 pieces,
V
iew (the presentation
layer),
C
ontrol (the application logic) and
M
odel

(the data container).



View


The layer directly
contacts
with user interface. Web interface /
NMS
/ Command Line probably are the mostly suitable applications
that stand

for view layer.



Control



The control layer contain various application
s

such as
DHCP
, firewall, network utilities and etc
,

which
are

all control
led

by a
program

call
ed

mxEventNotifier
. All applications
are ‘glue’
themselves
via

a register
ed

file (mxRegister)

to
program
mxEventNotifier.

Any modification in model layer will eventually
cause mxEventNotifier to
execute

the
registered

application
s
.

The
control layer contains the code linkin
g the business logic and the
presentation; we will have deeply discussion in “Inside the
framework” session.



Model



The layer
support
s

retrieve/save function
s

for

the business
logic needed to manipulate the data in the application
s
.

MIRF use
s

SQLite3 to s
upport this layer.

The MIRF architecture separates the business logic (model) and the
presentation (view), resulting in greater maintainability. For instance, if your
application require new presentation layer such as NMS, you just need
to
develop your own

new
V
iew

layer
; you can keep the original controller and
model

layer
.

Always keep in minds that View layer only responsible on how the
data to be presented for user, data itself is meaningless to view layer.

Figure
2
-
1
:
illustrates the MIRF architectural


8


Third
-
Party Software

The MIRF
framework
comes bundled with a lot of third
-
party software to
build up wireless gateway function. If you are Debian

or
Ubuntu user, you will
feel right at home. If you not, it
will also work fine, but you will just have to
download the binary from somewhere or compiling the source code by yourself.

It doesn’t

matter what the binary is buil
t

(C code/Bash/Perl/Python),
just make
sure your application is able to run on Linux platfo
rm, and everything will be
just
fine
.

Inside the framework


In MIRF, the
each

layer is designed to
work
independently to
other
layer
.

Although the default
V
iew layer is provided with web interfaces, but the
user
s
can feel

free to develop their own user int
erface such as
SNMP, command line

or proprietary software

without interfer
ing

to business logic
.
The model
layer
is
suppose
d

to save everything that use
s

to
present

by view
layer

or information
that will be retrieved by controller

layer
. In other words, if

you design
a

user
interactive interface which contain
s

three input box
es
;
normally
,
the model

9

layer (sqlite3 db table) suppose to contain 3 columns that used to save the
input box value.


Figure
2
-
2
:
illust
rates the relationship between view layer and
model

layer
.
Here is the
network setting UI
as an

example.



E
ach input box shown

on the UI interface is corresponding to
table with
different column.
As show in the
Figure
2
-
1

for the example, we create a new
table name myNetworkTable
in sqlite3 database
and the values

from view
model

are save
d

into 3 columns, IP, NETMASK, and GATEWAY.
Always
design new tables

with addition column name “modif
ied” so that
mxEventNotifier
able to

check

whether you
r

table is modified.
Once you
complete saving all data, u
pdate the modified column
from ‘0’
into ‘1’
. The
program
mxEventNotifier
will

be triggered and eventually
wakeup
the
corresponding application

in

controller layer

to handler the data

change. We

will demo
later on chapter 3
how to
simulate the enviro
n
ment
. To link the
relationship between
application
and

table
,

you need to
edit the file
mxRegister.conf under directory /
usr/local/bin
.

myNetworkTable

UI

IP

SETTING

NETMASK

GATEWAY

APPLY

IP COLUMN

NETMASK COLUMN

GATEWAY COLUMN

MODIFIED
COLUMN


10

Figure
2
-
3
: illustrates the file /usr/local/bin/mxRegister.config format.



Figure
2
-
3

show
s

the
text format use
d

to create relationship
between view
lay
er and control layer.

If you have more than

one

single application to be
executed, split the applications
with


space


between
them,
and
mxEventNotifier will run each application in

sequential order
. Then column

modified


will then

turn
from

1


to

0


af
ter
all the applications

register
ed

to
the
specific

table
that
has been terminated.
Please note that
developer
s

MUST
NOT design their application run in foreground infinitely
, or

the rest of the
application
s

will have to wait until the earlier process term
inate.


The controller layer is the heart of
the
applications. Mostly, the job of
the
controller layer
is
used to read the data from
model

and decide

what to do next.
Let
said we like to create

a new simple

network application

features for the
example.

We
first add

the line below in file /
usr/local/bin
/mxRegister.conf as
Figure
2
-
4
.

Figure
2
-
4
: illustrates how to register you own table & application to
mxRegister.conf

TABLE NAME = application1 application2 application3

N
ew table name here,
for example:
myNetworkTable.

First application is
executed once the table
has been modified.

Second application

Third application

A space
ke
ystroke

MUST
BE
added

to indicate
multiple applications.


11



Now, create

a simple controller
application

name “myNetworkApp”
,

then
put it into directory /usr/local/bin.
Follow the instruction as shown in
Figure
2
-
5
,
we simply create a simple ap
plication and register to control layer
.

The
program shout
string “
Hello World


as soon as database table mxNetworkTbl is
modified.

Figure
2
-
5
: Instruction to create you own proprietary control layer


You will discover the program myNetworkApp will be executed once
we us
e

sqlite3 command tool to emulate

view layer
triggering the column

modified


to
mxNetworkTbl.

Figure
2
-
6
: Illustrate

how we trigger the control layer

bash# echo

#!⽢楮ish


> u獲⽬o捡氯l楮⽭y乥kwo牫䅰p

ba獨#⁥捨o

echo

䡥e汯lto牬d


>> u獲⽬oca氯b楮imy乥kwo牫䅰p

ba獨#⁣ mod⁡+牷x u獲⽬o捡氯l楮imy乥kwo牫App

ba獨# e瑣t楮楴id⽭楲f⁲ 獴s牴



m
x
乥kwo牫rb氠ly乥kwo牫䅰p





12



Under most circumstances,
the
controller layer is designed to take care of
the
action
s

below:

1.

Stop the application.

2.

Clean / Remove
the
application configuration files.

3.

Read data from
model

lay
er and recreate the configuration files.

4.

Set

the env
ironment

for the applications.

5.

Restart the application.

See the example:
we
would
like to add proftp server
http://www.proftpd.org/

in
current platform
. Our shell
program scenario will like below:

1.

Install proftpd with command “apt
-
get install proftpd”

2.

Add line “/etc/init.d/proftpd stop” at the beginning of
application.

3.

Add line read
information

from table which
creates

for proftpd
. W
e will
have deep description how
to use the macro provided by the framework
later
in “Macro”

section.

4.

Add line to clean the file /etc/proftpd/proftpd.conf

5.

Create the same configuration format to file /etc/proftpd/proftpd.conf,
except with the newest value read from table.

6.

Add line “/etc/i
nit.d/proftpd restart” at the end of shell program

Controller
Macro


I
n

the controller applications
,
most of
the
actions
usually

include

the
function
macro from file /usr/local/bin/mxGlobal.inc.
If you
want

to develop your
own bash shell macro which share
s

more than a

single program, it
is advi
sed

to put it into file /usr/local/bin/mxGlobal.inc. The default macro is already
provided common function as below:

Global function

bash#

sqlite3 /home/moxa.db

UPDATE mxNetworkTbl SET VALUE
modified=1 WHERE id=1 ;


S
qlite
command tool.

D
efault database is locate
in directory /home, name
with moxa.db


13

gb_sql_query_opt


Description
-

used to return clean variables during query database

Argument
$1


SQL string

gb_sql_query_lopt


Description


used to return result with columns and variables during
query database. It
is
designed
especially
to use with gb_import_var function.

Argument
$1


SQL string

gb_import_var

Description


Import the

variable return from function gb_sql_query_lopt
to current environment.

Argument
$1


result return from function gb_sql_query_lopt

gb_save_file

Description


Attach string to file. Create file if doesn’t exit.

Argument
$1


String to be saved


$2


File
name

gb_clean_file

Description


Clean file content. Create file if doesn’t exit.

Argument $1

File name

gb_delete_file

Description


Remove file.

Argument $1


File name

gb_save_file_to

Description


Duplicate file content to another file
.

Argument $1


S
ource file name

Argument $2


Destination file name

gb_network_up

Description


Bring up the network interface
.

Argument $1


Net devices name, eth0 for the example.

gb_network_down

Description


Stop the network interface if currently in use. Clean
everyt
hing relative files if use dhcp client.

Argument $1


Net devices name, eth0 for the example.

gb_network_setting

Description


Network interface setting.

Argument $1


strings “yes” or “no”,
“yes” use dhcp instead of static ip.

Argument $2

Net devices nam
e, eth0 for the example.

Argument $3


string “ip address”, valid if argument $1 set to “no”.

Argument $4


string “ip netmask”, valid if argument $1 set to “no”


14

Argument $5


string “gateway”, valid if argument $1 set to “no”. Be
careful not
to
interfere

with multip
ath

routing setting, otherwise conflict
will
occur and
the route core process

will fail.

Argument $6


strings “UP” or “DOWN”, require network interface status
to be activate or inactivate.

Argument $7


if string defined to “NET”, require netwo
rk interface to set
as
default gateway

gb_delete_default_route

Description


Clean all default route, prevent conflict occur during route
core process
.

Argument


none

gb_network_detect_ip



Description


Wait 20s for net device to be activated with ip add
ress
existence.

Argument $1


Net devices name, eth0 for the example.

gb_network_intr_link

Description


Detect
that the
net device is activated.

Argument $1


Net devices name, eth0 for the example.

gb_network_intr_detect

Description


detect slow modem d
evices and wait for exits

during query

Argument $1


Net devices name, eth0 for the example.

Argument $2


Wait time.

gb_calculate_subnet


Description


calculate subnet mask.


Argument $1


string “ip address”


Argument $2


string “ip netmask”

Code Orga
nization

Now that you
already
know
n

the different
layer

of a MIRF, you're probably
wondering how they are organized.

Project Structure: Applications
/Utilities
, Web

services
, and Database

MIRF organizes code is located in
/usr/local/bin directory
. We
put

t
he
project file naming start with “mx”, such as mxEventNotification, mxWifi,
mxRouteCo
r
e and etc; the
default (web asp)

code is located in /var/www
,
goahead application source code will be attach in
deliver
disk by
default;

Model layer
(SQLite3)
exits with
in few type: C library, shell macro, perl/
php

provided by
open source community
http://www.sqlite.org

.


15

mxEventNotifi
er

-

The Parent of all process
es

indicate and run program
s

registered by user (/
usr/local/bin
/mxReg
ister
.conf
). mxEventNotifier will check

modified


column predefine in
each
${TABLES}
, it
take action to
corresponding program once table’s modified column set to

1
’ and turn to ‘0’
later on
.

mxRouteCo
r
e



Routing decision logic control. It read
s

the sta
tus from
different interfaces, change the routing rules
each time

policies match.

mxSnmpd

-

The main function of this script is
used to
re
-
generate
/etc/snmp/snmpd.conf configuration file according to
table
mxSnmpTbl and
restart snmp daemon.

mxOpenvpn

-

T
he program
is used to prepare files need
ed

by openvpn
application
.
It

read
s

vpn information from
table
mxOpenvpnTbl,
and
restart
s

the openvpn relate process
.

mxEthernet

-

The program
is used to

read network information from
mxEthernetTbl, and reset the sys
tem network address.

mxAccessPoint

-

W
ireless access point

relate pre
-
configuration program
.

Take care of hostapd daemon relate configuration files.

mxFirewall



This could be the most complex program occur in controller
layer.
The program is
called

almost

by all network
relate
devices.
Shorewall/Shoreline firewall are complex modules,
G
o to shorewall.net before
you start modify the

application
.

mxLogger

-

The program is
to
wake up each time table
mxLoggerTbl

that

is triggered
. The
program

is
use
d

to contro
l the log action

and refresh the log
data in table mxLogTbl
.

Web

services

MIRF use goahead web servers as default view component. Please follow
the link
http://www.goahead.com/products/
webserver/default.aspx

for any
detail information.


Database

MIRF use Sqlite3 as default
model

component. Please follow the link
http://www.sqlite.org

for any detail information.

Figure
2
-
7
: Illustrate
over
all code function


16


CONTROL LAYER

MODEL LAYER

VIEW LAYER

/var/www

SQLite3 database

/usr/bin

S
ave/
retrieve

db information

Perl : DBD
-
SQLite

SQLite PHP

SQLite3 utility

C Language: libsqlite3.so

Bash: MIRF macro

mxEventNotifier

mxRouteCore

mxAccessPoint

mxWiFi

mxEthernet

mxSnmpd

mxFirewall

mxOpenVpn

mxLogger


17

Chapter 3



Running the
framework

As you've learned in
the
previous chapters, the MIRF
is
the
platform

which
act
s

more
like

‘glue’

middleware
. The goal is to make the use of collection from
different appl
ications and
tools
that can be

easily
combine
d
.
MOXA

Wireless
Gateway project uses
all
these files

to focus on high availability middleware,

so
installing MIRF means getting these files and making them available for the
project.

In this chapter, we will
run

the framewo
rk by tweaking the
configuration

here and there. In the process, you will learn more about all the features we
have introduced from the previous few chapters.

Prerequisites


MIRF requires MOXA
hardware
. Make sure you have it installed by
opening a command
line and typing this command:

Figure
3
-
1
:
illustrates the command line to verify the suitable platform


If the version number is 1.0 or higher w
ith series V24xx
-
LX, then you

are

ready
for the installation, a
s described
later
in this chapter.

MIRF Installation

MIRF is installed with entire image; make sure you get V24xx
-
MIRF romfs
from MOXA. Upgrade the image with Clonezilla utility,
http://clonezilla.org/

.

Once you fin
ished the upgrade process, change your directory to /usr/local/bin,
and you will discovery all the program is already locate in the directory.


18

Figure 3
-
2 illustrates the content of /usr/local/bin directory


MIRF is turn
ed

to off as default, edit file /etc
/init.d/mirf
and

change the
setting if you desire to use the feature.
To
run

the framework,

use command
#/etc/init.d/mirf start. The same command is used to stop the framework
except different argument, type command #/etc/init.d/mirf stop. Users are able
t
o turn on the debugging mode on /etc/init.d/mirf file during development
process.

Figure
3
-
2
:

illustrates the line which turns on program and switch to the
debugging mode


Default view
model



web apps

MIRF
framework provides

a default view
model
, web
user interface
.
Connect LAN 2 to your intranet; the default ip address is 192.168.3.127 with
netmask 255.255.255.0. Set any ip address within netmask 192.168.3.255,
and then you can connect via the web interface

by your browser
http://192.168.3.127
.

Figure 3
-
4 show the web user interface.


19



We will not cover how to edit the web user interfaces in this document.
That’s because the goal
here
is about to
introduce the overall a
rchitectural of
MIRF framework. We encourage you to download MOXA Wireless Gateway
Web Server Development document if you interesting on adding new feature
on web interfaces.


20

Chapter 4



Basic Example
Creation

This chapter will teach you how to create an example b
ase
d

on

the

MIRF
framework, which is
an

ftp

application for control layer. You will learn how to
develop you own control layer

and

use

to interact with
model layer
.

We will
demo
strate

the whole development process with a simple command line
instead of comp
lex web interface, so that you can understand the working
model.

The project add
-
on features

Before diving into the code head
-
first, let's describe the
add
-
on features
.
The following sections describe the features we want to implement in the first
version/
iteration of the
features

with simple stories.

The features would like to have Network Transfer protocol support and users
are able to use
the following
functions:

1.

Provide ntp server ip address configuration which prefer to sync from.

2.

Schedule interface th
at can be use to trigger the time sync process.

3.

Enable/Disable ntp server
.


21

Figure
4
-
1
:

illustrates how
the
new add
-
on feature
will be
show
n

on web
interfaces. The figure



Actuall
y, it
really doesn’
t matter
whether

you use web interface or other
program to interact with user. Remember that view layer
is
suppose
d to design

independently from control layer.
Although

Figure
4
-
1

use the web int
erface as
example, but you can have you own proprietary application to interact with
user
s
, as long as your program able to support save/retrieve function from
database.

T
he Data Model


First we need to build
databases which store the information from view

model from current existence db, /home/moxa.db.

Wizard





NTP setting

Server ip :

168.95.1.1

Schedule

M
inute:

Hour:


0


Day of Month:


0


Month:


0


Day of Week:


0


0

Apply

Enable
NTP:



22

Figure
4
-
2
:

shows the instruction how to create new table



As you can see in the
Figure
4
-
2

above, we ha
ve

create
d exactly similar
number of column as view model. The ‘modified’ column is a MUST each time
we create a new table, so that mxEventNotifier will notify relative program once
it is
triggered by any view program.


Next, we are going to regist
er according to w
hat program that we expect
to wake up once the table
is
set. Go to /usr/local/bin, edit the file
mxRegister.conf as
Figure
4
-
3
.

Figure
4
-
3
:

illustrates how to add lin
k our own program in file mxRegister.conf



23


Figure
4
-
3

shows an example
on
how we create a relationship between
our program (myNtpProgram) and database table (mxNtpTbl).

If you have
more than
one
single program to

be executed, leave a space behind
“myNtpProgram” similar to mxFirewallTbl in the register table.

The Controller


In the previous section, we already create
d

a data model to save
information from our view model. Now, it’s time to develop an action control
l
er
program. Although we
do
not

prepare the view model, we still can simulate the
whole concept by using sqlite3 command tool. We will leave the view
programming guide (web interface) in the other documentation.


One of the powerful
functions
in
the
MIRF fr
amework is
to
design

to
leverage
the installation tools from
the
most popular Linux distribution
. In this
example, we will demonstrate how to develop a simple control program with
the power of Debian installer management.
Before we start, m
ake sure your
ta
rget is able reach the internet, and follow the instruction below:

Figure
4
-
4
:

illustrates how to install NTP client with Debian apt tools



Figure
4
-
5

show
s

how we

use the ntp tool to update time with NTP server.
It is advices to read the man pages if you not familiar with ntpdate utility.

Figure
4
-
5
:

illustrate simple ntp tool usage


24


It is time for us to start writin
g the code once everything is set up to be
prepared. We are going to use bash shell script to create the control action,
and use the ntpdate utility to handler the time sync jobs. Edit a file name
“myNtpProgram” under /usr/local/bin

and make sure the file
have authority to
be executed (#chmod 777
myNtpProgram
)
. Note that the file name must have
exactly same as you register the program name in file mxRegister.conf.

Figure
4
-
6
:

show
s

the control program to imple
ment ntp add
-
on features


We encourage you to edit

the “DEBUG” in file /etc/init.d/mirf set to “yes”
,
so that you can easily

be

aware of what happened during
the
development
process
.
Now, i
t is about time to simulate the view component with sqlite3
comman
d tool,
Figure
4
-
7
.

Figure
4
-
7
:

illustrates how to use sqlite3 to simulate view model



25

I
nsert

a default

column in table mxNtpTbl as show in
Figure
4
-
8
.
Please
reference
http://www.sqlite.org

if you do not familiar with sqlite3 utility.

Figure
4
-
8
:

shows how to update the table via command li
ne


We are now inserting a new column for user to save their information from
view model. Now, open another new window, so that we can easily view the
action trigger by mxEventNotifier program.

Figure
4
-
9
:

s
hows how to simulate apply action from view model


Follow the instruction in
Figure
4
-
9
, we simulate the apply command on new
window. You are able to view the result by reading the file myNtpProgram in
direction /
tmp.

Figure
4
-
10
:

The result after triggering the control layer



26

Apply

the same concept to crontab and add more mechanism to control the
schedule once user turn on the enable button from view program.
Figure
4
-
10
0
will show the whole myNtpProgram.

Figure
4
-
11
:

The complete code of myNtpProgram


Run the step
Figure
4
-
9

again, and

you will

find the result
shown in

Figure
4
-
12
.

Figure
4
-
12
:

illustrate
s

the result of myNtpProgram



27

Chapter 5




Mastering
Intelligent Routing Core

In this chapter,
we assu
me
you are ready to dig
the
routing core. That
means you can tweak the routing core behavior base on the current existence
design

to meet your requirement
. This chapter takes you deep into the routing
core decision file, including
model

layer and control l
ayer.
.

Routing Core

in Brief


MIRF

framework
delivers

itself with few basic type of routing rules/policy
.
We classify
all these

type into following categories:


Time
-


Description


If current time (UTC) is falling in between the START FROM
and END TO int
erval, choose the select WAN and exclude the others.

Geography
-


Description


If current
location

(
GPS
) is falling in between the
UPPER/LOWER and LATITUDE/LONGITUDE

interval, choose the select
WAN and exclude the others.

Train Speed
-


Description


If c
urrent
speed

is
above


Activate Speed


interval, choose
the select WAN and exclude the others.

Device Connection



L
ink up time

Description


If selected WAN is continuously ping IP target in
predefine time interval, choose the select WAN and exclude the
others.

Signal Quality Level

Description


If
selected WAN (Wireless/GPRS) signal quality above

Signal Quality Level


level
, choose the select WAN and exclude the
others.

Co
de

architectural


MIRF routing build from main control layer (mxRouteCore) and a b
unch of

28

policy farm locate in /usr/local/bin/policies

directory
.
Commonly, e
ach policy
files

used to handle decision making on specific event, such as Train Speed,
Time and Geography
.

But that is not strictly limitation, it depend on how the
developer desi
gn their rules.

Figure
5
-
1
:

illustrate
s

brief view of
the
control layer in routing core.


mxRouteCore

1

Policy

farm

Train Speed

2

Geography

Time

Device
Connection

3

4

If step 3 acknowledge
mxRouteCore policy
match, then
mxRouteCore will then
read the appropriate
routing info from
database, go to step 5.
Otherwise continue step
1.

5

Linux Routing Table


Database Policies


29


mxRouteCore application
stay
s

in daemon process once the mirf start
s
.
The daemon will
con
tinuously

read policy set
tings

from
the
database defined
by
user
according to
its

priority
(
1), and search the appropriate
rules (
program)

in policy farm (2). Once
a rule is

load,
the
rules then act

as

route decision
mak
er,

whether
to use the

policy

or not
.
Each r
ule mostly does

the below job:



Read the system/device current information.



Read information from database fetch by other process.



Filter/confirm the condition is match to user predefine policy.



Acknowledge mxRouteCore daemon if condition match.

If
the
rule decide
s

to change the policy, it then
will
acknowledge the daemon
by returning

1


(3). mxRouteCore daemon will then read the routing
information such as weight of each devices, gateway and so on (4), and apply
to Linux routing table (5). If none
of rules match the condition, mxRouteCore
will recycle again the process from the start.

Making your own rule

In this session, we are going to define our own rule. Develop a new rule

in

MIRF framework is pretty simple job than you though.
Again, i
t doesn

t

matter
bonding

any Linux available programming language that you familiar with, just
make sure the program is able to run on Linux
environment
.

B
efore diving into the code

head
-
first, let's describe
our own rule
a bit
more. The following sections describe

the
rule

we want to implement.


1.

Check if file name

myfile


appear in directory /tmp

2.

If it does, use the
rule

we predefine.

3.

Otherwise, ignore the rule.


MIRF provide
s

a tool to assist
creating your own rule just in few simple
steps
.

1.

Change your directory

to /usr/local/bin/tools

2.

Run the mxTool.

3.

Naming your new rule.

Figure
5
-
2
:

illustrate
s

first step on creating new rule.


30


4.

mxTool
will
automatically generate the lowest priority for you new rule. The
message w
ill pop up as below:

Figure
5
-
3
:

illustrate
s

message pop up the lowest priority for you new create
rule.


5.

Add a simple description to your new rule, or leave it by press
ing

ESC key
.


31

6.

The final step is to
sele
ct
the corresponding interface once your
rule
becomes

active.

Figure
5
-
4
:

illustrate
s

mxTool pop up select route interface.


7. Exit mxTool.


Now, change your directory to /usr/local/bin/policies. New policy

template
will be

create
d

with filename

myTestRule

, same as your rule

s name
. Edit t
he
script according to your need, or replace the file instead your own program.
To
remind you again,

echo

1


or print

1


will cause mxEventNotifiy

replace the
default r
outing
interface

which you select.



32

Appendix
A

-

Reference




http://lartc.org/



http://shorewall.net/



http://linux
-
ip.net/html/ch
-
routing.html



http://www.moxa.com


33

Appendix B

-

License

MOXA LICENSE

Version 1, 29 November 2007


Copyright (c) MOXA Inc. All rights reserved.


The SOFTWARE is copyrighted and is protected by all applicable national
laws. Any duplication of the SOFTWARE other than for archival purposes is a
violation of law, i.e., redistribution of this SOFTWARE in s
ource and binary
form are prohibited. You agree to prevent any unauthorized copying of the
SOFTWARE.


LIMITED WARRANTY: MOXA Inc. or its distributors, depending on which
party sold the SOFTWARE, warrants that the media on which the SOFTWARE
is installed wi
ll be free from defects in materials under normal use. MOXA or its
distributor warrants, for your benefit alone, that during the Warranty Period the
SOFTWARE, shall operate substantially in accordance with the functional
specifications in the User's Manual
. If, during the Warranty Period, a defect in
the SOFTWARE, appears, you may obtain a replacement of the SOFTWARE.
Any replacement SOFTWARE will be warranted for the reminder of the
Warranty Period.


THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR

IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL MOXA
OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY
, OR CONSEQUENTIAL DAMAGES

(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(
INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.