| 2016-09-28 18:50:52 |
Mike Pontillo |
bug |
|
|
added bug |
| 2016-09-28 18:51:02 |
Mike Pontillo |
maas: importance |
Undecided |
High |
|
| 2016-09-28 18:51:07 |
Mike Pontillo |
maas: milestone |
|
2.1.0 |
|
| 2016-09-28 18:51:15 |
Mike Pontillo |
nominated for series |
|
maas/2.0 |
|
| 2016-09-28 18:51:15 |
Mike Pontillo |
bug task added |
|
maas/2.0 |
|
| 2016-09-28 18:51:15 |
Mike Pontillo |
nominated for series |
|
maas/1.9 |
|
| 2016-09-28 18:51:15 |
Mike Pontillo |
bug task added |
|
maas/1.9 |
|
| 2016-09-28 18:51:21 |
Mike Pontillo |
maas/1.9: milestone |
|
2.0.1 |
|
| 2016-09-28 18:51:23 |
Mike Pontillo |
maas/2.0: milestone |
|
1.9.5 |
|
| 2016-09-28 18:51:26 |
Mike Pontillo |
maas/1.9: status |
New |
Triaged |
|
| 2016-09-28 18:51:28 |
Mike Pontillo |
maas/1.9: importance |
Undecided |
High |
|
| 2016-09-28 18:51:29 |
Mike Pontillo |
maas/2.0: importance |
Undecided |
High |
|
| 2016-09-28 18:51:33 |
Mike Pontillo |
maas/1.9: assignee |
|
Mike Pontillo (mpontillo) |
|
| 2016-09-28 18:51:35 |
Mike Pontillo |
maas/2.0: assignee |
|
Mike Pontillo (mpontillo) |
|
| 2016-09-29 16:35:22 |
Mike Pontillo |
maas/2.0: status |
New |
Triaged |
|
| 2016-09-29 16:35:29 |
Mike Pontillo |
maas/1.9: milestone |
2.0.1 |
1.9.5 |
|
| 2016-09-29 16:35:33 |
Mike Pontillo |
maas/2.0: milestone |
1.9.5 |
2.0.1 |
|
| 2016-09-29 18:41:25 |
Launchpad Janitor |
branch linked |
|
lp:~mpontillo/maas/interpret-dhcp-packets-correctly--bug-1628645 |
|
| 2016-10-03 16:13:26 |
Mike Pontillo |
summary |
MAAS incorrectly interprets DHCP packets when detecting external DHCP |
External DHCP detection is broken for a variety of reasons |
|
| 2016-10-03 16:14:56 |
Mike Pontillo |
description |
In provisioningserver/dhcp/detect.py, the following code exists:
self.dhcp_server_ID = socket.inet_ntoa(data[245:249])
That is, we assume that the DHCP server address will always be contained in bytes 245 through 249 of the DHCP reply payload.
This is an incorrect assumption. DHCP replies contain variable length options. A deeper knowledge of the DHCP packet is required in order to correctly interpret DHCP replies and detect DHCP servers operating external to MAAS. |
There are a several major issues with the current external DHCP detection code:
(1) We are not parsing the DHCP options; we use a hard-coded index into the packet to get the DHCP server identifier (IP address).*
(2) The way we bind to the sending socket doesn't work for interfaces with no address. So we cannot discover external DHCP servers on interfaces with no IP address configured.**
(3) The way we bind to the receive socket causes a race condition that makes it likely the DHCP offer will come in before we are listening to the receive socket.
(4) Since we set the 'broadcast' flag in the DHCP discover packet, we don't reliably receive replies from all servers. (It ignores packets from the DD-WRT router I tested it with, for example.) This is because the DHCP server assumes it cannot talk to the client on a unicast IP/MAC and broadcasts the response from a bogus IP address instead, which the Linux TCP/IP stack never sends up to the socket. One way to fix this is to listen to DHCP replies via something like 'tcpdump' or libpcap instead of a UDP socket. Another way to fix this is to unset the broadcast flag.
(5) UDP is unreliable, and we only send a single DHCP discover packet out before assuming no servers responded.
(6) The deferToThread() call was used to cover too much code. It should
only need to cover code that could block.
(7) It is difficult to debug MAAS's interpretation of DHCP offer packets.
*:
In provisioningserver/dhcp/detect.py, the following code exists:
self.dhcp_server_ID = socket.inet_ntoa(data[245:249])
That is, we assume that the DHCP server address will always be contained in bytes 245 through 249 of the DHCP reply payload.
This is an incorrect assumption. DHCP replies contain variable length options. A deeper knowledge of the DHCP packet is required in order to correctly interpret DHCP replies and detect DHCP servers operating external to MAAS.
**:
Fixing (2) requires additional privileges. To be specific, we need a way of sending a DHCP probe out directly on the interface, and a way of listening for the replies without relying on a socket bound to a unicast IP address. The listening portion is partially done in this branch (via `maas-rack observe-dhcp`) to ease debugging and support, but changing the design to use it in MAAS is a drastic design change that should not happen in this branch. |
|
| 2016-10-03 16:15:01 |
Mike Pontillo |
maas/2.0: status |
Triaged |
Won't Fix |
|
| 2016-10-03 16:15:05 |
Mike Pontillo |
maas/1.9: status |
Triaged |
Won't Fix |
|
| 2016-10-03 16:15:09 |
Mike Pontillo |
maas/1.9: assignee |
Mike Pontillo (mpontillo) |
|
|
| 2016-10-03 16:15:11 |
Mike Pontillo |
maas/2.0: assignee |
Mike Pontillo (mpontillo) |
|
|
| 2016-10-03 16:16:17 |
Mike Pontillo |
maas: status |
Triaged |
In Progress |
|
| 2016-10-03 16:16:21 |
Mike Pontillo |
maas: importance |
High |
Critical |
|
| 2016-10-03 16:16:28 |
Mike Pontillo |
maas/1.9: milestone |
1.9.5 |
|
|
| 2016-10-03 16:16:29 |
Mike Pontillo |
maas/2.0: milestone |
2.0.1 |
|
|
| 2016-10-03 16:16:40 |
Mike Pontillo |
maas/1.9: importance |
High |
Undecided |
|
| 2016-10-03 16:16:42 |
Mike Pontillo |
maas/2.0: importance |
High |
Undecided |
|
| 2016-10-03 16:22:30 |
Mike Pontillo |
description |
There are a several major issues with the current external DHCP detection code:
(1) We are not parsing the DHCP options; we use a hard-coded index into the packet to get the DHCP server identifier (IP address).*
(2) The way we bind to the sending socket doesn't work for interfaces with no address. So we cannot discover external DHCP servers on interfaces with no IP address configured.**
(3) The way we bind to the receive socket causes a race condition that makes it likely the DHCP offer will come in before we are listening to the receive socket.
(4) Since we set the 'broadcast' flag in the DHCP discover packet, we don't reliably receive replies from all servers. (It ignores packets from the DD-WRT router I tested it with, for example.) This is because the DHCP server assumes it cannot talk to the client on a unicast IP/MAC and broadcasts the response from a bogus IP address instead, which the Linux TCP/IP stack never sends up to the socket. One way to fix this is to listen to DHCP replies via something like 'tcpdump' or libpcap instead of a UDP socket. Another way to fix this is to unset the broadcast flag.
(5) UDP is unreliable, and we only send a single DHCP discover packet out before assuming no servers responded.
(6) The deferToThread() call was used to cover too much code. It should
only need to cover code that could block.
(7) It is difficult to debug MAAS's interpretation of DHCP offer packets.
*:
In provisioningserver/dhcp/detect.py, the following code exists:
self.dhcp_server_ID = socket.inet_ntoa(data[245:249])
That is, we assume that the DHCP server address will always be contained in bytes 245 through 249 of the DHCP reply payload.
This is an incorrect assumption. DHCP replies contain variable length options. A deeper knowledge of the DHCP packet is required in order to correctly interpret DHCP replies and detect DHCP servers operating external to MAAS.
**:
Fixing (2) requires additional privileges. To be specific, we need a way of sending a DHCP probe out directly on the interface, and a way of listening for the replies without relying on a socket bound to a unicast IP address. The listening portion is partially done in this branch (via `maas-rack observe-dhcp`) to ease debugging and support, but changing the design to use it in MAAS is a drastic design change that should not happen in this branch. |
There are a several major issues with the current external DHCP detection code:
(1) We are not parsing the DHCP options; we use a hard-coded index into the packet to get the DHCP server identifier (IP address).*
(2) The way we bind to the sending socket doesn't work for interfaces with no address. So we cannot discover external DHCP servers on interfaces with no IP address configured.**
(3) The way we bind to the receive socket causes a race condition that makes it likely the DHCP offer will come in before we are listening to the receive socket.
(4) Since we set the 'broadcast' flag in the DHCP discover packet, we don't reliably receive replies from all servers. (It ignores packets from the DD-WRT router I tested it with, for example.) This is because the DHCP server assumes it cannot talk to the client on a unicast IP/MAC and broadcasts the response from a bogus IP address instead, which the Linux TCP/IP stack never sends up to the socket. One way to fix this is to listen to DHCP replies via something like 'tcpdump' or libpcap instead of a UDP socket. Another way to fix this is to unset the broadcast flag.
(5) UDP is unreliable, and we only send a single DHCP discover packet out before assuming no servers responded.
(6) The deferToThread() call was used to cover too much code. It should
only need to cover code that could block.
(7) It is difficult to debug MAAS's interpretation of DHCP offer packets.
*:
In provisioningserver/dhcp/detect.py, the following code exists:
self.dhcp_server_ID = socket.inet_ntoa(data[245:249])
That is, we assume that the DHCP server address will always be contained in bytes 245 through 249 of the DHCP reply payload.
This is an incorrect assumption. DHCP replies contain variable length options. A deeper knowledge of the DHCP packet is required in order to correctly interpret DHCP replies and detect DHCP servers operating external to MAAS.
**:
Fixing (2) requires additional privileges. To be specific, we need a way of sending a DHCP probe out directly on the interface, and a way of listening for the replies without relying on a socket bound to a unicast IP address. The listening portion is partially done in this branch (via `maas-rack observe-dhcp`) to ease debugging and support, but changing the design to use it in MAAS is a drastic design change that will not happen along with the other bug fixes to be done for this feature. |
|
| 2016-10-05 03:22:54 |
MAAS Lander |
maas: status |
In Progress |
Fix Committed |
|
| 2016-10-06 01:59:28 |
Andres Rodriguez |
maas: status |
Fix Committed |
Fix Released |
|
