[rhos-list] dnsmasq cannot start properly

Shixiong Shang (shshang) shshang at cisco.com
Tue Feb 19 04:43:44 UTC 2013


Hi, Perry:

I guess I said "iptable rule allows DHCP" too early. :) I read the iptable entries one more time and here is the problem on quantum node running dhcp agent.

[dmd at as-net1 ~]$ sudo iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
quantum-l3-agent-INPUT  all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:53
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:53
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:67
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:67
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:9696
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain quantum-l3-agent-INPUT (1 references)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            7.10.177.2          tcp dpt:8775


By this default setting, DHCP request from remote host (i.e. nova-compute) destined to UDP/67 is ACCEPTED, as we saw previously. However, the DHCP OFFER message, which is sent to UDP/68 is actually blocked. Considering this bi-directional communication, I added the following line to "quantum-l3-agent-INPUT" chain and now my VM got IP address!!!!

iptables -A quantum-l3-agent-INPUT -p udp --dport 67:68 --sport 67:68 -j ACCEPT

[dmd at as-net1 ~]$ sudo tcpdump -vvn -i tap335cc0a4-c7 | grep BOOTP/DHCP
tcpdump: listening on tap335cc0a4-c7, link-type EN10MB (Ethernet), capture size 65535 bytes
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from fa:16:3e:98:7d:98, length 300, xid 0xa7c6d351, secs 3, Flags [none] (0x0000)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from fa:16:3e:98:7d:98, length 300, xid 0xa7c6d351, secs 3, Flags [none] (0x0000)
    192.168.178.2.bootps > 192.168.178.3.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 323, xid 0xa7c6d351, secs 3, Flags [none] (0x0000)
    192.168.178.2.bootps > 192.168.178.3.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 323, xid 0xa7c6d351, secs 3, Flags [none] (0x0000)

Would you please fix this problem in the bug you referred to, or maybe create a new for tracking purpose? In the meanwhile, we still need to understand the SELinux problem mentioned earlier in the email thread. Right now, my SELinux is disabled, which is not desired.

Thank you for the pointer, which truly forced me to think about it twice! Good night!

Shixiong










On Feb 18, 2013, at 7:58 PM, Perry Myers <pmyers at redhat.com<mailto:pmyers at redhat.com>>
 wrote:

On 02/18/2013 07:50 PM, Shixiong Shang (shshang) wrote:
Hi, Chris:

If I completely disabled SELinux, then dnsmasq process could start
without any error. However, my VM still couldn't obtain IP address from
the DHCP server. Based on tcpdump right on tap interface to which DHCP
server was hooked up, I saw inbound DHCP Discover message from VM. But I
never saw DHCP OFFER message returned back to VM. I checked dnsmasq host
files and it contains the right mapping between VM MAC and IP
address…..Anything could go wrong?

Maybe you're hitting this error?
https://bugzilla.redhat.com/show_bug.cgi?id=889868

Gary is working on that one, and we hope to have a fix in the next build
of quantum to put out on RHN/CDN.

There's an upstream patch in review:
https://review.openstack.org/#/c/22183/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rhos-list/attachments/20130219/7b3b590e/attachment.htm>


More information about the rhos-list mailing list