Skip Menu |

This queue is for tickets about the Net-DHCP CPAN distribution.

Report information
The Basics
Id: 54076
Status: resolved
Priority: 0/
Queue: Net-DHCP

People
Owner: Nobody in particular
Requestors: PHILIPP [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Need more constants added -- possibly at runtime
There are options missing from the current version of this module, as enumerated in: http://www.iana.org/assignments/bootp-dhcp-parameters/ I'm thinking that it would be handy to have the capability to do: our %my_dhcp_options = { DHO_LDAP_SERVERS => [ 95, 'string' ], }; use Net::DHCP::Constants extra_options => \%my_dhcp_options;
On Thu Jan 28 16:20:02 2010, RUZ wrote: Show quoted text
> There are options missing from the current version of this module, as > enumerated in: > > http://www.iana.org/assignments/bootp-dhcp-parameters/ > > I'm thinking that it would be handy to have the capability to do: > > our %my_dhcp_options = { > DHO_LDAP_SERVERS => [ 95, 'string' ], > }; > > use Net::DHCP::Constants extra_options => \%my_dhcp_options;
Any thoughts about this?
this is a good idea. i just wanted to put out a release with a bunch of the really easy fixes, then look at this sort of thing later.
you know that you can just wack in any value you like right? see addOptionRaw()
On Wed Nov 24 05:26:02 2010, djzort wrote: Show quoted text
> you know that you can just wack in any value you like right? > > see addOptionRaw()
I was thinking of the case where you might be deriving another package from Net::Dhcp, but wanted to still allow for the handling of typed arguments... and where the added arguments might be experimental, or vendor-specific, etc.
Subject: Re: [rt.cpan.org #54076] Need more constants added -- possibly at runtime
Date: Thu, 25 Nov 2010 00:27:10 -0800
To: "bug-Net-DHCP [...] rt.cpan.org" <bug-Net-DHCP [...] rt.cpan.org>
From: "Dean Hamstead" <dean [...] fragfest.com.au>
Yeha ok im with you. But the way Net::DHCP imports constants in to main:: name space is crappy. Im thinking that where now you call new ( CONSTANT() => 'value', ); it would be better just to go new( 'CONSTANT' => 'value' ); Then Net::DHCP examines each key, converting them to numbers internally. So with that in place, it would simply be a matter of overriding the sub that resolves the names to numbers - falling back to the original if its unable to find it. That would allow you to also tie in custom value types in addition to using 'int' etc On 11/24/2010, "Philip Prindeville via RT" <bug-Net-DHCP@rt.cpan.org> wrote: Show quoted text
> Queue: Net-DHCP > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=54076 > > >On Wed Nov 24 05:26:02 2010, djzort wrote:
>> you know that you can just wack in any value you like right? >> >> see addOptionRaw()
> >I was thinking of the case where you might be deriving another package >from Net::Dhcp, but wanted to still allow for the handling of typed >arguments... and where the added arguments might be experimental, or >vendor-specific, etc. > >
Ive just dropped 0.67_1 in to cpan. Obviously this is a developer release. It includes constants for everything in the IANA definition. The sub-options are all there as constants, but arent really usable as there is nothing in Packet to pack them - nor are all their data types described in Constants.pm yet either. There are obviously lots of options there, and some of the more exotic ones lack a clear description which makes it tricky for me to interpret them - almost impossible for me to test! Ill Put toegther the function to define your own values soon. I will also put together code to pack the Docsis sub options, as i just happen to work with a lot of cable gear at work ... :)
on further reflection. there is nothing stopping you from doing ... use Net::DHCP::Packet; use Net::DHCP::Constants qw( %DHO_FORMATS ); use constant DHO_MY_CODE => '999'; $DHO_FORMATS{DHO_MY_CODE} => 'string'; etc.