Bug 704073

Summary: suppress the message "DHCP packet received on eth<N> which has no address"
Product: Red Hat Enterprise Linux 6 Reporter: Mark Wu <dwu>
Component: dnsmasqAssignee: Daniel Veillard <veillard>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: azelinka, dallan, dyuan, jscotka, jwest, jzhenyon, moshiro, ohudlick, rhayden.public, xhu
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: dnsmasq-2.48-5.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1088482 (view as bug list) Environment:
Last Closed: 2011-12-06 18:54:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1088482    

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