InfiniBand DHCP flow with PRA and DHCP relay not working

Bug #1529815 reported by Talat Batheesh
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
isc-dhcp (Ubuntu)
Fix Released
Medium
Rafael David Tinoco
Trusty
Fix Released
Medium
Rafael David Tinoco
Wily
Won't Fix
Medium
Rafael David Tinoco
Xenial
Fix Released
Medium
Rafael David Tinoco

Bug Description

[Impact]

 * Infiniband users relying on DHCP can't use DHCP relay.

[Test Case]

 * Comment #13
 * Mellanox has tested themselves.
 * Clear way of knowing if fix worked (tcpdump).

[Regression Potential]

 * Only related to Infiniband.
 * Infiniband support could stop working (unlikely, already tested).

[Other Info]

DHCP client is sending discover with Unicast type request for the offer, in this configuration of IB to ETH through a relay we need the type to be broadcast.

The issue is that when using dhclient from the client on Ubuntu (and only on Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in unicast instead of broadcast. It seems there is no way to correct this from the client side using dhclient configuration file.
this issue exist even when we use always-broadcast statement in configuration file.

in other vendors we see that discover request type is broadcast.
attached pcap files from working (other vendor) and not working (Ubuntu) clients.

DHCP CLIENT (IPoIB)
Ubuntu 14.04 kernel 3.13.0-74
Mellanox OFED 3.1-1.0.3 or inbox driver
isc-dhcp-client 4.2.4-7ubuntu12.3

Revision history for this message
Talat Batheesh (talat-b87) wrote :
Revision history for this message
Talat Batheesh (talat-b87) wrote :

This is pacp for other vendor

Revision history for this message
David Duffey (dduffey) wrote :

When reading the RFC it appears the broadcast bit specifies to the server how the client wants the server to respond. I have a few requests:

1. Can you create pcaps in Ubuntu / RHEL with various settings (like always broadcast on and off) so we can compare the behaviour and packet changes

2. Is DHCP (program/code) on other treating IB differently (i.e. find the code/patch and does it do a 'if IB broadcast, else unicast reuest"

3. Can you point to other bug fixes you might have found for this?

I found via google someone doing the following:

interface "ethX" {
   supersede dhcp-server-identifier 255.255.255.255;
}

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in isc-dhcp (Ubuntu):
status: New → Confirmed
Revision history for this message
David Duffey (dduffey) wrote :

Just a couple of other data points.

It looks like dhclient added the broadcast request flag functionality in v5 (development release).

14.04 ships with 4.2
16.04 ships with 4.3 (the latest stable release)

Do we know if the user is using dhclient, or networkmanager or if either client is acceptable? This feature was added at different times for different dhcp clients. Can we get a package name for the dhcp client being used?

David

Revision history for this message
David Duffey (dduffey) wrote :

Actually, In #5 said this feature was added in isc v5, but that is not correct. Current upstream doesn't have broadcast flag settings.

https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=summary

Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :

Okay, I just provisioned 2 servers (ConnectX-3 & ConnectX-4) so I could reproduce this issue and work on it. I'll try to start reproducing the issue now.

Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :

As David stated,

Per RFC 1541:

https://tools.ietf.org/html/rfc1541

"DHCP uses the 'flags' field [21]. The leftmost bit is defined as the BROADCAST (B) flag"

Taking us to RFC 1542:

https://tools.ietf.org/html/rfc1542

3.1 Client use of the 'flags' field

3.1.1 The BROADCAST flag

   Normally, BOOTP servers and relay agents attempt to deliver BOOTREPLY
   messages directly to a client using unicast delivery. The IP
   destination address (in the IP header) is set to the BOOTP 'yiaddr'
   address and the link-layer destination address is set to the BOOTP
   'chaddr' address. Unfortunately, some client implementations are
   unable to receive such unicast IP datagrams until they know their own
   IP address (thus we have a "chicken and egg" issue). Often, however,
   they can receive broadcast IP datagrams (those with a valid IP
   broadcast address as the IP destination and the link-layer broadcast
   address as the link-layer destination).

   If a client falls into this category, it SHOULD set (to 1) the
   newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY
   messages it generates. This will provide a hint to BOOTP servers and
   relay agents that they should attempt to broadcast their BOOTREPLY
   messages to the client.

   If a client does not have this limitation (i.e., it is perfectly able
   to receive unicast BOOTREPLY messages), it SHOULD NOT set the
   BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0).

      DISCUSSION:

         This addition to the protocol is a workaround for old host
         implementations. Such implementations SHOULD be modified so
         that they may receive unicast BOOTREPLY messages, thus making
         use of this workaround unnecessary. In general, the use of
         this mechanism is discouraged.

I'll check DHCP IB implementation from my previous SRU from:

https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141

For this BROADCAST flag distinction on IB DHCP requests.

Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :

Continuation of RFC 1541 is RFC 2131:

https://tools.ietf.org/html/rfc2131 (adding DHCP INFORM msg type)

RFC 4390 from 2006:

https://tools.ietf.org/html/rfc4390
(Dynamic Host Configuration Protocol (DHCP) over InfiniBand) stipulates:

2.2. Use of the BROADCAST flag

   A DHCP client on IPoIB MUST set the BROADCAST flag in DHCPDISCOVER
   and DHCPREQUEST messages (and set "ciaddr" to zero) to ensure that
   the server (or the relay agent) broadcasts its reply to the client.

   Note: As described in [RFC2131], "ciaddr" MUST be filled in with the
         client's IP address during BOUND, RENEWING or REBINDING states;
         therefore, the BROADCAST flag MUST NOT be set. In these cases,
         the DHCP server unicasts DHCPACK message to the address in
         "ciaddr". The link address will be resolved by ARP.

Meaning that, during discovery, specifically for InfiniBand, the BROADCAST
flag must be turned on (MUST is used in RFC).

Changed in isc-dhcp (Ubuntu):
status: Confirmed → In Progress
Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :

RFC 4390 from 2006:

https://tools.ietf.org/html/rfc4390
(Dynamic Host Configuration Protocol (DHCP) over InfiniBand) also stipulates:

As described above, the link-layer address is unavailable to the DHCP
   server because the link-layer address is larger than the "chaddr"
   field length. As a result, the server cannot unicast its reply to
   the client. Therefore, a DHCP client MUST request that the server
   send a broadcast reply by setting the BROADCAST flag when IPoIB
   Address Resolution Protocol (ARP) is not possible, i.e., in
   situations where the client does not know its IP address.

   [RFC1542] discourages the use of a broadcast reply. But in the case
   of IPoIB, this is a necessity because the server does not receive the
   link-layer address.

Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :

## RHEL broadcast flag set during DHCP DISCOVER:
(this will tell DHCP server that DHCP response should come as a broadcast BOOT REPLY)

12:29:42.653772 IP (tos 0x0, ttl 128, id 16963, offset 0, flags [none], proto UDP (17), length 341)
    0.0.0.0.68 > 255.255.255.255.67: [no cksum] BOOTP/DHCP, Request, length 313, htype 32, hlen 0, xid 0x1f49749f, secs 1024, Flags [Broadcast] (0x8000)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Hostname Option 12, length 9: "l-supp-22"
            Vendor-Class Option 60, length 8: "MSFT 5.0"
            Parameter-Request Option 55, length 13:
              Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
              Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
              Static-Route, Classless-Static-Route, Classless-Static-Route-Microsoft, Option 252
              Vendor-Option
            Client-ID Option 61, length 20: hardware-type 255, 00:00:00:00:00:02:00:00:02:c9:00:00:02:c9:03:00:fc:78:32
            END Option 255, length 0
            TTL Option 23, length 0
            PAD Option 0, length 0, occurs 6
            T254 Option 254, length 128: [|rfc1048 128]

## UBUNTU broadcast flag not set during DHCP DISCOVER

06:42:18.949401 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request, length 300, htype 32, hlen 0, xid 0x52bc6268, secs 17, Flags [none] (0
x0000)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Lease-Time Option 51, length 4: 86400
            Parameter-Request Option 55, length 7:
              Subnet-Mask, BR, Time-Zone, Default-Gateway
              Domain-Name, Domain-Name-Server, Hostname
            Client-ID Option 61, length 20: hardware-type 255, 00:00:00:00:00:02:00:00:02:c9:00:f4:52:14:03:00:33:d1:91
            END Option 255, length 0
            PAD Option 0, length 0, occurs 19

Changed in isc-dhcp (Ubuntu):
assignee: nobody → Rafael David Tinoco (inaddy)
Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :

I think during the fix of:

https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141

I accidentally missed the following:

> + /* Set the broadcast flag */
> + ip->client->config->bootp_broadcast_always = 1;
> +

in find_subnet.

This comes from: dhcp-4.2.5-lpf-ib.patch in tag "dhcp-4.2.5-30.fc20" from
pkgs.fedoraproject.org/git/rpms/dhcp.git (since all IB patches are coming
from fedora project).

I'll review this and provide a PPA, asking for feedback.

Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :
Download full text (3.4 KiB)

Talat,

I was able to set the Broadcast flag in a DHCP negotiation when using IB interface.

Trusty patch is possibly ready.

TCPDUMP from the OFFER and ACK:

$ sudo tcpdump -i ib0 -nn -vvv -S
tcpdump: listening on ib0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes

04:38:01.051682 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request, length 300, htype 32, hlen 0, xid 0xb48b8735, Flags [Broadcast] (0x8000)
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message Option 53, length 1: Discover
     Hostname Option 12, length 5: "dixie"
     Parameter-Request Option 55, length 13:
       Subnet-Mask, BR, Time-Zone, Default-Gateway
       Domain-Name, Domain-Name-Server, Option 119, Hostname
       Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
       NTP
     Client-ID Option 61, length 17: hardware-type 56, 30:3a:30:30:3a:30:30:3a:34:38:3a:46:45:3a:38:30
     END Option 255, length 0
     PAD Option 0, length 0, occurs 15

04:38:01.051936 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    172.16.0.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, htype 32, hlen 0, xid 0xb48b8735, Flags [Broadcast] (0x8000)
   Your-IP 172.16.0.19
   Server-IP 172.16.0.1
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message Option 53, length 1: Offer
     Server-ID Option 54, length 4: 172.16.0.1
     Lease-Time Option 51, length 4: 600
     Subnet-Mask Option 1, length 4: 255.255.255.0
     BR Option 28, length 4: 172.16.0.255
     Domain-Name Option 15, length 7: "myib.cu"
     END Option 255, length 0
     PAD Option 0, length 0, occurs 23

04:38:01.052215 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request, length 300, htype 32, hlen 0, xid 0xb48b8735, Flags [Broadcast] (0x8000)
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message Option 53, length 1: Request
     Server-ID Option 54, length 4: 172.16.0.1
     Requested-IP Option 50, length 4: 172.16.0.19
     Hostname Option 12, length 5: "dixie"
     Parameter-Request Option 55, length 13:
       Subnet-Mask, BR, Time-Zone, Default-Gateway
       Domain-Name, Domain-Name-Server, Option 119, Hostname
       Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
       NTP
     Client-ID Option 61, length 17: hardware-type 56, 30:3a:30:30:3a:30:30:3a:34:38:3a:46:45:3a:38:30
     END Option 255, length 0
     PAD Option 0, length 0, occurs 3

04:38:01.052342 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    172.16.0.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, htype 32, hlen 0, xid 0xb48b8735, Flags [Broadcast] (0x8000)
   Your-IP 172.16.0.19
   Server-IP 172.16.0.1
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message Option 53, length 1: ACK
     Server-ID Option 54, length 4: 172.16.0.1
     Lease-Time Option 51, length 4: 600
     Subnet-Mask Option 1, length 4: 255.25...

Read more...

Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :

Last test I did was to see if IB DHCP would get the BROADCAST flag on IB interfaces. It did. Now, I removed:

ip->client->config->bootp_broadcast_always = 1;

from setup_ib_interface (when preparing for DHCP REQUEST), so I could check if the option:

bootp-broadcast-always

from the config file (added by this patch also) to check if it makes a difference.

====

## without bootp-broadcast-always

tcpdump: listening on ib0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
13:34:47.376362 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request, length 300, htype 32, hlen 0, xid 0x5f7f9774, Flags [none] (0x0000)
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message Option 53, length 1: Discover
     Hostname Option 12, length 5: "dixie"
     Parameter-Request Option 55, length 13:
       Subnet-Mask, BR, Time-Zone, Default-Gateway
       Domain-Name, Domain-Name-Server, Option 119, Hostname
       Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
       NTP
     Client-ID Option 61, length 17: hardware-type 56, 30:3a:30:30:3a:30:30:3a:34:38:3a:46:45:3a:38:30
     END Option 255, length 0
     PAD Option 0, length 0, occurs 15

## with bootp-broadcast-always

13:51:10.735292 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request, length 300, htype 32, hlen 0, xid 0x5bbf492d, Flags [Broadcast] (0x8000)
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message Option 53, length 1: Discover
     Hostname Option 12, length 5: "dixie"
     Parameter-Request Option 55, length 13:
       Subnet-Mask, BR, Time-Zone, Default-Gateway
       Domain-Name, Domain-Name-Server, Option 119, Hostname
       Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
       NTP
     Client-ID Option 61, length 17: hardware-type 56, 30:3a:30:30:3a:30:30:3a:34:38:3a:46:45:3a:38:30
     END Option 255, length 0
     PAD Option 0, length 0, occurs 15

====

So the following statement in dhclient.conf

interface "ib0" {
    send dhcp-client-identifier = "80:00:00:48:FE:80";
    bootp-broadcast-always;
}

Is working good also.

Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :

The PPA for tests is:

https://launchpad.net/~inaddy/+archive/ubuntu/lp1529815

$ sudo add-apt-repository ppa:inaddy/lp1529815
$ sudo apt-get update && sudo apt-get dist-upgrade

Using a versioning schema that will be superseded by the final SRU.

PS: I'm also attaching the Trusty debdiff if this PPA proves to work.

Thank you

Rafael

Changed in isc-dhcp (Ubuntu Trusty):
status: New → In Progress
Changed in isc-dhcp (Ubuntu Wily):
status: New → In Progress
Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :
Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "trusty_isc-dhcp_4.2.4-7ubuntu12.5.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch
Mathew Hodson (mhodson)
Changed in isc-dhcp (Ubuntu Trusty):
importance: Undecided → Medium
Changed in isc-dhcp (Ubuntu Wily):
importance: Undecided → Medium
Changed in isc-dhcp (Ubuntu Xenial):
importance: Undecided → Medium
Revision history for this message
Talat Batheesh (talat-b87) wrote :

The DHCP Relay issue still has not been resolved.
The issue was DHCP Offer packets that being sent from the DHCP server are not reaching the client.

Setup:
DHCP Client: IB Side Ubuntu OS with ConnectX3 FW ver 2.35.5000, Mellanox OFED 3.2-1.0.1
DHCP Server: ETH Side Win2012 R2 with ConnectX3 FW ver 2.35.5000, WinOF 5.10
SX GW, MLNX_OS ver 3.4.3002

Looking at the traffic capture I can see packets are coming from the Windows server towards the switch, but never leaving it.
Please refer to the following traffic capture files attached to the case:
Ibdump_dhcp – capture of ib0
Dhcp.pcap – port mirroring of the ETH port connected to the Windows
Dhcp_win2012 - wireshark capture of the windows dhcp server

Setup details is mentioned & marked above.

Setup:
IB Side: DHCP Client Ubunutu 14.04, OFED 3.2-1.0.1.1, CX3 2.35.5000 (10.7.55.193)
ETH Side: DHCP Server Win2012 R2, WinOF 5.10, CX3 2.35.5000 (10.7.55.190)
SX1036 GW: MLNX_OS ver 3.4.3002

Before installing the PPA
DHCP client sends discover, DHCP server send offer, however the packet never reach the client, bootp flag is Unicast

Revision history for this message
Talat Batheesh (talat-b87) wrote :

Hi Rafael,
Thank you for the great job.
The Broadcast flag is working, the packet drop was in the switch.
We will ask our costumer to install this PPA, will update later.

Thank you,
Talat

Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :

Okay, Tks Talat.

Ill propose this fix into all versions relying on the IB patches submitted in fix:

https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141

Check:

https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/comments/31

Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :
Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :
Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :
description: updated
Changed in isc-dhcp (Ubuntu Wily):
assignee: nobody → Rafael David Tinoco (inaddy)
Changed in isc-dhcp (Ubuntu Trusty):
assignee: nobody → Rafael David Tinoco (inaddy)
tags: added: sts sts-sponsor
Louis Bouchard (louis)
tags: added: sts-sru
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package isc-dhcp - 4.3.3-5ubuntu13

---------------
isc-dhcp (4.3.3-5ubuntu13) yakkety; urgency=medium

  * Fixed missing broadcast flag for Infiniband interfaces (LP: #1529815)
  - added:
    + d/p/dhcp-4.2.4-dhclient-options-changed.patch

 -- Rafael David Tinoco (Inaddy) <email address hidden> Tue, 07 Jun 2016 15:52:40 +0200

Changed in isc-dhcp (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello Talat, or anyone else affected,

Accepted isc-dhcp into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/isc-dhcp/4.3.3-5ubuntu12.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in isc-dhcp (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed
Changed in isc-dhcp (Ubuntu Wily):
status: In Progress → Fix Committed
Revision history for this message
Brian Murray (brian-murray) wrote :

Hello Talat, or anyone else affected,

Accepted isc-dhcp into wily-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/isc-dhcp/4.3.1-5ubuntu3.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Louis Bouchard (louis)
tags: removed: sts-sponsor
Revision history for this message
Martin Pitt (pitti) wrote :

Note for the trusty update: This includes the SRU for bug 1568485 which is v-failed, so the current package cannot be accepted. Either upload an ubuntu12.6 without the changes from 12.5, or coordinate with the uploader of the previous SRU to fix/update/merge the changes.

Revision history for this message
Martin Pitt (pitti) wrote :

Unsubscribing ubuntu-sponsors.

Mathew Hodson (mhodson)
description: updated
Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :
Download full text (4.0 KiB)

Verification for Xenial:

ubuntu@dixie:~$ uname -a
Linux dixie 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

ubuntu@dixie:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial

ubuntu@dixie:~$ dpkg -l | grep isc-dhcp
ii isc-dhcp-client 4.3.3-5ubuntu12.1 amd64 DHCP client for automatically obtaining an IP address
ii isc-dhcp-common 4.3.3-5ubuntu12.1 amd64 common files used by all of the isc-dhcp packages
ii isc-dhcp-server 4.3.3-5ubuntu12.1 amd64 ISC DHCP server for automatic IP address assignment

You can observe that DHCP works AND broadcast flag is set (by sniffing dhcp server ib0 interface):

ubuntu@dixie:~$ sudo tcpdump -i ib0 -nn -vvv -S
tcpdump: listening on ib0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:21:22.603191 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request, length 300, htype 32, hlen 0, xid 0x6775c96f, Flags [Broadcast] (0x8000)
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message Option 53, length 1: Discover
     Hostname Option 12, length 5: "hertz"
     Parameter-Request Option 55, length 13:
       Subnet-Mask, BR, Time-Zone, Default-Gateway
       Domain-Name, Domain-Name-Server, Option 119, Hostname
       Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
       NTP
     Client-ID Option 61, length 17: hardware-type 56, 30:3a:30:30:3a:30:30:3a:34:38:3a:46:45:3a:38:30
     END Option 255, length 0
     PAD Option 0, length 0, occurs 15
16:21:22.603401 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    172.16.0.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, htype 32, hlen 0, xid 0x6775c96f, Flags [Broadcast] (0x8000)
   Your-IP 172.16.0.19
   Server-IP 172.16.0.1
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message Option 53, length 1: Offer
     Server-ID Option 54, length 4: 172.16.0.1
     Lease-Time Option 51, length 4: 600
     Subnet-Mask Option 1, length 4: 255.255.255.0
     BR Option 28, length 4: 172.16.0.255
     Domain-Name Option 15, length 7: "myib.cu"
     END Option 255, length 0
     PAD Option 0, length 0, occurs 23
16:21:22.603586 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request, length 300, htype 32, hlen 0, xid 0x6775c96f, Flags [Broadcast] (0x8000)
   Vendor-rfc1048 Extensions
     Magic Cookie 0x63825363
     DHCP-Message Option 53, length 1: Request
     Server-ID Option 54, length 4: 172.16.0.1
     Requested-IP Option 50, length 4: 172.16.0.19
     Hostname Option 12, length 5: "hertz"
     Parameter-Request Option 55, length 13:
       Subnet-Mask, BR, Time-Zone, Default-Gateway
       Domain-Name, Domain-Name-Server, Option 119, Hostname
       Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
 ...

Read more...

tags: added: verification-done
removed: verification-needed
Revision history for this message
Adam Conrad (adconrad) wrote : Update Released

The verification of the Stable Release Update for isc-dhcp has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package isc-dhcp - 4.3.3-5ubuntu12.1

---------------
isc-dhcp (4.3.3-5ubuntu12.1) xenial; urgency=medium

  * Fixed missing broadcast flag for Infiniband interfaces (LP: #1529815)
  - added:
    + d/p/dhcp-4.2.4-dhclient-options-changed.patch

 -- Rafael David Tinoco (Inaddy) <email address hidden> Wed, 08 Jun 2016 10:51:06 +0200

Changed in isc-dhcp (Ubuntu Xenial):
status: Fix Committed → Fix Released
Adam Conrad (adconrad)
tags: added: verification-done-xenial
removed: verification-done
tags: added: verification-needed-trusty verification-needed-wily
Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :

I think I should skip Wily verification (EOL) and pursue Trusty verification.
It looks like Trusty fix wasn't committed. Could you commit Trusty so I can verify it ?

Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :

Subscribing sponsors again so Trusty can be sponsored. Still waiting on SRU for Trusty.

tags: removed: verification-needed-trusty
Revision history for this message
Louis Bouchard (louis) wrote :

Hello,

Looking at the history for this case, the SRU got rejected by pitti (Comment #29) because of a v-failed on the fix for LP: #1568485 which is also included in this SRU.

Since then, LP: #1568485 has been verified and is now fix-released. There is no longer any reason to hold on the trusty SRU for this bug. The delta between this SRU and trusty-updates is now only the patch that resolves this issue.

There should no longer be any roadblock for this SRU so I am re-uploading the 12.6 package. I am also unsubscribing ubuntu-sponsors

Revision history for this message
Chris J Arges (arges) wrote : Please test proposed package

Hello Talat, or anyone else affected,

Accepted isc-dhcp into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/isc-dhcp/4.2.4-7ubuntu12.6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in isc-dhcp (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed
Mathew Hodson (mhodson)
Changed in isc-dhcp (Ubuntu Wily):
status: Fix Committed → Won't Fix
tags: removed: verification-needed-wily
Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :

After long time I got the lab back so I'm verifying Trusty right now.

Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :

Okay, bug:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1496942

Is avoiding me to verify this.
The lab I was able to get was a ConnectX-4 HCA lab (I was planning to use SR-IOV).
I'll check if I can have two ConnectX-3 servers to verify this.

Be back soon.

Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :
Download full text (5.2 KiB)

Verification for Trusty:

## server

root@dixie:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty

root@dixie:~# dpkg -l | grep dhcp
ii isc-dhcp-client 4.2.4-7ubuntu12.6 amd64 ISC DHCP client
ii isc-dhcp-common 4.2.4-7ubuntu12.6 amd64 common files used by all the isc-dhcp* packages
ii isc-dhcp-server 4.2.4-7ubuntu12.6 amd64 ISC DHCP server for automatic IP address assignment

## client

root@hertz:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty

root@hertz:~# dpkg -l | grep dhcp
ii isc-dhcp-client 4.2.4-7ubuntu12.6 amd64 ISC DHCP client
ii isc-dhcp-common 4.2.4-7ubuntu12.6 amd64 common files used by all the isc-dhcp* packages

----------

## tcpdump showing broadcast flag set (client was able to get IP)

root@dixie:~# tcpdump -i ib0 -nn -vvv -S
Sep 8 12:31:32 dixie kernel: [ 1763.559815] device ib0 entered promiscuous mode
tcpdump: listening on ib0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
Sep 8 12:31:36 dixie dhcpd: DHCPDISCOVER from via ib0
Sep 8 12:31:36 dixie dhcpd: DHCPOFFER on 172.16.0.19 to via ib0
Sep 8 12:31:36 dixie dhcpd: Dynamic and static leases present for 172.16.0.19.
Sep 8 12:31:36 dixie dhcpd: Remove host declaration dixie or remove 172.16.0.19
Sep 8 12:31:36 dixie dhcpd: from the dynamic address pool for 172.16.0.0/24
Sep 8 12:31:36 dixie dhcpd: DHCPREQUEST for 172.16.0.19 (172.16.0.1) from via ib0
Sep 8 12:31:36 dixie dhcpd: DHCPACK on 172.16.0.19 to via ib0
12:31:36.612464 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request, length 300, htype 32, hlen 0, xid 0x6189781a, Flags [Broadcast] (0x8000)
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Hostname Option 12, length 5: "hertz"
            Parameter-Request Option 55, length 13:
              Subnet-Mask, BR, Time-Zone, Default-Gateway
              Domain-Name, Domain-Name-Server, Option 119, Hostname
              Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
              NTP
            Client-ID Option 61, length 17: hardware-type 56, 30:3a:30:30:3a:30:30:3a:34:38:3a:46:45:3a:38:30
            END Option 255, length 0
            PAD Option 0, length 0, occurs 15
12:31:36.612713 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    172.16.0.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, htype 32, hlen 0, xid 0x6189781a, Flags [Broadcast] (0x8000)
          Your-IP 172.16.0.19
          Server-IP 172.16.0.1
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Offer
            Server-ID Option 54, leng...

Read more...

tags: added: verification-done
removed: verification-done-xenial verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package isc-dhcp - 4.2.4-7ubuntu12.6

---------------
isc-dhcp (4.2.4-7ubuntu12.6) trusty; urgency=medium

  * Fixed missing broadcast flag for Infiniband interfaces (LP: #1529815)
    - added:
      + d/p/dhcp-4.2.4-dhclient-options-changed.patch

 -- Rafael David Tinoco <email address hidden> Tue, 07 Jun 2016 15:29:50 +0200

Changed in isc-dhcp (Ubuntu Trusty):
status: Fix Committed → Fix Released
Louis Bouchard (louis)
tags: removed: sts-sru
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.