On Thu, Dec 04, 2008 at 04:01:57PM -0000, Stephan Trebels wrote:
> I dont think I understand what you are trying to do.
>
> We could determine the MAC from HAL, right. The issue is, that we cannot
> do anything from there, I really wonder how this ever worked for me even
> with the eth0-XXX naming convention, how did it know which interface to
> operate on? Consider the following example interfaces file from
> /usr/share/doc/ifupdown/examples/network-interfaces.gz
>
> auto eth0 eth1
>
> mapping eth0 eth1
> script /path/to/get-mac-address.sh
> map 11:22:33:44:55:66 lan
> map AA:BB:CC:DD:EE:FF internet
>
> iface lan inet static
> address 192.168.42.1
> netmask 255.255.255.0
> pre-up /usr/local/sbin/enable-masq $IFACE
>
> iface internet inet dhcp
> pre-up /usr/local/sbin/firewall $IFACE
>
> both auto and mapping apply to multiple values which the parser does not support as of today,
> at least I think so.
>
> Additionally we don't know the mac address of each interface before HAL registers
> the device. For the iface stanzas we have no clue, which physical
> interface they will be applied to.
How about this:
1. create configurations for all iface stanzas as we do now
2. for each virtual configuration that is configured, we create one
connection for each interface they might be theoretically be mapped
to (e.g. for mapping eth0 eth1, we would duplicate the lan
configuration); e.g. in your example the lan and internet
connection would be duplicated, so we have one of each that can
later be locked to eth0 and one that can later be locked to eth1.
2. virtual configurations that have a mapping are not exported through
getconnections by default, unless they have been locked to a device.
3. everytime we see a hal device change event we go and run all
mapping scripts; based on the result we lock the config to the
device and apply the autoconnect flag as its configured for the
named mapping device(s); also we lock the configuration to the
mapped device.
4. when a mapping changes, we ensure that connections that are not
mapped anymore, become unlocked, autoconnect becomes unflagged and
they are not exported through the getconnections function
Is that simple enough? I am sure I forgot a bunch of
use-cases. anythint you can think of right now?
On Thu, Dec 04, 2008 at 04:01:57PM -0000, Stephan Trebels wrote: doc/ifupdown/ examples/ network- interfaces. gz get-mac- address. sh sbin/enable- masq $IFACE sbin/firewall $IFACE
> I dont think I understand what you are trying to do.
>
> We could determine the MAC from HAL, right. The issue is, that we cannot
> do anything from there, I really wonder how this ever worked for me even
> with the eth0-XXX naming convention, how did it know which interface to
> operate on? Consider the following example interfaces file from
> /usr/share/
>
> auto eth0 eth1
>
> mapping eth0 eth1
> script /path/to/
> map 11:22:33:44:55:66 lan
> map AA:BB:CC:DD:EE:FF internet
>
> iface lan inet static
> address 192.168.42.1
> netmask 255.255.255.0
> pre-up /usr/local/
>
> iface internet inet dhcp
> pre-up /usr/local/
>
> both auto and mapping apply to multiple values which the parser does not support as of today,
> at least I think so.
>
> Additionally we don't know the mac address of each interface before HAL registers
> the device. For the iface stanzas we have no clue, which physical
> interface they will be applied to.
How about this:
1. create configurations for all iface stanzas as we do now
2. for each virtual configuration that is configured, we create one
connection for each interface they might be theoretically be mapped
to (e.g. for mapping eth0 eth1, we would duplicate the lan
configuration); e.g. in your example the lan and internet
connection would be duplicated, so we have one of each that can
later be locked to eth0 and one that can later be locked to eth1.
2. virtual configurations that have a mapping are not exported through
getconnections by default, unless they have been locked to a device.
3. everytime we see a hal device change event we go and run all
mapping scripts; based on the result we lock the config to the
device and apply the autoconnect flag as its configured for the
named mapping device(s); also we lock the configuration to the
mapped device.
4. when a mapping changes, we ensure that connections that are not
mapped anymore, become unlocked, autoconnect becomes unflagged and
they are not exported through the getconnections function
Is that simple enough? I am sure I forgot a bunch of
use-cases. anythint you can think of right now?
- Alexander