Koozali.org: home of the SME Server
Obsolete Releases => SME Server 7.x => Topic started by: judgej on January 18, 2008, 12:36:53 AM
-
Is there a reason why a local IP address (linked to a MAC address) cannot be allocated within the DHCP range? I mean, the system does not allow it, but is there a *technical* reason why not, rather than just a foible of whoever put the admin script together?
It can be handy, after a machine has been allocated a DHCP address, and other machines get to know where it is, to 'lock' that machine onto that address. I'll raise a FR if there is no technical reason.
I'll also raise the fact that MAC addresses must be entered with ':' separating each part. It would be nice to be able to copy and paste an address such as '000E08CD774E' or '00-0E-08-CD-77-4E' from a device admin screen, or DOS box, and not have to go to the trouble of changing it to '00:0E:08:CD:77:4E'.
-- JJ
-
Make them different NFR's
Being able to copy and paste different formats would be handy
Find the verification routine, and post it and it'll help
start at 'slocate hostentries.pm'
-
judgej
It can be handy, after a machine has been allocated a DHCP address, and other machines get to know where it is, to 'lock' that machine onto that address. I'll raise a FR if there is no technical reason.
You can already force DHCP to allocate a specific IP to a device by entering the IP & the MAC address into the Hostnames and addresses panel. See the manual.
-
judgej
You can already force DHCP to allocate a specific IP to a device by entering the IP & the MAC address into the Hostnames and addresses panel. See the manual.
Yes, I know the manual says that, but I am talking about a limitation in what it does. If the admin screen says "you can't do that", then what the manual says is not so relevant.
-- JJ
-
Bug raised on the "inside DHCP range" error message:
http://bugs.contribs.org/show_bug.cgi?id=3775 (http://bugs.contribs.org/show_bug.cgi?id=3775)
Edited: I have my answer - there is no technical reason why it can't be done; just a policy decision by the developers, and that policy won't be changing.
The second FR:
http://bugs.contribs.org/show_bug.cgi?id=3776 (http://bugs.contribs.org/show_bug.cgi?id=3776)