Bug 704073 - suppress the message "DHCP packet received on eth<N> which has no address"
Summary: suppress the message "DHCP packet received on eth<N> which has no address"
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: dnsmasq
Version: 6.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Daniel Veillard
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 1088482
TreeView+ depends on / blocked
 
Reported: 2011-05-12 04:29 UTC by Mark Wu
Modified: 2018-11-14 12:41 UTC (History)
10 users (show)

Fixed In Version: dnsmasq-2.48-5.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1088482 (view as bug list)
Environment:
Last Closed: 2011-12-06 18:54:29 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1746 0 normal SHIPPED_LIVE dnsmasq bug fix update 2011-12-06 01:01:48 UTC

Description Mark Wu 2011-05-12 04:29:30 UTC
Description of problem:
The following message was reported to "/var/log/messages" on a host server.
"dnsmasq-dhcp[XXXX]: DHCP packet received on eth1 which has no address"
It happens when there's an interface without IP address configured, like a slave of bonding


Version-Release number of selected component (if applicable):
libvirt-0.8.7-16.el6
dnsmasq-2.48-4.el6

How reproducible:
always

1. Install a RHEL6 with KVM enabled.
2. make sure the virbr0 is up and dnsmasq is started by default.
3. make sure another interface, like eth1 is up but does not have a IP address.
4. generate a dhcp request in another host which is in the same LAN of eth1

Actual results:
get warning message: dnsmasq-dhcp[XXXX]: DHCP packet received on eth1 which has no address"

Expected results:
No messages reported


Additional info:

Comment 1 Mark Wu 2011-05-12 04:30:37 UTC
The dnsmasq command line:
nobody   21564  0.0  0.0  12796   604 ?        S    15:37   0:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override

I have verified that this message could be suppressed by appending "--interface=virbr0" manually. But currently libvirt doesn't use the option "--interface" in order to be compatible with old dnsmasq (<  2.47). Then how to resolve this problem?
One idea is changing the behaviour of "--bind-interfaces" for dhcp. Currently, even with "--bind-interfaces" and "--listen-address", dnsmasq listens on all interfaces, not like dns which only listens on the specified address.
The other is just adding "--interface" and let people who're using IPv6 upgrade dnsmasq.

Post to libvirt-list
https://www.redhat.com/archives/libvir-list/2011-May/msg00603.html

Comment 3 RHEL Program Management 2011-05-12 06:00:32 UTC
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 4 Dave Allan 2011-05-12 19:47:49 UTC
(In reply to comment #1)
> One idea is changing the behaviour of "--bind-interfaces" for dhcp. Currently,
> even with "--bind-interfaces" and "--listen-address", dnsmasq listens on all
> interfaces, not like dns which only listens on the specified address.
> The other is just adding "--interface" and let people who're using IPv6 upgrade
> dnsmasq.

This seems like something that's properly fixed in dnsmasq, not libvirt, so I'm changing the component.

Comment 6 Daniel Veillard 2011-06-02 02:32:09 UTC
I don't see any way to disable that out of the box in dnsmasq code,
I will ask the maintainer, but it is just a warning, and I think just
disabling the warning in the code for RHEL-6 would be an okay measure.
But I will try to join the upstream maintainer first,

Daniel

Comment 18 errata-xmlrpc 2011-12-06 18:54:29 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1746.html


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