Re: [Dnsmasq-discuss] bug:DHCP Relay not responding with DHCP OFFER.

2017-05-01 Thread Dan Sneddon
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

2017-03-29 Thread Dan Sneddon
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

2016-08-02 Thread Dan Sneddon
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

2016-06-24 Thread Dan Sneddon
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