command for creating virtual interface

[Jouni Malinen]

On Mon, Oct 27, 2014 at 08:11:08PM +0530, Jithu Jance wrote:
> >That patch seems to be adding only WPA_IF_STATION type interfaces which
> would be fine for another station, but maybe not ideal for AP.
> 
> Yes. But by setting an AP profile (mode=2), we should be able change
> the role to AP (I tried locally and it works). Having an AP
> concurrently with STA restricts the operation to same channel
> concurrency though.

There seem to be some drivers that do not support iftype changes. I'm
not sure whether I really care too much about this, but it is possible
that this would not work with such drivers. As an example, hostapd has
relatively recent changes that allow the iftype to be left as-is through
init and deinit if it was in AP mode originally to avoid issues with
such drivers.

> This would enable us to have an additional wireless IP connection
> (another STA-AP) to another device while the primary STA interface is
> being used for internet connectivity. Since it is the standard virtual
> STA functionality being added, I thought it is good to add support in
> the supplicant.
> 
> Basically the sequence I thought of is like as below.
> 
> interface_create //creates a virtual network interface
> interface_add //initializes the interface with appropriate conf file
> interface_remove // de-initializes the interface
> interface_del // deletes the network interface.
> 
> The virtual interface creation part can be integrated to already
> existing "interface_add" command by adding an additional argument.  I
> just kept the commands separate for testing and getting the initial
> feedback.

Merging interface_create to interface_add would indeed sound clearer
(and interface_del to interface_remove for a case where interface_add
added the new interface).

> >Since driver_nl80211.c is tracking interfaces added and removed through
> if_add() and if_remove() some of these operations triggered by external
> control could result in unexpected results. As such, this does not look
> like the safest way of addressing a need to add/remove a virtual
> interface for independent of internal wpa_supplicant needs.
> 
> It might be useful to get the internal status of the peer STA
> interface for later optimizations (to force single channel concurrency
> in case of role change to AP). since interface_add is getting called,
> the newly added STA initialization and connection is controlled via
> supplicant. so internal tracking is useful for this case as well,
> right?
> 
> Can some additional checks help to address the safety concern? Like
> for e.g, adding code to remove the externally added interfaces in case
> of a terminate signal.

Merging interface_create to interface_add could likely address the
concern by recording the added interface to the new driver_nl80211 data
structures related to the new interface rather than the one through
which it was added. interface_del case would be even clearer since there
would be no command for removing an arbitrary netdev, but it would
always be through interface_remove that would remove state from both
driver_nl80211 and core wpa_supplicant for the dynamically added
interface.

-- 
Jouni Malinen                                            PGP id EFC895FA