GNOME.org
 

Re: Late to the party - multiple search domains on the network.

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.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]