General architecture for virtual connections.

[Antony J Mee <A J Mee ncl ac uk>]

Dan, Tim, (and the list)

I stumbled in to this and have discussed it briefly with
Tim (as this is pretty much the topic of his SoC project). 
I have hear mention of "device" support and "dialup"
support mentioned with respect to the NetworkManager
core (not the applets). I have some ideas, from recent
experience, about where some of this should go and how
it should be tackled.  Here it is laid bare for your constructive
criticism.

I'll start with my conclusions:
I would like to propose a renaming of "VPN Connections", at
least in the applet to be something more inclusive.
The real nitty gritty is the minor modification of the current
Dbus interface and associated  classes/structures which
need few more abilities.  They all apply to all virtual
connections (VPN and Dialup) and fall under
two headings:

 1)  Deciding whether a connection is "achievable"
 2)  Monitoring a running connection

1) Deciding whether a connection is "achievable"
-----------------------------------------------------------------------------------
There are as I see it two way to handle this an keep the
abstraction.  One is that NM asks the connection plugins
individually if they are currently "achievable". The second
is that the connections export some information (stored
against the connection in gconf) to assist NetworkManager
in making the decision.  That structure currently only
contains a name and some routing information.  Additions
would be:
 - a connection type/sub-type (eg VPN, dialup, bluetooth, ....) 
            perhaps mostly for use by the applet.
 - enabled/disabled bit
 - can coexist bit (ie. can be up with another interface)
 - require existing IP connection (and perhaps a host/network for which 
a route must exist)
     (or the inverse... "cannot be a primary connection")
 - can run multiply bit
       (this is already discussed in the NM Todo, but given the
        modular/plugin nature of the vpn code it may be easier
        to actually implement than for the wired/wireless)
  - some kind of priority (or an associated "cost", like the metric in
     routing tables)
A few booleans will handle most of this but a list of requirements
may be useful.  A requirement might be the paring of "some type" and
piece of data eg.
 USB,   "some hal device ID"   USB subsystem and some device
 IP,    "128.240.0.0/16"      (requires an existing IP connection
                                          with routes to 128.240.0.0/16 
existing in
                                          the routing table)
 HCI,  "11:22:33:44:55:66"   Some bluetooth device must be in range
 DEV, "/dev/silly_idea"     A particular device node is present
There are many ways these things could be represented.  NM can
always ignore the requirements and leave the decision to the user for
the moment, but in the end this NM should get no more involved with
the various hardware types that these simple boolean "is alive" ideas.

2) Monitoring a running connection
 -  Dbus Signal or method call for QoS / bandwidth information
     (note: "ondemand" works with the present pppd plugin)

Adding these few bits to the existing sub-system would trivially
provide access to many new connection types (including dial-up). 
It would also stablise existing DBUS and other APIs instead of
creating new ones.

tOnY

-----------------------------------------------------------------------------------
Then for those who care to read on and hear some of where that comes from:
---------------------------------------
I started out wanting to use PPTP.  I created a bodge of a plugin
and following Dan & Robert's advice eventually modified the code
to handle the connections without a bunch of external configuration
files.

Without trying, what I ended up with is a much more general tool that
can handle all kinds of PPP connections.  Perhaps that ALL is lacking
a little emphasis :-) 

At first this did not seem consistent with the use of the acronym
"VPN" that  is so liberally scattered around the code.  VPN
conjures up various pictures in peoples heads, but it's present
use is most commonly associated with tunneled TCP/IP over
TCP/IP situations and people usually like to talk about office
networks, encryption and other security topics. 

It seems to me that what exists at present in NetworkManager
(under the guise of VPN) is a quite general virtual network interface. 
(In fact it could handle physical connections too).  For those a
better definition of  "virtual" think tunneled (including TCP/IP
over Serial etc...) really I guess it means that the Data Link layer
(OSI model layer 2) is implemented in user space somehow.  What
sets such connections apart is the necessity for configuration
-- to establish the data link layer).  That then includes Dial up
(TCP/IP over modem), TCP/IP over serial, TCP/IP over Bluetooth
(actually just another serial connection), TCP/IP over a piece
of string between two yogurt pots and pretty much anything
else you can dream up.

NM typically deals with Layer 3 (network layer!) stuff where much
of the layer 1 and 2 is dealt with by the OS.  This is a point that
I have heard re-stressed by Dan and others time and again on this
list, usually in the form of "we don't want to write workarounds
for all the different buggy hardware".

I notice regularly in discussions on the list that people talk as if
NM was going to talk to devices.  I don't think it does at present
and certainly don't think it should.  It should only care about
"network interfaces".

What exists in NM at present goes most of the way to solving
dialup... bluetooth... VPN... issues.  It is also pretty well tested
though it's DBUS interface has not yet been set in stone.

tOnY