Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
That fix is interesting. Doesn't ignoring a NAK sort of defeat the point of the 'authoritative' NAKing in the first place? On Tue, May 26, 2015 at 2:26 PM, Vladislav Grishenko themi...@mail.ru wrote: On 02/02/2015 05:47 PM, Brian Haley wrote: The one thing I'm curious about is if dnsmasq is restarted while a VM holds a lease, how will it respond? As someone else has pointed-out to me - isc-dhcp will respond with a DHCPNAK in that case, and wondered why there would be a difference with dnsmasq. Different interpretation of an RFC? If by dnsmasq is restarted you mean dnsmasq is restarted and therefore has its lease database deleted, then the RFC says that if a server gets a renewal for an unknown lease, it should return DHCPNAK. That's what dnsmasq does _unless_ --dhcp-authoritative is set, when instead it quietly re-creates the lease. Yes, your assumption is correct, as --leasefile-ro is used it knows of no current leases, and by default get a DHCPNAK. dhcp-authoritative gives permission to dnsmasq to violate the RFC in a way which is useful in certain circumstances. Thanks, it does seem to do what I want with my initial testing. Hi Simon, Replying to my old thread since using --dhcp-authoritative seems to have introduced an issue where a DHCP client can get a NAK when using multiple dnsmasq servers on the same subnet (they both have the same host information, 1 running just to get HA). Short story is that both dnsmasq's return the same lease info, but when the client ACKs (sending to broadcast), one agent ACKs and the other agent NAKs. The tcpdump shows this better than I'm describing: https://launchpadlibrarian.net/207180476/dhcp_neutron_bug.html Does that seem like normal operation to you? Does this second dnsmasq assume this response is from a rogue server and NAKs since it didn't send out the offer? Hi Brian, Second dnsmasq assume the client request is to another server and responds with NAK in authoritative mode. The root of loop issue is in that busybox 1.20.x udhcpc client, it doesn't check server id for anything but offer packet. Bug is already fixed in bb 1.23.x, see commit http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52 e588c0 Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Kevin Benton ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] format of lease database
Hi, Is there a pointer to the format of the lease database somewhere? I'm interested in what the last column is used for. It looks like the MAC of the client with an extra hex pair at the front. I just wanted to check if there is documentation somewhere before I did into the code to reverse the parsing code. Cheers -- Kevin Benton ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Infiniband IBoIP support
After some further googling around, I finally found some hints to this in the Mellanox Flexboot guide, but to save someone else the same amount of searching, I thought I'd summarize here. The Client ID for the IB interfaces is made up of a prefix (ff:00:00:00:00:00:02:00:00:02:c9:00) combined with the last 8 hex pairs from the hardware address (/sys/class/net/ib0/address). A quick hack to create dnsmasq dhcp-host entries from an IB host (assuming the IB interfaces have already gotten an IP by some other means) is: #!/bin/bash HWADDR=$(/sys/class/net/ib0/address) PREFIX=ff:00:00:00:00:00:02:00:00:02:c9:00 SUFFIX=$(echo $HWADDR | sed 's#..:..:..:..:..:..:..:..:..:..:..:..:\(..:..:..:..:..:..:..:..\)#\1#g') MACADDR=$(echo $HWADDR | sed 's#..:..:..:..:..:..:..:..:..:..:..:..:\(..:..:..:\)..:..:\(..:..:..\)#\1\2#g') IPADDR=$(ip -o addr show ib0 | grep inet | sed 's#.*inet \([0-9\.]*\)/.*#\1#g') HOSTNAME=$(hostname -s) echo $MACADDR,id:$PREFIX:$SUFFIX,$IPADDR,$HOSTNAME,1d Below is a rough offering for an additional entry about this in the dnsmasq.conf.example file. Thanks again for a great tool, jbh --- dnsmasq.conf.example.orig 2015-05-26 08:25:15.230230969 +0300 +++ dnsmasq.conf.example 2015-05-26 08:45:31.207683552 +0300 @@ -251,6 +251,13 @@ # the IP address 192.168.0.60 #dhcp-host=id:01:02:02:04,192.168.0.60 +# Always give the Infiniband interface with hardware address +# 80:00:00:48:fe:80:00:00:00:00:00:00:f4:52:14:03:00:28:05:81 the +# ip address 192.168.0.61. The client id is derived from the prefix +# ff:00:00:00:00:00:02:00:00:02:c9:00 and the last 8 pairs of +# hex digits of the hardware address. +#dhcp-host=id:ff:00:00:00:00:00:02:00:00:02:c9:00:f4:52:14:03:00:28:05:81,192.168.0.61 + # Always give the host with client identifier marjorie # the IP address 192.168.0.60 #dhcp-host=id:marjorie,192.168.0.60 @@ -645,4 +652,4 @@ #conf-dir=/etc/dnsmasq.d,.bak # Include all files in a directory which end in .conf -#conf-dir=/etc/dnsmasq.d/*.conf \ No newline at end of file +#conf-dir=/etc/dnsmasq.d/*.conf On Mon, May 25, 2015 at 3:16 PM, John Hanks griz...@gmail.com wrote: Moshe, Thank you, that works perfectly. jbh On Mon, May 25, 2015 at 3:12 PM, Moshe Levi mosh...@mellanox.com wrote: Hi John, The Infiniband dhcp is using client –id option as identifier so your host file should be 00:11:75:78:d6:7e,id:ff:00:00:00:00:00:02:00:00:02:c9:00:00:11:75:00:00:78:d6:7e ,set:pxemenu,192.168.22.1,db711-02-1,1d Let me know if that helps. Thanks, Moshe Levi *From:* Dnsmasq-discuss [mailto: dnsmasq-discuss-boun...@lists.thekelleys.org.uk] *On Behalf Of *John Hanks *Sent:* Monday, May 25, 2015 2:26 PM *To:* dnsmasq-discuss@lists.thekelleys.org.uk *Subject:* [Dnsmasq-discuss] Infiniband IBoIP support Hello, I'm trying to hand out addresses to my Infiniband adapters using dnsmasq, but doing the naive configuration doesn't seem to work. In my dhcp-hostsfile I have this entry: ff:00:00:00:00:00:02:00:00:02:c9:00:00:11:75:00:00:78:d6:7e,set:pxemenu,192.168.22.1,db711-02-1,1d When I attempt to bring up the ib0 interface on this node, I see this in the dnsmasq log: 717987360 available DHCP subnet: 192.168.16.0/255.255.240.0 717987360 DHCPDISCOVER(ib0) ff:00:00:00:00:00:02:00:00:02:c9:00:00:11:75:00:00:78:d6:7e ignored 717987360 available DHCP subnet: 192.168.16.0/255.255.240.0 717987360 DHCPDISCOVER(ib0) ff:00:00:00:00:00:02:00:00:02:c9:00:00:11:75:00:00:78:d6:7e ignored How do I get dnsmasq to hand out addresses to these requests? My searching hasn't turned up much other than some rpms for a mellanox version of dnsmasq, which I haven't yet tried as I am hoping to just use a vanilla DNSmasq for this project. Thanks, jbh ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
On 02/02/2015 05:47 PM, Brian Haley wrote: The one thing I'm curious about is if dnsmasq is restarted while a VM holds a lease, how will it respond? As someone else has pointed-out to me - isc-dhcp will respond with a DHCPNAK in that case, and wondered why there would be a difference with dnsmasq. Different interpretation of an RFC? If by dnsmasq is restarted you mean dnsmasq is restarted and therefore has its lease database deleted, then the RFC says that if a server gets a renewal for an unknown lease, it should return DHCPNAK. That's what dnsmasq does _unless_ --dhcp-authoritative is set, when instead it quietly re-creates the lease. Yes, your assumption is correct, as --leasefile-ro is used it knows of no current leases, and by default get a DHCPNAK. dhcp-authoritative gives permission to dnsmasq to violate the RFC in a way which is useful in certain circumstances. Thanks, it does seem to do what I want with my initial testing. Hi Simon, Replying to my old thread since using --dhcp-authoritative seems to have introduced an issue where a DHCP client can get a NAK when using multiple dnsmasq servers on the same subnet (they both have the same host information, 1 running just to get HA). Short story is that both dnsmasq's return the same lease info, but when the client ACKs (sending to broadcast), one agent ACKs and the other agent NAKs. The tcpdump shows this better than I'm describing: https://launchpadlibrarian.net/207180476/dhcp_neutron_bug.html Does that seem like normal operation to you? Does this second dnsmasq assume this response is from a rogue server and NAKs since it didn't send out the offer? Thanks, -Brian ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
On 02/02/2015 05:47 PM, Brian Haley wrote: The one thing I'm curious about is if dnsmasq is restarted while a VM holds a lease, how will it respond? As someone else has pointed-out to me - isc-dhcp will respond with a DHCPNAK in that case, and wondered why there would be a difference with dnsmasq. Different interpretation of an RFC? If by dnsmasq is restarted you mean dnsmasq is restarted and therefore has its lease database deleted, then the RFC says that if a server gets a renewal for an unknown lease, it should return DHCPNAK. That's what dnsmasq does _unless_ --dhcp-authoritative is set, when instead it quietly re-creates the lease. Yes, your assumption is correct, as --leasefile-ro is used it knows of no current leases, and by default get a DHCPNAK. dhcp-authoritative gives permission to dnsmasq to violate the RFC in a way which is useful in certain circumstances. Thanks, it does seem to do what I want with my initial testing. Hi Simon, Replying to my old thread since using --dhcp-authoritative seems to have introduced an issue where a DHCP client can get a NAK when using multiple dnsmasq servers on the same subnet (they both have the same host information, 1 running just to get HA). Short story is that both dnsmasq's return the same lease info, but when the client ACKs (sending to broadcast), one agent ACKs and the other agent NAKs. The tcpdump shows this better than I'm describing: https://launchpadlibrarian.net/207180476/dhcp_neutron_bug.html Does that seem like normal operation to you? Does this second dnsmasq assume this response is from a rogue server and NAKs since it didn't send out the offer? Hi Brian, Second dnsmasq assume the client request is to another server and responds with NAK in authoritative mode. The root of loop issue is in that busybox 1.20.x udhcpc client, it doesn't check server id for anything but offer packet. Bug is already fixed in bb 1.23.x, see commit http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52 e588c0 Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
