Jason Vas Dias wrote:
. The DHCP client needs the interface to be up during the configuration process so that it can send and receive packets. NM can't start with a downed interface and ask the DHCP client to get it an address.
Actually, the ISC DHCP client does not have this requirement - it will manage DHCP sessions for interfaces that are unconfigured and down - but it appears NM does:
Maybe because ISC dhclient uses Linux Packet Filter for raw net access then it can work with a down interface: using AF_PACKET needs the interface up (but not configured with an IP address, even 0.0.0.0).
NM keeps _all_ interfaces up all the time, since unless the device is up you cannot (a) detect link-change events via netlink sockets for wired cards, and (b) perform wireless scans for wireless cards. NM enforces security on devices that are not the "active" device my ensuring that those "inactive" devices have no IP address and do not show up in the routing table. So obviously, when NM requested the DHCP client to perform a DHCP transaction, the interface would be up.
However, I don't think its unreasonable to ensure the device is "up"
before you perform the DHCP transaction,
This is not required by DHCP - dhclient only uses the ethernet address to send DHCPDISCOVER packets, the IP address can be all zeros.
Up, but with no IP address set is fine for all, I think.
Here is an outline on what I am currently implementing - comments / ideas / suggestions appreciated:
1. The 'com.redhat.dhcp' D-BUS service on the system bus, will implement
the '/com/redhat/dhcp' object, and be provided by the dhcdbd executable from the rpm of that name.
This will manage all ISC dhclient sessions, and provide D-BUS objects representing all the DHCP options for each interface.
It will provide "interface" objects representing all the interfaces, and objects for each dhcp option under these interfaces.
The dhcp service will provide these D-BUS objects, interface interfaces and methods:
Interface Up / Down Methods:
Object: /com/redhat/dhcp/{$IP_INTERFACE_NAME}
Methods: /{up,down}( IN integer flags ) Interface: com.redhat.dhcp.action
So to initiate a dhcp session on eth0, you'd invoke the "up" method on the "/com/redhat/dhcp/eth0" object with the "com.redhat.dhcp.action" interface.
If the interface object did not exist yet, it would be created
if a matching interface name was found. If it did exist (implying a session had already been initiated), the "down"
method would be implied, meaning that any existing dhclient session would be shutdown before a new one was initiated.
The "down" method would shutdown the dhclient session and
remove all options explicitly.
The up and down methods would accept one integer argument
have these flags, currently implemented by corresponding
option variables in network-scripts:
1: PERSISTENT - dhclient should not give up trying to contact a DHCP server that does not respond, but should retry after a sleep interval
2: RELEASE - a down() should release the lease
dhcpdbd would then send signals from the /com/redhat/dhcp/{$IP_INTERFACE_NAME} object with the
"com.redhat.dhcp.state" interface for each dhclient state change. Each '/com/redhat/dhcp/{$IP_INTERFACE_NAME}/state' signal would contain tstate code (integer) and name (string) parameters :
{ "PREINIT", 1 }, /* initial state: configuration session started - no options valid */
{ "BOUND", 2 }, /* lease obtained - options valid */
{ "RENEW", 3 }, /* lease renewed - options valid */
{ "REBOOT", 4 }, /* have valid lease, but now obtained a different one - options valid */
{ "REBIND", 5 }, /* new, different lease - options valid */
{ "STOP" , 6 }, /* remove old lease - only "old/" options valid */
{ "MEDIUM", 7 }, /* media selection begun - (unused)- no options valid */
{ "TIMEOUT", 8 }, /* timed out contacting DHCP server - no options valid */
{ "FAIL", 9 }, /* all attempts to contact server timed out, sleeping - no options valid */
{ "EXPIRE", 10 }, /* lease has expired, renewing - only 'old/' options valid */
{ "RELEASE", 11 }, /* releasing lease - only 'old/' options valid */
{ "REVERT", 12 } /* After TIMEOUT, settings reverted to last valid lease - options valid*/
The dhcdbd service would try to guarantee that a PREINIT or FAIL signal
will be generated within 1 second of a up/down request being received.
Options methods:
Common "Option Definition" structure:
{ uint8t universe; // option space ID
uint8t code; // code unique within option space
string name; // option name
string type; // DHCP or D-BUS type string
};
Users can define new option spaces, or redefine / declare new options in existing option spaces in dhcp configuration files, so different options may be implemented at different sites.
How does this fit with Vendor-class options (DHCP option 43 and 60), where the "option space ID" is a string?
Objects: /com/redhat/dhcp // Interface list on Get interface /com/redhat/dhcp/options // Global Options Definitions /com/redhat/dhcp/${IP INTERFACE NAME}/{$OPTION NAME} // current option set for interface /com/redhat/dhcp/${IP INTERFACE NAME}/old/{$OPTION NAME} // previous set of options for interface
/com/redhat/dhcp/options // Global Options Definitions methods:
Methods: Option get ( void ); // returns array of all // known options
Option get( string option_name ); // returns named option // (universe names can prefix option // names separated by '.'.
Option get( uint8_t universe; uint8_t option_code ) ; // returns option with option_code in universe Option Interfaces:
com.redhat.dhcp.binary:
gets / sets data from / to binary structures
com.redhat.dhcp.text:
gets / sets data from / to text strings
com.redhat.dhcp.dbus.text:
com.redhat.dhcp.dbus.binary:
translates DHCP option type strings into D-BUS type strings So, for example, the calls:
( Object: /com/redhat/dhcp/options
Method: get
interface: com.redhat.dhcp.dbus.binary
arguments: none
) would return all option definitions known to the system
with type strings in dbus format.
( Object: /com/redhat/dhcp
Method: Get
interface:com.redhat.dhcp.text
arguments: none
) would return a list of all interface names currently configured with DHCP.
( Object: /com/redhat/dhcp/${IP_INTERFACE_NAME}
Method: Get
interface:com.redhat.dhcp.text
arguments: none
)
would return an array of all options for interface
with all values converted to text - ie. an array
of structures:
{ string universe; string code; string name; string type; string value;}
( Object: /com/redhat/dhcp/${IP_INTERFACE_NAME}
Method: Get
interface:com.redhat.dhcp.binary
arguments: none
)
would return an array of all options for interface
with all values in binary format
{ uint8_t universe; uint8_t code; string name; string type; uint8_t value[n]; }
where "uint8_t value[n]" is the unique binary structure corresponding to the type string.
I forsee a problem with the "all options" calls: I think that setting the "requested options" in a DHCP request to "everything" could easily result in a reply which overflows a DHCP packet (they are only 500 bytes or so) It might be better just to have the "get single option" methods, and generate DHCPINFORM queries to get the values of options from the DHCP server as and when needed.
( Object: /com/redhat/dhcp/${IP_INTERFACE_NAME}/${OPTION}
Method: Get
interface:com.redhat.dhcp.binary
arguments: none
)
would return the binary value corresponding to option named ${OPTION} for the interface ${IP_INTERFACE_NAME}.
( Object: /com/redhat/dhcp/${IP_INTERFACE_NAME}/${OPTION}
Method: Get
interface:com.redhat.dhcp.text
arguments: none
)
would return the text string corresponding to option named ${OPTION} for the interface ${IP_INTERFACE_NAME}.
The options would be set by the program executed for each state change
by the ISC dhclient (currently /sbin/dhclient-script, using dbus-send),
using an authentication mechanism that guaranteed that only that program,
a direct child of the dhclient process that is a direct child of dhcdbd,
would be allowed to make the setting. No options would become valid (the state change signal sent) until ALL options settings were sent and
processed. The initial version of dhcdbd will be complete in a few days and ready to submit by the end of this week.
Please could I see that as soon as you feel happy to release it? I'm currently struggling with the DBUS API (or rather the docs, incomplete, out of date, yadda yadda) so ready done code that implements a defined DBUS interface would really help me.
2. BIND D-BUS extensions : A subpackage of BIND, 'named_dbd', will contain a version of the named daemon of that name, compiled with extensions to support configuration of "forwarding zones" providing the 'com.redhat.bind' service on the D-BUS system bus.
named_dbd would start up using its normal $ROOTDIR/etc/named.conf configuration file, by default consisting of a caching-only nameserver but also optionally containing authoritative zones - this file would not be changed automatically by any software (except system-config-bind).
Forwarding zones could be created ONLY via a D-BUS interface by authorised
processes acting on these objects:
/com/redhat/bind/${ORIGIN}
/com/redhat/bind/${ORIGIN}/forwarders
/com/redhat/bind/${ORIGIN}/search
where $ORIGIN is a forward (eg. 'redhat.com.') or reverse ( eg. '80.16.172.in-addr.arpa.', 'd.a.e.d.1.0.0.2.ip6.arpa.') DNS zone origin name .
There would be "get" and "set" methods for each of the above objects; only
certain authorized processes would be allowed to use the set methods.
The D-BUS interface would be provided by a separate thread in named, so
query performance should not suffer, except when processing a set, when
mutual exclusive access to the configuration for forwarding zones will have to be implemented.
Each forwarding zone will consist of a domain name (forward or reverse) and a list of "forwarder" name server IPv4 or IPv6 addresses to which queries
for that zone will be addressed. For forward "forwarding" zones (ONLY!), a search list could also be specified
that would be applied to all queries of that zone in the same way the resolver
library applies to all queries.
Thus resolv.conf should be completely empty - the resolver library would append '.' to every name. Named would append each member of the search search list to the name,
and return the first positive result for the name suffixed with the lowest ordered
member of the search list.
This named extension I hope to complete by the end of next week.
Again, given that code I should be able to produce a revision of dnsmasq to do the same job in fairly short order.
Cheers,
Simon. _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
