content-type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-RT-Original-Encoding: utf-8
Content-Length: 1702

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