[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