Dhcpd-plugin - Revision history

Marie.o at 15:37, 25 August 2014

2014-08-25T15:37:19Z

←Older revision		Revision as of 15:37, 25 August 2014
Line 1:		Line 1:
			[[Category: Programmer's Guide]]
			[[Category: LinuxMCE Plugins]]

	== How it works ==		== How it works ==
	It's a very simple script, it continuously greps ''/var/log/syslog'' looking for DHCPREQUEST/DHCPACK lines.		It's a very simple script, it continuously greps ''/var/log/syslog'' looking for DHCPREQUEST/DHCPACK lines.
Line 23:		Line 26:
	* Same model may have different firmwares, meaning that sometimes the configuration script may fail.		* Same model may have different firmwares, meaning that sometimes the configuration script may fail.
	:This can't be solved right now. Usually firmware is not distributable, so you can't force to use a specific version with LinuxMCE. The firmware upgrade needs user interaction and is very delicate operation that may result in trashed equipment (for example power outage in the middle of upgrade)		:This can't be solved right now. Usually firmware is not distributable, so you can't force to use a specific version with LinuxMCE. The firmware upgrade needs user interaction and is very delicate operation that may result in trashed equipment (for example power outage in the middle of upgrade)

	~~[[Category: Programmer's Guide]]~~

Rwilson131 at 01:01, 6 September 2007

2007-09-06T01:01:31Z

←Older revision		Revision as of 01:01, 6 September 2007
Line 3:		Line 3:

	When finding one it tries to find out if it's a new device (not one already added and not one to be ignored).		When finding one it tries to find out if it's a new device (not one already added and not one to be ignored).
	Then it sends DCE Event #53(New Mac Address Detected) with params #5(MAC) and #28(IP) to DCERouter.		Then it sends DCE Event #53(New Mac Address Detected) with params #5(MAC) and #28(IP) to [[DCERouter]].

	As far as I know then it's processed somewhere in General_Info_Plugin (asking for device type, room and other such stuff), after that it creates a device with status set to ''RUN_CONFIG''.		As far as I know then it's processed somewhere in [[General_Info_Plugin]] (asking for device type, room and other such stuff), after that it creates a device with status set to ''RUN_CONFIG''.

	After that somebody else will run the configuration script specified in DeviceTemplate. Something like:		After that somebody else will run the configuration script specified in DeviceTemplate. Something like:
Line 12:		Line 12:

	== New p&p devices ==		== New p&p devices ==
	For each device that needs to be plug&play device, we need to:		For each device that needs to be [[plug&play]] device, we need to:
	* create a device template		* create a device template
	* add a MAC range in the device template to include such devices		* add a MAC range in the device template to include such devices
Line 19:		Line 19:
	== Possible problems ==		== Possible problems ==
	* Two or more models (with very different configurations) of same manufacturer share same IP range		* Two or more models (with very different configurations) of same manufacturer share same IP range
	:Now it's solved by asking the user what kind of device he added via plug&play.		:Now it's solved by asking the user what kind of device he added via [[plug&play]].
	:In future an auto detection script will be needed like the one deciding which Cisco phone we have, ie. 7960 or 7970, by getting the information from the phone itself, but it still will not be a perfect solution because it relies on certain firmware versions and/or default passwords.		:In future an auto detection script will be needed like the one deciding which [[Cisco]] phone we have, ie. 7960 or 7970, by getting the information from the phone itself, but it still will not be a perfect solution because it relies on certain firmware versions and/or default passwords.
	* Same model may have different firmwares, meaning that sometimes the configuration script may fail.		* Same model may have different firmwares, meaning that sometimes the configuration script may fail.
	:This can't be solved right now. Usually firmware is not distributable, so you can't force to use a specific version with LinuxMCE. The firmware upgrade needs user interaction and is very delicate operation that may result in trashed equipment (for example power outage in the middle of upgrade)		:This can't be solved right now. Usually firmware is not distributable, so you can't force to use a specific version with LinuxMCE. The firmware upgrade needs user interaction and is very delicate operation that may result in trashed equipment (for example power outage in the middle of upgrade)

			[[Category: Programmer's Guide]]

Jerry finn at 08:14, 19 March 2007

2007-03-19T08:14:10Z

←Older revision		Revision as of 08:14, 19 March 2007
Line 1:		Line 1:
	<table width="100%"> <tr><td bgcolor="#FFCFCF">This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007. In general any information should apply to LinuxMCE. However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.</td></tr> </table>== How it works ==		== How it works ==
	It's a very simple script, it continuously greps ''/var/log/syslog'' looking for DHCPREQUEST/DHCPACK lines.		It's a very simple script, it continuously greps ''/var/log/syslog'' looking for DHCPREQUEST/DHCPACK lines.

Juliet at 10:42, 15 March 2007

2007-03-15T10:42:39Z

←Older revision		Revision as of 10:42, 15 March 2007
Line 15:		Line 15:
	* create a device template		* create a device template
	* add a MAC range in the device template to include such devices		* add a MAC range in the device template to include such devices
	* create a script, as described above, that will be called that will configure the device to be used with ~~pluto~~		* create a script, as described above, that will be called that will configure the device to be used with LinuxMCE

	== Possible problems ==		== Possible problems ==
Line 22:		Line 22:
	:In future an auto detection script will be needed like the one deciding which Cisco phone we have, ie. 7960 or 7970, by getting the information from the phone itself, but it still will not be a perfect solution because it relies on certain firmware versions and/or default passwords.		:In future an auto detection script will be needed like the one deciding which Cisco phone we have, ie. 7960 or 7970, by getting the information from the phone itself, but it still will not be a perfect solution because it relies on certain firmware versions and/or default passwords.
	* Same model may have different firmwares, meaning that sometimes the configuration script may fail.		* Same model may have different firmwares, meaning that sometimes the configuration script may fail.
	:This can't be solved right now. Usually firmware is not distributable, so you can't force to use a specific version with ~~pluto~~. The firmware upgrade needs user interaction and is very delicate operation that may result in trashed equipment (for example power outage in the middle of upgrade)		:This can't be solved right now. Usually firmware is not distributable, so you can't force to use a specific version with LinuxMCE. The firmware upgrade needs user interaction and is very delicate operation that may result in trashed equipment (for example power outage in the middle of upgrade)

Wikiadmin: Minor editing for grammar

2006-12-10T14:47:31Z

Minor editing for grammar

Wikiadmin: spelling corrections

2006-12-10T14:35:44Z

spelling corrections

Wikiadmin at 08:47, 19 May 2006

2006-05-19T08:47:01Z

←Older revision		Revision as of 08:47, 19 May 2006
Line 8:		Line 8:

	After that somebody else will run the configuration script specified in DeviceTemplate. Something like:		After that somebody else will run the configuration script specified in DeviceTemplate. Something like:
	/usr/pluto/bin/configure_snom3xx.pl -d 47-i 192.168.80.253 -m 00:04:13:24:25:e9		/usr/pluto/bin/configure_snom3xx.pl -d 47- i 192.168.80.253 -m 00:04:13:24:25:e9
	That script is responsable to correctly configure Snom320, so it could be used almost imediatly.		That script is responsable to correctly configure Snom320, so it could be used almost imediatly.

Wikiadmin: /* Possible problems */

2006-05-18T14:14:41Z

Possible problems

←Older revision		Revision as of 14:14, 18 May 2006
Line 20:		Line 20:
	* Two or more models (whith very different configurations) of same manufacturer share same IP range		* Two or more models (whith very different configurations) of same manufacturer share same IP range
	:Now it's solved by asking the user what kind of device he plugged.		:Now it's solved by asking the user what kind of device he plugged.
			:In future an autodetection script will be needed (like the one deciding what king of cisco do we have 7960 or 7970 by getting the information from the phone itlef), but it's still won't be a perfect solution because it relies on certain firmware versions and/or default passwords.
	* Same model may have different firmwares, meaning that sometimes the configuration script may fail.		* Same model may have different firmwares, meaning that sometimes the configuration script may fail.
	:This can't be solved right now. Usually firmware is not distributable, so you can't force to use a specific version with pluto. The firmware upgrade needs user interaction and is very delicate operation that may result in trashed equipment (for example power outage in the middle of upgrade)		:This can't be solved right now. Usually firmware is not distributable, so you can't force to use a specific version with pluto. The firmware upgrade needs user interaction and is very delicate operation that may result in trashed equipment (for example power outage in the middle of upgrade)

Wikiadmin at 13:28, 18 May 2006

2006-05-18T13:28:12Z

@@ Line 1: / Line 1: @@
-<table width="100%"> <tr><td bgcolor="#FFCFCF">This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007.  In general any information should apply to LinuxMCE.  However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.</td></tr> </table>It's a very simple script, it continuosly greps ''/var/log/syslog'' looking for DHCPREQUEST/DHCPACK lines.
+<table width="100%"> <tr><td bgcolor="#FFCFCF">This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007.  In general any information should apply to LinuxMCE.  However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.</td></tr> </table>== How it works ==
 When finding one of those it tries to find out if it's a new device (not already added and not one of the ignored).
@@ Line 9: / Line 10: @@
   /usr/pluto/bin/configure_snom3xx.pl -d  47-i 192.168.80.253 -m 00:04:13:24:25:e9
 That script is responsable to correctly configure Snom320, so it could be used almost imediatly.

Wikiadmin at 13:16, 18 May 2006

2006-05-18T13:16:31Z

New page

<table width="100%"> <tr><td bgcolor="#FFCFCF">This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007. In general any information should apply to LinuxMCE. However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.</td></tr> </table>It's a very simple script, it continuosly greps ''/var/log/syslog'' looking for DHCPREQUEST/DHCPACK lines.

When finding one of those it tries to find out if it's a new device (not already added and not one of the ignored).
Then it sends DCE Event #53(New Mac Address Detected) with params #5(MAC) and #28(IP) to DCERouter.

As far as I know then it's processed somewhere in General_Info_Plugin (asking for device type, room and other such stuff), after that it creates device with status set to ''**RUN_CONFIG**''.

After that somebody else will run the configuration script specified in DeviceTemplate. Something like:
/usr/pluto/bin/configure_snom3xx.pl -d 47-i 192.168.80.253 -m 00:04:13:24:25:e9
That script is responsable to correctly configure Snom320, so it could be used almost imediatly.

←Older revision		Revision as of 14:47, 10 December 2006
Line 2:		Line 2:
	It's a very simple script, it continuously greps ''/var/log/syslog'' looking for DHCPREQUEST/DHCPACK lines.		It's a very simple script, it continuously greps ''/var/log/syslog'' looking for DHCPREQUEST/DHCPACK lines.

	When finding one ~~of those~~ it tries to find out if it's a new device (not already added and not one ~~of the~~ ignored).		When finding one it tries to find out if it's a new device (not one already added and not one to be ignored).
	Then it sends DCE Event #53(New Mac Address Detected) with params #5(MAC) and #28(IP) to DCERouter.		Then it sends DCE Event #53(New Mac Address Detected) with params #5(MAC) and #28(IP) to DCERouter.

	As far as I know then it's processed somewhere in General_Info_Plugin (asking for device type, room and other such stuff), after that it creates device with status set to ''RUN_CONFIG''.		As far as I know then it's processed somewhere in General_Info_Plugin (asking for device type, room and other such stuff), after that it creates a device with status set to ''RUN_CONFIG''.

	After that somebody else will run the configuration script specified in DeviceTemplate. Something like:		After that somebody else will run the configuration script specified in DeviceTemplate. Something like:
Line 12:		Line 12:

	== New p&p devices ==		== New p&p devices ==
	For each device that needs to be plug&play device we need to:		For each device that needs to be plug&play device, we need to:
	* create a device template		* create a device template
	* add a ~~mac~~ range in device template to include such devices		* add a MAC range in the device template to include such devices
	* create a script that will be called ~~as described above~~ that will configure the device to be used with pluto		* create a script, as described above, that will be called that will configure the device to be used with pluto

	== Possible problems ==		== Possible problems ==
	* Two or more models (with very different configurations) of same manufacturer share same IP range		* Two or more models (with very different configurations) of same manufacturer share same IP range
	:Now it's solved by asking the user what kind of device he ~~plugged~~.		:Now it's solved by asking the user what kind of device he added via plug&play.
	:In future an auto detection script will be needed (like the one deciding ~~what kind of cisco do~~ we have 7960 or 7970 by getting the information from the phone itself), but it's still ~~won't~~ be a perfect solution because it relies on certain firmware versions and/or default passwords.		:In future an auto detection script will be needed like the one deciding which Cisco phone we have, ie. 7960 or 7970, by getting the information from the phone itself, but it still will not be a perfect solution because it relies on certain firmware versions and/or default passwords.
	* Same model may have different firmwares, meaning that sometimes the configuration script may fail.		* Same model may have different firmwares, meaning that sometimes the configuration script may fail.
	:This can't be solved right now. Usually firmware is not distributable, so you can't force to use a specific version with pluto. The firmware upgrade needs user interaction and is very delicate operation that may result in trashed equipment (for example power outage in the middle of upgrade)		:This can't be solved right now. Usually firmware is not distributable, so you can't force to use a specific version with pluto. The firmware upgrade needs user interaction and is very delicate operation that may result in trashed equipment (for example power outage in the middle of upgrade)

←Older revision		Revision as of 14:35, 10 December 2006
Line 1:		Line 1:
	<table width="100%"> <tr><td bgcolor="#FFCFCF">This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007. In general any information should apply to LinuxMCE. However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.</td></tr> </table>== How it works ==		<table width="100%"> <tr><td bgcolor="#FFCFCF">This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007. In general any information should apply to LinuxMCE. However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.</td></tr> </table>== How it works ==
	It's a very simple script, it ~~continuosly~~ greps ''/var/log/syslog'' looking for DHCPREQUEST/DHCPACK lines.		It's a very simple script, it continuously greps ''/var/log/syslog'' looking for DHCPREQUEST/DHCPACK lines.

	When finding one of those it tries to find out if it's a new device (not already added and not one of the ignored).		When finding one of those it tries to find out if it's a new device (not already added and not one of the ignored).
Line 9:		Line 9:
	After that somebody else will run the configuration script specified in DeviceTemplate. Something like:		After that somebody else will run the configuration script specified in DeviceTemplate. Something like:
	/usr/pluto/bin/configure_snom3xx.pl -d 47- i 192.168.80.253 -m 00:04:13:24:25:e9		/usr/pluto/bin/configure_snom3xx.pl -d 47- i 192.168.80.253 -m 00:04:13:24:25:e9
	That script is ~~responsable~~ to correctly configure Snom320, so it could be used almost ~~imediatly~~.		That script is responsible to correctly configure Snom320, so it could be used almost immediately.

	== New p&p devices ==		== New p&p devices ==
Line 18:		Line 18:

	== Possible problems ==		== Possible problems ==
	* Two or more models (~~whith~~ very different configurations) of same manufacturer share same IP range		* Two or more models (with very different configurations) of same manufacturer share same IP range
	:Now it's solved by asking the user what kind of device he plugged.		:Now it's solved by asking the user what kind of device he plugged.
	:In future an ~~autodetection~~ script will be needed (like the one deciding what ~~king~~ of cisco do we have 7960 or 7970 by getting the information from the phone ~~itlef~~), but it's still won't be a perfect solution because it relies on certain firmware versions and/or default passwords.		:In future an auto detection script will be needed (like the one deciding what kind of cisco do we have 7960 or 7970 by getting the information from the phone itself), but it's still won't be a perfect solution because it relies on certain firmware versions and/or default passwords.
	* Same model may have different firmwares, meaning that sometimes the configuration script may fail.		* Same model may have different firmwares, meaning that sometimes the configuration script may fail.
	:This can't be solved right now. Usually firmware is not distributable, so you can't force to use a specific version with pluto. The firmware upgrade needs user interaction and is very delicate operation that may result in trashed equipment (for example power outage in the middle of upgrade)		:This can't be solved right now. Usually firmware is not distributable, so you can't force to use a specific version with pluto. The firmware upgrade needs user interaction and is very delicate operation that may result in trashed equipment (for example power outage in the middle of upgrade)