Bug 20876 - dnsmasq cannot change a IP address
Summary: dnsmasq cannot change a IP address
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 5
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Julien Moragny
QA Contact:
URL:
Whiteboard:
Keywords: UPSTREAM
Depends on:
Blocks:
 
Reported: 2017-05-17 00:37 CEST by Pierre Jarillon
Modified: 2020-08-02 12:57 CEST (History)
1 user (show)

See Also:
Source RPM: dnsmasq-2.71-4.mga5
CVE:
Status comment:


Attachments

Description Pierre Jarillon 2017-05-17 00:37:14 CEST
Description of problem:

I use dnsmasq on a server. 
I connect a new PC. As it is unknown, il gets the address IP 126. Correct.
I modify /etc/dnsmasq.conf: I add
dhcp-host=4C:CC:6A:B3:24:2A,gaina,192.168.33.5,infinite

I restart dnsmask, i restart and reboot the new PC. It has always the IP 126.

Core of the problem
The address 126 has been stored in /var/lib/misc/dnsmasq.leases
This file is used and the instruction in /etc/dnsmasq.conf is ignored.
If I remove the line in /var/lib/misc/dnsmasq.leases, the new value in /etc/dnmasq is used.

Suggestion:
If dnsmasq.conf is newer than dnsmasq.leases, dnsmasq.leases must be ignored
Comment 1 Marja Van Waes 2017-05-17 11:27:56 CEST
Assigning to the registered maintainer.

CC: (none) => marja11
Assignee: bugsquad => julien.moragny
Source RPM: dnsmasq 2.71-4.mga5 => dnsmasq-2.71-4.mga5

Comment 2 Julien Moragny 2017-05-17 21:37:58 CEST
Hello,

From what I understand of the DHCP protocol, it's the intended behavior. Lease are renewed at the end of lease time, if client request the release or exceptionally if you fiddle with the lease db.

As it is the behavior of dnsmasq itself, you should rise this issue directly to upstream ([1] and specifically [2])

In the meantime, dhcp_release in the package dnsmasq-utils is a tool used to clear a lease from the db :
    NAME
    dhcp_release - Release a DHCP lease on a the local dnsmasq DHCP server.

regards
Julien

[1]http://www.thekelleys.org.uk/dnsmasq/doc.html
[2]http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/
Comment 3 Pierre Jarillon 2018-08-27 22:31:48 CEST
If a former dhcpd has been setup and uninstalled, the file /var/lib/dhcp/dhcpd.leases still exists is used first by dnsmasq.
The file /var/lib/misc/dnsmasq.leases is read if dhcpd.leases doesn't exists.
If any of these files exist, a new declaration in dnmasq.conf is ignored.

If I plug a new network device to know its MAC address,  in order to set its IP in dnsmasq.conf, it receives also an IP recorded in the lease file, and dnsmasq.conf is ignored.

A new value in dnsmasq.conf must replace old values in leases files.
Comment 4 Marja Van Waes 2018-10-07 17:15:30 CEST
@ Julien & Pierre:

Sorry, after reading dozens of bug reports this afternoon, I fail to understand the comments in this one.

What should be done with this bug report? Kept open for Mga6? If so, should it get the UPSTREAM keyword and/or is there a packaging issue and/or is there user error involved?
Comment 5 Pierre Jarillon 2018-10-08 12:28:51 CEST
Dnsmasq uses statical and dynamical mecanisms.
The automatic and dynamic lease must not overwrite the static declaration.
Use of dhcp_release is not obvious. It is not easy to know that dhcp_release exists.

When I receive a new device, I plug it on the network to find its MAC address. Then dnsmasq  gives a dynamic IP address. Then I declare the new device with a fixed IP in dnsmasq.conf, I unplug  the device, restart dnsmasq and plug again the device. The new IP is ignored.

This looks like a bug. There is no warning telling that the static declaration is ignored.
The solution is to never overwrite dnsmasq.conf with dnsmasq.leases when a MAC address is already declared.

If this is not a bug, it is a serious problem...
Comment 6 Pierre Jarillon 2018-10-08 13:33:59 CEST
The solution is to never overwrite dnsmasq.conf with dnsmasq.leases for a MAC address which is already declared.

The problem is not in packaging. IMO, it should be reported upstream.
Comment 7 Marja Van Waes 2018-10-09 09:58:04 CEST
Thanks, Pierre.

Do you use Mageia 6 now, or Cauldron, or both?

The "Version:" of this report should be changed to the highest Mga version for which this issue is valid. If that is Cauldron, then "MAGEIA6TOO" should be put on the "Whiteboard:"

Would you have time to file a ticket upstream?

Keywords: (none) => UPSTREAM

Comment 8 Marja Van Waes 2020-08-02 12:57:17 CEST
(In reply to Marja Van Waes from comment #7)
> Thanks, Pierre.
> 
> Do you use Mageia 6 now, or Cauldron, or both?
> 
> The "Version:" of this report should be changed to the highest Mga version
> for which this issue is valid. If that is Cauldron, then "MAGEIA6TOO" should
> be put on the "Whiteboard:"
> 
> Would you have time to file a ticket upstream?

Closing as OLD, because this report is still against Mageia 5 and we don't even support Mageia 6 anymore.
Besides, if it is an upstream choice.... :-/

Resolution: (none) => OLD
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.