Re: [Dnsmasq-discuss] Dnsmasq not always seeing unicast packets

2011-09-12 Thread Brian Haley 
On 09/12/2011 03:16 PM, Jan Psota wrote:
 I'm running dnsmasq-2.57 on Linux (Ubuntu 11.04), and am starting two dnsmasq
 processes to serve DHCP on two interfaces to VMs I'm running.  Initial 
 packets
 (broadcast MAC/broadcast IP) are handled fine, but when it comes time to 
 renew
 and the VMs unicast the packet directly to the server IP, only one of the two
 dnsmasq processes is getting the packets - the second one started.

 [...]
 I'm not sure why it behaves like that (didn't tested), but if you want
 to have it working in easiest way - just start only one process of
 dnsmasq with two dhcp-range= and interface= set for both needed
 interfaces and dnsmasq will adjust proper range basing on serving
 interface's IP.

Thanks for the reply Jan.

Unfortunately using multiple range and interface arguments won't work since I
will need to run 100, with different conf files for each.

-Brian

Re: [Dnsmasq-discuss] Dnsmasq not always seeing unicast packets

2011-09-12 Thread Brian Haley 
On 09/12/2011 03:54 PM, Jan Psota wrote:
 Unfortunately using multiple range and interface arguments won't work since I
 will need to run 100, with different conf files for each.

 Didn't you forget to set bind-interfaces?

No, I set --bind-interfaces, --listen-address=1.2.3.4 and --interface=br0, but
netstat still shows 0.0.0.0 as the listner address, and debugging with strace
and printf's don't show SO_BINDTODEVICE being used.

-Brian

[Dnsmasq-discuss] Windows Server 2008 R2 issue

2012-10-13 Thread Brian Haley 
Hi,

I'm having trouble getting a Windows Server 2008 R2 virtual machine to get a
lease from dnsmasq running on Ubuntu Linux.  An R1, and any other OS, has no
problems.  The version of dnsmasq is 2.58-3.

My config is as follows:

eth0 - public interface - IP 15.3.2.1 (that's not my real IP)
brx1 - private bridge   - IP 10.13.128.1
vnetX - taps attached to the bridge

Here's the ps output for dnsmasq:

20761 ?S  0:00 dnsmasq --strict-order --bind-interfaces
--conf-file=/var/lib/nova/networks/dnsmasq.conf --domain=novalocal
--pid-file=/var/lib/nova/networks/nova-brx1.pid --listen-address=10.13.128.1
--except-interface=lo --dhcp-range=10.13.128.2,static,255.255.224.0,900s
--dhcp-lease-max=8192 --dhcp-hostsfile=/var/lib/nova/networks/nova-brx1.conf
--dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro

That dnsmasq.conf file just has two srv-host lines for my windows license 
servers.

Running tcpdump, I see plenty of good request/responses, for example, this is
an R1 server:

21:35:18.255923 02:16:3e:2e:e9:b7  ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800),
length 342: (tos 0x0, ttl 128, id 1, offset 0, flags [none], proto UDP (17),
length 328)
0.0.0.0.68  255.255.255.255.67: BOOTP/DHCP, Request from 02:16:3e:2e:e9:b7,
length 300, xid 0x4a51edc4, secs 1280, Flags [none]
  Client-Ethernet-Address 02:16:3e:2e:e9:b7
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 02:16:3e:2e:e9:b7
Hostname Option 12, length 15: WIN-HRD4U0NMS2R
Vendor-Class Option 60, length 8: MSFT 5.0
Parameter-Request Option 55, length 12:
  Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
  Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
  Static-Route, Classless-Static-Route,
Classless-Static-Route-Microsoft, Vendor-Option

21:35:18.256184 02:16:3f:0c:10:0d  02:16:3e:2e:e9:b7, ethertype IPv4 (0x0800),
length 345: (tos 0x0, ttl 64, id 22748, offset 0, flags [none], proto UDP (17),
length 331)
10.13.128.1.67  10.13.128.217.68: BOOTP/DHCP, Reply, length 303, xid
0x4a51edc4, secs 1280, Flags [none]
  Your-IP 10.13.128.217
  Server-IP 10.13.128.1
  Client-Ethernet-Address 02:16:3e:2e:e9:b7
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 10.13.128.1
Lease-Time Option 51, length 4: 900
RN Option 58, length 4: 450
RB Option 59, length 4: 787
Subnet-Mask Option 1, length 4: 255.255.224.0
BR Option 28, length 4: 10.13.159.255
Default-Gateway Option 3, length 4: 10.13.128.1
Domain-Name-Server Option 6, length 4: 10.13.128.1
Domain-Name Option 15, length 9: novalocal

But for the R2 server I see:

21:26:10.522156 02:16:3e:4b:cc:53  ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800),
length 342: (tos 0x0, ttl 128, id 346, offset 0, flags [none], proto UDP (17),
length 328)
0.0.0.0.68  255.255.255.255.67: BOOTP/DHCP, Request from 02:16:3e:4b:cc:53,
length 300, xid 0xcc8a146d, secs 6656, Flags [Broadcast]
  Client-Ethernet-Address 02:16:3e:4b:cc:53
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
NOAUTO Option 116, length 1: Y
Client-ID Option 61, length 7: ether 02:16:3e:4b:cc:53
Hostname Option 12, length 15: WIN-OE4E9RLAG6M
Vendor-Class Option 60, length 8: MSFT 5.0
Parameter-Request Option 55, length 12:
  Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
  Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
  Static-Route, Classless-Static-Route,
Classless-Static-Route-Microsoft, Vendor-Option

21:26:10.522590 02:16:3f:0c:10:0d  ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800),
length 345: (tos 0x0, ttl 64, id 58362, offset 0, flags [none], proto UDP (17),
length 331)
15.3.2.1.67  255.255.255.255.68: BOOTP/DHCP, Reply, length 303, xid
0xcc8a146d, secs 6656, Flags [Broadcast]
  Your-IP 10.13.128.194
  Server-IP 10.13.128.1
  Client-Ethernet-Address 02:16:3e:4b:cc:53
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 10.13.128.1
Lease-Time Option 51, length 4: 900
RN Option 58, length 4: 450
RB Option 59, length 4: 787
Subnet-Mask Option 1, length 4: 255.255.224.0
BR Option 28, length 4: 10.13.159.255
Default-Gateway Option 3, length 4: 10.13.128.1
Domain-Name-Server Option 6, length 4: 10.13.128.1
Domain-Name Option 15, length 9:

Re: [Dnsmasq-discuss] Windows Server 2008 R2 issue

2012-10-15 Thread Brian Haley 

On 10/15/2012 06:58 AM, Simon Kelley wrote:

On 13/10/12 17:34, Brian Haley wrote:

Hi,

I'm having trouble getting a Windows Server 2008 R2 virtual machine to
get a
lease from dnsmasq running on Ubuntu Linux.  An R1, and any other OS,
has no
problems.  The version of dnsmasq is 2.58-3.

My config is as follows:

eth0 - public interface - IP 15.3.2.1 (that's not my real IP)
brx1 - private bridge   - IP 10.13.128.1
vnetX - taps attached to the bridge

Here's the ps output for dnsmasq:

20761 ?S  0:00 dnsmasq --strict-order --bind-interfaces
--conf-file=/var/lib/nova/networks/dnsmasq.conf --domain=novalocal
--pid-file=/var/lib/nova/networks/nova-brx1.pid
--listen-address=10.13.128.1
--except-interface=lo --dhcp-range=10.13.128.2,static,255.255.224.0,900s
--dhcp-lease-max=8192
--dhcp-hostsfile=/var/lib/nova/networks/nova-brx1.conf
--dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro


snip


But for the R2 server I see:

21:26:10.522156 02:16:3e:4b:cc:53  ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800),
length 342: (tos 0x0, ttl 128, id 346, offset 0, flags [none], proto
UDP (17),
length 328)
 0.0.0.0.68  255.255.255.255.67: BOOTP/DHCP, Request from
02:16:3e:4b:cc:53,
length 300, xid 0xcc8a146d, secs 6656, Flags [Broadcast]
   Client-Ethernet-Address 02:16:3e:4b:cc:53
   Vendor-rfc1048 Extensions
 Magic Cookie 0x63825363
 DHCP-Message Option 53, length 1: Discover
 NOAUTO Option 116, length 1: Y
 Client-ID Option 61, length 7: ether 02:16:3e:4b:cc:53
 Hostname Option 12, length 15: WIN-OE4E9RLAG6M
 Vendor-Class Option 60, length 8: MSFT 5.0
 Parameter-Request Option 55, length 12:
   Subnet-Mask, Domain-Name, Default-Gateway,
Domain-Name-Server
   Netbios-Name-Server, Netbios-Node, Netbios-Scope,
Router-Discovery
   Static-Route, Classless-Static-Route,
Classless-Static-Route-Microsoft, Vendor-Option

21:26:10.522590 02:16:3f:0c:10:0d  ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800),
length 345: (tos 0x0, ttl 64, id 58362, offset 0, flags [none], proto
UDP (17),
length 331)
 15.3.2.1.67  255.255.255.255.68: BOOTP/DHCP, Reply, length 303, xid
0xcc8a146d, secs 6656, Flags [Broadcast]
   Your-IP 10.13.128.194
   Server-IP 10.13.128.1
   Client-Ethernet-Address 02:16:3e:4b:cc:53
   Vendor-rfc1048 Extensions
 Magic Cookie 0x63825363
 DHCP-Message Option 53, length 1: Offer
 Server-ID Option 54, length 4: 10.13.128.1
 Lease-Time Option 51, length 4: 900
 RN Option 58, length 4: 450
 RB Option 59, length 4: 787
 Subnet-Mask Option 1, length 4: 255.255.224.0
 BR Option 28, length 4: 10.13.159.255
 Default-Gateway Option 3, length 4: 10.13.128.1
 Domain-Name-Server Option 6, length 4: 10.13.128.1
 Domain-Name Option 15, length 9: novalocal

Notice the source IP address here is that of my Internet-facing
interface, not
the IP on the bridge.  That's actually causing me to drop the packet
on the
bridge due to an ebtables rule that only allows responses from
10.13.128.1 (for
security reasons).  Since I'm starting dnsmasq to only listen on that
IP, I
don't know why it's responding using the other, unless the Linux
network stack
is doing that?

The only thing I've noticed that's different is that in the R2 request
there is
an additional option:

NOAUTO Option 116, length 1: Y

Is that possibly causing dnsmasq to respond differently?  I haven't
dug into the
code yet, figured I'd ask on the list in case it's been seen before.



The option 116 thing is a red herring. I think the crucial difference
between R1 and R2 is that R2 is R2 is setting the Broadcast flag in its
requests, so that dnsmasq is sending replies to 255.255.255.255.


Thanks, I looked at that trace many times and never noticed that, 
strange that R2 would have changed something like this.



Dnsmasq is not explicitly setting the source address, so that's coming
from the Linux kernel, it looks like it's making a bad call under these
circumstances.


Is dnsmasq choosing the interface?  Like using SO_BINDTODEVICE?  I 
should go look, but it must be doing something since it's going out onto 
the bridge and not out eth0 where my default route is pointing.  I would 
have hoped the kernel would have chosen the address on the bridge, but I 
can look into why it didn't.



A tweak to your firewall rules to accept all packets to 255.255.255.255
may be a good solution.


The problem isn't the destination address, but the source, since we're 
trying to catch anyone spoofing the DHCP server, but I may be able to 
write an iptables rule to catch this case and change the source IP to be 
correct.


Thanks,

-Brian

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk

Re: [Dnsmasq-discuss] Cannot assign IPv6 address for /96 subnet

2013-02-12 Thread Brian Haley 
On 02/12/2013 05:43 PM, Sheng Yang wrote:
 I am also a little dubious here, but if people want to get some
 smaller subnet, do they able to get it anyway on IPv6?

You typically use a /64 on a link, but you can use longer.  The problem is that
address auto-configuration will only work if the prefix length is 64 since that
plus the IID length of 64 == 128.  In your case, 96 + 64 is simply too large.

A Linux system receiving a !64 prefix length will log this error in
/var/log/kern.log:

IPv6 addrconf: prefix with wrong length 96

That would confirm my assumption.

-Brian

 On Tue, Feb 12, 2013 at 1:06 PM, Brian Haley brian.ha...@hp.com wrote:
 On 02/08/2013 09:59 PM, Sheng Yang wrote:
 Hi Simon,

 I found I can't assign IPv6 address for /96 subnet.

 I specified DHCP range use 96 bits prefixes:

 dhcp-range=fc00:3:1602::7473,96,static

 This is in violation of RFC 4862 Section 5.5.3 Item d, right?

 If the sum of the prefix length and interface identifier length
  does not equal 128 bits, the Prefix Information option MUST be
  ignored.

 Basically, anything besides a /64 on an Ethernet isn't going to work.

 Unless I mis-understood the question?

 -Brian
 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] dnsmasq's AdvRouterAddr On equivalent

2014-04-17 Thread Brian Haley 
On 04/17/2014 09:20 AM, Simon Kelley wrote:
 On 15/04/14 23:31, Jorge Schrauwen wrote:
 Hey All, 

 I had a bit of trouble getting ra to work on OpenBSD but manually compiling 
 2.69 seems to have done the trick. (Yay!) 
 I was porting over my old radvd.conf from linux and I have this option set 
 AdvRouterAddr On. I cannot seem to find the equalivant in dnsmasq. 

 I want me router's global address 2001:DEAD:BEEF:::1 to be advertised as 
 the default route and not the link-local. 
 This breaks some firewall bits that I sadly don't have control over. I could 
 always go back to a dnsmasq+radvd setup but I want to retire the linux 
 server that currently runs radvd. 

 Some pointers appreciated! 
 
 This isn't currently supported by dnsmasq, sorry.
 
 It would be worth considering supporting rfc3775 sections 7.2 and 7.3.
 Would that be sensible stand-alone, or is other stuff needed too?

I'd think that's pretty good, since you don't need sections 7.1 and 7.4 unless
you're going to be a home agent.  It looks like you already support sending a
Source Link-Layer Address option in the RA (section 7.5), and the shorter
intervals might already be there too?

-Brian


 Below is my current configuration (anonimized): 
 # dnsmasq configuration 
 ### listen on interface 
 interface=vlan150 
 interface=vlan200 
 interface=vlan300 

 ### dns 
 ## hosts (import /etc/hosts) 
 #no-hosts 
 #addn-hosts=/etc/dnsmasq.d/hosts 
 ## custom resolvers 
 resolv-file=/etc/dnsmasq.d/resolvers 
 ## domain configuration 
 domain=example.org 
 domain-needed 
 expand-hosts 
 bogus-priv 

 ### dhcp 
 ## options 
 dhcp-authoritative 
 dhcp-option=option:netbios-nodetype,8 
 dhcp-option=option6:dns-server,[::] 
 dhcp-option-force=option:ntp-server,172.16.db.1 
 dhcp-option-force=option6:ntp-server,[2001:DEAD:BEEF:::1] 

 ## static leases 
 dhcp-hostsfile=/etc/dnsmasq.d/reservations 

 ## ipv4 
 dhcp-range=vlan150,172.16.db.100,172.16.db.225,24h 
 dhcp-range=vlan200,172.16.db.220,172.16.db.225,48h 
 dhcp-range=vlan300,172.16.db.200,172.16.db.225,48h 

 ## ipv6 
 enable-ra 
 dhcp-range=vlan150,2001:DEAD:BEEF:::,ra-stateless,ra-names,64,24h 
 dhcp-range=vlan200,2001:DEAD:BEEF:::,ra-stateless,ra-names,64,48h 
 dhcp-range=vlan300,2001:DEAD:BEEF:::,ra-stateless,ra-names,64,48h 

 ### logging 
 ## specify syslog facility (- to disable) 
 log-facility=- 
 ## verbose logging 
 #log-dhcp 
 #log-queries 

 ___
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

 
 
 ___
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] Query about solving a DHCPNAK issue

2015-02-02 Thread Brian Haley 
Hi,

There have been a number of people chasing an issue in Openstack where dnsmasq
was sending DHCPNAK's after it was restarted since it's being started with
--leasefile-ro (https://launchpad.net/bugs/1345947).

The first solution was to create a script that could be called to re-populate
the database inside dnsmasq based on the current contents of the hosts file
that had been created (https://review.openstack.org/#/c/108272/).

But then today someone else found the --dhcp-authoritative option
(https://review.openstack.org/#/c/152080/) that seems to be an even easier
solution.  Since when Openstack is managing the DHCP service it *is* the
authoritative server, this seems like the correct fix.  Does anyone see any
problem with this approach even when there are multiple dnsmasq processes being
run (for HA), since both are under control of the same DHCP authority?

I'm hoping not as this would be a much easier fix.  Thoughts?

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

2015-02-02 Thread Brian Haley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/02/2015 05:30 PM, Simon Kelley wrote:
 
 
 On 02/02/15 22:20, 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.

- -Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUz/5wAAoJEIYQqpVulyUo4/IH/RTpPryLt+1JPmYQTPtUz1vC
sU0FBEGTzrg956zQeTSJjBOudVZ1od1RltU0hJ9rKJsQrJylnV9/ucu8iF7VHQwH
x678qXK5+0wQADT/Ebd0CfVVIKrbUGlnv+01w0XmlRDaqMXxPAbU3qq0vLyKKi2o
4CR5Q2p70/oKq8lzowWNAej+pnOPg0zFdA2bDKZnFbrdqoFvoUOVhe1FSktwX3Kp
OC4hCrbUVcm+f7R3b5yluHKpMr9H6bmgAwx7sKHqYCXFMXW4qm667G6aK/dui2Mt
JPOMlq2igm6xcli/OfVAMDLZA36n+yaevTQJIOnhrS8EuYqOV7FkF80T9/wZUns=
=hC+F
-END PGP SIGNATURE-

___
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

2015-02-02 Thread Brian Haley 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/02/2015 03:30 PM, Simon Kelley wrote:
 
 On 02/02/15 19:50, Brian Haley wrote:
 Hi,
 
 There have been a number of people chasing an issue in Openstack where
 dnsmasq was sending DHCPNAK's after it was restarted since it's being
 started with --leasefile-ro (https://launchpad.net/bugs/1345947).
 
 I guess the first question is why you're giving yourself these problems in
 the first place? If you allow dnsmasq to have a lease file, or keep a lease
 database otherwise, then you'll have solved the source of the problem.

I don't have the complete changelog or discussion on why it was changed (lost
during project re-name), but can take a guess:

1) Neutron didn't want to store this info in it's own DB since it's updated
too often by too many processes
2) You can migrate where the DHCP server lives, or restart it, so without #1
there's no point seemingly in keeping such info, as the host file
contains the things we need to know about

 The first solution was to create a script that could be called to 
 re-populate the database inside dnsmasq based on the current contents of
 the hosts file that had been created 
 (https://review.openstack.org/#/c/108272/).
 
 
 But then today someone else found the --dhcp-authoritative option 
 (https://review.openstack.org/#/c/152080/) that seems to be an even 
 easier solution.  Since when Openstack is managing the DHCP service it
 *is* the authoritative server, this seems like the correct fix. Does
 anyone see any problem with this approach even when there are multiple
 dnsmasq processes being run (for HA), since both are under control of the
 same DHCP authority?
 
 
 It will probably be fine. The client first unicasts to the DHCP server, and
 --dhcp-authoritative means that the server will re-create the lost lease,
 rather then erroring. The problem is if the client broadcasts a renewal. In
 that case _both_ instances would reply. Exactly what happens in that case
 I'm not quite clear, I guess it would depend on the client. Maybe worth an
 experiment.

In this HA case with 1 dnsmasq both will already respond to broadcast
anyways, and it seems to work today - the first response is chosen.

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?

I'll test it anyways.

- -Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUz/grAAoJEIYQqpVulyUowr4H/2mKbwlpEfy+HtWsCRzKULUE
R4Uj5wRRDitur0wFX1ZKBfg10+B/9cLNwB9NLRdC/ZjEzfLiqt3tFoxQmTnTNeRF
m83m2OnP7HOHYBtyENThiRBxZUhz8AVns6wbHatuU4lLM3OjhQfp8+10gGOejoLm
maXs8WE+uh7LzVSy+Sa7zVvszF9KwzG/oyUdccCecG9iOtzsWFOjWSGMXjXGwIMw
XKTCSuDe5cwFmHiEdBn+p+5FvWNNddowQdBGvo4lJnh8Z/Uu8XNnBsAqlXFRRt40
h0ysI0nlr+EKh6tPqU1HT3KQCXa6wCGa1B0lq6jIHIEcbkwQhtHwTq2/YLXn1H8=
=BkGO
-END PGP SIGNATURE-

___
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

2015-05-26 Thread Brian Haley 

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] DNSMASQ wrong addresses allocated after changing DHCP Clients between Neutron vRouters

2018-12-06 Thread Brian Haley 

Luis,

You should probably file a bug against neutron 
(https://bugs.launchpad.net/neutron/) with the relevant info, along with 
the neutron commands you're running and debug from the dhcp-agent and 
/var/lib/neutron/dhcp/xxx/ files as necessary.  I don't exactly 
understand what you mean by "LAN changing", perhaps if I knew the 
commands you're using it would be clearer.


Thanks,

-Brian (from the Neutron team)

On 12/6/18 9:47 AM, Luis Kleber wrote:
Last days I install 2 servers, one with Centos7 and other with Debian8, 
without Openstack/Neutron. Both with the same DNSMASQ config I 
originally posted.
On both I was using version 2.76 and upgraded to 2.78, using the same 
ethernet interface changing the IP address between 100.97.97.1/24 
 and 100.98.98.1/24 , and 
everything works as expected. I also tested with 2 different interfaces 
ont each case and also worked fine.
The DHCP client always was the same in all cases (Debian8, Centos7, and 
Centos7 with Neutron).


It seems that the problem only happens when using DNSMAQ with Neutron 
routers.
How debug it better within Neutron?  Another cache table, or how see 
more detailed debug infos?


Thanks
--
Luis  Kleber


Em sex, 30 de nov de 2018 às 19:07, Luis Kleber > escreveu:


Hi Stappers!

No hardfeelings! There was only a question missing! :)
Thanks for your reply and yes,  it's a complex setup because of the
Neutron use (all installation needed).

After explained the problem, I was expecting a help to "how better
debug", how see some other logs, activate another debug, another
configuration, and so on...
I'll try if the same problem happens without Neutron. Only using a
DNSMASQ with 2 different access interfaces/networks.

Tanks.
--
Luis Kleber


Em sex, 30 de nov de 2018 às 16:33, Geert Stappers
mailto:stapp...@stappers.nl>> escreveu:

On Wed, Nov 28, 2018 at 08:49:57AM -0200, Luis Kleber wrote:
 > Em ter, 27 de nov de 2018 às 20:12, Geert Stappers escreveu:
 > > On Mon, Nov 26, 2018 at 04:42:05PM -0200, Luis Kleber wrote:
 > >     
 > > > dhcp-range=set:infra-70-subnet,100.101.1.11,100.101.1.64,600s
 > > > dhcp-option=tag:infra-70-subnet,3,100.101.1.1
 > > > dhcp-range=set:infra-71-subnet,100.101.2.11,100.101.2.64,600s
 > > > dhcp-option=tag:infra-71-subnet,3,100.101.2.1
 > > > dhcp-range=set:infra-72-subnet,100.98.98.11,100.98.98.64,600s
 > > > dhcp-option=tag:infra-72-subnet,3,100.98.98.1
 > >      infra-73 ... infra-92 
 > > > dhcp-range=set:infra-93-subnet,100.103.8.11,100.103.8.64,600s
 > > > dhcp-option=tag:infra-93-subnet,3,100.103.8.1
 > > > dhcp-range=set:infra-94-subnet,100.104.1.11,100.104.1.64,600s
 > > > dhcp-option=tag:infra-94-subnet,3,100.104.1.1
 > > > dhcp-range=set:infra-95-subnet,100.96.96.11,100.96.96.64,600s
 > > > dhcp-option=tag:infra-95-subnet,3,100.96.96.1
 > >
 > > Why?
 > >
 >
 > "Why" what?
 > If the question is the all other dhcp-ranges (unused for this
scenario),
 > the answer is because in production case these other networks
for each dhcp
 > range exist. These other unused ranges for this test case,
this cannot be a
 > problem.
 >
 > Thanks

No problem, no hardfeelings.

It was me who should have wrote in his initial reply


   Oops, that is a complex setup. Is really all the complexity
needed?


Anyway: Feel free to post, do known that it is been readed.


Groeten
Geert Stappers
-- 
 > this cannot be a problem.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk

http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Change dhcp_release to use first address when no IP subnet matches

2019-05-20 Thread Brian Haley 

Hi Simon,

Not sure if you had an opinion on this, seemed like a bug regardless of 
me trying to use Dbus.


Thanks,

-Brian

On 4/26/19 4:03 PM, Brian Haley wrote:

Currently, dhcp_release will only send a 'fake' release
when the address given is in the same subnet as an IP
on the interface that was given.

This doesn't work in an environment where dnsmasq is
managing leases for remote subnets via a DHCP relay, as
running dhcp_release locally will just cause it to
silently exit without doing anything, leaving the lease
n the database.

Change it to save the first IP it finds on the interface,
and if no matching subnet IP is found, use it as a fall-back.
This fixes an issue we are seeing in certain Openstack
deployments where we are using dnsmasq to provision baremetal
systems in a datacenter.

While using Dbus might have seemed like an obvious solution,
because of our extensive use of network namespaces (which
Dbus doesn't support), this seemed like a better solution
than creating system.d policy files for each dnsmasq we
might spawn and using --enable-dbus=$id in order to isolate
messages to specific dnsmasq instances.

Signed-off-by: Brian Haley 
---
  contrib/lease-tools/dhcp_release.c | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/contrib/lease-tools/dhcp_release.c 
b/contrib/lease-tools/dhcp_release.c
index 59883d4..63a732f 100644
--- a/contrib/lease-tools/dhcp_release.c
+++ b/contrib/lease-tools/dhcp_release.c
@@ -180,6 +180,7 @@ static int is_same_net(struct in_addr a, struct in_addr b, 
struct in_addr mask)
  
  static struct in_addr find_interface(struct in_addr client, int fd, unsigned int index)

  {
+  struct in_addr first_addr = {};
struct sockaddr_nl addr;
struct nlmsghdr *h;
ssize_t len;
@@ -218,7 +219,11 @@ static struct in_addr find_interface(struct in_addr 
client, int fd, unsigned int
  
for (h = (struct nlmsghdr *)iov.iov_base; NLMSG_OK(h, (size_t)len); h = NLMSG_NEXT(h, len))

if (h->nlmsg_type == NLMSG_DONE)
- exit(0);
+  {
+   if (first_addr.s_addr)
+ return first_addr;
+   exit(0);
+  }
else if (h->nlmsg_type == RTM_NEWADDR)
{
  struct ifaddrmsg *ifa = NLMSG_DATA(h);
@@ -234,7 +239,11 @@ static struct in_addr find_interface(struct in_addr 
client, int fd, unsigned int
  
  for (rta = IFA_RTA(ifa); RTA_OK(rta, len1); rta = RTA_NEXT(rta, len1))

  if (rta->rta_type == IFA_LOCAL)
-   addr = *((struct in_addr *)(rta+1));
+   {
+ addr = *((struct in_addr *)(rta+1));
+ if (!first_addr.s_addr)
+   first_addr = addr;
+   }

  if (addr.s_addr && is_same_net(addr, client, netmask))
  return addr;



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Change dhcp_release to use first address when no IP subnet matches

2019-05-14 Thread Brian Haley 

On 5/14/19 3:52 AM, Nicolas Cavallari wrote:

On 26/04/2019 22:03, Brian Haley wrote:

Currently, dhcp_release will only send a 'fake' release
when the address given is in the same subnet as an IP
on the interface that was given.

This doesn't work in an environment where dnsmasq is
managing leases for remote subnets via a DHCP relay, as
running dhcp_release locally will just cause it to
silently exit without doing anything, leaving the lease
n the database.

Change it to save the first IP it finds on the interface,
and if no matching subnet IP is found, use it as a fall-back.
This fixes an issue we are seeing in certain Openstack
deployments where we are using dnsmasq to provision baremetal
systems in a datacenter.

While using Dbus might have seemed like an obvious solution,
because of our extensive use of network namespaces (which
Dbus doesn't support), this seemed like a better solution
than creating system.d policy files for each dnsmasq we
might spawn and using --enable-dbus=$id in order to isolate
messages to specific dnsmasq instances.


I use D-Bus accross network namespaces without any problem.


I found I could only use the system bus and not the session bus with 
namespaces.  But maybe part is I don't think my dnsmasq configuration is 
very Dbus-friendly.  For example, it is running inside a network 
namespace because there are most likely >1 tenant using the same private 
IP address space.  So if I send a message on the system bus I want it 
scoped so only a single dnsmasq instance will get it, but my testing 
with some scripts showed that wasn't the case by default, I needed the 
--enable-bus flag and a corresponding profile entry.



I also configured
D-Bus to look for additional policies in a tmpfs, and each time i need to start
a D-Bus enabled dnsmasq, i create an additonal policy for a new name and SIGHUP
dbus-daemon.

If you want to isolate D-Bus across network namespaces, it is also possible
to start another dbus-daemon on another unix socket, then set the
DBUS_SYSTEM_BUS_ADDRESS to the address chosen by dbus-daemon, so that dnsmasq
and your other programs can use it.
I cobbled this shell script some time ago to test things, it could probably be
cleaned/adjusted:

bus_path="/tmp/test_$netns"
bus_addr="unix:abstract=$bus_path"

dbus_fifo="${bus_path}.fifo"

mkfifo "$dbus_fifo"

dbus-daemon --fork --address="$bus_addr" --system --nopidfile \
 --print-address=8 --print-pid=9 8>"$dbus_fifo" 9>&8 &

while read dbus_line; do
 case "$dbus_line" in
 "$bus_addr"*)
  export DBUS_SYSTEM_BUS_ADDRESS="$dbus_line";;
 [0-9]*)
  dbus_pid="$dbus_line";;
 *)
  echo "Unknown D-Bus output: '$dbus_line'" ;;
 esac
done < "$dbus_fifo"
wait


Thanks for the info, I hadn't thought of running an additional Dbus 
daemon inside the namespace.  Unfortunately this will then start 
consuming even more resources (cpu, memory) as there could be hundreds 
or thousands of namespaces in our setup.  If we can fix this with a 
small change it seems much less painful.


-Brian

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] [PATCH] Change dhcp_release to use first address when no IP subnet matches

2019-04-27 Thread Brian Haley 
Currently, dhcp_release will only send a 'fake' release
when the address given is in the same subnet as an IP
on the interface that was given.

This doesn't work in an environment where dnsmasq is
managing leases for remote subnets via a DHCP relay, as
running dhcp_release locally will just cause it to
silently exit without doing anything, leaving the lease
n the database.

Change it to save the first IP it finds on the interface,
and if no matching subnet IP is found, use it as a fall-back.
This fixes an issue we are seeing in certain Openstack
deployments where we are using dnsmasq to provision baremetal
systems in a datacenter.

While using Dbus might have seemed like an obvious solution,
because of our extensive use of network namespaces (which
Dbus doesn't support), this seemed like a better solution
than creating system.d policy files for each dnsmasq we
might spawn and using --enable-dbus=$id in order to isolate
messages to specific dnsmasq instances.

Signed-off-by: Brian Haley 
---
 contrib/lease-tools/dhcp_release.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/contrib/lease-tools/dhcp_release.c 
b/contrib/lease-tools/dhcp_release.c
index 59883d4..63a732f 100644
--- a/contrib/lease-tools/dhcp_release.c
+++ b/contrib/lease-tools/dhcp_release.c
@@ -180,6 +180,7 @@ static int is_same_net(struct in_addr a, struct in_addr b, 
struct in_addr mask)
 
 static struct in_addr find_interface(struct in_addr client, int fd, unsigned 
int index)
 {
+  struct in_addr first_addr = {};
   struct sockaddr_nl addr;
   struct nlmsghdr *h;
   ssize_t len;
@@ -218,7 +219,11 @@ static struct in_addr find_interface(struct in_addr 
client, int fd, unsigned int
 
   for (h = (struct nlmsghdr *)iov.iov_base; NLMSG_OK(h, (size_t)len); h = 
NLMSG_NEXT(h, len))
if (h->nlmsg_type == NLMSG_DONE)
- exit(0);
+  {
+   if (first_addr.s_addr)
+ return first_addr;
+   exit(0);
+  }
else if (h->nlmsg_type == RTM_NEWADDR)
   {
 struct ifaddrmsg *ifa = NLMSG_DATA(h);  
@@ -234,7 +239,11 @@ static struct in_addr find_interface(struct in_addr 
client, int fd, unsigned int
 
 for (rta = IFA_RTA(ifa); RTA_OK(rta, len1); rta = 
RTA_NEXT(rta, len1))
  if (rta->rta_type == IFA_LOCAL)
-   addr = *((struct in_addr *)(rta+1));
+   {
+ addr = *((struct in_addr *)(rta+1));
+ if (!first_addr.s_addr)
+   first_addr = addr;
+   }

 if (addr.s_addr && is_same_net(addr, client, netmask))
  return addr;
-- 
2.17.1


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Change dhcp_release to use first address when no IP subnet matches

2019-08-28 Thread Brian Haley 

On 8/22/19 6:50 PM, Simon Kelley wrote:

On 26/04/2019 21:03, Brian Haley wrote:

Currently, dhcp_release will only send a 'fake' release
when the address given is in the same subnet as an IP
on the interface that was given.

This doesn't work in an environment where dnsmasq is
managing leases for remote subnets via a DHCP relay, as
running dhcp_release locally will just cause it to
silently exit without doing anything, leaving the lease
n the database.

Change it to save the first IP it finds on the interface,
and if no matching subnet IP is found, use it as a fall-back.
This fixes an issue we are seeing in certain Openstack
deployments where we are using dnsmasq to provision baremetal
systems in a datacenter.

While using Dbus might have seemed like an obvious solution,
because of our extensive use of network namespaces (which
Dbus doesn't support), this seemed like a better solution
than creating system.d policy files for each dnsmasq we
might spawn and using --enable-dbus=$id in order to isolate
messages to specific dnsmasq instances.



The address we're determining here is the address used for the "server
identifier" for the DHCP lease. In the case of a client on the other
side from a DHCP relay, dnsmasq uses one of the addresses of the
interface through which the packet arrived. This patch also uses one of
the addresses, but it doesn't choose it in the same way, so for an
interface with multiple addresses, dhcp_release may pick a different
address than the one dnsmasq did, the server_id in the release message
will not match, and the operation will silently fail again.

If the interface has only one address, a common case, then that has to
be chosen, and all works. For more robustness, it makes sense for this
patch to pick one of the addresses in the same way that the dnsmasq code
does, namely, by doing

ioctl(..., SIOCGIFADDR, ...)

in the case that none of the addresses match the address of the lease.


A patch to do that instead of using the first one returned by netlink
would be great.


Thanks Simon, I'll update it and send a v2.

-Brian

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Change dhcp_release to use first address when no IP subnet matches

2019-08-06 Thread Brian Haley 

Simon - just re-sending since you're back.

Thanks,

-Brian

On 4/26/19 4:03 PM, Brian Haley wrote:

Currently, dhcp_release will only send a 'fake' release
when the address given is in the same subnet as an IP
on the interface that was given.

This doesn't work in an environment where dnsmasq is
managing leases for remote subnets via a DHCP relay, as
running dhcp_release locally will just cause it to
silently exit without doing anything, leaving the lease
n the database.

Change it to save the first IP it finds on the interface,
and if no matching subnet IP is found, use it as a fall-back.
This fixes an issue we are seeing in certain Openstack
deployments where we are using dnsmasq to provision baremetal
systems in a datacenter.

While using Dbus might have seemed like an obvious solution,
because of our extensive use of network namespaces (which
Dbus doesn't support), this seemed like a better solution
than creating system.d policy files for each dnsmasq we
might spawn and using --enable-dbus=$id in order to isolate
messages to specific dnsmasq instances.

Signed-off-by: Brian Haley 
---
  contrib/lease-tools/dhcp_release.c | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/contrib/lease-tools/dhcp_release.c 
b/contrib/lease-tools/dhcp_release.c
index 59883d4..63a732f 100644
--- a/contrib/lease-tools/dhcp_release.c
+++ b/contrib/lease-tools/dhcp_release.c
@@ -180,6 +180,7 @@ static int is_same_net(struct in_addr a, struct in_addr b, 
struct in_addr mask)
  
  static struct in_addr find_interface(struct in_addr client, int fd, unsigned int index)

  {
+  struct in_addr first_addr = {};
struct sockaddr_nl addr;
struct nlmsghdr *h;
ssize_t len;
@@ -218,7 +219,11 @@ static struct in_addr find_interface(struct in_addr 
client, int fd, unsigned int
  
for (h = (struct nlmsghdr *)iov.iov_base; NLMSG_OK(h, (size_t)len); h = NLMSG_NEXT(h, len))

if (h->nlmsg_type == NLMSG_DONE)
- exit(0);
+  {
+   if (first_addr.s_addr)
+ return first_addr;
+   exit(0);
+  }
else if (h->nlmsg_type == RTM_NEWADDR)
{
  struct ifaddrmsg *ifa = NLMSG_DATA(h);
@@ -234,7 +239,11 @@ static struct in_addr find_interface(struct in_addr 
client, int fd, unsigned int
  
  for (rta = IFA_RTA(ifa); RTA_OK(rta, len1); rta = RTA_NEXT(rta, len1))

  if (rta->rta_type == IFA_LOCAL)
-   addr = *((struct in_addr *)(rta+1));
+   {
+ addr = *((struct in_addr *)(rta+1));
+ if (!first_addr.s_addr)
+   first_addr = addr;
+   }

  if (addr.s_addr && is_same_net(addr, client, netmask))
  return addr;




___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH v2] Change dhcp_release to use default address when no IP subnet matches

2019-10-01 Thread Brian Haley 

On 10/1/19 10:24 AM, Petr Mensik wrote:

Hi Brian and Simon,

I have one objection here. I think the tool should never end without
sending the request or showing some error. There is still one case left,
where it would do nothing and still exit without error. I admit it would
be rare, as IPv4 address has to be missing on given device. Anyway, I
think showing error and returning error code does not hurt.

Patch attached.


LGTM, thanks Petr.

-Brian



On 8/30/19 10:22 PM, Simon Kelley wrote:

That looks fine. Patch applied.


Cheers,

Simon.



On 28/08/2019 21:13, haleyb@gmail.com wrote:

From: Brian Haley 

Currently, dhcp_release will only send a 'fake' release
when the address given is in the same subnet as an IP
on the interface that was given.

This doesn't work in an environment where dnsmasq is
managing leases for remote subnets via a DHCP relay, as
running dhcp_release locally will just cause it to
silently exit without doing anything, leaving the lease
in the database.

Change it to use the default IP on the interface, as the
dnsmasq source code at src/dhcp.c does, if no matching subnet
IP is found, as a fall-back.  This fixes an issue we are
seeing in certain Openstack deployments where we are using
dnsmasq to provision baremetal systems in a datacenter.

While using Dbus might have seemed like an obvious solution,
because of our extensive use of network namespaces (which
Dbus doesn't support), this seemed like a better solution
than creating system.d policy files for each dnsmasq we
might spawn and using --enable-dbus=$id in order to isolate
messages to specific dnsmasq instances.

Signed-off-by: Brian Haley 
---
  contrib/lease-tools/dhcp_release.c | 12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/contrib/lease-tools/dhcp_release.c 
b/contrib/lease-tools/dhcp_release.c
index 59883d4..c866cd9 100644
--- a/contrib/lease-tools/dhcp_release.c
+++ b/contrib/lease-tools/dhcp_release.c
@@ -178,7 +178,7 @@ static int is_same_net(struct in_addr a, struct in_addr b, 
struct in_addr mask)
return (a.s_addr & mask.s_addr) == (b.s_addr & mask.s_addr);
  }
  
-static struct in_addr find_interface(struct in_addr client, int fd, unsigned int index)

+static struct in_addr find_interface(struct in_addr client, int fd, unsigned 
int index, int ifrfd, struct ifreq *ifr)
  {
struct sockaddr_nl addr;
struct nlmsghdr *h;
@@ -218,7 +218,13 @@ static struct in_addr find_interface(struct in_addr 
client, int fd, unsigned int
  
for (h = (struct nlmsghdr *)iov.iov_base; NLMSG_OK(h, (size_t)len); h = NLMSG_NEXT(h, len))

if (h->nlmsg_type == NLMSG_DONE)
- exit(0);
+  {
+   /* No match found, return first address as src/dhcp.c code does */
+   ifr->ifr_addr.sa_family = AF_INET;
+   if (ioctl(ifrfd, SIOCGIFADDR, ifr) != -1)
+ return ((struct sockaddr_in *)>ifr_addr)->sin_addr;
+   exit(0);
+  }
else if (h->nlmsg_type == RTM_NEWADDR)
{
  struct ifaddrmsg *ifa = NLMSG_DATA(h);
@@ -285,7 +291,7 @@ int main(int argc, char **argv)
  }

lease.s_addr = inet_addr(argv[2]);

-  server = find_interface(lease, nl, if_nametoindex(argv[1]));
+  server = find_interface(lease, nl, if_nametoindex(argv[1]), fd, );

memset(, 0, sizeof(packet));
   




___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss




___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Fix potential memory leak

2024-03-17 Thread Brian Haley 

Hi,

On 3/17/24 9:38 AM, Geert Stappers wrote:

From: Brian Haley 

When a new IPv6 address is being added to a dhcp_config
struct, if there is anything invalid regarding the prefix
it looks like there is a potential memory leak.
ret_err_free() should be used to free it.

Signed-off-by: Brian Haley 
---
  src/option.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/option.c b/src/option.c
index f4ff7c0..db758ce 100644
--- a/src/option.c
+++ b/src/option.c
@@ -4034,7 +4034,7 @@ static int one_opt(int option, char *arg, char *errstr, 
char *gen_err, int comma
u64)1<<(128-new_addr->prefixlen))-1) & 
addrpart) != 0)
  {
dhcp_config_free(new);
-   ret_err(_("bad IPv6 prefix"));
+   ret_err_free(_("bad IPv6 prefix"), new_addr);
  }

new_addr->flags |= ADDRLIST_PREFIX;


Nak.

I don't believe this stands on it's own - new_addr has been linked into 
the list by this point, so freeing it could cause other issues like 
invalid memory references. My original submission moved that operation 
until later in the function to avoid this, so I would rather see that 
version merged.


Thanks,

-Brian

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] Fix potential memory leak

2024-03-18 Thread Brian Haley 

Hi,

On 3/16/24 6:07 AM, Geert Stappers wrote:

On Sat, Mar 02, 2024 at 05:03:01PM +0100, Geert Stappers wrote:

On Fri, Mar 01, 2024 at 04:43:20PM -0500, Brian Haley wrote:

When a new IPv6 address is being added to a dhcp_config
struct, if there is anything invalid regarding the prefix
it looks like there is a potential memory leak.
ret_err_free() should be used to free it.

Signed-off-by: Brian Haley 
---
  src/option.c | 6 +++---

}  1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/src/option.c b/src/option.c
index f4ff7c0..02be995 100644
--- a/src/option.c
+++ b/src/option.c

} @@ -4034,7 +4034,7 @@ static int one_opt(int option, char *arg, char *errstr, 
char *gen_err, int comma

u64)1<<(128-new_addr->prefixlen))-1) & 
addrpart) != 0)
  {
dhcp_config_free(new);
-   ret_err(_("bad IPv6 prefix"));
+   ret_err_free(_("bad IPv6 prefix"), new_addr);
  }

new_addr->flags |= ADDRLIST_PREFIX;


Looks good to me



New version of the patch is planned.


Again, just wanted to emphasize that I did not agree with the new 
version and want this one merged instead.



As an attempt to express that proposed patches get human attention.

I'm not sure what that means...

-Brian

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss