Difference between revisions of "Dhcpd-plugin"
m (Minor editing for grammar) |
|||
(3 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
− | + | [[Category: Programmer's Guide]] | |
+ | [[Category: LinuxMCE Plugins]] | ||
+ | |||
+ | == 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. | ||
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 15: | ||
== 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 | ||
− | * create a script, as described above, that will be called that will configure the device to be used with | + | * create a script, as described above, that will be called that will configure the device to be used with LinuxMCE |
== 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 | + | :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) |
Latest revision as of 16:37, 25 August 2014
How it works
It's a very simple script, it continuously greps /var/log/syslog looking for DHCPREQUEST/DHCPACK lines.
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.
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:
/usr/pluto/bin/configure_snom3xx.pl -d 47- i 192.168.80.253 -m 00:04:13:24:25:e9
That script is responsible to correctly configure Snom320, so it could be used almost immediately.
New p&p devices
For each device that needs to be plug&play device, we need to:
- create a device template
- 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 LinuxMCE
Possible problems
- 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.
- 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.
- 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)