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.

Steps Carried Out For Compiling, Debugging And Testing NodeAgent Code

• 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.

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).