Re: [Dnsmasq-discuss] Support for DHCP option 125
On 9/18/07, ~ Kunal Sharma ~ koolku...@gmail.com wrote: Actually, this is a pretty stable system and changing something as important as dnsmasq is fraught with risks. Apart from that, the management hasn't allocated enough time for me to be able to upgrade to the latest version and test all the related functionalities. I do hope, however, that the version I'm using does not have critical bugs or restrictions. I was referring more to the fact that fully testing your changes to dnsmasq would require the same set of testing as an upgrade. I work at a NASA contractor, and while our software (running in Mission Control) doesn't go through the process that the flight software does, there's still a lot of testing involved and a lot of people involved with every release. As a result, when we have a compelling need for a new release and the testing and deployment costs associated, we include all the fixes we know about at the same time. Maybe you've convinced your management that adding one feature requires less testing than an upgrade -- I'm a little skeptical considering the upgrade has already been deployed tens of thousands of times. Thanks, Kunal On 9/18/07, richardvo...@gmail.com richardvo...@gmail.com wrote: On 9/17/07, ~ Kunal Sharma ~ koolku...@gmail.com wrote: Hi Simon, Yes, I'm using 2.23, so its pretty old but I can't change it now for certain reasons ! Thanks, Kunal May I inquire as to the rationale that allows modifications to dnsmasq but not upgrade to the latest version? On 9/14/07, Simon Kelley si...@thekelleys.org.uk wrote: ~ Kunal Sharma ~ wrote: Hi Simon, Many thanks for replying. Basically, I'm trying to add support for the DHCP requirements that are needed for DSL Forum's TR-111 standard, in my gateway device. The existing support for non-vendor-identifying encapsulated options is in two places. The data gets laid out in the packet in the second half of do_options() in src/rfc2131.c. I hope you're talking about do_opt() or do_req_options() because I don't find do_options() in the code. I'm talking about do_options(). It sounds like you have an older release. The current release is 2.40. Unless you have very good reasons why not, it's best to work from that. And yes, I'm aware of GNU GPL. I just meant to make sure the author does not place any proprietary licence. So. I'll definitely share the source once I'm done with this. GPL v2 for all current releases. It's possible that future releases will be GPL v3, see current posts in this groups. Cheers, Simon. Thanks again, Kunal ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Support for DHCP option 125
On 9/18/2007, xerces8 (xerc...@butn.net) wrote: Simple : Do not do any changes to a working system, except the really necessary ones. This is so in any serious system. Of course, I agree that you shouldn't just update willy nilly for no reason at all, but when there is a *reason* - like, for example, something is getting really *dated* - then by all means - stay up to date. Of course, this requires you to test things, and be prepared to downgrade if something breaks badly. So, I guess it is more a question of what you consider 'really necessary'. Personally, I don't ever let my servers get out of date - ever. But running Gentoo, it is much easier to keep a server completely up to date - and/or roll back if desired. -- Best regards, Charles
Re: [Dnsmasq-discuss] Support for DHCP option 125
On 9/17/07, ~ Kunal Sharma ~ koolku...@gmail.com wrote: Hi Simon, Yes, I'm using 2.23, so its pretty old but I can't change it now for certain reasons ! Thanks, Kunal May I inquire as to the rationale that allows modifications to dnsmasq but not upgrade to the latest version? On 9/14/07, Simon Kelley si...@thekelleys.org.uk wrote: ~ Kunal Sharma ~ wrote: Hi Simon, Many thanks for replying. Basically, I'm trying to add support for the DHCP requirements that are needed for DSL Forum's TR-111 standard, in my gateway device. The existing support for non-vendor-identifying encapsulated options is in two places. The data gets laid out in the packet in the second half of do_options() in src/rfc2131.c. I hope you're talking about do_opt() or do_req_options() because I don't find do_options() in the code. I'm talking about do_options(). It sounds like you have an older release. The current release is 2.40. Unless you have very good reasons why not, it's best to work from that. And yes, I'm aware of GNU GPL. I just meant to make sure the author does not place any proprietary licence. So. I'll definitely share the source once I'm done with this. GPL v2 for all current releases. It's possible that future releases will be GPL v3, see current posts in this groups. Cheers, Simon. Thanks again, Kunal ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Support for DHCP option 125
From: richardvo...@gmail.com richardvo...@gmail.com On 9/17/07, ~ Kunal Sharma ~ koolku...@gmail.com wrote: Hi Simon, Yes, I'm using 2.23, so its pretty old but I can't change it now for certain reasons ! Thanks, Kunal May I inquire as to the rationale that allows modifications to dnsmasq but not upgrade to the latest version? Simple : Do not do any changes to a working system, except the really necessary ones. This is so in any serious system. Regards, David
Re: [Dnsmasq-discuss] Support for DHCP option 125
On 18/09/2007, xerces8 xerc...@butn.net wrote: [snip] May I inquire as to the rationale that allows modifications to dnsmasq but not upgrade to the latest version? Simple : Do not do any changes to a working system, except the really necessary ones. This is so in any serious system. Regards, David Surely making modifications to the source code has much more potential for breaking things than upgrading to a newer version? Many thanks Kevin
Re: [Dnsmasq-discuss] Support for DHCP option 125
Actually, this is a pretty stable system and changing something as important as dnsmasq is fraught with risks. Apart from that, the management hasn't allocated enough time for me to be able to upgrade to the latest version and test all the related functionalities. I do hope, however, that the version I'm using does not have critical bugs or restrictions. Thanks, Kunal On 9/18/07, richardvo...@gmail.com richardvo...@gmail.com wrote: On 9/17/07, ~ Kunal Sharma ~ koolku...@gmail.com wrote: Hi Simon, Yes, I'm using 2.23, so its pretty old but I can't change it now for certain reasons ! Thanks, Kunal May I inquire as to the rationale that allows modifications to dnsmasq but not upgrade to the latest version? On 9/14/07, Simon Kelley si...@thekelleys.org.uk wrote: ~ Kunal Sharma ~ wrote: Hi Simon, Many thanks for replying. Basically, I'm trying to add support for the DHCP requirements that are needed for DSL Forum's TR-111 standard, in my gateway device. The existing support for non-vendor-identifying encapsulated options is in two places. The data gets laid out in the packet in the second half of do_options() in src/rfc2131.c. I hope you're talking about do_opt() or do_req_options() because I don't find do_options() in the code. I'm talking about do_options(). It sounds like you have an older release. The current release is 2.40. Unless you have very good reasons why not, it's best to work from that. And yes, I'm aware of GNU GPL. I just meant to make sure the author does not place any proprietary licence. So. I'll definitely share the source once I'm done with this. GPL v2 for all current releases. It's possible that future releases will be GPL v3, see current posts in this groups. Cheers, Simon. Thanks again, Kunal ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Support for DHCP option 125
Hi Simon, Yes, I'm using 2.23, so its pretty old but I can't change it now for certain reasons ! Thanks, Kunal On 9/14/07, Simon Kelley si...@thekelleys.org.uk wrote: ~ Kunal Sharma ~ wrote: Hi Simon, Many thanks for replying. Basically, I'm trying to add support for the DHCP requirements that are needed for DSL Forum's TR-111 standard, in my gateway device. The existing support for non-vendor-identifying encapsulated options is in two places. The data gets laid out in the packet in the second half of do_options() in src/rfc2131.c. I hope you're talking about do_opt() or do_req_options() because I don't find do_options() in the code. I'm talking about do_options(). It sounds like you have an older release. The current release is 2.40. Unless you have very good reasons why not, it's best to work from that. And yes, I'm aware of GNU GPL. I just meant to make sure the author does not place any proprietary licence. So. I'll definitely share the source once I'm done with this. GPL v2 for all current releases. It's possible that future releases will be GPL v3, see current posts in this groups. Cheers, Simon. Thanks again, Kunal
[Dnsmasq-discuss] Support for DHCP option 125
Hi Friends, I'm new to this list and I'm new to DNSMASQ. Hence, this query ! I need to be able to add/enable support for DHCP option number 125 in my current implementation. At this point, since I've not had a look in, I'm not even aware that this is already there or not. Would anyone here be generous to help me with the following - 1) How to find out if this option is supported and/or enabled ? 2) If this is supported but disabled, how do I enable it (some compilation flag etc) ? 3) If I need to add support, how to go about it e.g. general directions needed, not the spoon-feeding stuff. Also, am I freely allowed to make my own changes to DNSMASQ ? Thank You, Kunal
Re: [Dnsmasq-discuss] Support for DHCP option 125
Hi Simon, Many thanks for replying. Basically, I'm trying to add support for the DHCP requirements that are needed for DSL Forum's TR-111 standard, in my gateway device. The existing support for non-vendor-identifying encapsulated options is in two places. The data gets laid out in the packet in the second half of do_options() in src/rfc2131.c. I hope you're talking about do_opt() or do_req_options() because I don't find do_options() in the code. And yes, I'm aware of GNU GPL. I just meant to make sure the author does not place any proprietary licence. So. I'll definitely share the source once I'm done with this. Thanks again, Kunal On 9/14/07, Simon Kelley si...@thekelleys.org.uk wrote: ~ Kunal Sharma ~ wrote: Hi Friends, I'm new to this list and I'm new to DNSMASQ. Hence, this query ! I need to be able to add/enable support for DHCP option number 125 in my current implementation. At this point, since I've not had a look in, I'm not even aware that this is already there or not. Would anyone here be generous to help me with the following - 1) How to find out if this option is supported and/or enabled ? Asking here is good. The answer is that it's not supported, except in the sense that you can code absolutely any option as a sequence of hex octets. Since RFC3925 options are fairly complex, that's probably not a good solution unless you have one, very simple option to encapsulate. 2) If this is supported but disabled, how do I enable it (some compilation flag etc) ? N/A 3) If I need to add support, how to go about it e.g. general directions needed, not the spoon-feeding stuff. The existing support for non-vendor-identifying encapsulated options is in two places. The data gets laid out in the packet in the second half of do_options() in src/rfc2131.c. That's quite hairy code, but it should be extendable to option 125 without too many problems. dhcp-option lines in the config file and command line are parsed into a linked-list of struct dhcp_opt in parse_dhcp_opt() in src/option.c. That's hairy too (sorry!). option-60 encapsulated options look like: dhcp-option=vendor:some vendor string,option data That could be extended to cope with something like dhcp-option=vendor-id:enterprise-number,option data Also, am I freely allowed to make my own changes to DNSMASQ ? dnsmasq is licensed under the GNU GPL, in the unlikely event that you're not familiar with that, Googling will find you several decades worth of reading very quickly. The deal is basically this: you can make changes to dnsmasq for your own use: if you sell/give the changed binary to anyone outside your organisation, you have to make the changed source code available as well (and under the same terms). If you add this functionality, I'd appreciate getting a copy of the patch. Cheers, Simon.
