| 2023-11-02 19:01:17 |
Timo M |
bug |
|
|
added bug |
| 2023-11-03 21:20:32 |
Mitchell Dzurick |
dnsmasq (Ubuntu): status |
New |
Incomplete |
|
| 2023-11-06 12:53:19 |
Timo M |
attachment added |
|
archive containing docker-compose.yml and needed configuration files https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2042587/+attachment/5716459/+files/sample.tar.gz |
|
| 2023-11-09 14:25:54 |
Lucas Kanashiro |
bug |
|
|
added subscriber Ubuntu Server |
| 2023-11-09 14:25:57 |
Lucas Kanashiro |
dnsmasq (Ubuntu): status |
Incomplete |
Triaged |
|
| 2023-11-09 14:26:23 |
Lucas Kanashiro |
nominated for series |
|
Ubuntu Jammy |
|
| 2023-11-09 14:26:23 |
Lucas Kanashiro |
bug task added |
|
dnsmasq (Ubuntu Jammy) |
|
| 2023-11-09 14:27:22 |
Lucas Kanashiro |
dnsmasq (Ubuntu Jammy): status |
New |
Triaged |
|
| 2023-11-09 14:27:26 |
Lucas Kanashiro |
dnsmasq (Ubuntu): status |
Triaged |
New |
|
| 2023-11-15 21:41:36 |
Mitchell Dzurick |
tags |
|
server-todo |
|
| 2023-12-13 16:20:05 |
Andreas Hasenack |
dnsmasq (Ubuntu Jammy): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2023-12-13 16:20:06 |
Andreas Hasenack |
dnsmasq (Ubuntu): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2024-01-10 18:57:56 |
Andreas Hasenack |
dnsmasq (Ubuntu Jammy): status |
Triaged |
In Progress |
|
| 2024-01-10 19:47:15 |
Andreas Hasenack |
description |
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument. From dnsmasq documentation for --dhcp-script:
> The arguments to the process are "add", "old" or "del", the MAC address of the host (or DUID for IPv6) , the IP address, and the hostname, if known.
I believe the change has been inadverently made in upstream commit 527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692 (https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blobdiff;f=src/helper.c;h=02340a01c00031db0cc682c8a4a279cfc1db574e;hp=d81de9622e6d484a264496b2cd3638b4e15e9677;hb=527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692;hpb=fcb4dcaf7cc8a86ac2533b933161b6455f75bf8f) as the commit message only speaks about inet_ntoa replacement and not the behavioral change it also introduces (previously the relay address was only set to the environment variable, now it effectively overrides the prevoiusly set client's IP address).
dnsmasq 2.86-1.1ubuntu0.3 / Ubuntu 22.04 |
[ Impact ]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original description ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument. From dnsmasq documentation for --dhcp-script:
> The arguments to the process are "add", "old" or "del", the MAC address of the host (or DUID for IPv6) , the IP address, and the hostname, if known.
I believe the change has been inadverently made in upstream commit 527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692 (https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blobdiff;f=src/helper.c;h=02340a01c00031db0cc682c8a4a279cfc1db574e;hp=d81de9622e6d484a264496b2cd3638b4e15e9677;hb=527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692;hpb=fcb4dcaf7cc8a86ac2533b933161b6455f75bf8f) as the commit message only speaks about inet_ntoa replacement and not the behavioral change it also introduces (previously the relay address was only set to the environment variable, now it effectively overrides the prevoiusly set client's IP address).
dnsmasq 2.86-1.1ubuntu0.3 / Ubuntu 22.04 |
|
| 2024-01-10 19:48:19 |
Andreas Hasenack |
description |
[ Impact ]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original description ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument. From dnsmasq documentation for --dhcp-script:
> The arguments to the process are "add", "old" or "del", the MAC address of the host (or DUID for IPv6) , the IP address, and the hostname, if known.
I believe the change has been inadverently made in upstream commit 527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692 (https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blobdiff;f=src/helper.c;h=02340a01c00031db0cc682c8a4a279cfc1db574e;hp=d81de9622e6d484a264496b2cd3638b4e15e9677;hb=527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692;hpb=fcb4dcaf7cc8a86ac2533b933161b6455f75bf8f) as the commit message only speaks about inet_ntoa replacement and not the behavioral change it also introduces (previously the relay address was only set to the environment variable, now it effectively overrides the prevoiusly set client's IP address).
dnsmasq 2.86-1.1ubuntu0.3 / Ubuntu 22.04 |
[ Impact ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original description ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument. From dnsmasq documentation for --dhcp-script:
> The arguments to the process are "add", "old" or "del", the MAC address of the host (or DUID for IPv6) , the IP address, and the hostname, if known.
I believe the change has been inadverently made in upstream commit 527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692 (https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blobdiff;f=src/helper.c;h=02340a01c00031db0cc682c8a4a279cfc1db574e;hp=d81de9622e6d484a264496b2cd3638b4e15e9677;hb=527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692;hpb=fcb4dcaf7cc8a86ac2533b933161b6455f75bf8f) as the commit message only speaks about inet_ntoa replacement and not the behavioral change it also introduces (previously the relay address was only set to the environment variable, now it effectively overrides the prevoiusly set client's IP address).
dnsmasq 2.86-1.1ubuntu0.3 / Ubuntu 22.04 |
|
| 2024-01-10 19:51:07 |
Andreas Hasenack |
attachment added |
|
setup-and-server.sh https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2042587/+attachment/5738170/+files/setup-and-server.sh |
|
| 2024-01-10 19:59:04 |
Andreas Hasenack |
description |
[ Impact ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument.
[ Test Plan ]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original description ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument. From dnsmasq documentation for --dhcp-script:
> The arguments to the process are "add", "old" or "del", the MAC address of the host (or DUID for IPv6) , the IP address, and the hostname, if known.
I believe the change has been inadverently made in upstream commit 527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692 (https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blobdiff;f=src/helper.c;h=02340a01c00031db0cc682c8a4a279cfc1db574e;hp=d81de9622e6d484a264496b2cd3638b4e15e9677;hb=527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692;hpb=fcb4dcaf7cc8a86ac2533b933161b6455f75bf8f) as the commit message only speaks about inet_ntoa replacement and not the behavioral change it also introduces (previously the relay address was only set to the environment variable, now it effectively overrides the prevoiusly set client's IP address).
dnsmasq 2.86-1.1ubuntu0.3 / Ubuntu 22.04 |
[ Impact ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument.
[ Test Plan ]
To easily test this on a single machine, a test script is being provided to setup networking and dnsmasq configuration.
# Launch a jammy VM
lxc launch ubuntu-daily:jammy j-dnsmasq-2042587 --vm
# open a root shell in that VM. All subsequent commands must be executed as root in that VM
lxc shell j-dnsmasq-2042587
# download test script
wget https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2042587/+attachment/5738170/+files/setup-and-server.sh
# make it executable
chmod +x setup-and-server.sh
# install dnsmasq. Ignore the postinst error (because systemd-resolved is also running and there is a port conflict)
apt update && apt install dnsmasq -y
# run the setup script. It will configure things and start dnsmasq ready to be tested
./setup-and-server.sh
# in another root session inside the vm (so run "lxc shell j-dnsmasq-2042587" in another terminal), run the proposed commands from the setup script (and press ctrl-c after the result is shown):
No DHCP relay:
ip netns exec client dhclient -d -v p2
The setup script should log an IP that is not a relay. For example:
dnsmasq-dhcp: DHCPDISCOVER(p1) aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPOFFER(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587
###########################
IP = 192.168.47.150
###########################
With DHCP relay set to 192.168.47.9, IP should NOT be that address:
ip netns exec client dhclient -d -v p2 -g 192.168.47.9
With the affected dnsmasq package, we will see an error:
dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587
###########################
IP = 192.168.47.9
TEST FAILED
###########################
The error is that the obtained IP is that of the dhcp relay (provided via the -g option).
With the fixed dnsmasq package, "TEST FAILED" must not appear, and the IP should not be that of the provided dhcp relay.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original description ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument. From dnsmasq documentation for --dhcp-script:
> The arguments to the process are "add", "old" or "del", the MAC address of the host (or DUID for IPv6) , the IP address, and the hostname, if known.
I believe the change has been inadverently made in upstream commit 527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692 (https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blobdiff;f=src/helper.c;h=02340a01c00031db0cc682c8a4a279cfc1db574e;hp=d81de9622e6d484a264496b2cd3638b4e15e9677;hb=527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692;hpb=fcb4dcaf7cc8a86ac2533b933161b6455f75bf8f) as the commit message only speaks about inet_ntoa replacement and not the behavioral change it also introduces (previously the relay address was only set to the environment variable, now it effectively overrides the prevoiusly set client's IP address).
dnsmasq 2.86-1.1ubuntu0.3 / Ubuntu 22.04 |
|
| 2024-01-10 19:59:44 |
Andreas Hasenack |
attachment removed |
setup-and-server.sh https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2042587/+attachment/5738170/+files/setup-and-server.sh |
|
|
| 2024-01-10 19:59:57 |
Andreas Hasenack |
attachment added |
|
setup-and-server.sh https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2042587/+attachment/5738174/+files/setup-and-server.sh |
|
| 2024-01-10 20:00:14 |
Andreas Hasenack |
description |
[ Impact ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument.
[ Test Plan ]
To easily test this on a single machine, a test script is being provided to setup networking and dnsmasq configuration.
# Launch a jammy VM
lxc launch ubuntu-daily:jammy j-dnsmasq-2042587 --vm
# open a root shell in that VM. All subsequent commands must be executed as root in that VM
lxc shell j-dnsmasq-2042587
# download test script
wget https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2042587/+attachment/5738170/+files/setup-and-server.sh
# make it executable
chmod +x setup-and-server.sh
# install dnsmasq. Ignore the postinst error (because systemd-resolved is also running and there is a port conflict)
apt update && apt install dnsmasq -y
# run the setup script. It will configure things and start dnsmasq ready to be tested
./setup-and-server.sh
# in another root session inside the vm (so run "lxc shell j-dnsmasq-2042587" in another terminal), run the proposed commands from the setup script (and press ctrl-c after the result is shown):
No DHCP relay:
ip netns exec client dhclient -d -v p2
The setup script should log an IP that is not a relay. For example:
dnsmasq-dhcp: DHCPDISCOVER(p1) aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPOFFER(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587
###########################
IP = 192.168.47.150
###########################
With DHCP relay set to 192.168.47.9, IP should NOT be that address:
ip netns exec client dhclient -d -v p2 -g 192.168.47.9
With the affected dnsmasq package, we will see an error:
dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587
###########################
IP = 192.168.47.9
TEST FAILED
###########################
The error is that the obtained IP is that of the dhcp relay (provided via the -g option).
With the fixed dnsmasq package, "TEST FAILED" must not appear, and the IP should not be that of the provided dhcp relay.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original description ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument. From dnsmasq documentation for --dhcp-script:
> The arguments to the process are "add", "old" or "del", the MAC address of the host (or DUID for IPv6) , the IP address, and the hostname, if known.
I believe the change has been inadverently made in upstream commit 527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692 (https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blobdiff;f=src/helper.c;h=02340a01c00031db0cc682c8a4a279cfc1db574e;hp=d81de9622e6d484a264496b2cd3638b4e15e9677;hb=527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692;hpb=fcb4dcaf7cc8a86ac2533b933161b6455f75bf8f) as the commit message only speaks about inet_ntoa replacement and not the behavioral change it also introduces (previously the relay address was only set to the environment variable, now it effectively overrides the prevoiusly set client's IP address).
dnsmasq 2.86-1.1ubuntu0.3 / Ubuntu 22.04 |
[ Impact ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument.
[ Test Plan ]
To easily test this on a single machine, a test script is being provided to setup networking and dnsmasq configuration.
# Launch a jammy VM
lxc launch ubuntu-daily:jammy j-dnsmasq-2042587 --vm
# open a root shell in that VM. All subsequent commands must be executed as root in that VM
lxc shell j-dnsmasq-2042587
# download test script
wget https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2042587/+attachment/5738174/+files/setup-and-server.sh
# make it executable
chmod +x setup-and-server.sh
# install dnsmasq. Ignore the postinst error (because systemd-resolved is also running and there is a port conflict)
apt update && apt install dnsmasq -y
# run the setup script. It will configure things and start dnsmasq ready to be tested
./setup-and-server.sh
# in another root session inside the vm (so run "lxc shell j-dnsmasq-2042587" in another terminal), run the proposed commands from the setup script (and press ctrl-c after the result is shown):
No DHCP relay:
ip netns exec client dhclient -d -v p2
The setup script should log an IP that is not a relay. For example:
dnsmasq-dhcp: DHCPDISCOVER(p1) aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPOFFER(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587
###########################
IP = 192.168.47.150
###########################
With DHCP relay set to 192.168.47.9, IP should NOT be that address:
ip netns exec client dhclient -d -v p2 -g 192.168.47.9
With the affected dnsmasq package, we will see an error:
dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587
###########################
IP = 192.168.47.9
TEST FAILED
###########################
The error is that the obtained IP is that of the dhcp relay (provided via the -g option).
With the fixed dnsmasq package, "TEST FAILED" must not appear, and the IP should not be that of the provided dhcp relay.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original description ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument. From dnsmasq documentation for --dhcp-script:
> The arguments to the process are "add", "old" or "del", the MAC address of the host (or DUID for IPv6) , the IP address, and the hostname, if known.
I believe the change has been inadverently made in upstream commit 527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692 (https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blobdiff;f=src/helper.c;h=02340a01c00031db0cc682c8a4a279cfc1db574e;hp=d81de9622e6d484a264496b2cd3638b4e15e9677;hb=527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692;hpb=fcb4dcaf7cc8a86ac2533b933161b6455f75bf8f) as the commit message only speaks about inet_ntoa replacement and not the behavioral change it also introduces (previously the relay address was only set to the environment variable, now it effectively overrides the prevoiusly set client's IP address).
dnsmasq 2.86-1.1ubuntu0.3 / Ubuntu 22.04 |
|
| 2024-01-10 20:00:26 |
Andreas Hasenack |
dnsmasq (Ubuntu): status |
New |
Fix Released |
|
| 2024-01-10 20:00:53 |
Andreas Hasenack |
description |
[ Impact ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument.
[ Test Plan ]
To easily test this on a single machine, a test script is being provided to setup networking and dnsmasq configuration.
# Launch a jammy VM
lxc launch ubuntu-daily:jammy j-dnsmasq-2042587 --vm
# open a root shell in that VM. All subsequent commands must be executed as root in that VM
lxc shell j-dnsmasq-2042587
# download test script
wget https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2042587/+attachment/5738174/+files/setup-and-server.sh
# make it executable
chmod +x setup-and-server.sh
# install dnsmasq. Ignore the postinst error (because systemd-resolved is also running and there is a port conflict)
apt update && apt install dnsmasq -y
# run the setup script. It will configure things and start dnsmasq ready to be tested
./setup-and-server.sh
# in another root session inside the vm (so run "lxc shell j-dnsmasq-2042587" in another terminal), run the proposed commands from the setup script (and press ctrl-c after the result is shown):
No DHCP relay:
ip netns exec client dhclient -d -v p2
The setup script should log an IP that is not a relay. For example:
dnsmasq-dhcp: DHCPDISCOVER(p1) aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPOFFER(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587
###########################
IP = 192.168.47.150
###########################
With DHCP relay set to 192.168.47.9, IP should NOT be that address:
ip netns exec client dhclient -d -v p2 -g 192.168.47.9
With the affected dnsmasq package, we will see an error:
dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587
###########################
IP = 192.168.47.9
TEST FAILED
###########################
The error is that the obtained IP is that of the dhcp relay (provided via the -g option).
With the fixed dnsmasq package, "TEST FAILED" must not appear, and the IP should not be that of the provided dhcp relay.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original description ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument. From dnsmasq documentation for --dhcp-script:
> The arguments to the process are "add", "old" or "del", the MAC address of the host (or DUID for IPv6) , the IP address, and the hostname, if known.
I believe the change has been inadverently made in upstream commit 527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692 (https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blobdiff;f=src/helper.c;h=02340a01c00031db0cc682c8a4a279cfc1db574e;hp=d81de9622e6d484a264496b2cd3638b4e15e9677;hb=527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692;hpb=fcb4dcaf7cc8a86ac2533b933161b6455f75bf8f) as the commit message only speaks about inet_ntoa replacement and not the behavioral change it also introduces (previously the relay address was only set to the environment variable, now it effectively overrides the prevoiusly set client's IP address).
dnsmasq 2.86-1.1ubuntu0.3 / Ubuntu 22.04 |
[ Impact ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument.
This was fixed in 2.87, therefore making only jammy carry an affected package.
[ Test Plan ]
To easily test this on a single machine, a test script is being provided to setup networking and dnsmasq configuration.
# Launch a jammy VM
lxc launch ubuntu-daily:jammy j-dnsmasq-2042587 --vm
# open a root shell in that VM. All subsequent commands must be executed as root in that VM
lxc shell j-dnsmasq-2042587
# download test script
wget https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2042587/+attachment/5738174/+files/setup-and-server.sh
# make it executable
chmod +x setup-and-server.sh
# install dnsmasq. Ignore the postinst error (because systemd-resolved is also running and there is a port conflict)
apt update && apt install dnsmasq -y
# run the setup script. It will configure things and start dnsmasq ready to be tested
./setup-and-server.sh
# in another root session inside the vm (so run "lxc shell j-dnsmasq-2042587" in another terminal), run the proposed commands from the setup script (and press ctrl-c after the result is shown):
No DHCP relay:
ip netns exec client dhclient -d -v p2
The setup script should log an IP that is not a relay. For example:
dnsmasq-dhcp: DHCPDISCOVER(p1) aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPOFFER(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587
###########################
IP = 192.168.47.150
###########################
With DHCP relay set to 192.168.47.9, IP should NOT be that address:
ip netns exec client dhclient -d -v p2 -g 192.168.47.9
With the affected dnsmasq package, we will see an error:
dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587
###########################
IP = 192.168.47.9
TEST FAILED
###########################
The error is that the obtained IP is that of the dhcp relay (provided via the -g option).
With the fixed dnsmasq package, "TEST FAILED" must not appear, and the IP should not be that of the provided dhcp relay.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original description ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument. From dnsmasq documentation for --dhcp-script:
> The arguments to the process are "add", "old" or "del", the MAC address of the host (or DUID for IPv6) , the IP address, and the hostname, if known.
I believe the change has been inadverently made in upstream commit 527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692 (https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blobdiff;f=src/helper.c;h=02340a01c00031db0cc682c8a4a279cfc1db574e;hp=d81de9622e6d484a264496b2cd3638b4e15e9677;hb=527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692;hpb=fcb4dcaf7cc8a86ac2533b933161b6455f75bf8f) as the commit message only speaks about inet_ntoa replacement and not the behavioral change it also introduces (previously the relay address was only set to the environment variable, now it effectively overrides the prevoiusly set client's IP address).
dnsmasq 2.86-1.1ubuntu0.3 / Ubuntu 22.04 |
|
| 2024-01-10 20:03:31 |
Andreas Hasenack |
description |
[ Impact ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument.
This was fixed in 2.87, therefore making only jammy carry an affected package.
[ Test Plan ]
To easily test this on a single machine, a test script is being provided to setup networking and dnsmasq configuration.
# Launch a jammy VM
lxc launch ubuntu-daily:jammy j-dnsmasq-2042587 --vm
# open a root shell in that VM. All subsequent commands must be executed as root in that VM
lxc shell j-dnsmasq-2042587
# download test script
wget https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2042587/+attachment/5738174/+files/setup-and-server.sh
# make it executable
chmod +x setup-and-server.sh
# install dnsmasq. Ignore the postinst error (because systemd-resolved is also running and there is a port conflict)
apt update && apt install dnsmasq -y
# run the setup script. It will configure things and start dnsmasq ready to be tested
./setup-and-server.sh
# in another root session inside the vm (so run "lxc shell j-dnsmasq-2042587" in another terminal), run the proposed commands from the setup script (and press ctrl-c after the result is shown):
No DHCP relay:
ip netns exec client dhclient -d -v p2
The setup script should log an IP that is not a relay. For example:
dnsmasq-dhcp: DHCPDISCOVER(p1) aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPOFFER(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587
###########################
IP = 192.168.47.150
###########################
With DHCP relay set to 192.168.47.9, IP should NOT be that address:
ip netns exec client dhclient -d -v p2 -g 192.168.47.9
With the affected dnsmasq package, we will see an error:
dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587
###########################
IP = 192.168.47.9
TEST FAILED
###########################
The error is that the obtained IP is that of the dhcp relay (provided via the -g option).
With the fixed dnsmasq package, "TEST FAILED" must not appear, and the IP should not be that of the provided dhcp relay.
[ Where problems could occur ]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[ Other Info ]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[ Original description ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument. From dnsmasq documentation for --dhcp-script:
> The arguments to the process are "add", "old" or "del", the MAC address of the host (or DUID for IPv6) , the IP address, and the hostname, if known.
I believe the change has been inadverently made in upstream commit 527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692 (https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blobdiff;f=src/helper.c;h=02340a01c00031db0cc682c8a4a279cfc1db574e;hp=d81de9622e6d484a264496b2cd3638b4e15e9677;hb=527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692;hpb=fcb4dcaf7cc8a86ac2533b933161b6455f75bf8f) as the commit message only speaks about inet_ntoa replacement and not the behavioral change it also introduces (previously the relay address was only set to the environment variable, now it effectively overrides the prevoiusly set client's IP address).
dnsmasq 2.86-1.1ubuntu0.3 / Ubuntu 22.04 |
[ Impact ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument.
This was fixed in 2.87, therefore making only jammy carry an affected package.
[ Test Plan ]
To easily test this on a single machine, a test script is being provided to setup networking and dnsmasq configuration.
# Launch a jammy VM
lxc launch ubuntu-daily:jammy j-dnsmasq-2042587 --vm
# open a root shell in that VM. All subsequent commands must be executed as root in that VM
lxc shell j-dnsmasq-2042587
# download test script
wget https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/2042587/+attachment/5738174/+files/setup-and-server.sh
# make it executable
chmod +x setup-and-server.sh
# install dnsmasq. Ignore the postinst error (because systemd-resolved is also running and there is a port conflict)
apt update && apt install dnsmasq -y
# run the setup script. It will configure things and start dnsmasq ready to be tested
./setup-and-server.sh
# in another root session inside the vm (so run "lxc shell j-dnsmasq-2042587" in another terminal), run the proposed commands from the setup script (and press ctrl-c after the result is shown):
No DHCP relay:
ip netns exec client dhclient -d -v p2
The setup script should log an IP that is not a relay. For example:
dnsmasq-dhcp: DHCPDISCOVER(p1) aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPOFFER(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587
###########################
IP = 192.168.47.150
###########################
With DHCP relay set to 192.168.47.9, IP should NOT be that address:
ip netns exec client dhclient -d -v p2 -g 192.168.47.9
With the affected dnsmasq package, we will see an error:
dnsmasq-dhcp: DHCPREQUEST(p1) 192.168.47.150 aa:a0:9d:00:5b:d6
dnsmasq-dhcp: DHCPACK(p1) 192.168.47.150 aa:a0:9d:00:5b:d6 j-dnsmasq-2042587
###########################
IP = 192.168.47.9
TEST FAILED
###########################
The error is that the obtained IP is that of the dhcp relay (provided via the -g option).
With the fixed dnsmasq package, "TEST FAILED" must not appear, and the IP should not be that of the provided dhcp relay.
[ Where problems could occur ]
If the fix is incorrect, it would mean the dhcp-script would get an incorrect IP again, or perhaps we could have crashes in dnsmasq when dealing with buffers and pointers if the dhcp-script option is in use.
This fix was committed upstream a few months after the bug was introduced, so it took a while to be noticed.
[ Other Info ]
Not at this time.
[ Original description ]
When upgrading from focal to jammy, existing dnsmasq dhcp-scripts stopped working in an environment where a DHCP relay is in use. Instead of the expected client IP address, the script gets the _relay_ IP address as an argument. From dnsmasq documentation for --dhcp-script:
> The arguments to the process are "add", "old" or "del", the MAC address of the host (or DUID for IPv6) , the IP address, and the hostname, if known.
I believe the change has been inadverently made in upstream commit 527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692 (https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blobdiff;f=src/helper.c;h=02340a01c00031db0cc682c8a4a279cfc1db574e;hp=d81de9622e6d484a264496b2cd3638b4e15e9677;hb=527c3c7d0d3bb4bf5fad699f10cf0d1a45a54692;hpb=fcb4dcaf7cc8a86ac2533b933161b6455f75bf8f) as the commit message only speaks about inet_ntoa replacement and not the behavioral change it also introduces (previously the relay address was only set to the environment variable, now it effectively overrides the prevoiusly set client's IP address).
dnsmasq 2.86-1.1ubuntu0.3 / Ubuntu 22.04 |
|
| 2024-01-10 20:09:04 |
Andreas Hasenack |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/dnsmasq/+git/dnsmasq/+merge/458373 |
|
| 2024-01-11 15:46:47 |
Ubuntu Archive Robot |
bug |
|
|
added subscriber Andreas Hasenack |
| 2024-01-20 00:12:29 |
Steve Langasek |
dnsmasq (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
| 2024-01-20 00:12:30 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2024-01-20 00:12:34 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2024-01-20 00:12:46 |
Steve Langasek |
tags |
server-todo |
server-todo verification-needed verification-needed-jammy |
|
| 2024-01-21 19:04:49 |
Timo M |
tags |
server-todo verification-needed verification-needed-jammy |
server-todo verification-done-jammy verification-needed |
|
| 2024-01-31 07:48:36 |
Bryce Harrington |
tags |
server-todo verification-done-jammy verification-needed |
server-todo verification-done verification-done-jammy |
|
| 2024-01-31 17:13:08 |
Robie Basak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2024-01-31 17:13:07 |
Launchpad Janitor |
dnsmasq (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
