Setup static ARP entry when using the tunnel device to communicate with each other over the GNURadio OFDM Link

---------- Forwarded message ----------
From: Alex Zhang <cingular.alex@gmail.com>
Date: Thu, May 3, 2012 at 11:30 PM
Subject: Setup static ARP entry when using the tunnel device to communicate with each other over the GNURadio OFDM Link
To: riveridea_wordpress <zuxo596ruhe@post.wordpress.com>


Here I am talking how to set the static routing entry between two nodes on both of which the tunnel device is used. As the physical layer is OFDM link which is sometime not so stable, the dynamic ARP query could degrade the link quality. The static ARP routing query is used in such experiment, with diagram of below.

     -----Socket-----TUN/TAP------OFDM-----> ======Radio===== ---->OFDM-----TUN/TAP------Socket--------
     \____________________________________/                   \_______________________________________/
                     Node 1                                                   Node 2


1. When creating the tunnel device, the MAC address of the tunnel device is autogenerated if not specified by yourself. And this MAC address is different for each time of creation of the tunnel device. But you can assign the fixed MAC address to the tunnel device by the iocntl() with SIOCSIFHWADDR option. Below is an example for such operation using Python code.

import os, sys
import random, time, struct
import fcntl
import socket
# /////////////////////////////////////////////////////////////////////////////
#
#   Use the Universal TUN/TAP device driver to move packets to/from kernel
#
#   See /usr/src/linux/Documentation/networking/tuntap.txt
#
# /////////////////////////////////////////////////////////////////////////////

# Linux specific...
# TUNSETIFF ifr flags from <linux/tun_if.h>

IFF_TUN        = 0x0001   # tunnel IP packets
IFF_TAP        = 0x0002   # tunnel ethernet frames
IFF_NO_PI    = 0x1000   # don't pass extra packet info
IFF_ONE_QUEUE    = 0x2000   # beats me ;)


# From linux/sockios.h
SIOCGIFINDEX = 0x8933
SIOCGIFFLAGS =  0x8913
SIOCSIFFLAGS =  0x8914
SIOCGIFHWADDR = 0x8927
SIOCSIFHWADDR = 0x8924
SIOCGIFADDR = 0x8915
SIOCSIFADDR = 0x8916
SIOCGIFNETMASK = 0x891B
SIOCSIFNETMASK = 0x891C
SIOCETHTOOL = 0x8946
 
# From linux/if.h
IFF_UP       = 0x1
 
# From linux/socket.h
AF_UNIX      = 1
AF_INET      = 2

def open_tun_interface(tun_device_filename):
    from fcntl import ioctl
   
    mode = IFF_TAP | IFF_NO_PI
    TUNSETIFF = 0x400454ca
   
    tun = os.open(tun_device_filename, os.O_RDWR)
    ifs = fcntl.ioctl(tun, TUNSETIFF, struct.pack("16sH", "gr%d", mode))

    ifname = ifs[:16].strip("\x00")

    newmac = '22:22:11:11:11:11'
    macbytes = [int(i, 16) for i in newmac.split(':')]
    ifreq = struct.pack('16sH6B8x', ifname, AF_UNIX, *macbytes)
    fcntl.ioctl(tun, SIOCSIFHWADDR, ifreq)

    ''' Obtain the device's mac address. '''
    ifreq = struct.pack('16sH14s', ifname, AF_UNIX, '\x00'*14)
    res = fcntl.ioctl(tun, SIOCGIFHWADDR, ifreq)
    address = struct.unpack('16sH14s', res)[2]
    mac = struct.unpack('6B8x', address)
    #print mac
 
    #print ":".join(['%02X' % i for i in mac])

    return (tun, ifname)

2. Add static ARP entry for the destination which is also a tunnel device
    As the tunnel device is now with a fixed MAC address for the destination, the source host can setup the static ARP entry as below:
    In /etc/network/if-up.d/, you can create a file named add-my-static-arp with below content:
    "arp -i gr0 -s 192.168.200.1 22:22:11:11:11:11"
    Every time, after you boot up the tunnel device in your source host, you can run the command of below to add such entry:
    /etc/network/if-up.d$ sudo ./add-my-static-arp

3. Of cours, you can not forget to config the IP address of your tunnel device as:
    sudo ifconfig gr0 192.168.200.2
   Before you config the IP address, you can ifconfig to check the name of your tunnel device.
  


--

Alex,

Dreams can come true – just believe.

--

Alex,

Dreams can come true – just believe.

Quicksoft Notes - 2011/06/01

Using the partition, the first pivot is using the a[right] or a[left+(right-left)/2]. For the latter, remember to swap the a[left+(right-left)/2] to the a[right] firstly.

Then

void quicksort(int* array, int left, int right)

{

if (right > left) // subarray of 0 or 1 elements already sorted

{

    //select a pivotIndex in the range left ≤ pivotIndex ≤ right
    // see Choice of pivot for possible choices

    int pivotIndex = left+(right-left)/2;

    int pivotNewIndex = inplace_partition(array, left, right,pivotIndex); // element at pivotNewIndex is now at its final position

    quicksort(array, left, pivotNewIndex - 1); // recursively sort elements on the left of pivotNewIndex

    quicksort(array, pivotNewIndex + 1, right); // recursively sort elements on the right of pivotNewIndex

}

}

One interesting thing for swap:

Can you see any problem for such code looking wise?

void swap(int& a, int& b)

{

a = a + b;

b = a - b;

a = a - b;

}

Reference: Introduction to Algorithms, Chapter 7.1.

UML PSM

UML Protocol State Machines

• always defined in the context of a classifier (e.g. a class or interface)
• specifies which operations of the classifier can be called in which state and under which condition
• states of protocol state machine cannot have entry, do and exit behaviors
• protocol state machines cannot have history and deep history pseudo states
• transitions of protocol state machines cannot have effects
• transitions have [precondition]trigger/[postcondition]:

• classifier operations not represented in a protocol state machine do not have an impact on state
• protocol conformance defined explicitly via ProtocolConformance (specific state machine, general state machine tuple)

Use Case In UML 2.0

Use Case in UML 2.0

Use case diagram has below key elements:
1. Actors:
2. Use Cases:
To describe the functionality unit which can be detected by the external world provided by the system. It is depicted to interaction between the system unit and one or more actors who intercts with it.
3. Relationships
1. Extend:
The extend relationship specifies that the behavior of a used case may be extended by the behavior of another use case. It is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior defined in another used case which is meaningful independently of the extending use case. It is something like the relationship between the base interactions(extended use case) and the supplementary services(extending use case).
This relationship also has below elements:
a) Condition: Reference the condition that must be hold when the first extension point is reached for the extension to take place. If no condition is associated with the extend relationship, the extension is unconditional.
b) Extension point. Please see below element on the description.
2. Include
This is quite a simple relationship, in which the behavior of a use case (included use case) can be inserted into behavior of another use case (including use case). The include relationship is extended to be used when there are common parts of the behavior of two or more use cases. This common part is then extracted to a separate use case, to be included by all the base use cases having this part in common. Since the primary use of the include relationship is for reuse of the common parts, what is left in a base use case is usually not complete in itself but dependent on the included parts to be meaningful.
4. Extension points:
Do not confuse it with the extend relationship!
It is a feature indicating a point where the behavior of a use case can be augmented with elements of another (extending) use case. In other words, this point resides in the extended use case, while the extended case adds the behavior at this point. And please also note that the extending case is not aware of the existence of the extending use cases. This is like the trigger point of the base interaction flow.
5. Extension Location
6. Subject:
7. Package: Usually the use case are owned by the package.

UML 4+1 View Materials

4+1 View of UML Diagrams

Considering that the UML diagrams can be used in different stages in the life cycle of a system, let us take a look at the "4+1 view" of UML diagrams. The 4+1 view offers a different perspective to classify and apply UML diagrams. The 4+1 view is essentially how a system can be viewed from a software life cycle perspective. Each of these views represents how a system can be modeled. This will enable us to understand where exactly the UML diagrams fit in and their applicability.

These different views are:

• Design View: The design view of a system is the structural view of the system. This gives an idea of what a given system is made up of. Class diagrams and object diagrams form the design view of the system.
• Process View: The dynamic behavior of a system can be seen using the process view. The different diagrams such as the state diagram, activity diagram, sequence diagram, and collaboration diagram are used in this view.
• Component View: Next, you have the component view that shows the grouped modules of a given system modeled using the component diagram.
• Deployment View: The deployment diagram of UML is used to identify the deployment modules for a given system. This is the deployment view of the
• Use case View: Finally, we have the use case view. Use case diagrams of UML are used to view a system from this perspective as a set of discrete activities or transactions.

------------------------------

The Unified Modeling Language (UML) was developed by Grady Booch, Jim Rumbaugh and Ivar Jacobson (the Three Amigos) as a way to define large complicated systems. This small page summarizes and over-simplifies some of their important work. Although titled 'UML' some of the Rational Unified Process (RUP) has somehow crept in.

1. UML has a Four+1 view of a system:
   1. Use Case View (the '+1' part).

      This spans all the other views and is central to UML and the Rational Unified Process. It presents a user centric view of the system without regard to implementations. The Use Case view should focus our attention all through the software development process on what we are really trying to accomplish. The main elements of this View are

      1. Actors - outside entities that interact with the system. These can be people or other systems. Represented by a stick figure.
      2. Use Cases. Represented by an oval.
      3. Use Case Diagrams. Contain actors with relationships.
      4. Interaction (Sequence, Collaboration) Diagrams
      5. Packages
   2. Logical View

      This view shows both the static and dynamic views of the system. The logical view concentrates on getting the best logical grouping of functionality into objects. The main objects of this View are

      1. Classes
      2. Stereotypes
      3. Packages
      4. Class Diagrams
      5. Relationships
      6. Collaborations
      7. Interactions
   3. Implementation View

      This view concentrates on taking the Logical view and dividing the logical entities into actual software components.

      1. Components
      2. Component Diagrams
      3. Hierarchy of Classes and Packages
   4. Process View

      This view is concerned with how all the independent flows of execution play together.

      1. Processes
      2. Interconnections between processes and threads
   5. Deployment View

      This view details how the software is deployed into that somewhat important layer we call 'hardware'.

      1. System performance
      2. Design times for responses
      3. Quality of Service (QoS)
      4. Maintenance frequency and effects on uptime
      5. Computing nodes within the system
2. UML has eight and a half types of diagrams
   1. Activity - the actions taken by an operation
   2. Class diagram - the static relationships, methods, and fields of an object
   3. Collaboration - the relationship between components
   4. Sequence - flow of events over time (oddly enough contains the same info as Collaboration)
   5. Component - the physical components
   6. Deployment - how to push the software to hardware
   7. Object - objects and their relationships
   8. Statechart - operation of system shown through states
   9. Use Case - the functions of a system from the user's perspective.

----------------------------

Software Architeture Course at Toronto Univ.

http://www.cdf.toronto.edu/~csc407h/

Just an example of how the UML&Soft Architecture is taught in the College. In fact, do not assume that you can learn a lot and become a master only via the process of such a college course facing the college students. But it still benefit you if you have no idea how to begin if you start to learn these abstract knowledge out of the campus.

Course List:
http://www.cdf.toronto.edu/courses/current.html

Classic UML textbooks

UML Books in hand:
1) Basis of the UML OO Programming by Miller Page-Jones
2) Applying UML and design Patterns by Craig Larman
3) UML Reference Manual by the James Rumbaugh, Ivar Jacobson, Grady Booch
4) UML distilled by Martin fowler, Kendall Scott

Jones and Larman's book 1)&2) can be regarded as the textbook as the daily learning and the 3) & 4) are more proper to be rea
d when needing reference or do more and further investigation.
It is interesting that there are also courses and exams based on Larman's book
on the website. Larman's book has already been used as the standard textbook,in
many universities, to teach the basic skills of developing the OO system and
carrying the OO projects.