Virtual Access Points

Virtual access point(s) may be defined as logical abstraction(s) built on an underlying physical device. Once defined on a physical device each virtual access point is capable of operating as an independent entity from other virtual devices defined on the same physical device. The current Atheros cards on the orbit nodes come with a ​MadWifi driver that supports setting up of multiple virtual access points on a single physical device.

Limitations

• Each physical device on a Atheros card is able to support upto 4 virtual access points and a single station.
• The number of devices supported on the single physical device also depend on the order in which the devices are created.
• If a single station is defined on a physical device then no more virtual devices may be created on the same physical device.
• If a virtual access point (master) is created on a physical device then upto a single station (with the nosbeacon – this flag will disable the use of the hardware beacon timers for the station mode operation of the device.) and upto a total of 3 more virtual access point may be defined on the same underlying physical device.

Test Topologies

Multiple Virtual Access Points, Single Physical Device

The sample topology to be setup is indicated in the diagram below. Here a single physical 802.11 NIC is being configured to act as multiple virtual access points. Nodes configured to act as stations connect to the corresponding virtual access point by explicitly choosing the appropriate ESSID. We used Iperf as our traffic generator to test the individual links. The two 802.11 networks are also seperated using explicit IP address allocation.

Sample Tutorial

Scenario

The user requests the creation of two 802.11 infrastructure-mode networks on a given set of nodes. Each network will have an access point and one station. The access point and the station are bound by the same essid's and belong to the same IP network. In the underlying architecture the user chooses the same physical interface on a node to act as a different access point on two seperate networks. The script shows that the user may be oblivious to the fact that he/she is requesting the same node to be acting as different AP's, thereby simulating the requests of two different users for two independent networks with the involvement of a common node (the virtual AP) without each others knowledge. The sample ruby script is as given below:

#
# Define nodes used in experiment
#

# Station on net01.
defNodes('sender1', [9,4]) {|node|
  node.prototype("test:proto:sender", {
    'destinationHost' => '192.168.10.4',
    'packetSize' => 1024,
    'rate' => 300,
    'protocol' => 'udp'    
  })
  node.net.w0.mode = "managed"
  node.net.w0.type = 'b'
  node.net.w0.essid = "net01"
  node.net.w0.ip = "192.168.10.5"
}


# AP on net01.
defNodes('receiver1', [10,4]) {|node|
  node.prototype("test:proto:receiver" , {
    'protocol' => 'udp'
  })
  node.net.w0.mode = "master"
  node.net.w0.type = 'b'
  node.net.w0.essid = "net01"
  node.net.w0.ip = "%192.168.%x.%y"
}

# Station on net02.
defNodes('sender2', [11,4]) {|node|
  node.prototype("test:proto:sender", {
    'destinationHost' => '192.168.11.4',
    'packetSize' => 1024,
    'rate' => 300,
    'protocol' => 'udp'    
  })
  node.net.w0.mode = "managed"
  node.net.w0.type = 'b'
  node.net.w0.essid = "net02"
  node.net.w0.ip = "192.168.11.5"
}

# Connect to the same physical but different virtual AP.
defNodes('receiver2', [10,4]) {|node|
  node.prototype("test:proto:receiver" , {
    'protocol' => 'udp'
  })
  node.net.w1.mode = "master"
  node.net.w1.type = 'b'
  node.net.w1.essid = "net02"
  node.net.w1.ip = "192.168.11.4"
}

#
# Now, start the application
#
whenAllInstalled() {|node|
  wait 30 

  allNodes.startApplications
  wait 40

  Experiment.done
}

Expected Response From The Virtualized Nodehandler Script

• Smart script that detects the usage of the same physical interface for multiple (>1) virtual interfaces.
• Checks the make of the driver on the node (Intel / Atheros).
• Virtualization of Intel based cards yet to be determined, hence for intel based devices, creates the first requested virtual interface and replies with a polite error for the second request saying "device already in use, please use another device".
• If card make is Atheros, do a constraint check on the number and type of virtual interfaces supported by the card.
• On each interface creation request, check the number of interfaces already created for that physical interface and see if it is possible to create more by verification with a global interface-usage table.
• If interface creation is possible, comply, else reply with the message that resource is currently busy.

How Will This Expected Response Be Orchestrated By The Current Software Code Base

• Nodehandler receives the name of the tutorial script that needs to be used from the command line.
• After all the parsing and function calls the node handler finally sends information to the client part of the code.
• The client will run a driver specific (Atheros based) initialization of the code. (Currently uses iwpriv and iwconfig to do this)
• These calls have to be replaced with wlanconfig calls supported by the Atheros drivers.
• The data structure used for consistency check which checks the number of interfaces defined on a node could be either local to the node or could be global to the entire grid. Personally, I prefer delineating node specific information and keeping it with the node. Status checks can be made with appropriate definition of API.
• The local data structure will have the following fields

     max_interface_number_allocated = 3 - removes the need to traverse the table below to determine next available number. 
     interface_allocation_table* = 
              
               interface | defined? | No of Virtual Interfaces defined       
               ---------------------------------------------------------               
                  w0     |    'y'   |        '3'                          
                  w1     |    'n'   |        '1'                         
     
     virtual_interface_details* =
         
              virtual_interface | Associated to phy dev. | mode     |  virtual ip      | ESSID
              ------------------------------------------------------------------------------------
                  'ath0'        |         'w0'           |   'AP'   |  '192.168.10.1'  | 'net00' 
                  'ath2'        |         'w0'           |   'AP'   |  '192.168.11.1'  | 'net01'
                  'ath3'        |         'w0'           |   'AP'   |  '192.168.12.1'  | 'net02'
                  'ath1'        |         'w1'           |   'Sta'  |  '192.168.11.2'  | 'net01' 
  
         * Text in quotes for both tables indicate values.
  

• Conventional value returned by the prop function in the AtherosDevice class needs to be changed.

Location Of Changes To Be Made To The Script

• In the process of event it was found out that the current code structure needed to be changed at two fundamental places to support the new 'wlanconfig' based interface configuration.
• Determine a place where the current drivers are loaded. → Use this location to delete the default "sta" interfaces created by the madwifi driver.
• Determine the place where the script tries to configure each individual interfaces based on the requests from the code. → Replace all conventional commands (iwconfig) with wlanconfig based interface configuration commands.

Steps Carried Out For Compiling, Debugging And Testing NodeAgent Code

• Use imageNodes with baseline-cougar.ndz which creates an image of the nodes with the latest version of the madwifi driver.
• Start each of the individual nodes using wget -O - -q '​http://cmc:5012/cmc/on?x=%x&y=%y'
• ssh into one of the current nodes which are turned on at root@nodex-y
• Check the running of the nodeAgent on the node by doing a ps -ef and locating process with /usr/sbin/nodeAgent
• Since you want to replace this code with a code that will be newly built, kill the instance of nodeagent based on PID. Also notice that there is another PID for another process using ruby, kill that process too.
• Go to the 'gateway' and compile nodeagent by doing a 'make nodeagent' —> Lookup definition in the makefile to determine exactly what is done —> Just compiles and builds the nodeagent script. If this script is compiled on the console, it will throw some errors while compiling as it is not able to access some of the libraries.
• Find the newly compiled nodeagent at the location /build/nodeagent in the compiled source code tree.
• Copy this file to the node: scp nodeHandler-3.6.4/build/nodeAgent root@node9-4:/usr/sbin/nodeagent (note the difference in cases here - nodeAgent in the original build and nodeagent in the deployment)
• Instantiate nodeagent by doing ssh in a client and executing /usr/sbin/nodeagent
• The new nodeagent code is now running on the client.
• Run the nodehandler on the console with our mini test script by: gautam@…:~$ nodehandler -k atheros-1-node, remember do not give the '.rb' extension, as this is some how appended by the script itself.
• All the status messages can be seen on the screen running the new nodeagent at command line and all the requests made are seen as a part of the INFO statements placed in the code for debugging (sample code running on node9-4):

   INFO NodeAgent: Located at 9:4
   INFO NodeAgent: RESET
   INFO WirelessDevice.unload: 
   INFO NodeAgent: Located at 9:4
   INFO AtherosDevice: configure net/w0/mode = master
   INFO AtherosDevice: activate: ath0 ath_pci false
   INFO AtherosDevice: activate: ath0 ath_pci destroy previous instance of ath0
   INFO AtherosDevice: activate: ath0 ath_pci destroy previous instance of ath1
   INFO AtherosDevice: Loaded ath_pci driver
   INFO AtherosDevice: getConfigCmd: master
   INFO AtherosDevice: configure net/w0/essid = neo
   INFO AtherosDevice: configure net/w0/channel = 36
   INFO AtherosDevice: configure net/w0/ip = 192.168.1.1
   INFO AtherosDevice: configure net/w0/mode = master
   INFO AtherosDevice: getConfigCmd: master
   INFO AtherosDevice: configure net/w1/essid = trinity
   INFO AtherosDevice: configure net/w1/ip = 192.168.2.1
   INFO AtherosDevice: New Cell ID: 00:60:B3:AC:2B:52
   INFO AtherosDevice: New Cell ID: 06:60:B3:AC:2B:52
   INFO NodeAgent: RESET
   INFO WirelessDevice.unload: 
   INFO WirelessDevice: Unloaded ath_pci driver
   INFO NodeAgent: Located at 9:4
  

• To check if the nodeagent worked properly ssh into the node, and do a iwconfig when the script is done configuring the interfaces. Detailed information with the essid's and mapped ip addresses will be seen on screen.
• The drivers are unloaded at the end of the experiment and this can be checked by doing a iwconfig at the end of the experiment.

Issues To Be Sorted

• The creation of a virtual IP address (vip) to ensure proper subnetting with the use of virtual interfaces :- Should the vip be completely independent of the current node based ip address mapping ?
• Current interface mapping (device mapping as reffered to in the code) happens based on the device name specified in the user - script (i.e net.wo or w1 is mapped to ath0 and ath1). Initially these interfaces (ath0 and ath1) were reffering to corresponding underlying physical device. For the process of testing, these interfaces (ath0 and ath1) are now virtual. Hence when a user makes a request to create a interface on w1, he/she will refer to the virtual interface ath1 which may be located on the physical device wifi0 (abstracted from the user).