Bug #31992 for dhcp-public: linux interface discovery fix using getifaddrs [patch]

Tue, 27 Nov 2012 12:32:12 -0500 Marius Tomaschewski <mt@suse.de> - Ticket created

Subject:	linux interface discovery fix using getifaddrs
Date:	Tue, 27 Nov 2012 18:31:57 +0100
To:	dhcp-bugs@isc.org
From:	Marius Tomaschewski <mt@suse.de>

Unlike dhcp 3.x, dhcp 4.x scans interfaces from /proc/net/dev, which provides only true interface names. When the address set on the interface has a label assigned (linux 2.0 alias interface compatibility), then the SIOCGIFADDR requires the label / alias name as argument instead of the interface name to return this address. When this is the only address assigned to an interface, dhcp-server is unable to find any address and fails to start. Changed to use getifaddrs() function, which retrieves all IP addresses on linux systems and is available since GLIBC 2.3. Gruesse / Regards, Marius Tomaschewski <mt@suse.de>, <mt@suse.com> -- SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg), GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, Maxfeldstraße 5, 90409 Nürnberg, Germany

0001-Fixed-linux-interface-discovery-using-getifaddrs.patch

Message body is not shown because sender requested not to inline it.

Wed, 28 Nov 2012 14:39:26 -0500 Michael McNally <mcnally@isc.org> - Correspondence added 2 minutes

On Tue Nov 27 17:32:12 2012, mt@suse.de wrote:
> Unlike dhcp 3.x, dhcp 4.x scans interfaces from /proc/net/dev,
> which provides only true interface names. When the address set
> on the interface has a label assigned (linux 2.0 alias interface
> compatibility), then the SIOCGIFADDR requires the label / alias
> name as argument instead of the interface name to return this
> address. When this is the only address assigned to an interface,
> dhcp-server is unable to find any address and fails to start.
>
> Changed to use getifaddrs() function, which retrieves all IP
> addresses on linux systems and is available since GLIBC 2.3.
>
> Gruesse / Regards,
> Marius Tomaschewski <mt@suse.de>, <mt@suse.com>

Marius --

Thank you for your suggested fix. I believe we have at least one other
similar proposed fix in the pipeline but I will make sure that the developers
see your suggestion.

Michael McNally
ISC Support

Wed, 28 Nov 2012 14:39:26 -0500 The RT System itself - Status changed from 'new' to 'open'

Wed, 28 Nov 2012 14:39:38 -0500 Michael McNally <mcnally@isc.org> - Severity S2 Normal added

Tue, 04 Mar 2014 00:21:58 -0500 Shawn Routhier <sar@isc.org> - Subject changed from 'linux interface discovery fix using getifaddrs' to 'linux interface discovery fix using getifaddrs [patch]'

Tue, 02 Sep 2014 13:29:46 -0400 Vicky Risk <vicky@isc.org> - Priority P1 High added

Tue, 02 Sep 2014 13:29:46 -0400 Vicky Risk <vicky@isc.org> - Versions Planned 4.3.2 added

Thu, 02 Oct 2014 00:50:46 -0400 Shawn Routhier <sar@isc.org> - FinalPriority changed from 'Medium' to 'High'

Thu, 02 Oct 2014 00:50:46 -0400 Shawn Routhier <sar@isc.org> - Priority changed from 'Medium' to 'High'

Mon, 23 Mar 2015 21:50:54 -0400 Shawn Routhier <sar@isc.org> - FinalPriority changed from 'High' to 'Low'

Mon, 23 Mar 2015 21:50:55 -0400 Shawn Routhier <sar@isc.org> - Priority changed from 'High' to 'Low'

Mon, 23 Mar 2015 21:50:55 -0400 Shawn Routhier <sar@isc.org> - Versions Planned 4.3.2 changed to 4.3.3

Mon, 06 Apr 2015 22:40:43 -0400 Shawn Routhier <sar@isc.org> - Reference by #28761: added

Thu, 30 Jul 2015 00:54:39 -0400 Shawn Routhier <sar@isc.org> - Versions Planned 4.3.3 changed to 4.3.4

Wed, 19 Aug 2015 01:46:59 -0400 Shawn Routhier <sar@isc.org> - TimeEstimated changed from (no value) to '1440'

Wed, 19 Aug 2015 01:46:59 -0400 Shawn Routhier <sar@isc.org> - TimeLeft changed from (no value) to '1440'

Thu, 21 Apr 2016 12:59:56 -0400 Shawn Routhier <sar@isc.org> - Versions Planned 4.3.4 changed to 4.3.5

Wed, 30 Nov 2016 10:00:02 -0500 Thomas Markwalder <tmark@isc.org> - Versions Planned 4.3.5 changed to 4.3.6

Wed, 14 Dec 2016 08:30:46 -0500 Francis Dupont <Francis_Dupont@isc.org> - Correspondence added

I've just pushed on the review queue a similar propose patch to use getifaddrs() for Linux.

Wed, 14 Dec 2016 08:34:48 -0500 Francis Dupont <Francis_Dupont@isc.org> - Dependency on #28761: added

Tue, 14 Feb 2017 14:29:18 -0500 Thomas Markwalder <tmark@isc.org> - Queue changed from #8 to #9

Tue, 21 Feb 2017 10:26:48 -0500 Thomas Markwalder <tmark@isc.org> - Version Fixed 4.4.0 4.3.6 4.1-ESV-R15 added

Tue, 21 Feb 2017 10:26:49 -0500 Thomas Markwalder <tmark@isc.org> - Dependency by #24720: added

Tue, 21 Feb 2017 10:26:49 -0500 Thomas Markwalder <tmark@isc.org> - Dependency by #43312: added

Tue, 21 Feb 2017 10:26:50 -0500 Thomas Markwalder <tmark@isc.org> - Dependency by #43313: added

Tue, 21 Feb 2017 10:32:33 -0500 Thomas Markwalder <tmark@isc.org> - Correspondence added

Hello Marius: You'll be pleased to hear that we have corrected this issue in our upcoming releases 4.3.6 and 4.1-ESV-R15 both due out in May/2017 as well as 4.4.0 (date TBD). You were among others who reported the issue and contribute solutions. We'll cite your contribution as we have in the past in our release notes. Thanks for the patch and your continued interest and contributions. Sincerely, Thomas Markwalder ISC Software Engineering

Tue, 21 Feb 2017 18:36:02 -0500 Marius Tomaschewski <mt@suse.de> - Correspondence added

Subject:	Re: [ISC-Bugs #31992] linux interface discovery fix using getifaddrs [patch]
Date:	Wed, 22 Feb 2017 00:35:52 +0100
To:	dhcp-review@isc.org, "Nirmoy Das" <ndas@suse.de>
From:	"Marius Tomaschewski" <mt@suse.de>

Hello Thomas! Thanks, this is very appreciated! Nirmoy (in Cc) took over the maintenance of our ISC dhcp package, but I continue to act as his fallback & reviewer. I've attached a ticked mail and a patch I'd like to incorporate upstream. Would be nice to hear, what you'd need to apply it. Short summary about infiniband: On a raw socket, the link-layer infiniband packet provides only some "useless" things, basically just the protocol number (there was an RFC about, but I don't remember it now). There is no source hardware address visible like on ethernet, so client-identifier is all what you have and infiniband dhcp RFC wants the new 0xff + iaid + duid at this place instead of hwtype + mac, zeroed and zero-len chaddr as the infiniband hwaddr is too long for chaddr and the client enables broadcast response flag in the dhcp header, because there is no source hwaddr visible on incoming packets the server could use for responses. Am 21.02.2017 um 16:32 schrieb Thomas Markwalder via RT: > Hello Marius: > > You'll be pleased to hear that we have corrected this issue in our upcoming releases 4.3.6 and 4.1-ESV-R15 both due out in May/2017 as well > as 4.4.0 (date TBD). You were among others who reported the issue and contribute solutions. > > We'll cite your contribution as we have in the past in our release notes. Thanks for the patch and your continued interest and contributions. > > Sincerely, > > Thomas Markwalder > ISC Software Engineering Gruesse / Regards, Marius Tomaschewski <mt@suse.de>, <mt@suse.com> -- SUSE LINUX GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg), Maxfeldstraße 5, 90409 Nürnberg, Germany

0016-infiniband-support.patch

Message body is not shown because sender requested not to inline it.

Subject:	[ISC-Bugs #44738] AutoReply: Infiniband support patch
Date:	Tue, 21 Feb 2017 23:16:24 +0000
To:	mt@suse.de
From:	"DHCP Bugs via RT" <dhcp-bugs@isc.org>

Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "Infiniband support patch", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [ISC-Bugs #44738]. Please include the string: [ISC-Bugs #44738] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, dhcp-bugs@isc.org ------------------------------------------------------------------------- Hi! I think/hope I've sent it to you already, but attached, an infiniband support patch. It's origins are at Mellanox (don't know the person). I've changed/improved it a lot to fit into dhcp-4.3.3 and address some places that weren't working well in the original. We will schedule to adopt and retest it for the upcoming 4.3.6 release ASAP and would be happy when it gets incorporated into 4.3.7 then :-) Gruesse / Regards, Marius Tomaschewski <mt@suse.de>, <mt@suse.com> -- SUSE LINUX GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg), Maxfeldstraße 5, 90409 Nürnberg, Germany

Fri, 24 Feb 2017 10:02:28 -0500 Thomas Markwalder <tmark@isc.org> - Reference by #28761: deleted

Wed, 26 Apr 2017 09:21:48 -0400 Thomas Markwalder <tmark@isc.org> - Status changed from 'open' to 'resolved'

Wed, 21 Jun 2017 15:39:59 -0400 Brian Conry <bconry@isc.org> - Queue changed from #9 to #8

Fri, 28 Jul 2017 16:11:30 -0400 Vicky Risk <vicky@isc.org> - Queue changed from #8 to dhcp-public

Created:	Tue, 27 Nov 2012 12:32:12 -0500
Updated:	Fri, 28 Jul 2017 16:11:30 -0400
Closed:	Wed, 26 Apr 2017 09:21:48 -0400

Bug #31992 for dhcp-public: linux interface discovery fix using getifaddrs [patch]

This bug tracker is no longer active.