Re: [Dnsmasq-discuss] bug:DHCP Relay not responding with DHCP OFFER.
Your routing table is wrong. You have both 10.168.101.0/24 and 10.168.102.0/24 both set up as local subnets (see the 0.0.0.0 gateway). The remote subnet should be routed through the local router, so your route would appear something like this: 10.168.101.0 0.0.0.0 255.255.255.0 U 0 0 0 ens160 10.168.102.0 10.168.101.1 255.255.255.0 U 0 0 0 ens160 -- Dan Sneddon | Senior Principal Software Engineer dsned...@redhat.com | redhat.com/openstack dsneddon:irc| @dxs:twitter On 04/27/2017 02:02 PM, Jason Kary wrote: > Hi Folks, > > I have a basic setup for DHCP relay across VLANS in DNSMASQ. > > My configuration file looks like: > > > bogus-priv > interface=ens160 > log-dhcp > dhcp-range=10.168.102.100,10.168.102.150,255.255.255.0,12h > > > The client and server are running on a VMs in separate VLANS. DHCP > requests appear to be coming across: > > > root@DHCP-UBUNTU-SERVER:~# tcpdump -i ens160 port 67 or port 68 -n > tcpdump: verbose output suppressed, use -v or -vv for full protocol > decode > listening on ens160, link-type EN10MB (Ethernet), capture size > 262144 bytes > 03:58:40.966944 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, > Request from 00:0c:29:65:e0:ea, length 322 > 03:58:46.487767 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, > Request from 00:0c:29:65:e0:ea, length 322 > 03:58:54.424895 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, > Request from 00:0c:29:65:e0:ea, length 322 > 03:59:07.795712 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, > Request from 00:0c:29:65:e0:ea, length 322 > 03:59:19.196022 IP 10.168.102.1.67 > 10.168.101.20.67: BOOTP/DHCP, > Request from 00:0c:29:65:e0:ea, length 322 > > root@DHCP-UBUNTU-SERVER:~# iptables -L > Chain INPUT (policy ACCEPT) > target prot opt source destination > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > root@DHCP-UBUNTU-SERVER:~# > > > The syslog log indicates the DCHP OFFERS are ‘supposed’ to be going out > however nothing is seen on the wire. > > > Apr 27 04:03:26 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > available DHCP range: 10.168.102.100 -- 10.168.102.150 > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > DHCPDISCOVER(ens160) 00:0c:29:65:e0:ea > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > tags: ens160 > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > DHCPOFFER(ens160) 10.168.102.128 00:0c:29:65:e0:ea > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > requested options: 1:netmask, 28:broadcast, 2:time-offset, > 121:classless-static-route, > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > requested options: 15:domain-name, 6:dns-server, 12:hostname, > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > requested options: 40:nis-domain, 41:nis-server, 42:ntp-server, > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > requested options: 26:mtu, 119:domain-search, 3:router, > 121:classless-static-route, > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > requested options: 249, 33:static-route, 252, 42:ntp-server > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > next server: 10.168.101.20 > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > sent size: 1 option: 53 message-type 2 > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > sent size: 4 option: 54 server-identifier 10.168.101.20 > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > sent size: 4 option: 51 lease-time 12h > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > sent size: 4 option: 58 T1 6h > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > sent size: 4 option: 59 T2 10h30m > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > sent size: 4 option: 1 netmask 255.255.255.0 > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > sent size: 4 option: 28 broadcast 10.168.102.255 > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > sent size: 4 option: 3 router 10.168.102.1 > Apr 27 04:03:29 DHCP-UBUNTU-SERVER dnsmasq-dhcp[17767]: 1121794364 > sent size: 4 opt
Re: [Dnsmasq-discuss] [PATCH] Delay DHCP replies for Raspberry Pi clients
On 03/29/2017 10:43 AM, Chris Novakovic wrote: > On 29/03/2017 18:13, Kurt H Maier wrote: >> On Wed, Mar 29, 2017 at 02:48:48PM +0200, Floris Bos wrote: >>> The PXE boot firmware implementation of the Raspberry Pi 3 >>> has a bug causing it to fail if it receives replies >>> instantly. >>> >>> As a workaround ensure there is a minimum delay of one >>> second if the client is a Pi. >>> >>> On Linux it looks up the exact receive time of the UDP >>> packet with the SIOCGSTAMP ioctl to prevent multiple >>> delays if multiple packets come in around the same time, >>> or if there already was a delay caused by a ping check. >> >> >> Why not have a configurable dhcp-delay setting instead of putting >> device-specific quirks into the source code of dnsmasq forever? > > +1 for a dhcp-delay setting, ideally per-MAC: the Ethernet adapters on > older RPi models (as well as the built-in wifi adapter on the RPi 3) > also use the b8:27:eb OUI, and this artificial delay oughtn't be applied > to them. > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > Another +1 for adding a dhcp-delay setting on a per-MAC basis. There is a side-benefit that this would enable a form of HA where you have two servers, and one is set to have a built-in delay in its responses. This would allow the primary server to (nearly) always respond first if up, and the secondary server would respond after a delay in case the first server was down. -- Dan Sneddon | Senior Principal Software Engineer dsned...@redhat.com | redhat.com/openstack dsneddon:irc| @dxs:twitter ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] suggestion filter out loopback addresses for query
On 08/02/2016 07:39 AM, Junyang Gu wrote: > It seems to me that dnsmasq should filter out loopback addresses for DNS > queries universally, or at least provide such an option. > > Consider such a scenario, > > dnsmasq runs on host1, and host1's /etc/hosts contains 127.0.1.1 host1, > which is usually the case. > > A second machine host2 queries dnsmasq for host1, and would get > 127.0.1.1, which is also a valid IP address, except it goes to host2. > > I do not see any any scenario where dnsmasq should return a loopback > address. > > > Regards > > I can think of scenarios where this would be desired. Imagine an application that was controlled via DNS with a short TTL, such that when the server was operating normally a real IP would be returned, but when the main server is down the hosts are redirected to a local cache. In this case, it would be useful to be able to point hosts at their local loopback address. It is also used for "blackholing" certain addresses, such as Websites with known malware or adult content. I could see filtering localhost responses being a useful option (if it wasn't mandatory or on by default). -- Dan Sneddon | Principal OpenStack Engineer dsned...@redhat.com | redhat.com/openstack 650.254.4025| dsneddon:irc @dxs:twitter ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Cannot obtain IP address from dnsmasq
On 06/24/2016 02:10 AM, Matwey V. Kornilov wrote: > Hello, > > I am running dnsmasq-2.71 and experiencing the following issue. > > I have network interface eth3 with 10.3.0.1/24 address assigned to it. > I want dnsmasq instance to supply everyone on eth3 L2-segment with IP > address from 10.3.0.1/24 subnet. I don't want DHCP be running on other > interfaces where it can interfere others. > > The issue is the following, HP commutator can not obtain address. > > 12:03:01.609174 IP 192.168.1.1.68 > 255.255.255.255.67: BOOTP/DHCP, > Request from 40:a8:f0:6f:64:40, length 256 > 12:03:23.952477 IP 192.168.1.1.68 > 255.255.255.255.67: BOOTP/DHCP, > Request from 40:a8:f0:6f:64:40, length 256 > > At the same time, other devises obtain address successfully: > > 12:03:45.311101 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request > from 44:aa:e8:00:0c:4e, length 249 > 12:03:45.313634 IP 10.3.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, > length 300 > 12:03:45.340273 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request > from 44:aa:e8:00:0c:4e, length 256 > 12:03:45.371271 IP 10.3.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, > length 300 > 12:03:45.395392 IP 10.3.0.33.1025 > 239.255.255.250.1900: UDP, length 320 > 12:03:46.884261 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request > from 44:aa:e8:00:0c:46, length 249 > 12:03:46.885707 IP 10.3.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, > length 300 > 12:03:46.911271 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request > from 44:aa:e8:00:0c:46, length 256 > 12:03:46.945596 IP 10.3.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, > length 300 > 12:03:46.968662 IP 10.3.0.32.1025 > 239.255.255.250.1900: UDP, length 320 > 12:03:50.390213 IP 10.3.0.33.1025 > 239.255.255.250.1900: UDP, length 320 > > I suppose, that the issue here is that HP's source address is > 192.168.1.1, how could I configure dnsmasq to overcome this issue? > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss I'm going to take a wild guess at your problem, based on the limited data available. If the DHCP request is coming from 192.168.1.1, that sounds like a configuration issue on the HP commutator (whatever that is). Is the HP configured to use a particular IP with DHCP (for the subnet mask, gateway, etc.)? If so, you need to reconfigure the HP, because it won't be able to obtain a reservation for it's preferred IP because it's on the wrong subnet. You can either configure the HP to use a static IP on the correct subnet, or modify it to obtain an IP address dynamically. -- Dan Sneddon | Principal OpenStack Engineer dsned...@redhat.com | redhat.com/openstack 650.254.4025| dsneddon:irc @dxs:twitter ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss