[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Testing netapplet



On Mon, 06 Sep 2004 21:10:12 +0200, Matthew Garrett wrote:
> One
> instance of netapplet is used to switch between which network interface
> is currently active, and perform some small amount of runtime 
> configuration such as switching wireless networks.


I am not sure what you mean.  A host can have multiple interfaces, all
active at the same time. Each physical interface can be independently
controlled, so I don't know what you mean by "switch between which network
interface is currently active".

Changing the configuration of a wireless card with ifupdown is a matter of
ifdowning the interface and ifupping it as another logical interface with
different wireless options.  My description of what netapplet should do
(in my previous message) fits this case.


> In order to do that, it needs to know:
> 
> a) the list of interfaces that currently exists (easy enough to manage -
> we can get that from the kernel)
>
> b) the list of interfaces that can be brought into existence by doing an
> ifup interfacename
>
> b is difficult. In my case, I have a tun0 device configured in
> /etc/network/interfaces. Doing ifup tun0 uses pre-up statements to
> establish the tunnel, which then allows ifupdown to apply the correct
> configuration. This doesn't fit into your view above.


Even in the case of tun0 there is a difference between the physical
interface (which gets created by a pre-up command) and the logical
interface as which ifup configures tun0.  The only aspect of this case
that is peculiar is the fact that tun0 doesn't exist until ifup is run. 
However, my previous description of how netapplet should work applies to
this case just as well as to the others.

You do raise an issue that I didn't consider in my last message, namely,
how does one compile a list of all the interfaces that could be created if
ifup were run with the right arguments?

It seems that what you are saying is that you want to be able to compile
such a list by parsing /e/n/i and that you want to assume that the list of
logical interface names in /e/n/i _is_ that list. This places a couple of
restrictions on how the administrator can write his
/etc/network/interfaces:

  * the logical interface name in each case must be the name
    of the physical interface that gets created if ifup is
    called with that logical interface specified

  * only one logical interface can be defined for any one
    "emergent" physical interface

These restrictions rule out the possibility of using multiple profiles for
a given physical interface.  If, e.g., tun0 can only be created by the
pre-up of a logical interface definition named 'tun0' (in order to meet
the conditions set out above) then you can only set up ifupdown to
configure tun0 one way. You won't be able to do

    ifup tun0=home-tunnel

at one time and

    ifup tun0=work-tunnel

at another.

Instead of placing these restrictions on the administrator I suggest
using a special option in the logical interface definition which specifies
the name of the physical interface that gets created by that logical
interface's pre-up.  netapplet can use this field in order to compile
a list of emergent physical interfaces and the logical interfaces
with which they are associated.

-- 
Thomas Hood



Reply to: