From ranceh at gmail.com Wed Jul 1 04:46:58 2009 From: ranceh at gmail.com (Rance Hall) Date: Tue, 30 Jun 2009 22:46:58 -0500 Subject: [Dnsmasq-discuss] problem getting gpxe to work within dnsmasq Message-ID: <845c0f80906302046s7e79b65bld2f26920beaa71a@mail.gmail.com> Heres my setup dnsmasq is my dhcp/dns/tftpserver all together. I have a working pxe menu system I like, and it affords me the chance to boot dban, memtest, etc just from pxe. I've really struggled getting gPXE to work the way I want it to since Simon was so nice to alter dnsmasq to that gpxe would work the gpxe authors and Simon have apparently teamed up as there is some really good docs out there. Here is what Im trying to accomplish: leave the currently setup pxe menus alone, except add an option from one of the menus to boot gpxe from pxe. pxe supplies the gpxe kernel just like it would for any other product. gpxe starts, gets a different bootfile name and starts the gPXe menu page where you can define the various iSCSI drives that are netbootable problem: here is the stock dnsmasq config file section # Boot for Etherboot gPXE. The idea is to send two different # filenames, the first loads gPXE, and the second tells gPXE what to # load. The dhcp-match sets the gpxe tag for requests from gPXE. #dhcp-match=gpxe,175 # gPXE sends a 175 option. #dhcp-boot=net:#gpxe,undionly.kpxe I have the following configuration dhcp-boot=pxelinux.0 dhcp-match=gpxe,175 # gPXE sends a 175 option. dhcp-boot=net:#menu.gpxe where menu.gpxe exists right next to the pxelinux.0 file in the fttp directory and the file is a gpxe script that tells it what to do next. on my clients I get the following behavior... pxe boots as expected. select gpxe from pxe menu gpxe loads as expected gpxe does NOT load the script and create the menu. gpxe reloads itself ONCE no filename or root path specified BOOT FAILURE. **************************************** if I dont try to give gpxe a menu, gxe loads ONCE, and then gives me a "press ctrl-b to get a command prompt" and when the command prompt is present, I can manually do what I want. I'm open to the possibility that my menu is hosed, but I just want to double check that my setup is correct. From mandeepsandhu.chd at gmail.com Wed Jul 1 05:04:58 2009 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Wed, 1 Jul 2009 09:34:58 +0530 Subject: [Dnsmasq-discuss] using dnsmasq to restrict dns resolution to only certain domains In-Reply-To: <2e59e6970906300735r4d944295q53772783213705c0@mail.gmail.com> References: <2e59e6970906300735r4d944295q53772783213705c0@mail.gmail.com> Message-ID: >> Here's my requirement: >> >> * I have a small device with to communication interfaces - lets call >> them if1 and if2. >> * if1 is connected to say a PC and if2 is connected to a dsl modem/router. >> * I want that the PC host, when using this device, should connect to >> only 1 server on the internet (say myserver.net). >> * The PC cannot use IP addresses directly as IP routing between the 2 >> interfaces on the device is disabled. > > If routing is disabled, then you've got a proxy, right? ?You won't > need to provide any DNS service to clients at all, because they > wouldn't be able to use the IP addresses they got back. ?And the proxy > implementation can easily filter or redirect based on hostname or any > other part of the URL. Well you're right...but there's a catch! The client on the PC does NOT have proxy support!! :( So I thought, I'll put a tiny webserver on my device. Clients on the PC can request for only say myserver.com...and this gets resolved to the device's IP address (on if1) (the device has dnsmasq running on if1). The client can then request for services only from this webserver. I also don't want the client s/w to change when, say the PC gets direct connectivity to the net w/o my device attached (it's directly connected to a DSL modem/router). In that case, dns requests for myserver.com will be resolved by some public (or ISPs) DNS server, which would point to my server on the internet! Thats why I wanted to prevent any DNS lookups for domains other than myserver.com Does this make sense? Thanks, -mandeep > >> * If the PC tries to resolve any other public server, it should fail >> (something like how we force a dns resolution with the "address=" >> directive). >> >> Please pardon me if this sounds crazy! :) >> >> Any helps really appreciated. >> >> Thanks, >> -mandeep >> >> _______________________________________________ >> Dnsmasq-discuss mailing list >> Dnsmasq-discuss at lists.thekelleys.org.uk >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >> > From richardvoigt at gmail.com Wed Jul 1 13:45:45 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Wed, 1 Jul 2009 07:45:45 -0500 Subject: [Dnsmasq-discuss] using dnsmasq to restrict dns resolution to only certain domains In-Reply-To: References: <2e59e6970906300735r4d944295q53772783213705c0@mail.gmail.com> Message-ID: <2e59e6970907010545g172459b4jc6b42d6dce12ccab@mail.gmail.com> On Tue, Jun 30, 2009 at 11:04 PM, Mandeep Sandhu wrote: >>> Here's my requirement: >>> >>> * I have a small device with to communication interfaces - lets call >>> them if1 and if2. >>> * if1 is connected to say a PC and if2 is connected to a dsl modem/router. >>> * I want that the PC host, when using this device, should connect to >>> only 1 server on the internet (say myserver.net). >>> * The PC cannot use IP addresses directly as IP routing between the 2 >>> interfaces on the device is disabled. >> >> If routing is disabled, then you've got a proxy, right? ?You won't >> need to provide any DNS service to clients at all, because they >> wouldn't be able to use the IP addresses they got back. ?And the proxy >> implementation can easily filter or redirect based on hostname or any >> other part of the URL. > > Well you're right...but there's a catch! The client on the PC does NOT have > proxy support!! :( > > So I thought, I'll put a tiny webserver on my device. Clients on the PC can > request for only say myserver.com...and this gets resolved to the device's > IP address (on if1) (the device has dnsmasq running on if1). The client can > then request for services only from this webserver. > > I also don't want the client s/w to change when, say the PC gets > direct connectivity > to the net w/o my device attached (it's directly connected to ?a DSL > modem/router). > > In that case, dns requests for myserver.com will be resolved by some public > (or ISPs) DNS server, which would point to my server on the internet! > Thats why I wanted to prevent any DNS lookups for domains other than > myserver.com You could always not configure dnsmasq with any valid upstream nameservers. It reads /etc/resolv.conf by default but you can change that. You could instead use iptables to rewrite all http connections as connections to your local server, then any address the client uses will hit your server. Depends on whether the user can open a browser or you're only interested in making a specific custom application work. > > Does this make sense? > > Thanks, > -mandeep > >> >>> * If the PC tries to resolve any other public server, it should fail >>> (something like how we force a dns resolution with the "address=" >>> directive). >>> >>> Please pardon me if this sounds crazy! :) >>> >>> Any helps really appreciated. >>> >>> Thanks, >>> -mandeep >>> >>> _______________________________________________ >>> Dnsmasq-discuss mailing list >>> Dnsmasq-discuss at lists.thekelleys.org.uk >>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >>> >> > From simon at thekelleys.org.uk Wed Jul 1 17:03:46 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Wed, 01 Jul 2009 17:03:46 +0100 Subject: [Dnsmasq-discuss] problem getting gpxe to work within dnsmasq In-Reply-To: <845c0f80906302046s7e79b65bld2f26920beaa71a@mail.gmail.com> References: <845c0f80906302046s7e79b65bld2f26920beaa71a@mail.gmail.com> Message-ID: <4A4B88E2.70206@thekelleys.org.uk> Rance Hall wrote: > Heres my setup dnsmasq is my dhcp/dns/tftpserver all together. > > I have a working pxe menu system I like, and it affords me the chance > to boot dban, memtest, etc just from pxe. > > I've really struggled getting gPXE to work the way I want it to since > Simon was so nice to alter dnsmasq to that gpxe would work > > the gpxe authors and Simon have apparently teamed up as there is some > really good docs out there. > > Here is what Im trying to accomplish: > > > leave the currently setup pxe menus alone, except add an option from > one of the menus to boot gpxe from pxe. > > pxe supplies the gpxe kernel just like it would for any other product. > > gpxe starts, gets a different bootfile name and starts the gPXe menu > page where you can define the various iSCSI drives that are > netbootable > > problem: > > here is the stock dnsmasq config file section > > # Boot for Etherboot gPXE. The idea is to send two different > # filenames, the first loads gPXE, and the second tells gPXE what to > # load. The dhcp-match sets the gpxe tag for requests from gPXE. > #dhcp-match=gpxe,175 # gPXE sends a 175 option. > #dhcp-boot=net:#gpxe,undionly.kpxe > > > I have the following configuration > > dhcp-boot=pxelinux.0 > dhcp-match=gpxe,175 # gPXE sends a 175 option. > dhcp-boot=net:#menu.gpxe ^ This doesn't look right, should probably be dhcp-boot=net:#gpxe,menu.gpxe > > where menu.gpxe exists right next to the pxelinux.0 file in the fttp > directory and the file is a gpxe script that tells it what to do next. > > on my clients I get the following behavior... > > > pxe boots as expected. > > select gpxe from pxe menu > > gpxe loads as expected > > gpxe does NOT load the script and create the menu. > > gpxe reloads itself ONCE > > no filename or root path specified > > BOOT FAILURE. > > Cheers, Simon. From terry at beach-works.com Wed Jul 1 18:53:33 2009 From: terry at beach-works.com (Terry Stone) Date: Wed, 1 Jul 2009 13:53:33 -0400 Subject: [Dnsmasq-discuss] Hard Coded Routes with Asterisk Message-ID: <000301c9fa74$dc011aa0$94034fe0$@com> Have been away and not been able to follow up on these suggestions until now. Yes, the good news is that hard coding in the routes in /etc/hosts has solved the problem. I really like the suggestion of doing a regular lookup to check that the IP address has not changed, rather than re-invent the wheel does anyone have a script that might do this? Terry ---------------------------------------------------------------------- Message: 1 Date: Mon, 18 May 2009 13:38:35 -0400 From: "Terry Stone" Subject: [Dnsmasq-discuss] Cache Size To: Message-ID: <00c001c9d7df$79029120$6b07b360$@com> Content-Type: text/plain; charset="us-ascii" I am using DNSMASQ on a server that also runs Trixbox Asterisk IP PBX. Asterisk has an unfortunate trait that if SIP trunks that register with a VOIP provider cannot obtain DNS resolution all SIP extensions stop working for internal phone calls. I installed DNSMASQ in an attempt to stop this from happening, the theory being that DNSMASQ would resolve the address from its cache. This worked fine until I had a long Internet outage when after about 15 minutes things stopped working. My guess is that DNSMASQ flushed the cache and needed to go to another server for updated information. Can anyone tell me how long DNSMASQ holds information in the cache and if it is possible to lengthen that time. Cache size is not an issue as DNSMASQ is only used to resolve the SIP trunk addresses therefore the cache is very small. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/2009051 8/db1c7212/attachment.html ------------------------------ Message: 2 Date: Mon, 18 May 2009 17:07:53 -0400 From: Tom Metro Subject: Re: [Dnsmasq-discuss] Cache Size To: Terry Stone Cc: dnsmasq-discuss at lists.thekelleys.org.uk Message-ID: <4A11CE29.3090508 at gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Terry Stone wrote: > Can anyone tell me how long DNSMASQ holds information in the cache... I would assume the length of time varies per record, as it is something specified as part of the record. It's part of the DNS protocol that the upstream server gets to say how long a record is good for. > ...and if it is possible to lengthen that time. I suspect not. > Asterisk has an unfortunate trait that if SIP trunks that register > with a VOIP provider cannot obtain DNS resolution all SIP extensions > stop working for internal phone calls. Your best bet is probably to make sure this bug is filed with Asterisk and encourage the developers to fix it. Another option might be to use a SIP proxy. That might put a layer between your Asterisk server and your VoIP provider, such that Asterisk doesn't notice when the WAN connection is down. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ ------------------------------ Message: 3 Date: Tue, 19 May 2009 08:39:54 +0200 From: Rune Kock Subject: Re: [Dnsmasq-discuss] Cache Size To: Terry Stone Cc: dnsmasq-discuss at lists.thekelleys.org.uk Message-ID: Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 18, 2009 at 19:38, Terry Stone wrote: > I am using DNSMASQ on a server that also runs Trixbox Asterisk IP PBX. > Asterisk has an unfortunate trait that if SIP trunks that register with a > VOIP provider cannot obtain DNS resolution all SIP extensions stop working > for internal phone calls. I installed DNSMASQ in an attempt to stop this > from happening, the theory being that DNSMASQ would resolve the address from > its cache. This worked fine until I had a long Internet outage when after > about 15 minutes things stopped working. My guess is that DNSMASQ flushed > the cache and needed to go to another server for updated information. Can > anyone tell me how long DNSMASQ holds information in the cache and if it is > possible to lengthen that time. Cache size is not an issue as DNSMASQ is > only used to resolve the SIP trunk addresses therefore the cache is very > small. Would it be an option for you just to hardcode the response for the most common addresses? (Use a address statements in dnsmasq.conf or use the host file). Rune ------------------------------ Message: 4 Date: Tue, 19 May 2009 06:23:27 -0400 From: RevRagnarok Subject: Re: [Dnsmasq-discuss] Cache Size To: dnsmasq-discuss at lists.thekelleys.org.uk Message-ID: Content-Type: text/plain; charset="iso-8859-1" > > > Would it be an option for you just to hardcode the response for the > most common addresses? (Use a address statements in dnsmasq.conf or > use the host file). > > That's quite the hack, and I like it. I would expand upon it a little; I would write a small perl script that went into cron.daily or something similar to update the host file in case they ever change, but major vendor IPs won't change all that often... Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/2009051 9/dca9f598/attachment-0001.htm ------------------------------ _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss at lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss End of Dnsmasq-discuss Digest, Vol 48, Issue 8 ********************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090701/cd159b05/attachment-0001.htm From tmetro+dnsmasq at gmail.com Thu Jul 2 22:32:04 2009 From: tmetro+dnsmasq at gmail.com (Tom Metro) Date: Thu, 02 Jul 2009 17:32:04 -0400 Subject: [Dnsmasq-discuss] multiple programs using UDP port 53 Message-ID: <4A4D2754.6080300@gmail.com> Yesterday I rebooted a Debian Lenny system for the first time since applying the upgrade to Lenny a few months ago, and about 5 minutes later Dnsmasq stopped responding to DNS queries (local or LAN). Restarting Dnsmasq didn't help. No queries would show up in the log from that point forward. A reboot would restore operation for a little while, but then it would break again. I explored a whole bunch of potential causes, but the culprit turned up when I took a closer look at netstat: # netstat -anp | fgrep dns tcp 0 0 192.168.0.35:53 0.0.0.0:* LISTEN 6348/dnsmasq udp 0 0 192.168.0.35:53 0.0.0.0:* 6348/dnsmasq udp 111356 0 192.168.0.35:53 0.0.0.0:* 4969/dnscache udp 0 0 127.0.0.10:53 0.0.0.0:* 2987/tinydns udp 0 0 0.0.0.0:67 0.0.0.0:* 6348/dnsmasq The Lenny upgrade apparently resurrected a dormant (and now completely removed) installation of djbdns (dnscache, tinydns). I think this set up a situation similar to what was described in this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310772 talking about how bind9, if configured to listen on all IPv4 and IPv6 addresses can block, if it receives a UDP packet on "an IPv4 address on which bind9 is NOT listening." The symptoms described are identical to what I observed. As if an OS buffer for the UDP packets filled up, and from that point forward, things didn't work. (The above netstat output reflects some changes I made to Dnsmasq's settings to get it to listen specifically on the LAN IP address, in an attempt to resolve the problem, but it didn't work. I had been running with the default (unset) settings. I did find that setting bind-interfaces in addition to listen-address fixed the problem, prior to finding the true case, but with djbdns removed, I've reverted back to the default settings.) I'm wondering of Dnsmasq could be enhanced to detect this kind of a conflict, and issue a warning? -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ From stunbox at gmail.com Fri Jul 3 09:26:42 2009 From: stunbox at gmail.com (Stun Box) Date: Fri, 3 Jul 2009 10:26:42 +0200 Subject: [Dnsmasq-discuss] CACHE DNS not working for MX type request Message-ID: Hi everybody, I've been looking on the internet but can't find the answer. Why my dnsmaq configuration does not cache MX DNS requests ? I can't find the good option that will fix that... Thanks in advance, G. From simon at thekelleys.org.uk Fri Jul 3 09:44:33 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Fri, 03 Jul 2009 09:44:33 +0100 Subject: [Dnsmasq-discuss] CACHE DNS not working for MX type request In-Reply-To: References: Message-ID: <4A4DC4F1.8020701@thekelleys.org.uk> Stun Box wrote: > Hi everybody, > > I've been looking on the internet but can't find the answer. > Why my dnsmaq configuration does not cache MX DNS requests ? I can't > find the good option that will fix that... > > Thanks in advance, > The reason is half historical and half design. Very very early versions of dnsmasq only handled A records and PTR records. The cache code was therefore written as a store if IP addresses and names, rather than a store of DNS records. The forwarding part of dnsmasq then got the ability to handle arbitrary records, but the cache was never changed, since 1) Almost everyone really only cares about caching A records (and AAAA records, if they're using IPv6) 2) The cache code is much more efficient (especially memory efficient) than a more general cache would be. Since dnsmasq runs on small hardware, that;s important. So that anwser to your question is that there's no option, and it would take a complete rewrite to provide one. HTH Simon. From tmetro+dnsmasq at gmail.com Fri Jul 3 22:13:28 2009 From: tmetro+dnsmasq at gmail.com (Tom Metro) Date: Fri, 03 Jul 2009 17:13:28 -0400 Subject: [Dnsmasq-discuss] multiple programs using UDP port 53 In-Reply-To: <4A4DC605.8010404@thekelleys.org.uk> References: <4A4D2754.6080300@gmail.com> <4A4DC605.8010404@thekelleys.org.uk> Message-ID: <4A4E7478.8060402@gmail.com> Simon Kelley wrote: > Tom Metro wrote: >> # netstat -anp | fgrep dns >> tcp 0 0 192.168.0.35:53 0.0.0.0:* LISTEN 6348/dnsmasq >> udp 0 0 192.168.0.35:53 0.0.0.0:* 6348/dnsmasq >> udp 111356 0 192.168.0.35:53 0.0.0.0:* 4969/dnscache >> udp 0 0 127.0.0.10:53 0.0.0.0:* 2987/tinydns >> udp 0 0 0.0.0.0:67 0.0.0.0:* 6348/dnsmasq >> >> (The above netstat output reflects some changes I made to Dnsmasq's >> settings to get it to listen specifically on the LAN IP address, in an >> attempt to resolve the problem, but it didn't work. I had been running >> with the default (unset) settings. I did find that setting >> bind-interfaces in addition to listen-address fixed the problem, prior >> to finding the true case, but with djbdns removed, I've reverted back >> to the default settings.) > > That netstat output makes it look like "bind-interfaces" is set in > dnsmasq, was that the case? I'm not absolutely positive, as I plucked that screen capture from a terminal history after the fact, but I'm pretty sure that it represents a point in time when bind-interfaces was unset, but listen-address was set. I can easily enough repeat the conditions with the exception of running djbdns. So here's the netstat with the default (and current) settings: # netstat -anp | fgrep dns tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 16281/dnsmasq tcp6 0 0 :::53 :::* LISTEN 16281/dnsmasq udp 0 0 0.0.0.0:53 0.0.0.0:* 16281/dnsmasq udp 0 0 0.0.0.0:67 0.0.0.0:* 16281/dnsmasq udp6 0 0 :::53 :::* 16281/dnsmasq With listen-address: # netstat -anp | fgrep dns tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 1862/dnsmasq tcp6 0 0 :::53 :::* LISTEN 1862/dnsmasq udp 0 0 0.0.0.0:53 0.0.0.0:* 1862/dnsmasq udp 0 0 0.0.0.0:67 0.0.0.0:* 1862/dnsmasq udp6 0 0 :::53 :::* 1862/dnsmasq With listen-address and bind-interfaces: # netstat -anp | fgrep dns tcp 0 0 192.168.0.35:53 0.0.0.0:* LISTEN 2062/dnsmasq udp 0 0 192.168.0.35:53 0.0.0.0:* 2062/dnsmasq udp 0 0 0.0.0.0:67 0.0.0.0:* 2062/dnsmasq This would seem to confirm your suspicion that bind-interfaces was in effect when that netstat was captured. > Do you still see the problem without "bind-interfaces" and with > dnsmasq bdound to 0.0.0.0:53? No, once the other DNS server was killed off, Dnsmasq worked normally. As I noted, I reverted to the original default Dnsmasq settings once I located the source of the problem. > Is there a known reason why dnscache would not be reading arriving > packets, thus eventually filling the kernel buffers associated with the > socket? Unknown. dnscache hasn't been used in several years. I could speculate that there may have been a problem with its logging, seeing as it uses its own logging system, but really it could have been anything, like a missing config file. I just checked the logs for it, which seem to have been functioning, but I see the "supervise" process process never died (and can't be killed, apparently - returns a "Operation not permitted" to a TERM signal), so it has overwritten the logs with a repeated message like: softlimit: fatal: unable to run /usr/bin/dnscache: file does not exist and: softlimit: fatal: unable to run /usr/bin/tinydns: file does not exist So unfortunately the original cause is lost. I take it the system calls permit more than one process to bind to a UDP port? If so, then what determines which process gets the packets? If you don't get direct feedback of the problem from the system calls, then I guess detecting this situation would require adding code to specifically look for it, would would probably be messy and fragile. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ From felix.schwarz at oss.schwarz.eu Sat Jul 4 21:10:29 2009 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Sat, 04 Jul 2009 22:10:29 +0200 Subject: [Dnsmasq-discuss] ethers should have precedence over client dhcp request Message-ID: <4A4FB735.4090207@oss.schwarz.eu> I have the situation that I changed the ip address in /etc/ethers. However when the client sends a DHCPREQUEST with its old address (because the lease is still valid) dnsmasq sends a DHCPACK and renews the lease. Therefore the client could use the ip indefinitely. Is that correct or did I misinterpreted my logs? What I would like to see is that /etc/ethers has precedence over the lease file. If a new DHCPDISCOVER / DHCPREQUEST comes in, dnsmasq should check the ethers and offer only the ip address which is written there. fs From felix.schwarz at oss.schwarz.eu Sat Jul 4 21:10:55 2009 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Sat, 04 Jul 2009 22:10:55 +0200 Subject: [Dnsmasq-discuss] dnsmasq should support duplicate ip addresses in /etc/ethers or warn about them Message-ID: <4A4FB74F.1060102@oss.schwarz.eu> How does dnsmasq behave if there are multiple lines in /etc/ethers which reference the same ip address (with different mac addresses)? It looks to me as if dnsmasq would just use the last one. I would like to see that both items would be valid (e.g. laptop with wlan+lan always gets the same ip without any client-side configuration a la client-id). If you don't like this, please add a warning while parsing /etc/ethers so that the administrator will be aware of this problem.... fs From carlos at fisica.ufpr.br Sun Jul 5 00:38:16 2009 From: carlos at fisica.ufpr.br (Carlos Carvalho) Date: Sat, 4 Jul 2009 20:38:16 -0300 Subject: [Dnsmasq-discuss] dnsmasq should support duplicate ip addresses in /etc/ethers or warn about them In-Reply-To: <4A4FB74F.1060102@oss.schwarz.eu> References: <4A4FB74F.1060102@oss.schwarz.eu> Message-ID: <19023.59368.26661.140722@fisica.ufpr.br> Felix Schwarz (felix.schwarz at oss.schwarz.eu) wrote on 4 July 2009 22:10: >How does dnsmasq behave if there are multiple lines in /etc/ethers which >reference the same ip address (with different mac addresses)? > >It looks to me as if dnsmasq would just use the last one. I would like to see >that both items would be valid (e.g. laptop with wlan+lan always gets the same >ip without any client-side configuration a la client-id). This can be done putting more than one mac address in the same dhcp-host line. It has the additional benefit of transitioning the same lease from one mac to the other. From ronf at timeheart.net Sun Jul 5 01:14:07 2009 From: ronf at timeheart.net (Ron Frederick) Date: Sat, 04 Jul 2009 17:14:07 -0700 Subject: [Dnsmasq-discuss] Best way to assign different static IPs on different VLANs? Message-ID: <4A4FF04F.50605@timeheart.net> Hello... I have been using dnsmasq for a number of years now and it has been working great. I recently rearranged my network slightly, though, and while I have the new configuration working again, I'm wondering if there's a better way to do what I'm trying to do. Basically, I have two subnets at home. One of them is a public /29 subnet provided by my ISP. The other is a local 192.168.1.0/24 network I use for internal hosts. I have dnsmasq running on a Linksys WRT54GS under OpenWRT. One of my hosts needs to be on both networks, so am I using VLANs on both the Linksys and the host for this. VLAN 1 on the Linksys is my public subnet and VLAN 2 is my private one. On both the Linksys and the dual-homed host, I use VLAN tagging to keep the private network traffic separate from the public traffic. What I'd like to do is have dnsmasq automatically assign a static public IP when it sees a request on VLAN 1 and a static private IP when it sees a request on VLAN 2, even though it will see the same MAC address in both requests. Can this be done? Normally, I just fill in MAC address information in /etc/ethers and host information in /etc/hosts and the static mapping is automatically made. However, since I can only associate a single name with the MAC address in /etc/ethers, I'm not sure how to configure the two different IPs I'd like to assign. For now, I have told the dual-homed host to use different client IDs (foo and foo-private) in its two requests, and then added entries like: dhcp-host=id:foo,foo dhcp-host=id:foo-private,foo-private By putting entries in /etc/hosts for foo and foo-private, the right thing seems to happen. However, it feels like there should be a way to do this without using client IDs, since dnsmasq knows which VLAN the request is arriving on. I've checked through the documentation and I don't see anything which covers this specific case. Is there a way to do what I'm looking to do? -- Ron Frederick ronf at timeheart.net From richardvoigt at gmail.com Sun Jul 5 02:47:29 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Sat, 4 Jul 2009 20:47:29 -0500 Subject: [Dnsmasq-discuss] Best way to assign different static IPs on different VLANs? In-Reply-To: <4A4FF04F.50605@timeheart.net> References: <4A4FF04F.50605@timeheart.net> Message-ID: <2e59e6970907041847s3c88cdc7q40f0d8f6c5f0dd3@mail.gmail.com> dnsmasq will only consider address matches from the same subnet as the local IP address(es) on the interface where the request arrived. But you may have to use dnsmasq configuration (dhcp-host) instead of /etc/ethers, because as you say /etc/ethers doesn't provide space for multiple IPs. dhcp-host can match based on MAC address instead of client id. On Sat, Jul 4, 2009 at 7:14 PM, Ron Frederick wrote: > Hello... > > I have been using dnsmasq for a number of years now and it has been > working great. I recently rearranged my network slightly, though, and > while I have the new configuration working again, I'm wondering if > there's a better way to do what I'm trying to do. > > Basically, I have two subnets at home. One of them is a public /29 > subnet provided by my ISP. The other is a local 192.168.1.0/24 network I > use for internal hosts. I have dnsmasq running on a Linksys WRT54GS > under OpenWRT. One of my hosts needs to be on both networks, so am I > using VLANs on both the Linksys and the host for this. VLAN 1 on the > Linksys is my public subnet and VLAN 2 is my private one. On both the > Linksys and the dual-homed host, I use VLAN tagging to keep the private > network traffic separate from the public traffic. > > What I'd like to do is have dnsmasq automatically assign a static public > IP when it sees a request on VLAN 1 and a static private IP when it sees > a request on VLAN 2, even though it will see the same MAC address in > both requests. Can this be done? Normally, I just fill in MAC address > information in /etc/ethers and host information in /etc/hosts and the > static mapping is automatically made. However, since I can only > associate a single name with the MAC address in /etc/ethers, I'm not > sure how to configure the two different IPs I'd like to assign. > > For now, I have told the dual-homed host to use different client IDs > (foo and foo-private) in its two requests, and then added entries like: > > dhcp-host=id:foo,foo > dhcp-host=id:foo-private,foo-private > > By putting entries in /etc/hosts for foo and foo-private, the right > thing seems to happen. However, it feels like there should be a way to > do this without using client IDs, since dnsmasq knows which VLAN the > request is arriving on. > > I've checked through the documentation and I don't see anything which > covers this specific case. Is there a way to do what I'm looking to do? > > -- > Ron Frederick > ronf at timeheart.net > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From felix.schwarz at oss.schwarz.eu Sun Jul 5 07:17:37 2009 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Sun, 05 Jul 2009 08:17:37 +0200 Subject: [Dnsmasq-discuss] dnsmasq should support duplicate ip addresses in /etc/ethers or warn about them In-Reply-To: <19023.59368.26661.140722@fisica.ufpr.br> References: <4A4FB74F.1060102@oss.schwarz.eu> <19023.59368.26661.140722@fisica.ufpr.br> Message-ID: <4A504581.8070000@oss.schwarz.eu> Carlos Carvalho wrote: > This can be done putting more than one mac address in the same dhcp-host > line. It has the additional benefit of transitioning the same lease > from one mac to the other. Something like this? --dhcp-host=,1.2.3.4 --dhcp-host=,1.2.3.4 However yesterday I spent some hours because I mistyped an IP address so that I had two lines with the same ip address. dnsmasq just used the last line which is where the trouble started for me. What would have helped me is a warning that stated that I have a duplicated line in /etc/ethers. fs From Hullen at t-online.de Sun Jul 5 06:56:00 2009 From: Hullen at t-online.de (Helmut Hullen) Date: 05 Jul 2009 07:56:00 +0200 Subject: [Dnsmasq-discuss] extension of configuration files Message-ID: Hallo all, I prefer dividing "/etc/dnsmasq.conf" into some separate files, using "conf-dir=/etc/dnsmasq.d". Then dnsmasq reads all files in this directory - fine. But (p.e.) slackware put sometimes configuration files with the extension *.new into such a directory and doesn't delete them if there is a file with the same name (but without this extension). Could dnsmasq exclude *.new files from reading? Some other programs do so. Viele Gruesse! Helmut From Hullen at t-online.de Sun Jul 5 13:56:00 2009 From: Hullen at t-online.de (Helmut Hullen) Date: 05 Jul 2009 14:56:00 +0200 Subject: [Dnsmasq-discuss] extension of configuration files In-Reply-To: Message-ID: Hallo, RevRagnarok, Du meintest am 05.07.09 zum Thema Re: [Dnsmasq-discuss] extension of configuration files: >> Could dnsmasq exclude *.new files from reading? Some other programs >> do so. > By extension, it should probably just ignore everything not *.conf, > since other package managers use other methods, e.g. .rpmnew and > .rpmold. Sounds reasonable. Please keep the traffic in the mailing list! Viele Gruesse! Helmut From ranceh at gmail.com Sun Jul 5 15:56:53 2009 From: ranceh at gmail.com (Rance Hall) Date: Sun, 5 Jul 2009 09:56:53 -0500 Subject: [Dnsmasq-discuss] extension of configuration files In-Reply-To: References: Message-ID: <845c0f80907050756q654cd093m449df483d87ff1d3@mail.gmail.com> On Sun, Jul 5, 2009 at 7:56 AM, Helmut Hullen wrote: > Hallo, RevRagnarok, > > Du meintest am 05.07.09 zum Thema Re: [Dnsmasq-discuss] extension of configuration files: > >>> Could dnsmasq exclude *.new files from reading? Some other programs >>> do so. > >> By extension, it should probably just ignore everything not *.conf, >> since other package managers use other methods, e.g. .rpmnew and >> .rpmold. > > Sounds reasonable. > Please keep the traffic in the mailing list! > > Viele Gruesse! > Helmut > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > I think this is a great idea but I don't think it belongs in dnsmasq proper. I think it makes the code base bigger for no real feature gain. This is something that could be handled in an init script stanza prior to actually launching dnsmasq. set a variable for the main config file parse it looking for config_dir if found, check contents for updated scripts (test will be different for each distro I suspect) mv the updated files to config_dir.update start dnsmasq the normal way If you did this in the init script then it would be much more flexible for per distro variations. Personally, I've never seen a distro actually populate the config_dir usually its commented out of the main config file Its ultimately up to Simon, but I've seen other comments from him that indicate code size is important for him as he knows that dnsmasq is used in embedded devices. I don't see embedded devices benefiting from this change. Just my $0.02 Rance From simon at thekelleys.org.uk Sun Jul 5 16:41:22 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Sun, 05 Jul 2009 16:41:22 +0100 Subject: [Dnsmasq-discuss] extension of configuration files In-Reply-To: <845c0f80907050756q654cd093m449df483d87ff1d3@mail.gmail.com> References: <845c0f80907050756q654cd093m449df483d87ff1d3@mail.gmail.com> Message-ID: <4A50C9A2.5080906@thekelleys.org.uk> Rance Hall wrote: > On Sun, Jul 5, 2009 at 7:56 AM, Helmut Hullen wrote: >> Hallo, RevRagnarok, >> >> Du meintest am 05.07.09 zum Thema Re: [Dnsmasq-discuss] extension of configuration files: >> >>>> Could dnsmasq exclude *.new files from reading? Some other programs >>>> do so. >>> By extension, it should probably just ignore everything not *.conf, >>> since other package managers use other methods, e.g. .rpmnew and >>> .rpmold. >> Sounds reasonable. >> Please keep the traffic in the mailing list! >> >> Viele Gruesse! >> Helmut >> >> _______________________________________________ >> Dnsmasq-discuss mailing list >> Dnsmasq-discuss at lists.thekelleys.org.uk >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >> > > I think this is a great idea but I don't think it belongs in dnsmasq > proper. I think it makes the code base bigger for no real feature > gain. This is something that could be handled in an init script > stanza prior to actually launching dnsmasq. > > set a variable for the main config file > parse it looking for config_dir > if found, check contents for updated scripts (test will be different > for each distro I suspect) > mv the updated files to config_dir.update > > start dnsmasq the normal way > > If you did this in the init script then it would be much more flexible > for per distro variations. > > Personally, I've never seen a distro actually populate the config_dir > usually its commented out of the main config file > > Its ultimately up to Simon, but I've seen other comments from him that > indicate code size is important for him as he knows that dnsmasq is > used in embedded devices. I don't see embedded devices benefiting > from this change. > I'd be in a stronger position to refuse to do this if the code didn't already weed out filenames which look like .file and file~ and #file#. I'm an emacs user and those last two are emacs droppings. I guess the problem is knowing _which_ files should be ignored ( how many conventions are there?) and not ignoring files which someone, somewhere, thinks are perfectly OK and should be used. Cheers, Simon. From Hullen at t-online.de Sun Jul 5 16:25:00 2009 From: Hullen at t-online.de (Helmut Hullen) Date: 05 Jul 2009 17:25:00 +0200 Subject: [Dnsmasq-discuss] extension of configuration files In-Reply-To: <845c0f80907050756q654cd093m449df483d87ff1d3@mail.gmail.com> Message-ID: Hallo, Rance, Du meintest am 05.07.09: >>>> Could dnsmasq exclude *.new files from reading? Some other >>>> programs do so. >>> By extension, it should probably just ignore everything not *.conf, >>> since other package managers use other methods, e.g. .rpmnew and >>> .rpmold. > I think this is a great idea but I don't think it belongs in dnsmasq > proper. I think it makes the code base bigger for no real feature > gain. ??? Instead of include $conf-dir/* there would be include $conf-dir/*.conf Nothing more to do. > This is something that could be handled in an init script > stanza prior to actually launching dnsmasq. > set a variable for the main config file > parse it looking for config_dir > if found, check contents for updated scripts (test will be different > for each distro I suspect) > mv the updated files to config_dir.update > start dnsmasq the normal way I may not write (and test, and debug) such a wrapper ... Viele Gruesse! Helmut From carlos at fisica.ufpr.br Sun Jul 5 17:12:50 2009 From: carlos at fisica.ufpr.br (Carlos Carvalho) Date: Sun, 5 Jul 2009 13:12:50 -0300 Subject: [Dnsmasq-discuss] dnsmasq should support duplicate ip addresses in /etc/ethers or warn about them In-Reply-To: <4A504581.8070000@oss.schwarz.eu> References: <4A4FB74F.1060102@oss.schwarz.eu> <19023.59368.26661.140722@fisica.ufpr.br> <4A504581.8070000@oss.schwarz.eu> Message-ID: <19024.53506.168093.948802@fisica.ufpr.br> Felix Schwarz (felix.schwarz at oss.schwarz.eu) wrote on 5 July 2009 08:17: >Carlos Carvalho wrote: >> This can be done putting more than one mac address in the same dhcp-host >> line. It has the additional benefit of transitioning the same lease >> from one mac to the other. > >Something like this? >--dhcp-host=,1.2.3.4 --dhcp-host=,1.2.3.4 No, in the same dhcp-host declaration. See the last paragraph in the dhcp-host entry of the manual. >However yesterday I spent some hours because I mistyped an IP address so that >I had two lines with the same ip address. dnsmasq just used the last line >which is where the trouble started for me. What would have helped me is a >warning that stated that I have a duplicated line in /etc/ethers. Yes, that'd be useful. From dnsmasq at lists.bod.org Sun Jul 5 17:18:49 2009 From: dnsmasq at lists.bod.org (Paul Chambers) Date: Sun, 05 Jul 2009 09:18:49 -0700 Subject: [Dnsmasq-discuss] extension of configuration files In-Reply-To: <4A50C9A2.5080906@thekelleys.org.uk> References: <845c0f80907050756q654cd093m449df483d87ff1d3@mail.gmail.com> <4A50C9A2.5080906@thekelleys.org.uk> Message-ID: <4A50D269.1010402@lists.bod.org> Simon Kelley wrote: > Rance Hall wrote: > >> On Sun, Jul 5, 2009 at 7:56 AM, Helmut Hullen wrote: >> >>> Hallo, RevRagnarok, >>> >>> Du meintest am 05.07.09 zum Thema Re: [Dnsmasq-discuss] extension of configuration files: >>> >>> >>>>> Could dnsmasq exclude *.new files from reading? Some other programs >>>>> do so. >>>>> >>>> By extension, it should probably just ignore everything not *.conf, >>>> since other package managers use other methods, e.g. .rpmnew and >>>> .rpmold. >>>> >>> Sounds reasonable. >>> Please keep the traffic in the mailing list! >>> >>> Viele Gruesse! >>> Helmut >>> >>> _______________________________________________ >>> Dnsmasq-discuss mailing list >>> Dnsmasq-discuss at lists.thekelleys.org.uk >>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >>> >>> >> I think this is a great idea but I don't think it belongs in dnsmasq >> proper. I think it makes the code base bigger for no real feature >> gain. This is something that could be handled in an init script >> stanza prior to actually launching dnsmasq. >> >> set a variable for the main config file >> parse it looking for config_dir >> if found, check contents for updated scripts (test will be different >> for each distro I suspect) >> mv the updated files to config_dir.update >> >> start dnsmasq the normal way >> >> If you did this in the init script then it would be much more flexible >> for per distro variations. >> >> Personally, I've never seen a distro actually populate the config_dir >> usually its commented out of the main config file >> >> Its ultimately up to Simon, but I've seen other comments from him that >> indicate code size is important for him as he knows that dnsmasq is >> used in embedded devices. I don't see embedded devices benefiting >> from this change. >> > I'd be in a stronger position to refuse to do this if the code didn't > already weed out filenames which look like .file and file~ and #file#. > I'm an emacs user and those last two are emacs droppings. I guess the > problem is knowing _which_ files should be ignored ( how many > conventions are there?) and not ignoring files which someone, somewhere, > thinks are perfectly OK and should be used. > I'm not in favor of having dnsmasq ignore config files - sounds like a trap for the unwary to me. I'd much rather see it done in an init script like Rance suggested - at least then it could be distro-specific (Fedora uses .rpmnew and .rpmsave, so seems like there's no consistency at all :). Having said that, if some logic were added that identified filenames that only differed by the addition of an extension, and then only ingested the one with the shortest name, perhaps that would behave well in the majority of cases? I don't really see the current implementation as 'broken', but if it's going to be 'fixed'... -- Paul From dnsmasq.list at michaelrack.de Sun Jul 5 17:15:06 2009 From: dnsmasq.list at michaelrack.de (Michael Rack) Date: Sun, 05 Jul 2009 18:15:06 +0200 Subject: [Dnsmasq-discuss] extension of configuration files In-Reply-To: <4A50C9A2.5080906@thekelleys.org.uk> References: <845c0f80907050756q654cd093m449df483d87ff1d3@mail.gmail.com> <4A50C9A2.5080906@thekelleys.org.uk> Message-ID: <4A50D18A.3000402@michaelrack.de> I think, there is a really easy solution: conf-dir should expect a expression at the end. Or a new attribute have to be added like "include". In Apache you can say include /etc/httpd/conf.d/*.conf now i am very flexible to include as many patterns as i need. Michael. Am 05.07.2009 17:41, schrieb Simon Kelley: > Rance Hall wrote: >> On Sun, Jul 5, 2009 at 7:56 AM, Helmut Hullen wrote: >>> Hallo, RevRagnarok, >>> >>> Du meintest am 05.07.09 zum Thema Re: [Dnsmasq-discuss] extension of configuration files: >>> >>>>> Could dnsmasq exclude *.new files from reading? Some other programs >>>>> do so. >>>> By extension, it should probably just ignore everything not *.conf, >>>> since other package managers use other methods, e.g. .rpmnew and >>>> .rpmold. >>> Sounds reasonable. >>> Please keep the traffic in the mailing list! >>> >>> Viele Gruesse! >>> Helmut >>> >>> _______________________________________________ >>> Dnsmasq-discuss mailing list >>> Dnsmasq-discuss at lists.thekelleys.org.uk >>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >>> >> I think this is a great idea but I don't think it belongs in dnsmasq >> proper. I think it makes the code base bigger for no real feature >> gain. This is something that could be handled in an init script >> stanza prior to actually launching dnsmasq. >> >> set a variable for the main config file >> parse it looking for config_dir >> if found, check contents for updated scripts (test will be different >> for each distro I suspect) >> mv the updated files to config_dir.update >> >> start dnsmasq the normal way >> >> If you did this in the init script then it would be much more flexible >> for per distro variations. >> >> Personally, I've never seen a distro actually populate the config_dir >> usually its commented out of the main config file >> >> Its ultimately up to Simon, but I've seen other comments from him that >> indicate code size is important for him as he knows that dnsmasq is >> used in embedded devices. I don't see embedded devices benefiting >> from this change. >> > > I'd be in a stronger position to refuse to do this if the code didn't > already weed out filenames which look like .file and file~ and #file#. > I'm an emacs user and those last two are emacs droppings. I guess the > problem is knowing _which_ files should be ignored ( how many > conventions are there?) and not ignoring files which someone, somewhere, > thinks are perfectly OK and should be used. > > > Cheers, > > Simon. > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss From ranceh at gmail.com Sun Jul 5 16:46:53 2009 From: ranceh at gmail.com (Rance Hall) Date: Sun, 5 Jul 2009 10:46:53 -0500 Subject: [Dnsmasq-discuss] extension of configuration files In-Reply-To: <4A50C9A2.5080906@thekelleys.org.uk> References: <845c0f80907050756q654cd093m449df483d87ff1d3@mail.gmail.com> <4A50C9A2.5080906@thekelleys.org.uk> Message-ID: <845c0f80907050846m5f80594md32c4c753ae2516a@mail.gmail.com> On Sun, Jul 5, 2009 at 10:41 AM, Simon Kelley wrote: > > I'd be in a stronger position to refuse to do this if the code didn't > already weed out filenames which look like .file and file~ and #file#. > I'm an emacs user and those last two are emacs droppings. I guess the > problem is knowing _which_ files should be ignored ( how many > conventions are there?) and not ignoring files which someone, somewhere, > thinks are perfectly OK and should be used. > Who knows how many conventions there are, and if you could list them all, that doesnt mean someone isnt free to come up with another one. Which is why I dont think this actually belongs in dnsmasq proper. And as far as the backup filename syntax goes that up to the editor, some editors let you turn off auto backups, and others let you configure the syntax you want. Trying to keep up with all possible choices here is a loosing battle. I'd prefer you spend your time on more fruitful pursuits. From simon at thekelleys.org.uk Sun Jul 5 20:38:39 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Sun, 05 Jul 2009 20:38:39 +0100 Subject: [Dnsmasq-discuss] dnsmasq should support duplicate ip addresses in /etc/ethers or warn about them In-Reply-To: <4A4FB74F.1060102@oss.schwarz.eu> References: <4A4FB74F.1060102@oss.schwarz.eu> Message-ID: <4A51013F.9010104@thekelleys.org.uk> Felix Schwarz wrote: > How does dnsmasq behave if there are multiple lines in /etc/ethers which > reference the same ip address (with different mac addresses)? > > It looks to me as if dnsmasq would just use the last one. I would like to see > that both items would be valid (e.g. laptop with wlan+lan always gets the same > ip without any client-side configuration a la client-id). If you don't like > this, please add a warning while parsing /etc/ethers so that the administrator > will be aware of this problem.... The lack of a warning is an oversight. I've fixed that. You have to be careful with this. If dnsmasq leases an IP address to a MAC address (say the wlan address of the laptop) for (say) 10 hours, and then the lan MAC address comes along then dnsmasq can't give the IP address to the lan MAC, because it already promised it to the wlan MAC for the next 10 hours. From two lines in /etc/ethers it has no way to know that they are the same machine. There is a way to tell dnsmasq to terminate a lease early and give the same IP to another MAC, you have to do dhcp-host=,, By putting both MACs on one line, you're telling dnsmasq that only one will be active at a time and that it's OK to dump a lease for one MAC to give it to the other one. This works with any number of MAC addresses, not just two. Cheers, Simon. From simon at thekelleys.org.uk Sun Jul 5 20:45:40 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Sun, 05 Jul 2009 20:45:40 +0100 Subject: [Dnsmasq-discuss] ethers should have precedence over client dhcp request In-Reply-To: <4A4FB735.4090207@oss.schwarz.eu> References: <4A4FB735.4090207@oss.schwarz.eu> Message-ID: <4A5102E4.9050308@thekelleys.org.uk> Felix Schwarz wrote: > I have the situation that I changed the ip address in /etc/ethers. However > when the client sends a DHCPREQUEST with its old address (because the lease is > still valid) dnsmasq sends a DHCPACK and renews the lease. Therefore the > client could use the ip indefinitely. Is that correct or did I misinterpreted > my logs? > > What I would like to see is that /etc/ethers has precedence over the lease > file. If a new DHCPDISCOVER / DHCPREQUEST comes in, dnsmasq should check the > ethers and offer only the ip address which is written there. > That's the designed behavior: dnsmasq should send a DHCPNAK when a client has a defined IP address and the client renews a lease for a different address. The DHCPNAK will force the client to go through the whole DISCOVER/REQUEST cycle. I suspect that your problems with duplicate IP addresses in /etc/ethers may have confused this, but if you have a clear case where it's not working, please let me have details and I'll check it out as a possble bug. Cheers, Simon. From richardvoigt at gmail.com Sun Jul 5 22:02:10 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Sun, 5 Jul 2009 16:02:10 -0500 Subject: [Dnsmasq-discuss] ethers should have precedence over client dhcp request In-Reply-To: <4A5102E4.9050308@thekelleys.org.uk> References: <4A4FB735.4090207@oss.schwarz.eu> <4A5102E4.9050308@thekelleys.org.uk> Message-ID: <2e59e6970907051402y5e8c3cet8fa7e664debb8eda@mail.gmail.com> aargh, gmail's deletion of the reply-to-all as default is driving me crazy. Resending: Local settings do take precedence over options in the dhcp request, but the content of /etc/ethers is cached in memory? Did you send dnsmasq a signal to ask it to re-read /etc/ethers? On Sun, Jul 5, 2009 at 2:45 PM, Simon Kelley wrote: > Felix Schwarz wrote: >> I have the situation that I changed the ip address in /etc/ethers. However >> when the client sends a DHCPREQUEST with its old address (because the lease is >> still valid) dnsmasq sends a DHCPACK and renews the lease. Therefore the >> client could use the ip indefinitely. Is that correct or did I misinterpreted >> my logs? >> >> What I would like to see is that /etc/ethers has precedence over the lease >> file. If a new DHCPDISCOVER / DHCPREQUEST comes in, dnsmasq should check the >> ethers and offer only the ip address which is written there. >> > That's the designed behavior: dnsmasq should send a DHCPNAK when a > client has a defined IP address and the client renews a lease for a > different address. The DHCPNAK will force the client to go through the > whole DISCOVER/REQUEST cycle. > > I suspect that your problems with duplicate IP addresses in /etc/ethers > may have confused this, but if you have a clear case where it's not > working, please let me have details and I'll check it out as a possble bug. > > Cheers, > > Simon. > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From carlos at fisica.ufpr.br Sun Jul 5 22:29:11 2009 From: carlos at fisica.ufpr.br (Carlos Carvalho) Date: Sun, 5 Jul 2009 18:29:11 -0300 Subject: [Dnsmasq-discuss] extension of configuration files In-Reply-To: <4A50C9A2.5080906@thekelleys.org.uk> References: <845c0f80907050756q654cd093m449df483d87ff1d3@mail.gmail.com> <4A50C9A2.5080906@thekelleys.org.uk> Message-ID: <19025.6951.324761.911117@fisica.ufpr.br> Simon Kelley (simon at thekelleys.org.uk) wrote on 5 July 2009 16:41: >I guess the problem is knowing _which_ files should be ignored ( how >many conventions are there?) and not ignoring files which someone, >somewhere, thinks are perfectly OK and should be used. That's clearly impossible. If you decide to do it there are only two possibilities: define the (only) extension in dnsmasq, or do it like apache, as Michael says. I think the later is too much bloat. I'd rather not have any exclusion but since you ruled this out we're left with the first alternative. What about just leaving it as it's now? :-) From richardvoigt at gmail.com Sun Jul 5 23:20:39 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Sun, 5 Jul 2009 17:20:39 -0500 Subject: [Dnsmasq-discuss] extension of configuration files In-Reply-To: <19025.6951.324761.911117@fisica.ufpr.br> References: <845c0f80907050756q654cd093m449df483d87ff1d3@mail.gmail.com> <4A50C9A2.5080906@thekelleys.org.uk> <19025.6951.324761.911117@fisica.ufpr.br> Message-ID: <2e59e6970907051520x3fed530fua92c95c99668954f@mail.gmail.com> On Sun, Jul 5, 2009 at 4:29 PM, Carlos Carvalho wrote: > Simon Kelley (simon at thekelleys.org.uk) wrote on 5 July 2009 16:41: > ?>I guess the problem is knowing _which_ files should be ignored ( how > ?>many conventions are there?) and not ignoring files which someone, > ?>somewhere, thinks are perfectly OK and should be used. > > That's clearly impossible. If you decide to do it there are only two > possibilities: define the (only) extension in dnsmasq, or do it like > apache, as Michael says. I think the later is too much bloat. I'd > rather not have any exclusion but since you ruled this out we're left > with the first alternative. > > What about just leaving it as it's now? :-) How about a compromise -- not a full wildcard syntax, but a user-controlled literal suffix match? e.g. conf-dir-suffix=.conf Or you could let other programs do the heavy lifting and have a just-in-time config command whose output is processed. Dangerous because it has to be run before forking as nobody, but very powerful: jit-config=/bin/sh -c "cat /etc/conf.d/dnsmasq/*.conf" > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From ranceh at gmail.com Mon Jul 6 02:18:21 2009 From: ranceh at gmail.com (Rance Hall) Date: Sun, 5 Jul 2009 20:18:21 -0500 Subject: [Dnsmasq-discuss] extension of configuration files In-Reply-To: <2e59e6970907051520x3fed530fua92c95c99668954f@mail.gmail.com> References: <845c0f80907050756q654cd093m449df483d87ff1d3@mail.gmail.com> <4A50C9A2.5080906@thekelleys.org.uk> <19025.6951.324761.911117@fisica.ufpr.br> <2e59e6970907051520x3fed530fua92c95c99668954f@mail.gmail.com> Message-ID: <845c0f80907051818p204436deqfdafbfe3d702163c@mail.gmail.com> On Sun, Jul 5, 2009 at 5:20 PM, richardvoigt at gmail.com wrote: > How about a compromise -- not a full wildcard syntax, but a > user-controlled literal suffix match? ?e.g. > > conf-dir-suffix=.conf > > Or you could let other programs do the heavy lifting and have a > just-in-time config command whose output is processed. ?Dangerous > because it has to be run before forking as nobody, but very powerful: > > jit-config=/bin/sh -c "cat /etc/conf.d/dnsmasq/*.conf" > Just a couple of thoughts and I'll let Simon finish digesting this thread. I have an objection to the apache multiple includes approach. I think that the only way to make room for this is to rip out the current behavior of accommodating for the various emacs patterns Simon mentioned earlier in the thread to make room for this. I question the need for the apache include approach since apache will let you specify more than one include statement. Dnsmasq has few enough options that a single directory with multiple files is really sufficient. the conf-dir-suffix idea really seems to be the most flexible, and the easiest to add in the current mix. From Hullen at t-online.de Mon Jul 6 07:11:00 2009 From: Hullen at t-online.de (Helmut Hullen) Date: 06 Jul 2009 08:11:00 +0200 Subject: [Dnsmasq-discuss] extension of configuration files In-Reply-To: <19025.6951.324761.911117@fisica.ufpr.br> Message-ID: Hallo, Carlos, Du meintest am 05.07.09: >> I guess the problem is knowing _which_ files should be ignored ( how >> many conventions are there?) and not ignoring files which someone, >> somewhere, thinks are perfectly OK and should be used. > That's clearly impossible. If you decide to do it there are only two > possibilities: define the (only) extension in dnsmasq, or do it like > apache, as Michael says. I think the later is too much bloat. I'd > rather not have any exclusion but since you ruled this out we're left > with the first alternative. If dnsmasq had defined "allowed extensions" from the beginning there would be no problem, but it hasn't. And therefore every user may have declared his own extensions (or no one). Therefor dnsmasq cannot change its behaviour - I had forgotten this small problem ... > What about just leaving it as it's now? :-) Under my slackware installation I'll write my special slackware extension watcher ... it first has to look what's the name of "conf- dir". Ugly. Viele Gruesse! Helmut From Hullen at t-online.de Mon Jul 6 07:17:00 2009 From: Hullen at t-online.de (Helmut Hullen) Date: 06 Jul 2009 08:17:00 +0200 Subject: [Dnsmasq-discuss] extension of configuration files In-Reply-To: <2e59e6970907051520x3fed530fua92c95c99668954f@mail.gmail.com> Message-ID: Hallo, richardvoigt at gmail.com, Du meintest am 05.07.09: >> What about just leaving it as it's now? :-) > How about a compromise -- not a full wildcard syntax, but a > user-controlled literal suffix match? e.g. > conf-dir-suffix=.conf And then many old installations which have files with no extensions get problems ... Perhaps something like either no extension or extension = .conf may solve the most problems. > Or you could let other programs do the heavy lifting and have a > just-in-time config command whose output is processed. Dangerous > because it has to be run before forking as nobody, but very powerful: > jit-config=/bin/sh -c "cat /etc/conf.d/dnsmasq/*.conf" My distribution (slackware) has no "/etc/conf.d" directory - that's the second problem. Each user (sysadm) can define his (or her) own "conf- dir". Viele Gruesse! Helmut From dnsmasq.list at michaelrack.de Mon Jul 6 08:46:21 2009 From: dnsmasq.list at michaelrack.de (Michael Rack) Date: Mon, 06 Jul 2009 09:46:21 +0200 Subject: [Dnsmasq-discuss] ethers should have precedence over client dhcp request In-Reply-To: <4A5102E4.9050308@thekelleys.org.uk> References: <4A4FB735.4090207@oss.schwarz.eu> <4A5102E4.9050308@thekelleys.org.uk> Message-ID: <4A51ABCD.6030003@michaelrack.de> Am 05.07.2009 21:45, schrieb Simon Kelley: > Felix Schwarz wrote: > >> I have the situation that I changed the ip address in /etc/ethers. However >> when the client sends a DHCPREQUEST with its old address (because the lease is >> still valid) dnsmasq sends a DHCPACK and renews the lease. Therefore the >> client could use the ip indefinitely. Is that correct or did I misinterpreted >> my logs? >> >> What I would like to see is that /etc/ethers has precedence over the lease >> file. If a new DHCPDISCOVER / DHCPREQUEST comes in, dnsmasq should check the >> ethers and offer only the ip address which is written there. >> >> > That's the designed behavior: dnsmasq should send a DHCPNAK when a > client has a defined IP address and the client renews a lease for a > different address. The DHCPNAK will force the client to go through the > whole DISCOVER/REQUEST cycle. > > I suspect that your problems with duplicate IP addresses in /etc/ethers > may have confused this, but if you have a clear case where it's not > working, please let me have details and I'll check it out as a possble bug. > > Cheers, > > Simon. > Hi Simon, i have the same probleme here. I just plugged in the network-cable to my VoIP-Phone (snom 360). Snom discovered for an ip-address and dnsmasq gave it a free address in the dhcp-pool. After that, i added the mac-address to the dhcp-host-addresses and set the ip-address to a different one. Snom 360 allways got DHCPACK for requesting the old ip-address. I had to delete the dhcp-lease-file-entry and restart dnsmasq. Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090706/9221ce0e/attachment.htm From simon at thekelleys.org.uk Mon Jul 6 14:42:28 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Mon, 06 Jul 2009 14:42:28 +0100 Subject: [Dnsmasq-discuss] extension of configuration files In-Reply-To: References: Message-ID: <4A51FF44.90305@thekelleys.org.uk> Helmut Hullen wrote: > Hallo, Carlos, > > Du meintest am 05.07.09: > >>> I guess the problem is knowing _which_ files should be ignored ( how >>> many conventions are there?) and not ignoring files which someone, >>> somewhere, thinks are perfectly OK and should be used. > >> That's clearly impossible. If you decide to do it there are only two >> possibilities: define the (only) extension in dnsmasq, or do it like >> apache, as Michael says. I think the later is too much bloat. I'd >> rather not have any exclusion but since you ruled this out we're left >> with the first alternative. > > If dnsmasq had defined "allowed extensions" from the beginning there > would be no problem, but it hasn't. And therefore every user may have > declared his own extensions (or no one). Therefor dnsmasq cannot change > its behaviour - I had forgotten this small problem ... > >> What about just leaving it as it's now? :-) > > Under my slackware installation I'll write my special slackware > extension watcher ... it first has to look what's the name of "conf- > dir". Ugly. > There's an alternative which is backwards compatible: extend the --conf-dir option optionally allow extensions which should _NOT_ be used, so the correct form to solve the initial problem would be --conf-dir=/etc/dnsmasq.d,.new I guess that for completeness, more than one extension should be allowed. That would meant that (for instance) the Debian dnsmasq package, which automatically reads /etc/dnsmasq.d for config fragments dropped by other packages, could ignore *.dpkg-dist *.dpkg-old and *.dpkg-new. That's a useful improvement. Cheers, Simon. From Hullen at t-online.de Mon Jul 6 14:59:00 2009 From: Hullen at t-online.de (Helmut Hullen) Date: 06 Jul 2009 15:59:00 +0200 Subject: [Dnsmasq-discuss] extension of configuration files In-Reply-To: <4A51FF44.90305@thekelleys.org.uk> Message-ID: Hallo, Simon, Du meintest am 06.07.09: >> Under my slackware installation I'll write my special slackware >> extension watcher ... it first has to look what's the name of "conf- >> dir". Ugly. > There's an alternative which is backwards compatible: extend the > --conf-dir option optionally allow extensions which should _NOT_ be > used, so the correct form to solve the initial problem would be > --conf-dir=/etc/dnsmasq.d,.new > I guess that for completeness, more than one extension should be > allowed. Sounds very good - thank you! Viele Gruesse! Helmut From richardvoigt at gmail.com Mon Jul 6 15:15:01 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Mon, 6 Jul 2009 09:15:01 -0500 Subject: [Dnsmasq-discuss] extension of configuration files In-Reply-To: References: <2e59e6970907051520x3fed530fua92c95c99668954f@mail.gmail.com> Message-ID: <2e59e6970907060715p2fa4052fw5da01eb28ccb9c63@mail.gmail.com> On Mon, Jul 6, 2009 at 1:17 AM, Helmut Hullen wrote: > Hallo, richardvoigt at gmail.com, > > Du meintest am 05.07.09: > >>> What about just leaving it as it's now? :-) > >> How about a compromise -- not a full wildcard syntax, but a >> user-controlled literal suffix match? ?e.g. > >> conf-dir-suffix=.conf > > And then many old installations which have files with no extensions get > problems ... > > Perhaps something like > > ? ? ? ?either no extension > ? ? ? ?or > ? ? ? ?extension = .conf > > may solve the most problems. > >> Or you could let other programs do the heavy lifting and have a >> just-in-time config command whose output is processed. ?Dangerous >> because it has to be run before forking as nobody, but very powerful: > >> jit-config=/bin/sh -c "cat /etc/conf.d/dnsmasq/*.conf" > > My distribution (slackware) has no "/etc/conf.d" directory - that's the > second problem. Each user (sysadm) can define his (or her) own "conf- > dir". > > Viele Gruesse! > Helmut I guess I didn't explain these were meant to be examples of configuration options, that the user could edit to suit themselves, just like every other configuration option dnsmasq provides. If slackware doesn't have /etc/conf.d then supply your own command for finding the configuration. And the default would be no external configuration directory, just like it is today. But Simon's solution of a user-defined list of suffixes to exclude seems an ideal tradeoff between flexibility and complexity. From richardvoigt at gmail.com Mon Jul 6 15:16:49 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Mon, 6 Jul 2009 09:16:49 -0500 Subject: [Dnsmasq-discuss] ethers should have precedence over client dhcp request In-Reply-To: <4A51ABCD.6030003@michaelrack.de> References: <4A4FB735.4090207@oss.schwarz.eu> <4A5102E4.9050308@thekelleys.org.uk> <4A51ABCD.6030003@michaelrack.de> Message-ID: <2e59e6970907060716y38866fd0t5e785df9706de3a6@mail.gmail.com> On Mon, Jul 6, 2009 at 2:46 AM, Michael Rack wrote: > Am 05.07.2009 21:45, schrieb Simon Kelley: > > Felix Schwarz wrote: > > > I have the situation that I changed the ip address in /etc/ethers. However > when the client sends a DHCPREQUEST with its old address (because the lease > is > still valid) dnsmasq sends a DHCPACK and renews the lease. Therefore the > client could use the ip indefinitely. Is that correct or did I > misinterpreted > my logs? > > What I would like to see is that /etc/ethers has precedence over the lease > file. If a new DHCPDISCOVER / DHCPREQUEST comes in, dnsmasq should check the > ethers and offer only the ip address which is written there. > > > > That's the designed behavior: dnsmasq should send a DHCPNAK when a > client has a defined IP address and the client renews a lease for a > different address. The DHCPNAK will force the client to go through the > whole DISCOVER/REQUEST cycle. > > I suspect that your problems with duplicate IP addresses in /etc/ethers > may have confused this, but if you have a clear case where it's not > working, please let me have details and I'll check it out as a possble bug. > > Cheers, > > Simon. > > > Hi Simon, > > i have the same probleme here. I just plugged in the network-cable to my > VoIP-Phone (snom 360). Snom discovered for an ip-address and dnsmasq gave it > a free address in the dhcp-pool. After that, i added the mac-address to the > dhcp-host-addresses and set the ip-address to a different one. Snom 360 > allways got DHCPACK for requesting the old ip-address. I had to delete the > dhcp-lease-file-entry and restart dnsmasq. I don't think you had to delete the lease entry, you definitely needed to restart dnsmasq because the configuration is cached at startup. There's a signal for re-reading some files but not the main configuration. > > Michael. > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > From dnsmasq.list at michaelrack.de Mon Jul 6 16:37:12 2009 From: dnsmasq.list at michaelrack.de (Michael Rack) Date: Mon, 06 Jul 2009 17:37:12 +0200 Subject: [Dnsmasq-discuss] ethers should have precedence over client dhcp request In-Reply-To: <2e59e6970907060716y38866fd0t5e785df9706de3a6@mail.gmail.com> References: <4A4FB735.4090207@oss.schwarz.eu> <4A5102E4.9050308@thekelleys.org.uk> <4A51ABCD.6030003@michaelrack.de> <2e59e6970907060716y38866fd0t5e785df9706de3a6@mail.gmail.com> Message-ID: <4A521A28.6020503@michaelrack.de> Hi Richard, i am an advanced user :-D You don't have to tell me, that i have to restart dnsmasq in order to reload the configuration-data ;-) Of course, dnsmasq was restarted after changing the configuration, but no ip-change on the client was affected. Michael. >> Hi Simon, >> >> i have the same probleme here. I just plugged in the network-cable to my >> VoIP-Phone (snom 360). Snom discovered for an ip-address and dnsmasq gave it >> a free address in the dhcp-pool. After that, i added the mac-address to the >> dhcp-host-addresses and set the ip-address to a different one. Snom 360 >> allways got DHCPACK for requesting the old ip-address. I had to delete the >> dhcp-lease-file-entry and restart dnsmasq. > > I don't think you had to delete the lease entry, you definitely needed > to restart dnsmasq because the configuration is cached at startup. > There's a signal for re-reading some files but not the main > configuration. From simon at thekelleys.org.uk Mon Jul 6 17:14:12 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Mon, 06 Jul 2009 17:14:12 +0100 Subject: [Dnsmasq-discuss] ethers should have precedence over client dhcp request In-Reply-To: <4A521A28.6020503@michaelrack.de> References: <4A4FB735.4090207@oss.schwarz.eu> <4A5102E4.9050308@thekelleys.org.uk> <4A51ABCD.6030003@michaelrack.de> <2e59e6970907060716y38866fd0t5e785df9706de3a6@mail.gmail.com> <4A521A28.6020503@michaelrack.de> Message-ID: <4A5222D4.6050700@thekelleys.org.uk> Michael Rack wrote: > Hi Richard, > > i am an advanced user :-D You don't have to tell me, that i have to > restart dnsmasq in order to reload the configuration-data ;-) > > Of course, dnsmasq was restarted after changing the configuration, but > no ip-change on the client was affected. > > Michael. > > >>> Hi Simon, >>> >>> i have the same probleme here. I just plugged in the network-cable to my >>> VoIP-Phone (snom 360). Snom discovered for an ip-address and dnsmasq >>> gave it >>> a free address in the dhcp-pool. After that, i added the mac-address >>> to the >>> dhcp-host-addresses and set the ip-address to a different one. Snom 360 >>> allways got DHCPACK for requesting the old ip-address. I had to >>> delete the >>> dhcp-lease-file-entry and restart dnsmasq. >> >> I don't think you had to delete the lease entry, you definitely needed >> to restart dnsmasq because the configuration is cached at startup. >> There's a signal for re-reading some files but not the main >> configuration. > Well I just tried it here Client (Freebsd running under Qemu, dhclient) rebooted and picked up existing address-pool lease: Jul 6 16:53:27 thekelleys dnsmasq-dhcp[5110]: DHCPDISCOVER(eth2) 192.168.3.148 52:54:00:12:34:56 Jul 6 16:53:27 thekelleys dnsmasq-dhcp[5110]: DHCPOFFER(eth2) 192.168.3.148 52:54:00:12:34:56 Jul 6 16:53:30 thekelleys dnsmasq-dhcp[5110]: DHCPREQUEST(eth2) 192.168.3.148 52:54:00:12:34:56 Jul 6 16:53:30 thekelleys dnsmasq-dhcp[5110]: DHCPACK(eth2) 192.168.3.148 52:54:00:12:34:56 freebsd Then I added dhcp-host=52:54:00:12:34:56,192.168.3.130 to /etc/dnsmasq and restarted dnsmasq, killed dhclient and re-ran it. Jul 6 16:57:10 thekelleys dnsmasq-dhcp[6046]: DHCPREQUEST(eth2) 192.168.3.148 52:54:00:12:34:56 Jul 6 16:57:10 thekelleys dnsmasq-dhcp[6046]: DHCPNAK(eth2) 192.168.3.148 52:54:00:12:34:56 static lease available Jul 6 16:57:10 thekelleys dnsmasq-dhcp[6046]: DHCPDISCOVER(eth2) 52:54:00:12:34:56 Jul 6 16:57:10 thekelleys dnsmasq-dhcp[6046]: DHCPOFFER(eth2) 192.168.3.130 52:54:00:12:34:56 Jul 6 16:57:13 thekelleys dnsmasq-dhcp[6046]: DHCPREQUEST(eth2) 192.168.3.130 52:54:00:12:34:56 Jul 6 16:57:13 thekelleys dnsmasq-dhcp[6046]: DHCPACK(eth2) 192.168.3.130 52:54:00:12:34:56 freebsd Finally I removed dhcp-host and added read-ethers, and put 52:54:00:12:34:56 192.168.3.119 in /etc/ethers and restarted dhclient again Jul 6 17:00:20 thekelleys dnsmasq-dhcp[6449]: DHCPREQUEST(eth2) 192.168.3.130 52:54:00:12:34:56 Jul 6 17:00:20 thekelleys dnsmasq-dhcp[6449]: DHCPNAK(eth2) 192.168.3.130 52:54:00:12:34:56 static lease available Jul 6 17:00:20 thekelleys dnsmasq-dhcp[6449]: DHCPDISCOVER(eth2) 52:54:00:12:34:56 Jul 6 17:00:20 thekelleys dnsmasq-dhcp[6449]: DHCPOFFER(eth2) 192.168.3.119 52:54:00:12:34:56 Jul 6 17:00:23 thekelleys dnsmasq-dhcp[6449]: DHCPREQUEST(eth2) 192.168.3.119 52:54:00:12:34:56 Jul 6 17:00:23 thekelleys dnsmasq-dhcp[6449]: DHCPACK(eth2) 192.168.3.119 52:54:00:12:34:56 freebsd Can Michael or Felix repeat the same test with their clients, and if it fails, get some packet captures of the DHCP packets Cheers, Simon From simon at thekelleys.org.uk Mon Jul 6 17:16:44 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Mon, 06 Jul 2009 17:16:44 +0100 Subject: [Dnsmasq-discuss] extension of configuration files In-Reply-To: References: Message-ID: <4A52236C.9050202@thekelleys.org.uk> Helmut Hullen wrote: > Hallo, Simon, > > Du meintest am 06.07.09: > >>> Under my slackware installation I'll write my special slackware >>> extension watcher ... it first has to look what's the name of "conf- >>> dir". Ugly. > >> There's an alternative which is backwards compatible: extend the >> --conf-dir option optionally allow extensions which should _NOT_ be >> used, so the correct form to solve the initial problem would be > >> --conf-dir=/etc/dnsmasq.d,.new > >> I guess that for completeness, more than one extension should be >> allowed. > > Sounds very good - thank you! > Try this: http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.50test6.tar.gz which implements it (many extensions). Cheers, Simon. From felix.schwarz at oss.schwarz.eu Mon Jul 6 17:52:22 2009 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Mon, 06 Jul 2009 21:52:22 +0500 Subject: [Dnsmasq-discuss] ethers should have precedence over client dhcp request In-Reply-To: <4A5222D4.6050700@thekelleys.org.uk> References: <4A4FB735.4090207@oss.schwarz.eu> <4A5102E4.9050308@thekelleys.org.uk> <4A51ABCD.6030003@michaelrack.de> <2e59e6970907060716y38866fd0t5e785df9706de3a6@mail.gmail.com> <4A521A28.6020503@michaelrack.de> <4A5222D4.6050700@thekelleys.org.uk> Message-ID: <4A522BC6.8010901@oss.schwarz.eu> Am 06.07.2009 21:14, schrieb Simon Kelley: > Can Michael or Felix repeat the same test with their clients, and if it > fails, get some packet captures of the DHCP packets I'll check when I'm home again (so end of this week). fs From Hullen at t-online.de Mon Jul 6 18:39:00 2009 From: Hullen at t-online.de (Helmut Hullen) Date: 06 Jul 2009 19:39:00 +0200 Subject: [Dnsmasq-discuss] extension of configuration files In-Reply-To: <4A52236C.9050202@thekelleys.org.uk> Message-ID: Hallo, Simon, Du meintest am 06.07.09: >>> --conf-dir=/etc/dnsmasq.d,.new >> >>> I guess that for completeness, more than one extension should be >>> allowed. > http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.50test6.tar.gz > which implements it (many extensions). Works like a charm - thank you! One more problem solved. Viele Gruesse! Helmut From ronf at timeheart.net Mon Jul 6 19:38:16 2009 From: ronf at timeheart.net (Ron Frederick) Date: Mon, 06 Jul 2009 11:38:16 -0700 Subject: [Dnsmasq-discuss] Best way to assign different static IPs on different VLANs? In-Reply-To: <2e59e6970907041847s3c88cdc7q40f0d8f6c5f0dd3@mail.gmail.com> References: <4A4FF04F.50605@timeheart.net> <2e59e6970907041847s3c88cdc7q40f0d8f6c5f0dd3@mail.gmail.com> Message-ID: <4A524498.4040700@timeheart.net> Hi Richard... On 7/4/09 6:47 PM, richardvoigt at gmail.com wrote: > dnsmasq will only consider address matches from the same subnet as the > local IP address(es) on the interface where the request arrived. > > But you may have to use dnsmasq configuration (dhcp-host) instead of > /etc/ethers, because as you say /etc/ethers doesn't provide space for > multiple IPs. dhcp-host can match based on MAC address instead of > client id. > Thanks for the suggestion. This is actually the first thing I tried, but it didn't work. I think the reason is that the later dhcp_host line overrides the earlier one when they both have the same MAC address listed. What you suggest would have worked fine (with no special configuration) if I was willing to accept a dynamic IP, but it won't work for static IPs. It worked with client IDs because I was able to make the names different, preventing the rules from clashing with one another. After doing some more reading, I think the option I need is the "dhcp-fqdn" option in dnsmasq 2.46, possibly combined with the support there for the ability to associate domains with specific subnets. Unfortunately, I'm currently running an older release of dnsmasq (2.35) on my Linksys router, so I've been unable to try this yet. If I'm reading things right, though, this would let me put the unqualified name in /etc/ethers and have qualified names in two different domains in /etc/hosts and have dnsmasq assign the right IP depending on which domain was associated with the subnet the request arrived on. Can anyone confirm this for me? Is there any way to get this kind of behavior with pre-2.46 dnsmasq? It looked to me at one point like "localise-queries" might have been enough here, but that didn't seem to be enough. > On Sat, Jul 4, 2009 at 7:14 PM, Ron Frederick wrote: > >> Hello... >> >> I have been using dnsmasq for a number of years now and it has been >> working great. I recently rearranged my network slightly, though, and >> while I have the new configuration working again, I'm wondering if >> there's a better way to do what I'm trying to do. >> >> Basically, I have two subnets at home. One of them is a public /29 >> subnet provided by my ISP. The other is a local 192.168.1.0/24 network I >> use for internal hosts. I have dnsmasq running on a Linksys WRT54GS >> under OpenWRT. One of my hosts needs to be on both networks, so am I >> using VLANs on both the Linksys and the host for this. VLAN 1 on the >> Linksys is my public subnet and VLAN 2 is my private one. On both the >> Linksys and the dual-homed host, I use VLAN tagging to keep the private >> network traffic separate from the public traffic. >> >> What I'd like to do is have dnsmasq automatically assign a static public >> IP when it sees a request on VLAN 1 and a static private IP when it sees >> a request on VLAN 2, even though it will see the same MAC address in >> both requests. Can this be done? Normally, I just fill in MAC address >> information in /etc/ethers and host information in /etc/hosts and the >> static mapping is automatically made. However, since I can only >> associate a single name with the MAC address in /etc/ethers, I'm not >> sure how to configure the two different IPs I'd like to assign. >> >> For now, I have told the dual-homed host to use different client IDs >> (foo and foo-private) in its two requests, and then added entries like: >> >> dhcp-host=id:foo,foo >> dhcp-host=id:foo-private,foo-private >> >> By putting entries in /etc/hosts for foo and foo-private, the right >> thing seems to happen. However, it feels like there should be a way to >> do this without using client IDs, since dnsmasq knows which VLAN the >> request is arriving on. >> >> I've checked through the documentation and I don't see anything which >> covers this specific case. Is there a way to do what I'm looking to do? >> -- Ron Frederick ronf at timeheart.net From richardvoigt at gmail.com Mon Jul 6 20:56:08 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Mon, 6 Jul 2009 14:56:08 -0500 Subject: [Dnsmasq-discuss] Best way to assign different static IPs on different VLANs? In-Reply-To: <4A524498.4040700@timeheart.net> References: <4A4FF04F.50605@timeheart.net> <2e59e6970907041847s3c88cdc7q40f0d8f6c5f0dd3@mail.gmail.com> <4A524498.4040700@timeheart.net> Message-ID: <2e59e6970907061256n7c4d8cbaj90fe42fbd204ba43@mail.gmail.com> On Mon, Jul 6, 2009 at 1:38 PM, Ron Frederick wrote: > Hi Richard... > > On 7/4/09 6:47 PM, richardvoigt at gmail.com wrote: >> dnsmasq will only consider address matches from the same subnet as the >> local IP address(es) on the interface where the request arrived. >> >> But you may have to use dnsmasq configuration (dhcp-host) instead of >> /etc/ethers, because as you say /etc/ethers doesn't provide space for >> multiple IPs. ?dhcp-host can match based on MAC address instead of >> client id. >> > > Thanks for the suggestion. This is actually the first thing I tried, but > it didn't work. I think the reason is that the later dhcp_host line > overrides the earlier one when they both have the same MAC address > listed. What you suggest would have worked fine (with no special > configuration) if I was willing to accept a dynamic IP, but it won't > work for static IPs. It worked with client IDs because I was able to > make the names different, preventing the rules from clashing with one > another. > > After doing some more reading, I think the option I need is the > "dhcp-fqdn" option in dnsmasq 2.46, possibly combined with the support > there for the ability to associate domains with specific subnets. > Unfortunately, I'm currently running an older release of dnsmasq (2.35) > on my Linksys router, so I've been unable to try this yet. If I'm > reading things right, though, this would let me put the unqualified name > in /etc/ethers and have qualified names in two different domains in > /etc/hosts and have dnsmasq assign the right IP depending on which > domain was associated with the subnet the request arrived on. Can anyone > confirm this for me? > > Is there any way to get this kind of behavior with pre-2.46 dnsmasq? It > looked to me at one point like "localise-queries" might have been enough > here, but that didn't seem to be enough. Worst case scenario, you could run separate instances of dnsmasq, one for each VLAN. Then each would have its own configuration file and distinct sets of dhcp-host settings. From ronf at timeheart.net Wed Jul 8 01:48:34 2009 From: ronf at timeheart.net (Ron Frederick) Date: Tue, 07 Jul 2009 17:48:34 -0700 Subject: [Dnsmasq-discuss] Best way to assign different static IPs on different VLANs? In-Reply-To: <2e59e6970907061256n7c4d8cbaj90fe42fbd204ba43@mail.gmail.com> References: <4A4FF04F.50605@timeheart.net> <2e59e6970907041847s3c88cdc7q40f0d8f6c5f0dd3@mail.gmail.com> <4A524498.4040700@timeheart.net> <2e59e6970907061256n7c4d8cbaj90fe42fbd204ba43@mail.gmail.com> Message-ID: <4A53ECE2.9090700@timeheart.net> On 7/6/09 12:56 PM, richardvoigt at gmail.com wrote: > On Mon, Jul 6, 2009 at 1:38 PM, Ron Frederick wrote: > >> On 7/4/09 6:47 PM, richardvoigt at gmail.com wrote: >> >>> dnsmasq will only consider address matches from the same subnet as the >>> local IP address(es) on the interface where the request arrived. >>> >>> But you may have to use dnsmasq configuration (dhcp-host) instead of >>> /etc/ethers, because as you say /etc/ethers doesn't provide space for >>> multiple IPs. dhcp-host can match based on MAC address instead of >>> client id. >>> >>> >> Thanks for the suggestion. This is actually the first thing I tried, but >> it didn't work. I think the reason is that the later dhcp_host line >> overrides the earlier one when they both have the same MAC address >> listed. What you suggest would have worked fine (with no special >> configuration) if I was willing to accept a dynamic IP, but it won't >> work for static IPs. It worked with client IDs because I was able to >> make the names different, preventing the rules from clashing with one >> another. >> >> After doing some more reading, I think the option I need is the >> "dhcp-fqdn" option in dnsmasq 2.46, possibly combined with the support >> there for the ability to associate domains with specific subnets. >> Unfortunately, I'm currently running an older release of dnsmasq (2.35) >> on my Linksys router, so I've been unable to try this yet. If I'm >> reading things right, though, this would let me put the unqualified name >> in /etc/ethers and have qualified names in two different domains in >> /etc/hosts and have dnsmasq assign the right IP depending on which >> domain was associated with the subnet the request arrived on. Can anyone >> confirm this for me? >> >> Is there any way to get this kind of behavior with pre-2.46 dnsmasq? It >> looked to me at one point like "localise-queries" might have been enough >> here, but that didn't seem to be enough. >> > > Worst case scenario, you could run separate instances of dnsmasq, one > for each VLAN. Then each would have its own configuration file and > distinct sets of dhcp-host settings. > That's true, but I'd then have to split things out into multiple hosts files for each instance, or just move away from that entirely and keep everything in the config file. I was really hoping to be able to stick with the simplicity of getting mappings out of /etc/hosts and /etc/ethers. I compiled my own version of dnsmasq 2.49 for my Linksys today so that I could try out the new domain features, but I'm still not able to get it to work right when using /etc/hosts... After reading through the source code and adding some debugging info, I think I have figured out at least one issue. It seems that address information in /etc/hosts is only read in for config entries which already exist. So, if you have a short name in /etc/ethers and then you add fully qualified names in /etc/hosts, those fully qualified names are not added to the config. However, if you add similar entries directly in the config file using dhcp-host directives, things work correctly and IP addresses associated with those fully qualified names are properly assigned as static IPs. In order for dnsmasq to do what I want here, it would need to add entries for everything it finds in /etc/hosts, whether it matched an existing config entry or not, the way it currently does when reading ethers. I'm also seeing another problem which I haven't fully tracked down yet. The entries being written to the DHCP leases file still only have the short name in them. As a result, only one entry in the leases file is added for my multi-homed host. Whenever it tries to renew its other address, it gets back a NAK the first time and has to go through another DISCOVER phase. At that point, the proper address is assigned, but dnsmasq deletes the other address in the process, causing the leases table to thrash back and forth instead of properly remembering that both addresses are legitimately assigned to this host. A quick look at the lease_update_file routine tells me that it isn't even trying to write out the fqdn, even when one is stored in the lease entry. It appears to only ever write the hostname. The in-memory data structure should still be correct at least until dnsmasq restarts, though, so that doesn't fully explain the NAK problem I mention above... -- Ron Frederick ronf at timeheart.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090707/6d143336/attachment.htm From santiago at zarate.net.ve Wed Jul 8 16:28:06 2009 From: santiago at zarate.net.ve (Santiago Zarate) Date: Wed, 08 Jul 2009 10:58:06 -0430 Subject: [Dnsmasq-discuss] Using Ipv6 on dnsmasq Message-ID: <4A54BB06.7030701@zarate.net.ve> Hi, I've been looking for a while on the internet... to see if i can use dnsmasq as a dhcp server... is this possible?... if so... how?... any link? or ill have to stick with radvd? Thanks in advance From ranceh at gmail.com Thu Jul 9 02:12:19 2009 From: ranceh at gmail.com (Rance Hall) Date: Wed, 8 Jul 2009 20:12:19 -0500 Subject: [Dnsmasq-discuss] writing a dhclient-exit-hooks script to manage dnsmasq Message-ID: <845c0f80907081812k695bcb78i83879079520faf8d@mail.gmail.com> hey gang, Im trying to do something I've done repeatedly with static external ip addresses but now that I have a external dhcp address things have gone a little off. What I used to do was mv /etc/resolv.conf to /etc/resolv.conf.dnsmasq and tell dnsmasq to read this file instead of /etc/resolv.conf then I would edit /etc/resolv.conf to point the machine back to itself. This way during normal operation the dhcp server ping, ssh, etc to the same machines by hostname that the clients all did. no biggie Enter a dhcp based external interface /etc/resolv.conf is rewritten from time to time as my ISP uses a set of DNS servers and selects the least busy one to give out for load balancing reasons. There are lots of tutorials on how to get /etc/resolv.conf to NOT get rewritten, but if the ISP changes it on purpose, not rewriting the file is not an option. so, I came up with the idea of creating an extra file called /etc/resolv.conf.perm for the permanant /etc/resolv.conf to reside. Then as part of dhclient-exit-hooks, I would check if /etc/resolv.conf had been rewritten some way and if it did, move the .conf file to .conf.dnsmasq and then copy the .conf.perm into .conf then I would have to send dnsmasq a signal (a SIGHUP if I read the docs correctly) Then I need the script to do something strange, I want it to upload a file to my isp's webhosting account so that my public ip address is available via a simple grep of a downloaded .html file I already know how to script an ftp session, so that part is easy. I have several questions... 1) according to dnsmasq documentation a SIGHUP will cause all the config files to re re-read and it will also re-read /etc/resolv.conf if the no-poll option is set. Am I reading this correctly? Is there a way to ask dnsmasq to just re-read the resolv file without having to reload everything? 2) I'm not convinced that dhclient-exit-hooks is the right place for this, but I cant think of another. There are lots of google hits on errors with dhclient-exit-hooks not running. Not to mention that I dont yet understand when the various things happen that dhclient-script asks for. (like "Is /etc/resolv.conf created before or after the exit-hooks-script is run?" or "What about one of the interface specific scripts that dhclient-script executes at different places in the process?" or "Is the value of the new IP available to a dhclient-exit-hooks script so I could just reference the variable, or do I have to look it up on my own?" If someone would be so kind as to help straighten me out with a pointer to a good primer, or something like that I would be grateful. Is there a better way/place to do what I want to do? 3) if anyone has done anything like this, and wouldn't mind sharing, I'd love to see a reasonably active script that really does some stuff. Thanks all for the time, and I apologize for the parts of this that are related, but maybe off topic As a way of saying thanks I would like to contribute the script for public use when its done. Simon, you think there is room for something like this in /contrib? From ranceh at gmail.com Thu Jul 9 03:03:43 2009 From: ranceh at gmail.com (Rance Hall) Date: Wed, 8 Jul 2009 21:03:43 -0500 Subject: [Dnsmasq-discuss] Please Ignore writing a dhclient-exit-hooks script to manage dnsmasq Message-ID: <845c0f80907081903r1d93654ja057c744c0b33ce1@mail.gmail.com> Please forget what I previously wrote. We use two main linux distros and one FreeBSD box and what I needed to do needed to be portable across distros, I know that I didnt mention that in my first post but I knew I could handle the portability part. Anyway the short of it is that half of my machines do not support the ftp -s:scriptname syntax that I was going to use to upload my files to the web server I think now I have to come up with another approach altogether. maybe something like a filewatcher in the background that checks if resolv.conf changed and if so, do the stuff I need done. Thanks all for your attention From richardvoigt at gmail.com Thu Jul 9 05:48:54 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Wed, 8 Jul 2009 23:48:54 -0500 Subject: [Dnsmasq-discuss] writing a dhclient-exit-hooks script to manage dnsmasq In-Reply-To: <845c0f80907081812k695bcb78i83879079520faf8d@mail.gmail.com> References: <845c0f80907081812k695bcb78i83879079520faf8d@mail.gmail.com> Message-ID: <2e59e6970907082148y5b50683ej459cb22fd85023a4@mail.gmail.com> On Wed, Jul 8, 2009 at 8:12 PM, Rance Hall wrote: > hey gang, Im trying to do something I've done repeatedly with static > external ip addresses but now that I have a external dhcp address > things have gone a little off. > > What I used to do was mv /etc/resolv.conf to /etc/resolv.conf.dnsmasq > and tell dnsmasq to read this file instead of /etc/resolv.conf ?then I > would edit /etc/resolv.conf to point the machine back to itself. Yep, that's a pretty common setup. > > This way during normal operation the dhcp server ping, ssh, etc to the > same machines by hostname that the clients all did. > > no biggie > > Enter a dhcp based external interface > > /etc/resolv.conf is rewritten from time to time as my ISP uses a set > of DNS servers and selects the least busy one to give out for load > balancing reasons. > > There are lots of tutorials on how to get /etc/resolv.conf to NOT get > rewritten, but if the ISP changes it on purpose, not rewriting the > file is not an option. > > so, I came up with the idea of creating an extra file called > /etc/resolv.conf.perm for the permanant /etc/resolv.conf to reside. > > Then as part of dhclient-exit-hooks, I would check if /etc/resolv.conf > had been rewritten some way and if it did, move the .conf file to > .conf.dnsmasq and then copy the .conf.perm into .conf You can configure dhclient to overwrite /etc/resolv.conf.dnsmasq instead of /etc/resolv.conf > > then I would have to send dnsmasq a signal (a SIGHUP if I read the > docs correctly) > > Then I need the script to do something strange, I want it to upload a > file to my isp's webhosting account so that my public ip address is > available via a simple grep of a downloaded .html file ?I already know > how to script an ftp session, so that part is easy. > > I have several questions... > > 1) according to dnsmasq documentation a SIGHUP will cause all the > config files to re re-read and it will also re-read /etc/resolv.conf > if the no-poll option is set. > > Am I reading this correctly? Is there a way to ask dnsmasq to just > re-read the resolv file without having to reload everything? If you don't set the no-poll option, then dnsmasq will notice the change and re-read just the DNS server settings, no SIGHUP required. Also SIGHUP doesn't actually re-apply the entire configuration, some settings can't be changed after dnsmasq forks as a restricted user. > > 2) I'm not convinced that dhclient-exit-hooks is the right place for > this, but I cant think of another. ?There are lots of google hits on > errors with dhclient-exit-hooks not running. > Not to mention that I dont yet understand when the various things > happen that dhclient-script asks for. ?(like "Is /etc/resolv.conf > created before or after the exit-hooks-script is run?" > or "What about one of the interface specific scripts that > dhclient-script executes at different places in the process?" or "Is > the value of the new IP available to a dhclient-exit-hooks script so I > could just reference the variable, or do I have to look it up on my > own?" > > If someone would be so kind as to help straighten me out with a > pointer to a good primer, or something like that I would be grateful. > > Is there a better way/place to do what I want to do? > > 3) if anyone has done anything like this, and wouldn't mind sharing, > I'd love to see a reasonably active script that really does some > stuff. > > Thanks all for the time, and I apologize for the parts of this that > are related, but maybe off topic > As a way of saying thanks I would like to contribute the script for > public use when its done. > > Simon, you think there is room for something like this in /contrib? > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From b-morgan at concentric.net Thu Jul 9 06:24:31 2009 From: b-morgan at concentric.net (Brad Morgan) Date: Wed, 8 Jul 2009 23:24:31 -0600 Subject: [Dnsmasq-discuss] writing a dhclient-exit-hooks script to manage dnsmasq In-Reply-To: <845c0f80907081812k695bcb78i83879079520faf8d@mail.gmail.com> References: <845c0f80907081812k695bcb78i83879079520faf8d@mail.gmail.com> Message-ID: <001001ca0055$8bf79840$a3e6c8c0$@net> > Then I need the script to do something strange, I want it to upload a > file to my isp's webhosting account so that my public ip address is > available via a simple grep of a downloaded .html file I already know > how to script an ftp session, so that part is easy. A simpler solution might be to look at using dyndns.com or one of the other dynamic DNS sites. They provide a script (or other tools) that will run on your machine and update a DNS entry on their servers when your IP changes. You then just use that name when you want to reference your machine from the outside world. Regards, Brad From ranceh at gmail.com Thu Jul 9 13:54:34 2009 From: ranceh at gmail.com (Rance Hall) Date: Thu, 9 Jul 2009 07:54:34 -0500 Subject: [Dnsmasq-discuss] writing a dhclient-exit-hooks script to manage dnsmasq In-Reply-To: <001001ca0055$8bf79840$a3e6c8c0$@net> References: <845c0f80907081812k695bcb78i83879079520faf8d@mail.gmail.com> <001001ca0055$8bf79840$a3e6c8c0$@net> Message-ID: <845c0f80907090554q58c58554va9a31bd9d479da07@mail.gmail.com> On Thu, Jul 9, 2009 at 12:24 AM, Brad Morgan wrote: >> Then I need the script to do something strange, I want it to upload a >> file to my isp's webhosting account so that my public ip address is >> available via a simple grep of a downloaded .html file ?I already know >> how to script an ftp session, so that part is easy. > > A simpler solution might be to look at using dyndns.com or one of the other > dynamic DNS sites. They provide a script (or other tools) that will run on > your machine and update a DNS entry on their servers when your IP changes. > You then just use that name when you want to reference your machine from the > outside world. > > Regards, > > Brad > > > Brad, I've tried this sort of setup and its been nothing but grief, my isp's dhcp server has a very long cache setup and it resupplies the same ip for quite some time, in fact my ip changed once in three months, and that was after a power outage that forced almost every client in town to get a new ip when the power came back up. when I try the dyndns type approach I keep getting emails from the system saying my account is going to be suspended due to inactivity. I either need to write a second script to force a dyndns update even if no ip address has changed, and maintain the script that comes with the service so I can get faster response when my ip does change. If it wasnt for the high fee that the ISP charges for static ip (they dont actually sell static ip, they sell business class service which I cant afford) I would just get one of those, I have pseudo static ip now. From weizen_42 at ipcop-forum.de Thu Jul 9 15:09:46 2009 From: weizen_42 at ipcop-forum.de (Olaf Westrik) Date: Thu, 09 Jul 2009 16:09:46 +0200 Subject: [Dnsmasq-discuss] writing a dhclient-exit-hooks script to manage dnsmasq In-Reply-To: <845c0f80907090554q58c58554va9a31bd9d479da07@mail.gmail.com> References: <845c0f80907081812k695bcb78i83879079520faf8d@mail.gmail.com> <001001ca0055$8bf79840$a3e6c8c0$@net> <845c0f80907090554q58c58554va9a31bd9d479da07@mail.gmail.com> Message-ID: <4A55FA2A.40308@ipcop-forum.de> Rance Hall wrote: >>> Then I need the script to do something strange, I want it to upload a >>> file to my isp's webhosting account so that my public ip address is >>> available via a simple grep of a downloaded .html file I already know >>> how to script an ftp session, so that part is easy. >>> >> A simpler solution might be to look at using dyndns.com or one of the other >> dynamic DNS sites. They provide a script (or other tools) that will run on >> your machine and update a DNS entry on their servers when your IP changes. >> You then just use that name when you want to reference your machine from the >> outside world > > > Brad, I've tried this sort of setup and its been nothing but grief, my > isp's dhcp server has a very long cache setup and it resupplies the > same ip for quite some time, in fact my ip changed once in three > months, and that was after a power outage that forced almost every > client in town to get a new ip when the power came back up. > > when I try the dyndns type approach I keep getting emails from the > system saying my account is going to be suspended due to inactivity. > > I either need to write a second script to force a dyndns update even > if no ip address has changed, and maintain the script that comes with > the service so I can get faster response when my ip does change. > Not that difficult to make a cronjob that forces a weekly update, for the case that your IP has not changed. If the IP does change, you'd want to hook into your DHCP client and kick the dyndns update from there. Roy Marples' new incarnation of dhcpcd is pretty cool for such stuff. Olaf -- A weizen a day helps keep the doctor away. From simon at thekelleys.org.uk Thu Jul 9 22:35:11 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Thu, 09 Jul 2009 22:35:11 +0100 Subject: [Dnsmasq-discuss] Using Ipv6 on dnsmasq In-Reply-To: <4A54BB06.7030701@zarate.net.ve> References: <4A54BB06.7030701@zarate.net.ve> Message-ID: <4A56628F.5020505@thekelleys.org.uk> Santiago Zarate wrote: > Hi, I've been looking for a while on the internet... to see if i can use > dnsmasq as a dhcp server... is this possible?... if so... how?... any link? > > or ill have to stick with radvd? > There's IPv6 support in the DNS server part, but not the DHCP part. That's not going to change any time soon. Sorry, Simon. From tmetro+dnsmasq at gmail.com Thu Jul 9 22:52:23 2009 From: tmetro+dnsmasq at gmail.com (Tom Metro) Date: Thu, 09 Jul 2009 17:52:23 -0400 Subject: [Dnsmasq-discuss] writing a dhclient-exit-hooks script to manage dnsmasq In-Reply-To: <845c0f80907090554q58c58554va9a31bd9d479da07@mail.gmail.com> References: <845c0f80907081812k695bcb78i83879079520faf8d@mail.gmail.com> <001001ca0055$8bf79840$a3e6c8c0$@net> <845c0f80907090554q58c58554va9a31bd9d479da07@mail.gmail.com> Message-ID: <4A566697.2010309@gmail.com> Rance Hall wrote: > when I try the dyndns type approach I keep getting emails from the > system saying my account is going to be suspended due to inactivity. > > I either need to write a second script to force a dyndns update even > if no ip address has changed, and maintain the script that comes with > the service so I can get faster response when my ip does change. You might want to take a look at Dynamic Host Information Services (http://dhis.org/). They offer a dynamic DNS service that is specifically designed to time out after a short period of time (by default, 6 minutes) and works with a client that repeatedly lets the service know that it is still alive at and what IP address. This is a better (and in some ways more secure) approach to dynamic DNS. It reduces the chance that someone trying to connect to a service on your servers is going to get connected to someone else at your ISP who happened to pick up your IP address. See: http://dhis.org/WebEngine.ipo?context=dhis.website.links.tech and: http://dhis.org/WebEngine.ipo?context=dhis.website.updating -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ From santiago at zarate.net.ve Fri Jul 10 00:15:32 2009 From: santiago at zarate.net.ve (Santiago Zarate) Date: Thu, 09 Jul 2009 18:45:32 -0430 Subject: [Dnsmasq-discuss] Using Ipv6 on dnsmasq In-Reply-To: <4A56628F.5020505@thekelleys.org.uk> References: <4A54BB06.7030701@zarate.net.ve> <4A56628F.5020505@thekelleys.org.uk> Message-ID: <4A567A14.3040500@zarate.net.ve> Uhm... no problem... i can live with that... also... i forgot to write it in my fist email.. how do i add AAA records? Simon Kelley escribi?: > Santiago Zarate wrote: >> Hi, I've been looking for a while on the internet... to see if i can >> use dnsmasq as a dhcp server... is this possible?... if so... how?... >> any link? >> >> or ill have to stick with radvd? >> > > There's IPv6 support in the DNS server part, but not the DHCP part. > That's not going to change any time soon. > > Sorry, > > Simon. > From ranceh at gmail.com Fri Jul 10 02:05:23 2009 From: ranceh at gmail.com (Rance Hall) Date: Thu, 9 Jul 2009 20:05:23 -0500 Subject: [Dnsmasq-discuss] writing a dhclient-exit-hooks script to manage dnsmasq In-Reply-To: <004c01ca00a1$47c332f0$d74998d0$@net> References: <845c0f80907081812k695bcb78i83879079520faf8d@mail.gmail.com> <001001ca0055$8bf79840$a3e6c8c0$@net> <845c0f80907090554q58c58554va9a31bd9d479da07@mail.gmail.com> <004c01ca00a1$47c332f0$d74998d0$@net> Message-ID: <845c0f80907091805m70d3a912k68880f7cc3a84f38@mail.gmail.com> On Thu, Jul 9, 2009 at 9:26 AM, Brad Morgan wrote: > I use dyndns.com for my home system and my IP hasn't changed in 6 months. > There's a configurable parameter in the script I use that says how often to > send an update even if the IP hasn't changed. The script was obtained from > the dyndns.com site, I didn't write it. > > Regards, > > Brad Brad, and the rest of the crew..... I was able to solve my problem, thanks to Brads suggestion and others on this list I started researching dyndns providers, and dyndns.com seemed like a better fit for what I wanted to do. so I signed up, got an even better domain to have a subdomain on and the perl script that Brad refered to also comes with a cron setup file for use in /etc/cron.d and a sample /etc/dhclient-exit-hooks script so that your dyndns gets updated on a regular basis AND whenever you get a new IP address. Darn Nifty As to my resolv.conf problem I ended up solving it this way: I could not change the dhclient-script to change the name of the resolv file without changing core system scripts that would be overwritten on the next update/upgrade. so I now have three resolv files /etc/resolv.conf.perm /etc/resolv.conf /ec/resolv.conf.forwards .perm is the permanant resolv file whose nameserver line is self-referencing .forwards is the one I ask dnsmasq to use. As part of my dhclient-exit-hooks script I execute this code just before the dhclient-exit-hooks script wants to get out to the internet to update my dyndns server. cp -f /etc/resolv.conf /etc/resolv.conf.forwards && cp -f /etc/resolv.conf.perm /etc/resolv.conf and thats just that simple. I did end up with one question -- assuming dnsmasq is polling the resolv file how long should I wait between replacing the file and trying to get on the net. Im wondering if a "sleep 1" or something needs to go after the resolv file business and a dyndns update. thanks all for your insight and patience as I worked this one out. From simon at thekelleys.org.uk Fri Jul 10 07:27:27 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Fri, 10 Jul 2009 07:27:27 +0100 Subject: [Dnsmasq-discuss] Using Ipv6 on dnsmasq In-Reply-To: <4A567A14.3040500@zarate.net.ve> References: <4A54BB06.7030701@zarate.net.ve> <4A56628F.5020505@thekelleys.org.uk> <4A567A14.3040500@zarate.net.ve> Message-ID: <4A56DF4F.5010709@thekelleys.org.uk> Santiago Zarate wrote: > Uhm... no problem... i can live with that... also... i forgot to write > it in my fist email.. how do i add AAA records? Just put IPV6 addresses in /etc/hosts or (address= lines in /etc/dnsmasq.conf) If that fails, check that dnsmasq has been compiled with IPv6 support: it's optional. "dnsmasq -v" will tell you. HTH Simon. From dnschnur at gmail.com Sat Jul 11 02:06:23 2009 From: dnschnur at gmail.com (David Schnur) Date: Fri, 10 Jul 2009 21:06:23 -0400 Subject: [Dnsmasq-discuss] VPN DNS prioritization Message-ID: <50000b2e0907101806g1afab12aj6fd45153111e5c32@mail.gmail.com> I just set up Dnsmasq on my small home network. I previously spent quite some time trying, unsucessfully, to get the Windows Server DNS service working. So it made me smile to go from tarball to compiled, configured & working in about five minutes with Dnsmasq. I am having one issue, though, and I apologize if it's just because of a lack of understanding of DNS. Prior to setting up Dnsmasq, I had DHCP enabled on my router, set up to forward DNS to OpenDNS. Now, I'm using Dnsmasq DHCP on an OS X 10.5 machine, with some /etc/hosts entries, and the OpenDNS servers in /etc/resolv.conf I also have a Windows machine that occasionally VPNs into a company network. Before Dnsmasq, Windows gave priority to the VPN DNS; now it does not. So server.company.com used to resolve to the correct internal address. Now, it resolves to the OpenDNS wildcard address. I tried two things to fix this: 1. Adding a server entry for company.com in dnsmasq.conf 2. Adding a bogus-nxdomain entry for OpenDNS in dnsmasq.conf The problem with #1 is that there are machines in the company.com domain with public addresses. For example, www.company.com does not have an entry in internal DNS. Also, vpn.company.com no longer resolves, since I'm not actually VPNed in when it needs to be resolved. Solution #2 again almost works. Without the bogus success from OpenDNS, Windows properly falls back to the VPN DNS. The problem is that, due to security restrictions, I need to connect to some machines on their internal address to perform certain tasks. But OpenDNS legitimately resolves those names to their public address. I'm sure I can work around this easily enough with a little extra work. But at this point I'm curious why the behavior changed in the first place. What is different about Dnsmasq that would cause Windows to change where it checks first? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090710/e01fa2ac/attachment.htm From tmetro+dnsmasq at gmail.com Sat Jul 11 03:04:33 2009 From: tmetro+dnsmasq at gmail.com (Tom Metro) Date: Fri, 10 Jul 2009 22:04:33 -0400 Subject: [Dnsmasq-discuss] VPN DNS prioritization In-Reply-To: <50000b2e0907101806g1afab12aj6fd45153111e5c32@mail.gmail.com> References: <50000b2e0907101806g1afab12aj6fd45153111e5c32@mail.gmail.com> Message-ID: <4A57F331.1040300@gmail.com> David Schnur wrote: > Prior to setting up Dnsmasq, I had DHCP enabled on my router, set up to > forward DNS to OpenDNS. Now, I'm using Dnsmasq DHCP on an OS X 10.5 > machine... > > I also have a Windows machine that occasionally VPNs into a company > network. Before Dnsmasq, Windows gave priority to the VPN DNS; now it > does not. So server.company.com used to > resolve to the correct internal address. Now, it resolves to the > OpenDNS wildcard address. ... > What is different about Dnsmasq that would cause Windows to > change where it checks first? I'm guessing what used to happen is that when the VPN became active, your DNS settings got "hijacked" and all queries - both public and private - were directed to the VPN supplied DNS server. I'm not sure why that wouldn't continue to happen after switching to Dnsmasq as your DHCP server. What does "ipconfig /all" report on the Windows machine before and after activating the VPN? > 1. Adding a server entry for company.com in > dnsmasq.conf > > The problem with #1 is that there are machines in the company.com > domain with public addresses. For example, > www.company.com does not have an entry in > internal DNS. Are you sure the private server doesn't resolve the public addresses? If so, that would suggest things are somewhat broken for the people within company.com's LAN, if they're using the same private server. DNS resolution doesn't normally operate using a chain of lookups, where you keep trying until you get the name resolved. If there are multiple servers available, the client is only supposed to try a second one if the first one was not reachable. If it returns a response - even a response saying that the domains is unknown - that is supposed to end the lookup process. Your hack #2 worked because you made the public server unreachable, though I'm not entire clear on how you did that, as you seemed to imply there was a DNS lookup for the DNS server itself, which is usually something that doesn't happen. (Post your relevant Dnsmasq config lines.) > Also, vpn.company.com no longer > resolves, since I'm not actually VPNed in when it needs to be resolved. If there are only a few specific hosts that need to be resolved, you could add Dnsmasq server entries for them that point to a public server. I suspect Dnsmasq will pick the most specific matching server entry (but I haven't tried it). Technically, if the VPN is only accessible from one machine on your LAN, the Dnsmasq being used by all the machines on your LAN is not the best place to inject your fix. You'd be better off applying some fix to the Windows box directly. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ From dnschnur at gmail.com Sat Jul 11 04:59:17 2009 From: dnschnur at gmail.com (David Schnur) Date: Fri, 10 Jul 2009 23:59:17 -0400 Subject: [Dnsmasq-discuss] VPN DNS prioritization In-Reply-To: <4A57F331.1040300@gmail.com> References: <50000b2e0907101806g1afab12aj6fd45153111e5c32@mail.gmail.com> <4A57F331.1040300@gmail.com> Message-ID: <50000b2e0907102059n227d6463l77e317f8529f9a4a@mail.gmail.com> Thanks for your help; responses inline: On Fri, Jul 10, 2009 at 10:04 PM, Tom Metro > wrote: > > What does "ipconfig /all" report on the Windows machine before and after > activating the VPN? > I ran it with/without VPN and with/without dnsmasq. I can attach all output if you'd like, but here's a condensed version of dnsmasq + vpn: Windows IP Configuration Host Name . . . . . . . . . . . . : myhost Primary Dns Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Peer-Peer IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : mysuffix Ethernet adapter Wireless Network Connection: Connection-specific DNS Suffix . : mysuffix Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.2.51 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.2.1 DHCP Server . . . . . . . . . . . : 192.168.2.31 DNS Servers . . . . . . . . . . . : 192.168.2.31 PPP adapter mycompany Connection-specific DNS Suffix . : Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface Dhcp Enabled. . . . . . . . . . . : No IP Address. . . . . . . . . . . . : 192.168.1.?? Subnet Mask . . . . . . . . . . . : 255.255.255.255 Default Gateway . . . . . . . . . : 192.168.1.?? DNS Servers . . . . . . . . . . . : 192.168.1.?? Without Dnsmasq: 1. No 'DNS Suffix Search List' entry 2. The 'Connection-specific DNS Suffix' is empty 3. Ethernet adapter 'DHCP Server' is 192.168.2.1 4. Ethernet adapter 'DNS Servers' lists the two OpenDNS servers Aside from that they're identical. When the VPN is disconnected (with or without dnsmasq), the PPP adapter section disappears; the rest remains the same. > Are you sure the private server doesn't resolve the public addresses? If > so, that would suggest things are somewhat broken for the people within > company.com's LAN, if they're using the same private server. > Sorry, you're right; I was mistaken about that. I must have made a mistake or typo when trying that. > Your hack #2 worked because you made the public server unreachable, though > I'm not entire clear on how you did that, as you seemed to imply there was a > DNS lookup for the DNS server itself, which is usually something that > doesn't happen. (Post your relevant Dnsmasq config lines.) There's a setting (set by default) on VPN connections in Windows where, according to its label text, if Windows tries to resolve an address using local DNS, and that fails, it tries again with the VPN DNS. That setting didn't come into play before, since the VPN DNS was used first. Once the VPN DNS was no longer first, it would try OpenDNS (via dnsmasq). But OpenDNS rewrites NXDOMAIN to point to a revenue-generating website. In dnsmasq.conf, I added: bogus-nxdomain=208.67.217.132 Then the failures were properly reported as such, causing Windows to retry using the VPN DNS (or so I understand it, at least). > Technically, if the VPN is only accessible from one machine on your LAN, > the Dnsmasq being used by all the machines on your LAN is not the best place > to inject your fix. You'd be better off applying some fix to the Windows box > directly. That is a much better idea, but I haven't yet found anything I can do locally to mimic the old behavior. It's mostly about one machine in particular where it's much more convenient if the internal IP is used when the VPN is connected, and the public IP is used when VPN is not connected. Thanks again, David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090710/9399975c/attachment.htm From tmetro+dnsmasq at gmail.com Sat Jul 11 07:24:48 2009 From: tmetro+dnsmasq at gmail.com (Tom Metro) Date: Sat, 11 Jul 2009 02:24:48 -0400 Subject: [Dnsmasq-discuss] VPN DNS prioritization In-Reply-To: <50000b2e0907102059n227d6463l77e317f8529f9a4a@mail.gmail.com> References: <50000b2e0907101806g1afab12aj6fd45153111e5c32@mail.gmail.com> <4A57F331.1040300@gmail.com> <50000b2e0907102059n227d6463l77e317f8529f9a4a@mail.gmail.com> Message-ID: <4A583030.1030601@gmail.com> David Schnur wrote: > There's a setting (set by default) on VPN connections in Windows where, > according to its label text, if Windows tries to resolve an address > using local DNS, and that fails, it tries again with the VPN DNS. That > setting didn't come into play before, since the VPN DNS was used first. Ah, OK, that makes sense. It sounds like a hack that would be better served by having an explicit rule saying when to use which DNS server, but I can see how they'd implement this in an attempt to do the expected thing in most cases. So the questions remains then, why did switching to Dnsmasq impact the ordering that DNS servers are tried by this hack? > Windows IP Configuration > Host Name . . . . . . . . . . . . : myhost > Primary Dns Suffix . . . . . . . : > DNS Suffix Search List. . . . . . : mysuffix > > Ethernet adapter Wireless Network Connection: > Connection-specific DNS Suffix . : mysuffix > DNS Servers . . . . . . . . . . . : 192.168.2.31 No lease information reported? (Is this Windows XP or Vista?) > PPP adapter mycompany > Connection-specific DNS Suffix . : > Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface > Dhcp Enabled. . . . . . . . . . . : No > IP Address. . . . . . . . . . . . : 192.168.1.?? > Subnet Mask . . . . . . . . . . . : 255.255.255.255 > Default Gateway . . . . . . . . . : 192.168.1.?? > DNS Servers . . . . . . . . . . . : 192.168.1.?? Is 192.168.1.?? an attempt to obscure an internal, non-routable address? Why isn't DHCP enabled for that connection? > Without Dnsmasq: > > 3. Ethernet adapter 'DHCP Server' is 192.168.2.1 > 4. Ethernet adapter 'DNS Servers' lists the two OpenDNS servers I presume that's the address of your router, and those are the DNS servers it is supplying to DHCP clients, so that's as expected. > 1. No 'DNS Suffix Search List' entry > 2. The 'Connection-specific DNS Suffix' is empty > > Aside from that they're identical. When the VPN is disconnected (with > or without dnsmasq), the PPP adapter section disappears; the rest > remains the same. Normally the suffix has little impact on DNS and only applies when looking up unqualified names, but so far this is the best lead. Perhaps when it sees any suffix specified, it moves that DNS server up in priority. You could try statically specifying a suffix for the VPN - to put both connections on a level playing field, or you could try tweaking the Dnsmasq settings so that it doesn't supply a suffix to the client. Try unsetting the domain= option. >> You'd be better off applying some fix to the Windows box directly. > > That is a much better idea, but I haven't yet found anything I can do > locally to mimic the old behavior. Have you tried specifying the DNS servers statically? List the VPN server first, then your LAN server. If the VPN server is unreachable, it ought to proceed to your LAN server, though that might result in a delay. There may be DNS proxies/caches that you can run on the machine locally that provide better control. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ From dnschnur at gmail.com Sat Jul 11 17:01:22 2009 From: dnschnur at gmail.com (David Schnur) Date: Sat, 11 Jul 2009 12:01:22 -0400 Subject: [Dnsmasq-discuss] VPN DNS prioritization In-Reply-To: <4A583030.1030601@gmail.com> References: <50000b2e0907101806g1afab12aj6fd45153111e5c32@mail.gmail.com> <4A57F331.1040300@gmail.com> <50000b2e0907102059n227d6463l77e317f8529f9a4a@mail.gmail.com> <4A583030.1030601@gmail.com> Message-ID: <50000b2e0907110901o2ef8ba99va0db4ac424908334@mail.gmail.com> On Sat, Jul 11, 2009 at 2:24 AM, Tom Metro > wrote: > No lease information reported? (Is this Windows XP or Vista?) > I removed the lease information, MAC, and adapter brand/model to shorten the output. The machine's running XP. Is 192.168.1.?? an attempt to obscure an internal, non-routable address? > Yes, sorry, I was just masking internal IPs; they are the correct ones. Why isn't DHCP enabled for that connection? > I was surprised by that, too, since I am getting assigned an address; I don't have anything set manually for that connection. 1. No 'DNS Suffix Search List' entry >> 2. The 'Connection-specific DNS Suffix' is empty >> > Normally the suffix has little impact on DNS and only applies when looking > up unqualified names, but so far this is the best lead. Perhaps when it sees > any suffix specified, it moves that DNS server up in priority. > > You could try statically specifying a suffix for the VPN - to put both > connections on a level playing field, or you could try tweaking the Dnsmasq > settings so that it doesn't supply a suffix to the client. Try unsetting the > domain= option. > I tried unsetting the domain option, and (in a second test) adding a domain suffix to the VPN connection, but neither had an effect. The only thing I noticed is that, with the router, the 'DNS Suffix Search List' entry is not present. With Dnsmasq, it's always present, although empty if the dnsmasq.conf domain option is not set. Have you tried specifying the DNS servers statically? List the VPN server > first, then your LAN server. If the VPN server is unreachable, it ought to > proceed to your LAN server, though that might result in a delay. That's actually a really simple solution, and it works as expected. I'll have to see how noticeable the delay is. At this point I'm just curious as to why it changed. I spent some more time googling this, and apparently querying VPN DNS first is the expected behavior on XP (Vista has slightly different rules). I found a couple of posts from people who wanted the opposite, but none of the responders knew how to make that happen. In any case, this seems like mainly a Windows issue; I'll spend some more time playing around with it. Thanks for your help! David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090711/ff143a18/attachment.htm From dnschnur at gmail.com Sat Jul 11 17:05:51 2009 From: dnschnur at gmail.com (David Schnur) Date: Sat, 11 Jul 2009 12:05:51 -0400 Subject: [Dnsmasq-discuss] VPN DNS prioritization In-Reply-To: <4A583030.1030601@gmail.com> References: <50000b2e0907101806g1afab12aj6fd45153111e5c32@mail.gmail.com> <4A57F331.1040300@gmail.com> <50000b2e0907102059n227d6463l77e317f8529f9a4a@mail.gmail.com> <4A583030.1030601@gmail.com> Message-ID: <50000b2e0907110905k2782892bx893722ad8fd0478a@mail.gmail.com> > > Have you tried specifying the DNS servers statically? List the VPN server >> first, then your LAN server. If the VPN server is unreachable, it ought to >> proceed to your LAN server, though that might result in a delay. > > I came across another solution, in this Microsoft KB article: http://support.microsoft.com/default.aspx?scid=kb;en-us;311218 There's a registry setting that determines the order in which adapters are used. The VPN adapter is at the end of the list whether I'm using Dnsmasq or not, so that's still a mystery. Moving the adapter to the top of the list restores the old behavior without having to specify DNS servers manually. David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090711/341c401e/attachment.htm From tmetro+dnsmasq at gmail.com Sat Jul 11 23:32:52 2009 From: tmetro+dnsmasq at gmail.com (Tom Metro) Date: Sat, 11 Jul 2009 18:32:52 -0400 Subject: [Dnsmasq-discuss] VPN DNS prioritization In-Reply-To: <50000b2e0907110901o2ef8ba99va0db4ac424908334@mail.gmail.com> References: <50000b2e0907101806g1afab12aj6fd45153111e5c32@mail.gmail.com> <4A57F331.1040300@gmail.com> <50000b2e0907102059n227d6463l77e317f8529f9a4a@mail.gmail.com> <4A583030.1030601@gmail.com> <50000b2e0907110901o2ef8ba99va0db4ac424908334@mail.gmail.com> Message-ID: <4A591314.4050000@gmail.com> David Schnur wrote: >> Why isn't DHCP enabled for that connection? > > I was surprised by that, too, since I am getting assigned an address; I > don't have anything set manually for that connection. If that interface is really using PPP as indicated, I seem to recall that PPP included its own mechanism for assigning the IP address. > I tried unsetting the domain option... The only thing I noticed is > that, with the router, the 'DNS Suffix Search List' entry is not > present. With Dnsmasq, it's always present, although empty if the > dnsmasq.conf domain option is not set. Perhaps Dnsmasq is sending the domain DHCP option always, just with an empty value, while the router is excluding that option from the packet. (If you feel adventurous, a packet sniffer (Wireshark) can answer that question.) In any case, having a suffix present should be common, so either it is a real fragile hack, or something else is the underlying cause of it breaking. >> Have you tried specifying the DNS servers statically? > > That's actually a really simple solution, and it works as expected. Great. > In any case, this seems like mainly a Windows issue; Yup. You'll probably get better answers in other forums. But if you get to the bottom of it, let us know what you find. > Thanks for your help! You're welcome. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ From felix.schwarz at oss.schwarz.eu Sun Jul 12 13:01:19 2009 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Sun, 12 Jul 2009 14:01:19 +0200 Subject: [Dnsmasq-discuss] dnsmasq sends DHCPNAK for address offered with DHCPOFFER Message-ID: <4A59D08F.8020603@oss.schwarz.eu> Hi, I just found another interesting thing in dnsmasq: dnsmasq[5181]: DHCPDISCOVER(br-lan) 00:13:AA:BB:CC:DD dnsmasq[5181]: DHCPOFFER(br-lan) 192.168.0.5 00:13:AA:BB:CC:DD dnsmasq[5181]: DHCPREQUEST(br-lan) 192.168.0.5 00:13:AA:BB:CC:DD dnsmasq[5181]: DHCPNAK(br-lan) 192.168.0.5 00:13:AA:BB:CC:DD address reserved dnsmasq[5181]: DHCPREQUEST(br-lan) 192.168.0.5 00:13:AA:BB:CC:DD dnsmasq[5181]: DHCPNAK(br-lan) 192.168.0.5 00:13:AA:BB:CC:DD address reserved dnsmasq[5181]: DHCPDISCOVER(br-lan) 00:13:AA:BB:CC:DD dnsmasq[5181]: DHCPOFFER(br-lan) 192.168.0.5 00:13:AA:BB:CC:DD dnsmasq[5181]: DHCPREQUEST(br-lan) 192.168.0.5 00:13:AA:BB:CC:DD dnsmasq[5181]: DHCPNAK(br-lan) 192.168.0.5 00:13:AA:BB:CC:DD address reserved As you can see, dnsmasq offers an IP address but when the client tries to use it, it gets an DHCPNAK... The reason is another configuration error on my side: /etc/ethers: 00:13:AA:BB:CC:DD 192.168.0.5 ... 00:13:EE:FF:GG:HH 192.168.0.5 ... It would be nice if dnsmasq could detect such a situation and handle it more gracefully... fs From simon at thekelleys.org.uk Sun Jul 12 13:16:42 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Sun, 12 Jul 2009 13:16:42 +0100 Subject: [Dnsmasq-discuss] dnsmasq sends DHCPNAK for address offered with DHCPOFFER In-Reply-To: <4A59D08F.8020603@oss.schwarz.eu> References: <4A59D08F.8020603@oss.schwarz.eu> Message-ID: <4A59D42A.8020307@thekelleys.org.uk> Felix Schwarz wrote: > Hi, > > I just found another interesting thing in dnsmasq: > dnsmasq[5181]: DHCPDISCOVER(br-lan) 00:13:AA:BB:CC:DD > dnsmasq[5181]: DHCPOFFER(br-lan) 192.168.0.5 00:13:AA:BB:CC:DD > dnsmasq[5181]: DHCPREQUEST(br-lan) 192.168.0.5 00:13:AA:BB:CC:DD > dnsmasq[5181]: DHCPNAK(br-lan) 192.168.0.5 00:13:AA:BB:CC:DD address reserved > dnsmasq[5181]: DHCPREQUEST(br-lan) 192.168.0.5 00:13:AA:BB:CC:DD > dnsmasq[5181]: DHCPNAK(br-lan) 192.168.0.5 00:13:AA:BB:CC:DD address reserved > dnsmasq[5181]: DHCPDISCOVER(br-lan) 00:13:AA:BB:CC:DD > dnsmasq[5181]: DHCPOFFER(br-lan) 192.168.0.5 00:13:AA:BB:CC:DD > dnsmasq[5181]: DHCPREQUEST(br-lan) 192.168.0.5 00:13:AA:BB:CC:DD > dnsmasq[5181]: DHCPNAK(br-lan) 192.168.0.5 00:13:AA:BB:CC:DD address reserved > > As you can see, dnsmasq offers an IP address but when the client tries to use > it, it gets an DHCPNAK... > > The reason is another configuration error on my side: > /etc/ethers: > 00:13:AA:BB:CC:DD 192.168.0.5 > ... > 00:13:EE:FF:GG:HH 192.168.0.5 > ... > > It would be nice if dnsmasq could detect such a situation and handle it more > gracefully... > What version were you using? If possible, could you check that http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.50test6.tar.gz fixes this by producing a warning about the second line and then ignoring it? Cheers, Simon. From weizen_42 at ipcop-forum.de Sun Jul 12 14:52:20 2009 From: weizen_42 at ipcop-forum.de (Olaf Westrik) Date: Sun, 12 Jul 2009 15:52:20 +0200 Subject: [Dnsmasq-discuss] DHCP options and SIGHUP Message-ID: <4A59EA94.1060101@ipcop-forum.de> Hi everyone, I have a question and/or problem with using various DHCP options and reloading them by using SIGHUP. Following use case: 'global' DHCP settings (rarely changing) and several static leases, some of which using dhcp-boot for PXE boot. Now I would like to reread the static leases after changes have been made by using SIGHUP. No problem if I put the dhcp-host configuration lines in a file referenced by dhcp-hostsfile, but what to do with the dhcp-boot lines? Any thoughts? Thanks Olaf -- A weizen a day helps keep the doctor away. From felix.schwarz at oss.schwarz.eu Sun Jul 12 14:59:20 2009 From: felix.schwarz at oss.schwarz.eu (Felix Schwarz) Date: Sun, 12 Jul 2009 15:59:20 +0200 Subject: [Dnsmasq-discuss] dnsmasq sends DHCPNAK for address offered with DHCPOFFER In-Reply-To: <4A59D42A.8020307@thekelleys.org.uk> References: <4A59D08F.8020603@oss.schwarz.eu> <4A59D42A.8020307@thekelleys.org.uk> Message-ID: <4A59EC38.40309@oss.schwarz.eu> Simon Kelley schrieb: > What version were you using? If possible, could you check that dnsmasq in OpenWRT Kamikaze 8.09.1 (I think it is 2.47-3). > http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.50test6.tar.gz > > fixes this by producing a warning about the second line and then > ignoring it? I'll check - unfortunately this will be next week as I'm almost in the airplane right now. fs From ranceh at gmail.com Sun Jul 12 15:44:30 2009 From: ranceh at gmail.com (Rance Hall) Date: Sun, 12 Jul 2009 09:44:30 -0500 Subject: [Dnsmasq-discuss] DHCP options and SIGHUP In-Reply-To: <4A59EA94.1060101@ipcop-forum.de> References: <4A59EA94.1060101@ipcop-forum.de> Message-ID: <845c0f80907120744u68a253d2q871999592898652b@mail.gmail.com> On Sun, Jul 12, 2009 at 8:52 AM, Olaf Westrik wrote: > Hi everyone, > > > I have a question and/or problem with using various DHCP options and > reloading them by using SIGHUP. > > Following use case: > 'global' DHCP settings (rarely changing) and several static leases, some > of which using dhcp-boot for PXE boot. > > Now I would like to reread the static leases after changes have been > made by using SIGHUP. No problem if I put the dhcp-host configuration > lines in a file referenced by dhcp-hostsfile, but what to do with the > dhcp-boot lines? > > > Any thoughts? > > Thanks > Olaf First I'll start by saying I dont have the answer to your question. That being said, the fact that you are in a situation where the question is relevant really interests me. In my setup I only have one dhcp-boot line, and a gpxe match dhcp-boot line (which may be going away as my experiments with gpxe and iscsi booting have not provided fruitful results) For my personal curiosity, if no other reason, could you explain what you are trying to do. It sounds like you are wanting to set a host specific dhcp-boot so that different hosts get different starts, am I right? Im not sure this is possible as you have stated it. But have you explored the idea of a scripted pxelinux default dhcp-boot file? suppose you could start all clients the same, they started with pxelinux.0 and loaded the default file. then that default file is where the advanced selection is made. and you get a special kernel/append line on a per instance basis. the latest version of syslinux includes gpxelinux.0 which works as a replacement for pxelinux.0 and it is scriptable if pxelinux.0 is not. HTH Rance From simon at thekelleys.org.uk Mon Jul 13 11:50:25 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Mon, 13 Jul 2009 11:50:25 +0100 Subject: [Dnsmasq-discuss] DHCP options and SIGHUP In-Reply-To: <4A59EA94.1060101@ipcop-forum.de> References: <4A59EA94.1060101@ipcop-forum.de> Message-ID: <4A5B1171.9070406@thekelleys.org.uk> Olaf Westrik wrote: > Hi everyone, > > > I have a question and/or problem with using various DHCP options and > reloading them by using SIGHUP. > > Following use case: > 'global' DHCP settings (rarely changing) and several static leases, some > of which using dhcp-boot for PXE boot. > > Now I would like to reread the static leases after changes have been > made by using SIGHUP. No problem if I put the dhcp-host configuration > lines in a file referenced by dhcp-hostsfile, but what to do with the > dhcp-boot lines? > > > Any thoughts? > It's (mostly) possible. The trick is to use dhcp-optsfile which, like dhcp-hostfile get re-read on SIGHUP. dhcp-optsfile contains dhcp-option lines, not dhcp-boot lines, but the filename and servername information in dhcp-boot can be represented as dhcp options. So, if you have dhcp-host=,,net: dhcp-boot=net:, then you can put ,,net: in a dhcp-hostfile and net:,opt:bootfile-name, in dhcp-optsfile and get the same effect, but the configuration is re-read on SIGHUP. The only thing that this doesn't work for is the server address field in dhcp-boot, since there's no option defined to represent this. As long as you're relying on the default that's OK. A "pseudo option" should probably be defined for this data too, to fix this hole. HTH Simon. From simon at thekelleys.org.uk Mon Jul 13 20:28:56 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Mon, 13 Jul 2009 20:28:56 +0100 Subject: [Dnsmasq-discuss] DHCP options and SIGHUP In-Reply-To: <4A59EA94.1060101@ipcop-forum.de> References: <4A59EA94.1060101@ipcop-forum.de> Message-ID: <4A5B8AF8.7020800@thekelleys.org.uk> Simon wrote: > So, if you have > > dhcp-host=,,net: > dhcp-boot=net:, > > then you can put > > ,,net: > > in a dhcp-hostfile > > and > > net:,opt:bootfile-name, > > in dhcp-optsfile > > and get the same effect, but the configuration is re-read on SIGHUP. That should, of course, be net:,option:bootfile-name, Cheers, Simon. From weizen_42 at ipcop-forum.de Tue Jul 14 19:01:09 2009 From: weizen_42 at ipcop-forum.de (Olaf Westrik) Date: Tue, 14 Jul 2009 20:01:09 +0200 Subject: [Dnsmasq-discuss] DHCP options and SIGHUP In-Reply-To: <4A5B1171.9070406@thekelleys.org.uk> References: <4A59EA94.1060101@ipcop-forum.de> <4A5B1171.9070406@thekelleys.org.uk> Message-ID: <4A5CC7E5.90301@ipcop-forum.de> Hello Rance, Hello Simon, >> I have a question and/or problem with using various DHCP options and >> reloading them by using SIGHUP. >> >> Following use case: >> 'global' DHCP settings (rarely changing) and several static leases, >> some of which using dhcp-boot for PXE boot. >> >> Now I would like to reread the static leases after changes have been >> made by using SIGHUP. No problem if I put the dhcp-host configuration >> lines in a file referenced by dhcp-hostsfile, but what to do with the >> dhcp-boot lines? >> >> >> Any thoughts? >> > > It's (mostly) possible. The trick is to use dhcp-optsfile which, like > dhcp-hostfile get re-read on SIGHUP. > > dhcp-optsfile contains dhcp-option lines, not dhcp-boot lines, but the > filename and servername information in dhcp-boot can be represented as > dhcp options. > > So, if you have > > > dhcp-host=,,net: > dhcp-boot=net:, > > then you can put > > ,,net: > > in a dhcp-hostfile > > and > > net:,opt:bootfile-name, > > in dhcp-optsfile > > and get the same effect, but the configuration is re-read on SIGHUP. OK, that would work (most of it anyway, as you write below ;-)) To explain a bit more about how I (the project I am working on) handle things. There is a 'GUI interface to dnsmasq DHCP', which is explained here: http://www.ipcop.org/2.0.0/en/admin/html/services-dhcp.html The form to add static DHCP leases is this: http://www.ipcop.org/2.0.0/en/admin/images/dhcp3.png This adds lines to a config file which look like this: dhcp-host=00:0e:f0:05:00:9A,net:STATIC_0,192.168.10.2 dhcp-boot=net:STATIC_0,pxelinux.cfg,,192.168.10.201 Rance is correct to assume that the filename and server address are very, very unlikely to be different and differentiating between PCs will be done in pxelinux.cfg file. Still the option is there and I would like to be able to use that. > That should, of course, be > > net:,option:bootfile-name, According to http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html both opt and option are valid? The code in option.c thinks differently though ;-) > The only thing that this doesn't work for is the server address field in > dhcp-boot, since there's no option defined to represent this. As long as > you're relying on the default that's OK. A "pseudo option" should > probably be defined for this data too, to fix this hole. Am I correct to assume that this requires an addition to opttab in option.c (next-server-ip) and matching code in rfc2131.c? If so, say the word and I will get at it :-), not before thursday though. Olaf -- A weizen a day helps keep the doctor away. From simon at thekelleys.org.uk Tue Jul 14 20:50:44 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Tue, 14 Jul 2009 20:50:44 +0100 Subject: [Dnsmasq-discuss] DHCP options and SIGHUP In-Reply-To: <4A5CC7E5.90301@ipcop-forum.de> References: <4A59EA94.1060101@ipcop-forum.de> <4A5B1171.9070406@thekelleys.org.uk> <4A5CC7E5.90301@ipcop-forum.de> Message-ID: <4A5CE194.1080804@thekelleys.org.uk> Olaf Westrik wrote: > >> That should, of course, be >> >> net:,option:bootfile-name, > > According to http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html > both opt and option are valid? > The code in option.c thinks differently though ;-) I can't find anywhere in the man page which says that "opt:" is valid. What have I missed? > > >> The only thing that this doesn't work for is the server address field >> in dhcp-boot, since there's no option defined to represent this. As >> long as you're relying on the default that's OK. A "pseudo option" >> should probably be defined for this data too, to fix this hole. > > Am I correct to assume that this requires an addition to opttab in > option.c (next-server-ip) and matching code in rfc2131.c? > If so, say the word and I will get at it :-), not before thursday though. > Thanks for the offer but I did this last night: it's a simple change. Code is available at http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.50test7.tar.gz Cheers, Simon. From weizen_42 at ipcop-forum.de Tue Jul 14 20:51:46 2009 From: weizen_42 at ipcop-forum.de (Olaf Westrik) Date: Tue, 14 Jul 2009 21:51:46 +0200 Subject: [Dnsmasq-discuss] DHCP options and SIGHUP In-Reply-To: <4A5CE194.1080804@thekelleys.org.uk> References: <4A59EA94.1060101@ipcop-forum.de> <4A5B1171.9070406@thekelleys.org.uk> <4A5CC7E5.90301@ipcop-forum.de> <4A5CE194.1080804@thekelleys.org.uk> Message-ID: <4A5CE1D2.3010005@ipcop-forum.de> Simon Kelley wrote: >> According to http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html >> both opt and option are valid? >> The code in option.c thinks differently though ;-) > > I can't find anywhere in the man page which says that "opt:" is valid. > What have I missed? Ah sorry, I misinterpreted this: --dhcp-option=[,[,]][encap:,][vendor:[],][|option:],[[,]] and thought I saw something like: [opt|option:] (those config lines sure are painful for the eyes/brain) > Thanks for the offer but I did this last night: it's a simple change. > > Code is available at > > http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.50test7.tar.gz Thanks! I'll try this Thursday/Friday and report back. Olaf -- A weizen a day helps keep the doctor away. From akameswaran at gmail.com Wed Jul 15 19:47:40 2009 From: akameswaran at gmail.com (Anand Kameswaran) Date: Wed, 15 Jul 2009 14:47:40 -0400 Subject: [Dnsmasq-discuss] two dnsmasq servers providing dhcp for one domain Message-ID: <8bfd07420907151147r315eb1c3v41ef7340cd1eb7fb@mail.gmail.com> I am maintaining an internal private domain using dnsmasq. However there are n number of subnets connected via infrastructure VPN, and up until now I have had dnsmasq only on one subnet and it has been succesfully serving DNS for all subnets. However I now have a need to add DHCP to those subnets. Now I have succesfully setup dnsmasq to serve DHCP to the subnet it is on. However on the other side of the VPN, obviously dhcp requests will not be recieved. I was thinking I could setup a second dnsmasq instance on the other side of the VPN, but then each DNSmasq will only know about the DHCP names for the machines on it's side of the VPN. I don't think DHCP relay is an option (I could be wrong - but it is for a rather large number of subnets) Is there a way to configure the two dnsmasq servers to update and/or querry each other? All machines on the subnets share the same domain, so my understanding is that if dnsmasq doesn't find hostx.domain.com then it will give up. Currently the dnsmasq also do forward lookups for external addresses. Thanks, AK -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090715/d1f10394/attachment.htm From mike at dcsamerica.com Thu Jul 16 00:23:50 2009 From: mike at dcsamerica.com (Data Control Systems - Mike Elkevizth) Date: Wed, 15 Jul 2009 19:23:50 -0400 Subject: [Dnsmasq-discuss] two dnsmasq servers providing dhcp for one domain In-Reply-To: <8bfd07420907151147r315eb1c3v41ef7340cd1eb7fb@mail.gmail.com> Message-ID: I do this by separating the two subnets into two domains. Then you can tell the server on domain1 to forward all queries for domain2 to the other server. It works well for me, but I always know which subnet each host is on. You could also use the config option "server=//server.domain2" and visa-versa to make all queries with an unqualified domain name forward to the other server. If anyone knows a better way, I would like to know myself. Mike E. -----Original Message----- From: dnsmasq-discuss-bounces at lists.thekelleys.org.uk [mailto:dnsmasq-discuss-bounces at lists.thekelleys.org.uk]On Behalf Of Anand Kameswaran Sent: Wednesday, July 15, 2009 2:48 PM To: dnsmasq-discuss at lists.thekelleys.org.uk Subject: [Dnsmasq-discuss] two dnsmasq servers providing dhcp for one domain I am maintaining an internal private domain using dnsmasq. However there are n number of subnets connected via infrastructure VPN, and up until now I have had dnsmasq only on one subnet and it has been succesfully serving DNS for all subnets. However I now have a need to add DHCP to those subnets. Now I have succesfully setup dnsmasq to serve DHCP to the subnet it is on. However on the other side of the VPN, obviously dhcp requests will not be recieved. I was thinking I could setup a second dnsmasq instance on the other side of the VPN, but then each DNSmasq will only know about the DHCP names for the machines on it's side of the VPN. I don't think DHCP relay is an option (I could be wrong - but it is for a rather large number of subnets) Is there a way to configure the two dnsmasq servers to update and/or querry each other? All machines on the subnets share the same domain, so my understanding is that if dnsmasq doesn't find hostx.domain.com then it will give up. Currently the dnsmasq also do forward lookups for external addresses. Thanks, AK -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090715/285a44e4/attachment.htm From akameswaran at gmail.com Thu Jul 16 16:11:39 2009 From: akameswaran at gmail.com (Anand Kameswaran) Date: Thu, 16 Jul 2009 11:11:39 -0400 Subject: [Dnsmasq-discuss] two dnsmasq servers providing dhcp for one domain In-Reply-To: References: <8bfd07420907151147r315eb1c3v41ef7340cd1eb7fb@mail.gmail.com> Message-ID: <8bfd07420907160811o979806boe5d799a7d8f52138@mail.gmail.com> Unfortunately, I can't split the subnets into individual domains. The separate subnets need to be "invisible" to the outside world for other reasons. One thing, that I wondered, can I point to the dhcp.leases file as an additional source of dns data? I could then possibly setup nfs and let each dnsmasq read the other's dhcp.leases file. Or would that be a really dumb thing? On Wed, Jul 15, 2009 at 7:23 PM, Data Control Systems - Mike Elkevizth < mike at dcsamerica.com> wrote: > I do this by separating the two subnets into two domains. Then you can > tell the server on domain1 to forward all queries for domain2 to the other > server. It works well for me, but I always know which subnet each host is > on. You could also use the config option "server=//server.domain2" and > visa-versa to make all queries with an unqualified domain name forward to > the other server. If anyone knows a better way, I would like to know > myself. > > Mike E. > > > -----Original Message----- > *From:* dnsmasq-discuss-bounces at lists.thekelleys.org.uk [mailto: > dnsmasq-discuss-bounces at lists.thekelleys.org.uk]*On Behalf Of *Anand > Kameswaran > *Sent:* Wednesday, July 15, 2009 2:48 PM > *To:* dnsmasq-discuss at lists.thekelleys.org.uk > *Subject:* [Dnsmasq-discuss] two dnsmasq servers providing dhcp for one > domain > > I am maintaining an internal private domain using dnsmasq. However there > are n number of subnets connected via infrastructure VPN, and up until now > I have had dnsmasq only on one subnet and it has been succesfully serving > DNS for all subnets. However I now have a need to add DHCP to those > subnets. Now I have succesfully setup dnsmasq to serve DHCP to the subnet > it is on. However on the other side of the VPN, obviously dhcp requests > will not be recieved. > I was thinking I could setup a second dnsmasq instance on the other side of > the VPN, but then each DNSmasq will only know about the DHCP names for the > machines on it's side of the VPN. I don't think DHCP relay is an option (I > could be wrong - but it is for a rather large number of subnets) > Is there a way to configure the two dnsmasq servers to update and/or querry > each other? All machines on the subnets share the same domain, so my > understanding is that if dnsmasq doesn't find hostx.domain.com then it > will give up. > > Currently the dnsmasq also do forward lookups for external addresses. > > Thanks, > AK > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090716/8c3662ee/attachment.htm From simon at thekelleys.org.uk Thu Jul 16 16:17:21 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Thu, 16 Jul 2009 16:17:21 +0100 Subject: [Dnsmasq-discuss] two dnsmasq servers providing dhcp for one domain In-Reply-To: <8bfd07420907151147r315eb1c3v41ef7340cd1eb7fb@mail.gmail.com> References: <8bfd07420907151147r315eb1c3v41ef7340cd1eb7fb@mail.gmail.com> Message-ID: <4A5F4481.7040402@thekelleys.org.uk> Anand Kameswaran wrote: > I am maintaining an internal private domain using dnsmasq. However > there are n number of subnets connected via infrastructure VPN, and up > until now I have had dnsmasq only on one subnet and it has been > succesfully serving DNS for all subnets. However I now have a need to > add DHCP to those subnets. Now I have succesfully setup dnsmasq to > serve DHCP to the subnet it is on. However on the other side of the > VPN, obviously dhcp requests will not be recieved. > I was thinking I could setup a second dnsmasq instance on the other side > of the VPN, but then each DNSmasq will only know about the DHCP names > for the machines on it's side of the VPN. I don't think DHCP relay is > an option (I could be wrong - but it is for a rather large number of > subnets) > Is there a way to configure the two dnsmasq servers to update and/or > querry each other? All machines on the subnets share the same domain, > so my understanding is that if dnsmasq doesn't find hostx.domain.com > then it will give up. > > Currently the dnsmasq also do forward lookups for external addresses. > Why do you dismiss DHCP relay? That seems to be the perfect solution in this case. Dnsmasq can handle lots of subnets without problem. You need to have a machine on each subnet which can run the DHCP relay: it doesn't have to be the VPN router, though it can be. http://www.thekelleys.org.uk/dhcp-helper/ or the ISC dhcp relay would do the job nicely. I can't see any other way to achieve what you want easily. Cheers, Simon. From weizen_42 at ipcop-forum.de Fri Jul 17 08:01:45 2009 From: weizen_42 at ipcop-forum.de (Olaf Westrik) Date: Fri, 17 Jul 2009 09:01:45 +0200 Subject: [Dnsmasq-discuss] DHCP options and SIGHUP In-Reply-To: <4A5CE194.1080804@thekelleys.org.uk> References: <4A59EA94.1060101@ipcop-forum.de> <4A5B1171.9070406@thekelleys.org.uk> <4A5CC7E5.90301@ipcop-forum.de> <4A5CE194.1080804@thekelleys.org.uk> Message-ID: <4A6021D9.3030604@ipcop-forum.de> Hello Simon, >>> The only thing that this doesn't work for is the server address field >>> in dhcp-boot, since there's no option defined to represent this. As >>> long as you're relying on the default that's OK. A "pseudo option" >>> should probably be defined for this data too, to fix this hole. >> Am I correct to assume that this requires an addition to opttab in >> option.c (next-server-ip) and matching code in rfc2131.c? >> If so, say the word and I will get at it :-), not before thursday though. >> > > Thanks for the offer but I did this last night: it's a simple change. Works, thanks! May I suggest changing the option name tftpserver-address in server-ip-address (or siaddr)? IMHO that would make the purpose and differentiation to the tftp-server option (66) easier. Attached I have a small patch that moves logging "read dhcp-hosts file" and "read dhcp-opts file" to the dnsmasq-dhcp section. Apply if you agree. Ignore if you do not agree ;-) For reference, this is what dhcp-hosts and dhcp-opts file look like: 00:0e:f0:05:00:00,net:STATIC_0,192.168.242.1 00:0e:f0:00:10:57,net:STATIC_1,192.168.242.2 net:STATIC_0,option:bootfile-name,pxelinux.cfg net:STATIC_0,option:tftpserver-address,192.168.10.201 net:STATIC_1,option:bootfile-name,pxelinux.cfg net:STATIC_1,option:tftpserver-address,192.168.10.201 Olaf -- A weizen a day helps keep the doctor away. -------------- next part -------------- A non-text attachment was scrubbed... Name: dnsmasq-2.49_log-dhcp.patch Type: text/x-diff Size: 674 bytes Desc: not available Url : http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090717/ed87d82c/attachment.patch From akameswaran at gmail.com Fri Jul 17 13:50:32 2009 From: akameswaran at gmail.com (Anand Kameswaran) Date: Fri, 17 Jul 2009 08:50:32 -0400 Subject: [Dnsmasq-discuss] two dnsmasq servers providing dhcp for one domain In-Reply-To: <4A5F7845.6060806@thekelleys.org.uk> References: <8bfd07420907151147r315eb1c3v41ef7340cd1eb7fb@mail.gmail.com> <4A5F4481.7040402@thekelleys.org.uk> <8bfd07420907161124o5e4f2bd6sb0f7b9706f984554@mail.gmail.com> <4A5F7845.6060806@thekelleys.org.uk> Message-ID: <8bfd07420907170550j5a143c15hfa60baeaa4fa351@mail.gmail.com> Maybe this is a lot more straightforward than I am thinking, but I'm not sure how I should configure DHCP, once I start using DHCP helper. Let me try and explain the setup. Each embedded device has 2 physical NIC cards. Eth0 and Eth1. Eth0 is used for public communincations and the VPN tunnels are setup between the two devices eth0 interfaces. Eth1 had multiple virtual adapters to handle the subnetting, ie. eth1:1...eth1:n depending on the number of required subnets. Now when configuring DNSMasq I had run into an oddity. The machines absolutely should not provide DHCP over eth0 as that would impact the public network. Initially I configured dnsmasq to explicitly listen on all eth1.x interfaces, but it didn't work. However, when I configured dnsmasq to only exclude eth0 everything worked fine. Here is the crux of the problem using dhcp_helper. So device 1 is providing DHCP/DNS. I need to assign a different subnet for nodes on device 2 than for device 1, so that routing can occur over the tunnels. Obviously each side of the vpn tunnels needs unique subnets. That is one problem, although I know dnsmasq can serve up addresses in multiple ranges. The real problem I suspect is that requests from nodes on device two, sent over broadcast will probably be received physically on eth0. ALthough their is in fact a "tunnel" device as well. (btw using GRE tunnels for the VPN - not encrypted as I am only concerned about network segregation not security) Now I'm not really a good networking guy - so forgive me if my terminology is slightly off, but hopefully my problem is clear. And I am not really to clear on how to configure dnsmasq once I have DHCP helper working. I need those requests that come over the DHCP_Helper to get a different subnet. Any suggestions? Cheers, AK On Thu, Jul 16, 2009 at 2:58 PM, Simon Kelley wrote: > Anand Kameswaran wrote: > > Simon, > > The reason I initially discounted this, as my routers are essentially > > embedded devices based off an old debian Sarge, and somewhat gimped. I > did > > not want to tackle trying to get additional packages installed, as the > > system does not have aptitude, or even apt-get. However, following your > > suggestion, I will try to get DHCP helper installed. This is more due to > > implementation details rather than best practice. I am currently > > unarchiving my old images of Sarge, and will try and get dhcp-helper > > integrated into the embedded device. I suppose in worst case, I can > build > > out a sarge system and try to compile source against it, and move it into > my > > device. > > > > Dhcp-helper is very simple: a few hundred lines of C on one source file. > It only depends on the C library. > > There are packages in Sarge, which don't depend in anything other than > libc, so dpkg should be enough to install them. In extremis you could > compile it statically-linked on another machine and end up with a binary > that would just slot in. > > Good luck. > > Cheers, > > Simon. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090717/72a86b03/attachment.htm From simon at thekelleys.org.uk Fri Jul 17 14:21:05 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Fri, 17 Jul 2009 14:21:05 +0100 Subject: [Dnsmasq-discuss] two dnsmasq servers providing dhcp for one domain In-Reply-To: <8bfd07420907170550j5a143c15hfa60baeaa4fa351@mail.gmail.com> References: <8bfd07420907151147r315eb1c3v41ef7340cd1eb7fb@mail.gmail.com> <4A5F4481.7040402@thekelleys.org.uk> <8bfd07420907161124o5e4f2bd6sb0f7b9706f984554@mail.gmail.com> <4A5F7845.6060806@thekelleys.org.uk> <8bfd07420907170550j5a143c15hfa60baeaa4fa351@mail.gmail.com> Message-ID: <4A607AC1.7010700@thekelleys.org.uk> Anand Kameswaran wrote: > Maybe this is a lot more straightforward than I am thinking, but I'm not > sure how I should configure DHCP, once I start using DHCP helper. > > Let me try and explain the setup. Each embedded device has 2 physical > NIC cards. Eth0 and Eth1. Eth0 is used for public communincations and > the VPN tunnels are setup between the two devices eth0 interfaces. Eth1 > had multiple virtual adapters to handle the subnetting, ie. > eth1:1...eth1:n depending on the number of required subnets. > > Now when configuring DNSMasq I had run into an oddity. The machines > absolutely should not provide DHCP over eth0 as that would impact the > public network. Initially I configured dnsmasq to explicitly listen on > all eth1.x interfaces, but it didn't work. However, when I configured > dnsmasq to only exclude eth0 everything worked fine. > > Here is the crux of the problem using dhcp_helper. So device 1 is > providing DHCP/DNS. I need to assign a different subnet for nodes on > device 2 than for device 1, so that routing can occur over the tunnels. > Obviously each side of the vpn tunnels needs unique subnets. That is > one problem, although I know dnsmasq can serve up addresses in multiple > ranges. The real problem I suspect is that requests from nodes on > device two, sent over broadcast will probably be received physically on > eth0. ALthough their is in fact a "tunnel" device as well. (btw using > GRE tunnels for the VPN - not encrypted as I am only concerned about > network segregation not security) > > Now I'm not really a good networking guy - so forgive me if my > terminology is slightly off, but hopefully my problem is clear. And I > am not really to clear on how to configure dnsmasq once I have DHCP > helper working. I need those requests that come over the DHCP_Helper to > get a different subnet. Any suggestions? > > Cheers, > AK You're worrying too much. It all happens automagically. Set up dhcp-helper to listen for broadcasts on the correct interface and bounce them to dnsmasq. When dhcp-helper does this, it puts the address of the interface on which the broadcast was received into the packet, in the giaddr field. When dnsmasq gets a packet with giaddr set, it uses that address to decide which subnet to allocate an address on, not the interface that dnsmasq received the packet on. So: dnsmasq, just list all the subnets you will need as dhcp-ranges. dhcp-helper, select the interfaces to listen for broadcasts using -i and/or -e and tell dhcp-helper where to send the packets to with -s If the dnsmasq server is multi-homed you can use any of its addresses, as long as they are routable from the relay. The address of any interface that dhcp-helper is listening on must be routable from the host running dnsmasq. HTH Simon. From simon at thekelleys.org.uk Fri Jul 17 15:17:51 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Fri, 17 Jul 2009 15:17:51 +0100 Subject: [Dnsmasq-discuss] DHCP options and SIGHUP In-Reply-To: <4A6021D9.3030604@ipcop-forum.de> References: <4A59EA94.1060101@ipcop-forum.de> <4A5B1171.9070406@thekelleys.org.uk> <4A5CC7E5.90301@ipcop-forum.de> <4A5CE194.1080804@thekelleys.org.uk> <4A6021D9.3030604@ipcop-forum.de> Message-ID: <4A60880F.5090607@thekelleys.org.uk> Olaf Westrik wrote: > Works, thanks! > > Great!. > May I suggest changing the option name tftpserver-address in > server-ip-address (or siaddr)? > IMHO that would make the purpose and differentiation to the tftp-server > option (66) easier. > > Sounds sensible: done. > Attached I have a small patch that moves logging "read dhcp-hosts file" > and "read dhcp-opts file" to the dnsmasq-dhcp section. > Apply if you agree. Ignore if you do not agree ;-) Applied. http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.50test8.tar.gz > > > For reference, this is what dhcp-hosts and dhcp-opts file look like: > 00:0e:f0:05:00:00,net:STATIC_0,192.168.242.1 > 00:0e:f0:00:10:57,net:STATIC_1,192.168.242.2 > > net:STATIC_0,option:bootfile-name,pxelinux.cfg > net:STATIC_0,option:tftpserver-address,192.168.10.201 > net:STATIC_1,option:bootfile-name,pxelinux.cfg > net:STATIC_1,option:tftpserver-address,192.168.10.201 > Looks sensible. Cheers, Simon. From akameswaran at gmail.com Sat Jul 18 15:22:14 2009 From: akameswaran at gmail.com (Anand Kameswaran) Date: Sat, 18 Jul 2009 10:22:14 -0400 Subject: [Dnsmasq-discuss] two dnsmasq servers providing dhcp for one domain In-Reply-To: <4A607AC1.7010700@thekelleys.org.uk> References: <8bfd07420907151147r315eb1c3v41ef7340cd1eb7fb@mail.gmail.com> <4A5F4481.7040402@thekelleys.org.uk> <8bfd07420907161124o5e4f2bd6sb0f7b9706f984554@mail.gmail.com> <4A5F7845.6060806@thekelleys.org.uk> <8bfd07420907170550j5a143c15hfa60baeaa4fa351@mail.gmail.com> <4A607AC1.7010700@thekelleys.org.uk> Message-ID: <8bfd07420907180722k403d4661s4bbf9b66409e853c@mail.gmail.com> I got dhcp-helper 0.7.1 from debian etch installed. Sarge aparently did not come with it, and when I try running a 1.0 version I get a segfault. So for the moment I'm using the 0.7.1 What is the difference between -i and -e? I have tried binding to every interface, and I am sending the -s to an IP Address that is pingable (It does go over the tunnel interface to reach there) However, so far as I can tell nothing is happening. Without ethereal, I'm not sure how to debug which step is failing, but I would have expected DNSMasq to at least serve a dhcp address, even if incorrectly. Something else is it appears that broadcast over GRE tunnels is not possible in 2.4 kernel. I've found some things on how to do it in 2.6, but not 2.4 I'm going to do more research On Fri, Jul 17, 2009 at 9:21 AM, Simon Kelley wrote: > Anand Kameswaran wrote: > >> Maybe this is a lot more straightforward than I am thinking, but I'm not >> sure how I should configure DHCP, once I start using DHCP helper. >> >> Let me try and explain the setup. Each embedded device has 2 physical NIC >> cards. Eth0 and Eth1. Eth0 is used for public communincations and the VPN >> tunnels are setup between the two devices eth0 interfaces. Eth1 had >> multiple virtual adapters to handle the subnetting, ie. eth1:1...eth1:n >> depending on the number of required subnets. >> >> Now when configuring DNSMasq I had run into an oddity. The machines >> absolutely should not provide DHCP over eth0 as that would impact the public >> network. Initially I configured dnsmasq to explicitly listen on all eth1.x >> interfaces, but it didn't work. However, when I configured dnsmasq to only >> exclude eth0 everything worked fine. >> >> Here is the crux of the problem using dhcp_helper. So device 1 is >> providing DHCP/DNS. I need to assign a different subnet for nodes on device >> 2 than for device 1, so that routing can occur over the tunnels. Obviously >> each side of the vpn tunnels needs unique subnets. That is one problem, >> although I know dnsmasq can serve up addresses in multiple ranges. The real >> problem I suspect is that requests from nodes on device two, sent over >> broadcast will probably be received physically on eth0. ALthough their is >> in fact a "tunnel" device as well. (btw using GRE tunnels for the VPN - not >> encrypted as I am only concerned about network segregation not security) >> Now I'm not really a good networking guy - so forgive me if my terminology >> is slightly off, but hopefully my problem is clear. And I am not really to >> clear on how to configure dnsmasq once I have DHCP helper working. I need >> those requests that come over the DHCP_Helper to get a different subnet. >> Any suggestions? >> >> Cheers, >> AK >> > > You're worrying too much. It all happens automagically. Set up dhcp-helper > to listen for broadcasts on the correct interface and bounce them to > dnsmasq. When dhcp-helper does this, it puts the address of the interface on > which the broadcast was received into the packet, in the giaddr field. When > dnsmasq gets a packet with giaddr set, it uses that address to decide which > subnet to allocate an address on, not the interface that dnsmasq received > the packet on. > > So: > > dnsmasq, just list all the subnets you will need as dhcp-ranges. > > dhcp-helper, select the interfaces to listen for broadcasts using -i > and/or -e and tell dhcp-helper where to send the > packets to with -s > > If the dnsmasq server is multi-homed you can use any of its addresses, as > long as they are routable from the relay. The address of any interface that > dhcp-helper is listening on must be routable from the host running dnsmasq. > > HTH > > Simon. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090718/e501fcf2/attachment.htm From dnsmasq.list at michaelrack.de Sun Jul 19 14:32:36 2009 From: dnsmasq.list at michaelrack.de (Michael Rack) Date: Sun, 19 Jul 2009 15:32:36 +0200 Subject: [Dnsmasq-discuss] Please export GIADDR / Gateway-IP-Address to ENV Message-ID: <4A632074.4060402@michaelrack.de> Hi Simon, can you please export the giaddr / gateway-ip-address as a enviroment variable to use it with the DHCP-Script? I have to know witch Outdoor-Access-Unit is requesting for an ip-address in my MySQL-Database for later application. I have try to implement the function in helper.c but i am not sure how to do this. Michael. From lslofstra at hotmail.com Sun Jul 19 15:01:03 2009 From: lslofstra at hotmail.com (Lammert Slofstra) Date: Sun, 19 Jul 2009 14:01:03 +0000 Subject: [Dnsmasq-discuss] ext. tftpserver doesn't boot Message-ID: First let me explain te situation : I've got a Asus router which is running dnsmasq en tftp-hpa where each client that makes contact with the asus is booting fine. With this line : dhcp-boot=pxelinux.0,asus,192.168.1.1 On a other server i've got also tftp-hpa running where no client can reach the tftp server. With this line : dhcp-boot=pxelinux.0,,192.168.1.98 On the client a only see TFTP. filesize = 0 buffsize= something I think I missed something because too me it's like the client is searching on the asus for a tftpboot server but the config file explicity says the tftpboot server is on 192.168.1.98 so it tries something and then gives a timeout after sometime. When I'll do a tftp localhost on the other server an then a get pxelinux.0 I'll perfectly receive the file so the tftp server is running fine. What did I configured wrong in dnsmasq.conf ? Gr. Lammert _________________________________________________________________ Nieuw: onbeperkte opslagruimte in Windows Live Hotmail http://mail.live.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090719/947077ec/attachment.htm From simon at thekelleys.org.uk Mon Jul 20 15:19:41 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Mon, 20 Jul 2009 15:19:41 +0100 Subject: [Dnsmasq-discuss] Please export GIADDR / Gateway-IP-Address to ENV In-Reply-To: <4A632074.4060402@michaelrack.de> References: <4A632074.4060402@michaelrack.de> Message-ID: <4A647CFD.9070509@thekelleys.org.uk> Michael Rack wrote: > Hi Simon, > > can you please export the giaddr / gateway-ip-address as a enviroment > variable to use it with the DHCP-Script? > > I have to know witch Outdoor-Access-Unit is requesting for an ip-address > in my MySQL-Database for later application. > > I have try to implement the function in helper.c but i am not sure how > to do this. > Try http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.50test9.tar.gz the variable is called DHCP_RELAY_ADDRESS. Note that this information isn't always available, since it's not stored in the leases file and a configured client doesn't have to use the relay: it can talk to the server direct. Cheers, Simon. From simon at thekelleys.org.uk Mon Jul 20 15:22:34 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Mon, 20 Jul 2009 15:22:34 +0100 Subject: [Dnsmasq-discuss] ext. tftpserver doesn't boot In-Reply-To: References: Message-ID: <4A647DAA.1070106@thekelleys.org.uk> Lammert Slofstra wrote: > First let me explain te situation : > > I've got a Asus router which is running dnsmasq en tftp-hpa where each > client that makes contact with the asus is booting fine. > With this line : > dhcp-boot=pxelinux.0,asus,192.168.1.1 > > On a other server i've got also tftp-hpa running where no client can > reach the tftp server. > With this line : > dhcp-boot=pxelinux.0,,192.168.1.98 > > On the client a only see > > TFTP. > > filesize = 0 buffsize= something > > I think I missed something because too me it's like the client is > searching on the asus for a tftpboot server but the config file > explicity says the tftpboot server is on 192.168.1.98 so it tries > something and then gives a timeout after sometime. > When I'll do a tftp localhost on the other server an then a get > pxelinux.0 I'll perfectly receive the file so the tftp server is running > fine. > > What did I configured wrong in dnsmasq.conf ? > There are lots of buggy PXE ROMS out there that assume the TFTP server is at the same IP address as the DHCP server, even if given a different address by the DHCP server. That could explain what you are seeing. Cheers, Simon. From lslofstra at hotmail.com Tue Jul 21 20:13:12 2009 From: lslofstra at hotmail.com (Lammert Slofstra) Date: Tue, 21 Jul 2009 19:13:12 +0000 Subject: [Dnsmasq-discuss] ext. tftpserver doesn't boot In-Reply-To: <4A647DAA.1070106@thekelleys.org.uk> References: <4A647DAA.1070106@thekelleys.org.uk> Message-ID: > There are lots of buggy PXE ROMS out there that assume the TFTP server > is at the same IP address as the DHCP server, even if given a different > address by the DHCP server. > That could explain what you are seeing. > > > Cheers, > > Simon. > Thanks for the info I shall try with a tftp-server on the dhcp-server only for now. Gr, Lammert _________________________________________________________________ 25GB gratis online harde schijf http://skydrive.live.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090721/fc343ec6/attachment.htm From mailgabriel at gmail.com Tue Jul 21 21:23:00 2009 From: mailgabriel at gmail.com (gabriel) Date: Tue, 21 Jul 2009 22:23:00 +0200 Subject: [Dnsmasq-discuss] dhcp address allocation Message-ID: <20090721202300.GA6670@deepthought.lh2.lan> hi, a few months ago i found dnsmasq as a comfortable replacement for my dhcp3-server, bind9 with ddns setup. but one thing i am currently missing: the dhcp server from isc tries to provide the same ip address to a client. even if the client disconnects and afterwards connects again to the network the server looks up in the leases file for the outdated ticked an tries to keep its ip. if i didn't got it totally confused this is not the case for dnsmasq - in the sources i found a simple increment for the ip address after some validity and consistency checks were passed. so my question finally is: is it possible to get a similar behaviour of dnsmasq without switching to fixed addresses? actually i use arpwatch to detect new clients on my network and since the ip addresses from the clients permanently change this is not possible anymore. thanks for reply in advance, gabriel -- gpg/pgp schl?ssel (id 0x4BBD6B8F) unter: http://pgpkeys.pca.dfn.de/pks/lookup?search=0x4BBD6B8F&op=vindex -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090721/cded3058/attachment.pgp From simon at thekelleys.org.uk Wed Jul 22 07:57:11 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Wed, 22 Jul 2009 07:57:11 +0100 Subject: [Dnsmasq-discuss] dhcp address allocation In-Reply-To: <20090721202300.GA6670@deepthought.lh2.lan> References: <20090721202300.GA6670@deepthought.lh2.lan> Message-ID: <4A66B847.1010905@thekelleys.org.uk> gabriel wrote: > hi, > a few months ago i found dnsmasq as a comfortable replacement for my > dhcp3-server, bind9 with ddns setup. but one thing i am currently missing: > > the dhcp server from isc tries to provide the same ip address to a client. > > even if the client disconnects and afterwards connects again to the network > the server looks up in the leases file for the outdated ticked an tries to > keep its ip. if i didn't got it totally confused this is not the case for > dnsmasq - in the sources i found a simple increment for the ip address after > some validity and consistency checks were passed. > > so my question finally is: is it possible to get a similar behaviour of > dnsmasq without switching to fixed addresses? > > actually i use arpwatch to detect new clients on my network and since the ip > addresses from the clients permanently change this is not possible anymore. > > > thanks for reply in advance, > gabriel > Either you're looking at a _very_ old version of dnsmasq or you've misunderstood the source. Dnsmasq uses a hash of the MAC address to do IP address allocation, precisely so that the IP address of any host can remain constant, without having to retain a historical database of leases like the ISC daemon. The increment code is there just to deal with hash collisions, when two clients hash to the same IP address. Is your DHCP address range small compared to the number of clients? If so try increasing it so that hash collisions are less likely. HTH Simon. From stefano.bridi at gmail.com Fri Jul 24 09:54:10 2009 From: stefano.bridi at gmail.com (Stefano Bridi) Date: Fri, 24 Jul 2009 10:54:10 +0200 Subject: [Dnsmasq-discuss] "random" problem with name resolution Message-ID: Hi all, first of all thanks for the wonderful tool! I have a problem with the dns part of dnsmasq: sometimes does not resolve hostnames. The machine on which dnsmasq run is a Debian Lenny firewall between lan,dmz,internet and some other private network with some openVPN tunnel on board... version of dnsmasq is 2.45-1 The firewall itself is configured to resolve the name asking to dnsmasq. (127.0.0.1) The dnsmasq.conf is: ########################################### no-resolv server=/ctn.mydomain.tld/CTN.MYDOMAIN.TLD DNS SERVER server=ISP DNS 1 server=ISP DNS 2 server=ISP DNS 3 no-dhcp-interface=eth2 no-dhcp-interface=eth3 no-hosts addn-hosts=/etc/hosts.dnsmasq expand-hosts domain=mydomain.tld dhcp-range=.......... dhcp-host=............. dhcp-host=............. dhcp-host=............. dhcp-host=............. dhcp-option=3,0.0.0.0 dhcp-option=42,0.0.0.0 dhcp-option=44,LAN WINS SERVER dhcp-authoritative cache-size=4096 no-negcache log-queries log-async query-port=0 ########################################### where "CTN.MYDOMAIN.TLD DNS SERVER" "ISP DNS *" "LAN WINS SERVER" are the correct value. Usually all works fine but sometimes the dnsmasq doesn't resolve some hostname and in the logs I find: ... Jul 20 13:33:14 fw00 dnsmasq[15606]: query[A] pmi.mydomain.tld from 10.x.x.249 Jul 20 13:33:14 fw00 dnsmasq[15606]: forwarded pmi.mydomain.tld to ISP DNS 1 Jul 20 13:33:14 fw00 dnsmasq[15606]: forwarded pmi.mydomain.tld to ISP DNS 2 Jul 20 13:33:14 fw00 dnsmasq[15606]: forwarded pmi.mydomain.tld to ISP DNS 3 Jul 20 13:33:14 fw00 dnsmasq[15606]: reply pmi.mydomain.tld is ... while some seconds (in this case minutes) after It works. ... Jul 20 13:35:07 fw00 dnsmasq[15606]: query[A] pmi.mydomain.tld from 10.x.x.249 Jul 20 13:35:07 fw00 dnsmasq[15606]: forwarded pmi.mydomain.tld to ISP DNS 1 Jul 20 13:35:07 fw00 dnsmasq[15606]: reply pmi.mydomain.tld is Jul 20 13:35:07 fw00 dnsmasq[15606]: reply web002.mydomain.tld is x.x.x.228 ... Obviously the network connection is always on and there are no other known problem. The problem seems to manifest only with hostname with domain=mydomain.tld or other domain hosted on the same public dns server. Checking with dig the server that before had problems I see something like this: # dig pmi.mydomain.tld ; <<>> DiG 9.5.1-P2 <<>> pmi.mydomain.tld ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16903 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;pmi.mydomain.tld. IN A ;; ANSWER SECTION: pmi.mydomain.tld. 3600 IN CNAME web002.mydomain.tld. web002.mydomain.tld. 86400 IN A x.x.x.228 ;; AUTHORITY SECTION: mydomain.tld. 8400 IN NS ns00.mydomain.tld. mydomain.tld. 8400 IN NS ns02.mydomain.tld. ;; ADDITIONAL SECTION: ns00.mydomain.tld. 86400 IN A x.x.x.4 ns02.mydomain.tld. 8400 IN A y.y.y.148 ;; Query time: 24 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jul 24 10:21:39 2009 ;; MSG SIZE rcvd: 141 Where SERVER: 127.0.0.1#53(127.0.0.1) is the dnsmasq Could be a problem the different TTL ? any idea? thanks stef P.S.: At the moment I'm trying to "patch" with dnsmasq that ask to a dedicated pdnsd that act as a recursive dns cache server. In the eventuality that this sandwich setup solve the problem... In your opinion can I gain other advantage/problem? From stefano.bridi at gmail.com Fri Jul 24 11:00:03 2009 From: stefano.bridi at gmail.com (Stefano Bridi) Date: Fri, 24 Jul 2009 12:00:03 +0200 Subject: [Dnsmasq-discuss] "random" problem with name resolution In-Reply-To: <99024f5f0907240240q65dab2fdoe2b9b7fd32c5625a@mail.gmail.com> References: <99024f5f0907240240q65dab2fdoe2b9b7fd32c5625a@mail.gmail.com> Message-ID: On Fri, Jul 24, 2009 at 11:40 AM, Kiswono Prayogo wrote: > yes, i had the same thing before i join this mailing list yesterday, > the solution is to remove all server in /etc/resolv.conf that block your > recursive queries, > how to know which one? by starting the dnsmasq in debug mode.. (i did that > yesterday ^^) > Regards, > GB > On Fri, Jul 24, 2009 at 3:54 PM, Stefano Bridi > wrote: >> >> Hi all, first of all thanks for the wonderful tool! >> I have a problem with the dns part of dnsmasq: sometimes does not >> resolve hostnames. ... in resolv.conf I have only nameserver 127.0.0.1 So I think that you are pointing me to the "server=" entry in the dnsmasq file... What I don't understand is Why only sometimes? And why when it fails dnsmasq ask to ALL the server and reply only with the [A] and not the related [PTR] record? I'm sorry if somebody else already answer yesterday but I don't see the mail after 22/7/2009 in the archive and subscribed today;) thanks stef From ranceh at gmail.com Fri Jul 24 11:09:32 2009 From: ranceh at gmail.com (Rance Hall) Date: Fri, 24 Jul 2009 05:09:32 -0500 Subject: [Dnsmasq-discuss] "random" problem with name resolution In-Reply-To: References: Message-ID: <845c0f80907240309y78714959ndab76ce4139f596d@mail.gmail.com> On Fri, Jul 24, 2009 at 3:54 AM, Stefano Bridi wrote: > Hi all, first of all thanks for the wonderful tool! > I have a problem with the dns part of dnsmasq: sometimes does not > resolve hostnames. > The machine on which dnsmasq run is a Debian Lenny firewall between > lan,dmz,internet and some other private network with some openVPN > tunnel on board... version of dnsmasq is 2.45-1 > > The firewall itself is configured to resolve the name asking to > dnsmasq. (127.0.0.1) > > The dnsmasq.conf is: > ########################################### > no-resolv > server=/ctn.mydomain.tld/CTN.MYDOMAIN.TLD DNS SERVER > server=ISP DNS 1 > server=ISP DNS 2 > server=ISP DNS 3 > no-dhcp-interface=eth2 > no-dhcp-interface=eth3 > no-hosts > addn-hosts=/etc/hosts.dnsmasq > expand-hosts > domain=mydomain.tld > dhcp-range=.......... > dhcp-host=............. > dhcp-host=............. > dhcp-host=............. > dhcp-host=............. > dhcp-option=3,0.0.0.0 > dhcp-option=42,0.0.0.0 > dhcp-option=44,LAN WINS SERVER > dhcp-authoritative > cache-size=4096 > no-negcache > log-queries > log-async > query-port=0 > ########################################### > where "CTN.MYDOMAIN.TLD DNS SERVER" "ISP DNS *" "LAN WINS SERVER" are > the correct value. There are two things that I want to point you to: 1) the local=/domain.tld/ option if you specify this option correctly then members of that domain are never forwarded to isp. This option will fix your problem of forwarding names to the public internet that dont exist. and should speed things up right off. 2) while the above is good advice, its not complete, it doesnt fix the problem of dnsmasq not knowing about the boxes on the localnet in the first place. On its face, I'd say that this is a configuration error. In all my years of using dnsmasq Ive never seen this problem on a otherwise correctly configured dnsmasq that wasnt my fault. the way you have dnsmasq configured local queries only come from one of two places, the alternate host file you specified, and the dhcp leases file. Make absolutely sure that the host you are occasionally having trouble with is actually present in either one of these files. I suspect it is not present at the point you are having the trouble. HTH Rance From ranceh at gmail.com Fri Jul 24 11:15:32 2009 From: ranceh at gmail.com (Rance Hall) Date: Fri, 24 Jul 2009 05:15:32 -0500 Subject: [Dnsmasq-discuss] "random" problem with name resolution In-Reply-To: <845c0f80907240309y78714959ndab76ce4139f596d@mail.gmail.com> References: <845c0f80907240309y78714959ndab76ce4139f596d@mail.gmail.com> Message-ID: <845c0f80907240315q282fb1ccp10d5e4e0045df589@mail.gmail.com> On Fri, Jul 24, 2009 at 5:09 AM, Rance Hall wrote: > On Fri, Jul 24, 2009 at 3:54 AM, Stefano Bridi wrote: >> Hi all, first of all thanks for the wonderful tool! >> I have a problem with the dns part of dnsmasq: sometimes does not >> resolve hostnames. > There are two things that I want to point you to: > > 1) the local=/domain.tld/ option > > if you specify this option correctly then members of that domain are > never forwarded to isp. ?This option will fix your problem of > forwarding names to the public internet that dont exist. ?and should > speed things up right off. > > 2) while the above is good advice, its not complete, it doesnt fix the > problem of dnsmasq not knowing about the boxes on the localnet in the > first place. > > On its face, I'd say that this is a configuration error. ?In all my > years of using dnsmasq Ive never seen this problem on a otherwise > correctly configured dnsmasq that wasnt my fault. > > the way you have dnsmasq configured local queries only come from one > of two places, the alternate host file you specified, and the dhcp > leases file. > > Make absolutely sure that the host you are occasionally having trouble > with is actually present in either one of these files. ?I suspect it > is not present at the point you are having the trouble. > > HTH > > Rance > Oh and I forgot one other thing, I use TWO resolv.conf files Rather than listing them in the config file I have a /etc/resolv.conf file that points the server box back to itself as you do, But I also have a /etc/resolv.conf.forwards file that has the nameservers from the isp in the proper resolv.conf format. then I dont have the entries in the config file. Its not that one way is better than the other, but I find that its easier to troubleshoot problems like this when you know exactly which configuration file is causing you problems and the fact that each file is not that large so it makes mistakes easier to spot. Just a thought. HTH From simon at thekelleys.org.uk Fri Jul 24 12:12:45 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Fri, 24 Jul 2009 12:12:45 +0100 Subject: [Dnsmasq-discuss] "random" problem with name resolution In-Reply-To: References: Message-ID: <4A69972D.5090501@thekelleys.org.uk> Stefano Bridi wrote: > Hi all, first of all thanks for the wonderful tool! > I have a problem with the dns part of dnsmasq: sometimes does not > resolve hostnames. > The machine on which dnsmasq run is a Debian Lenny firewall between > lan,dmz,internet and some other private network with some openVPN > tunnel on board... version of dnsmasq is 2.45-1 > > The firewall itself is configured to resolve the name asking to > dnsmasq. (127.0.0.1) > > The dnsmasq.conf is: > ########################################### > no-resolv > server=/ctn.mydomain.tld/CTN.MYDOMAIN.TLD DNS SERVER > server=ISP DNS 1 > server=ISP DNS 2 > server=ISP DNS 3 > no-dhcp-interface=eth2 > no-dhcp-interface=eth3 > no-hosts > addn-hosts=/etc/hosts.dnsmasq > expand-hosts > domain=mydomain.tld > dhcp-range=.......... > dhcp-host=............. > dhcp-host=............. > dhcp-host=............. > dhcp-host=............. > dhcp-option=3,0.0.0.0 > dhcp-option=42,0.0.0.0 > dhcp-option=44,LAN WINS SERVER > dhcp-authoritative > cache-size=4096 > no-negcache > log-queries > log-async > query-port=0 > ########################################### > where "CTN.MYDOMAIN.TLD DNS SERVER" "ISP DNS *" "LAN WINS SERVER" are > the correct value. > Usually all works fine but sometimes the dnsmasq doesn't resolve some > hostname and in the logs I find: > ... > Jul 20 13:33:14 fw00 dnsmasq[15606]: query[A] pmi.mydomain.tld from 10.x.x.249 > Jul 20 13:33:14 fw00 dnsmasq[15606]: forwarded pmi.mydomain.tld to ISP DNS 1 > Jul 20 13:33:14 fw00 dnsmasq[15606]: forwarded pmi.mydomain.tld to ISP DNS 2 > Jul 20 13:33:14 fw00 dnsmasq[15606]: forwarded pmi.mydomain.tld to ISP DNS 3 > Jul 20 13:33:14 fw00 dnsmasq[15606]: reply pmi.mydomain.tld is > ... > while some seconds (in this case minutes) after It works. > ... > Jul 20 13:35:07 fw00 dnsmasq[15606]: query[A] pmi.mydomain.tld from 10.x.x.249 > Jul 20 13:35:07 fw00 dnsmasq[15606]: forwarded pmi.mydomain.tld to ISP DNS 1 > Jul 20 13:35:07 fw00 dnsmasq[15606]: reply pmi.mydomain.tld is > Jul 20 13:35:07 fw00 dnsmasq[15606]: reply web002.mydomain.tld is x.x.x.228 > ... > > Obviously the network connection is always on and there are no other > known problem. > > The problem seems to manifest only with hostname with > domain=mydomain.tld or other domain hosted on the same public dns > server. Checking with dig the server that before had problems I see > something like this: > > # dig pmi.mydomain.tld > > ; <<>> DiG 9.5.1-P2 <<>> pmi.mydomain.tld > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16903 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 > > ;; QUESTION SECTION: > ;pmi.mydomain.tld. IN A > > ;; ANSWER SECTION: > pmi.mydomain.tld. 3600 IN CNAME web002.mydomain.tld. > web002.mydomain.tld. 86400 IN A x.x.x.228 > > ;; AUTHORITY SECTION: > mydomain.tld. 8400 IN NS ns00.mydomain.tld. > mydomain.tld. 8400 IN NS ns02.mydomain.tld. > > ;; ADDITIONAL SECTION: > ns00.mydomain.tld. 86400 IN A x.x.x.4 > ns02.mydomain.tld. 8400 IN A y.y.y.148 > > ;; Query time: 24 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Fri Jul 24 10:21:39 2009 > ;; MSG SIZE rcvd: 141 > > Where SERVER: 127.0.0.1#53(127.0.0.1) is the dnsmasq > > Could be a problem the different TTL ? > > any idea? My guess is that when it goes wrong, the upstream server is returning the CNAME record, but not the A record. That's the most likely explanationf for the log messages you are seeing. I've never found an actual standard that says what the semantics of this are, but practically, all resolvers, when they ask for the A record for and get back CNAME without the corresponding A 1.2.3.4 treat this to mean the there is no A record for target, and don't try a query for A Dnsmasq will just be passing this reply straight through, so the resolver which made the query will behave in this way. This looks like an upstream server problem. Making the TTLs equal might be enough to solve it. > P.S.: > At the moment I'm trying to "patch" with dnsmasq that ask to a > dedicated pdnsd that act as a recursive dns cache server. In the > eventuality that this sandwich setup solve the problem... In your > opinion can I gain other advantage/problem? Given the above, that may well be a good solution. Cheers, Simon. > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From morac99-lists at yahoo.com Sat Jul 25 17:20:46 2009 From: morac99-lists at yahoo.com (Mike K.) Date: Sat, 25 Jul 2009 09:20:46 -0700 (PDT) Subject: [Dnsmasq-discuss] Question about the server option Message-ID: <645244.64328.qm@web31803.mail.mud.yahoo.com> I'm trying to use the "-S" option to use a different dns server for an entire domain. In this case, llnw.net (Limelight Networks). The reason being that my local Limelight server is having problems so I want to be redirected to a different one, but I don't want to change my dns for all other geodistributed severs (Akamai, Yahoo, etc). I tried adding "server=/llnw.net/4.2.2.1" to the dnsmasq.conf file, but that only works for *.llnw.net. It doesn't work for *.*.llnw.net which it what Limelight uses (amazon-128.fcod.llnwd.net for example). Is there any existing way to do what I'm trying to do? If not could an option be added for this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090725/064f44f7/attachment.htm From richardvoigt at gmail.com Sat Jul 25 19:49:19 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Sat, 25 Jul 2009 13:49:19 -0500 Subject: [Dnsmasq-discuss] Question about the server option In-Reply-To: <645244.64328.qm@web31803.mail.mud.yahoo.com> References: <645244.64328.qm@web31803.mail.mud.yahoo.com> Message-ID: <2e59e6970907251149m22290a2eme9099b78dc3f1c2f@mail.gmail.com> Does the server you specify actually answer the query, or does it reply by delegating to a different server? If the latter, I don't see a way for dnsmasq to override. And is the trailing d of "llnwd" in your example a typo or are you maybe missing some related domains? On Sat, Jul 25, 2009 at 11:20 AM, Mike K. wrote: > I'm trying to use the "-S" option to use a different dns server for an > entire domain.? In this case, llnw.net (Limelight Networks).? The reason > being that my local Limelight server is having problems so I want to be > redirected to a different one, but I don't want to change my dns for all > other geodistributed severs (Akamai, Yahoo, etc). > > I tried adding "server=/llnw.net/4.2.2.1" to the dnsmasq.conf file, but that > only works for *.llnw.net.? It doesn't work for *.*.llnw.net which it what > Limelight uses (amazon-128.fcod.llnwd.net for example). > > Is there any existing way to do what I'm trying to do?? If not could an > option be added for this? > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > From morac99-lists at yahoo.com Sat Jul 25 21:25:46 2009 From: morac99-lists at yahoo.com (Mike K.) Date: Sat, 25 Jul 2009 13:25:46 -0700 (PDT) Subject: [Dnsmasq-discuss] Question about the server option In-Reply-To: <2e59e6970907251149m22290a2eme9099b78dc3f1c2f@mail.gmail.com> References: <645244.64328.qm@web31803.mail.mud.yahoo.com> <2e59e6970907251149m22290a2eme9099b78dc3f1c2f@mail.gmail.com> Message-ID: <279990.5818.qm@web31804.mail.mud.yahoo.com> It wasn't a typo and that's why it wasn't working. Basically I made a mistake. Everything's good. ----- Original Message ---- > From: "richardvoigt at gmail.com" > To: Mike K. > Cc: dnsmasq-discuss at lists.thekelleys.org.uk > Sent: Saturday, July 25, 2009 2:49:19 PM > Subject: Re: [Dnsmasq-discuss] Question about the server option > > Does the server you specify actually answer the query, or does it > reply by delegating to a different server? If the latter, I don't see > a way for dnsmasq to override. > > And is the trailing d of "llnwd" in your example a typo or are you > maybe missing some related domains? > > On Sat, Jul 25, 2009 at 11:20 AM, Mike K.wrote: > > I'm trying to use the "-S" option to use a different dns server for an > > entire domain. In this case, llnw.net (Limelight Networks). The reason > > being that my local Limelight server is having problems so I want to be > > redirected to a different one, but I don't want to change my dns for all > > other geodistributed severs (Akamai, Yahoo, etc). > > > > I tried adding "server=/llnw.net/4.2.2.1" to the dnsmasq.conf file, but that > > only works for *.llnw.net. It doesn't work for *.*.llnw.net which it what > > Limelight uses (amazon-128.fcod.llnwd.net for example). > > > > Is there any existing way to do what I'm trying to do? If not could an > > option be added for this? > > > > _______________________________________________ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss at lists.thekelleys.org.uk > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > > From james.meyer at operamail.com Sun Jul 26 02:36:02 2009 From: james.meyer at operamail.com (james meyer) Date: Sat, 25 Jul 2009 20:36:02 -0500 Subject: [Dnsmasq-discuss] Dnsmasq is not sending the hostname to the client. Message-ID: <200907252036.03233.james.meyer@operamail.com> Hello, I am attempting to make dnsmasq send hostnames to a dhcp client when it makes a request. While working the Roy of dhcpcd fame we discovered that dnsmasq doesn't send the hostname when the dhcp client sends a hostname to the server. Howerver the the client doesn't send a hostname then dnsmasq will respond with the correct hostname as defined in the dnsmasq.conf. I have run into a situation where I always want to know the hostname from dnsmasq regardless of what the client is going to do with it. Is there a setting within the dnsmasq.conf file to enable this ability? -james dnsmasq.conf # cat /etc/dnsmasq.conf pid-file=/var/run/dnsmasq.pid interface=br0 resolv-file=/etc/resolv.dnsmasq addn-hosts=/etc/hosts.dnsmasq expand-hosts min-port=4096 dhcp-range=192.168.1.101,192.168.1.250,255.255.255.0,10080m dhcp-option=3,192.168.1.1 dhcp-lease-max=255 dhcp-authoritative dhcp-host=00:E0:81:B3:12:FA,192.168.1.5,10080m dhcp-host=00:1F:C6:09:BF:2F,192.168.1.101,10080m dhcp-host=00:14:FD:12:50:54,192.168.1.114,10080m local=/lan/ domain=lan dhcp-option=6,192.168.1.1 dhcp-host=00:0C:29:CF:02:FC,192.168.1.205,fred From james.meyer at operamail.com Mon Jul 27 02:34:22 2009 From: james.meyer at operamail.com (james meyer) Date: Sun, 26 Jul 2009 20:34:22 -0500 Subject: [Dnsmasq-discuss] Dnsmasq is not sending the hostname to the client. In-Reply-To: <4A6C8702.9080907@thekelleys.org.uk> References: <200907252036.03233.james.meyer@operamail.com> <4A6C8702.9080907@thekelleys.org.uk> Message-ID: <200907262034.22669.james.meyer@operamail.com> On Sunday 26 July 2009, Simon Kelley wrote: > james meyer wrote: > > Hello, > > I am attempting to make dnsmasq send hostnames to a dhcp client when it makes > > a request. While working the Roy of dhcpcd fame we discovered that dnsmasq > > doesn't send the hostname when the dhcp client sends a hostname to the > > server. Howerver the the client doesn't send a hostname then dnsmasq will > > respond with the correct hostname as defined in the dnsmasq.conf. > > > > I have run into a situation where I always want to know the hostname from > > dnsmasq regardless of what the client is going to do with it. Is there a > > setting within the dnsmasq.conf file to enable this ability? > > > > -james > > _______________________________________________ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss at lists.thekelleys.org.uk > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > I think the dhcp-ignore-names does what you want. > > > HTH > > Simon. > > pid-file=/var/run/dnsmasq.pid Simon, I tried adding the dhcp-ignore-names option as you suggested, but it didn't make a difference. Running dhcpcd -Td eth0 doesn't print any suggested hostnames from dnsmasq, unless I tell the client to not send a hostname. Is it desired behaviour to only send the client a hostname under certain conditions? It would really help me out if it always sent it, and then let the client decide what to do with it. -james dnsmasq.conf: interface=br0 resolv-file=/etc/resolv.dnsmasq addn-hosts=/etc/hosts.dnsmasq expand-hosts min-port=4096 dhcp-range=192.168.1.101,192.168.1.250,255.255.255.0,10080m dhcp-option=3,192.168.1.1 dhcp-lease-max=255 dhcp-authoritative dhcp-host=00:E0:81:B3:12:FA,192.168.1.5,10080m dhcp-host=00:1F:C6:09:BF:2F,192.168.1.101,10080m dhcp-host=00:14:FD:12:50:54,192.168.1.114,10080m local=/lan/ domain=lan dhcp-option=6,192.168.1.1 dhcp-ignore-names=00:0C:29:CF:02:FC dhcp-host=00:0C:29:CF:02:FC,192.168.1.206,fred From richardvoigt at gmail.com Mon Jul 27 08:18:22 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Mon, 27 Jul 2009 02:18:22 -0500 Subject: [Dnsmasq-discuss] Dnsmasq is not sending the hostname to the client. In-Reply-To: <200907262034.22669.james.meyer@operamail.com> References: <200907252036.03233.james.meyer@operamail.com> <4A6C8702.9080907@thekelleys.org.uk> <200907262034.22669.james.meyer@operamail.com> Message-ID: <2e59e6970907270018n7774fdd2p9ac2c7d1e8864d2b@mail.gmail.com> > Simon, > I tried adding the dhcp-ignore-names ?option as you suggested, but it didn't > make a difference. I don't think that dhcp-ignore-names matches against a MAC address as you've tried to do, it uses a "network-id" instead (although the dhcp-host line can map between them). Have you tried ignoring all names first to see if it has the desired effect? Then you can restrict it if needed after you know whether it works. > Running dhcpcd -Td eth0 doesn't print any suggested hostnames from dnsmasq, > unless I tell the client to not send a hostname. > > Is it desired behaviour to only send the client a hostname under certain > conditions? ?It would really help me out if it always sent it, and then let > the client decide what to do with it. > > -james > > dnsmasq.conf: > > interface=br0 > resolv-file=/etc/resolv.dnsmasq > addn-hosts=/etc/hosts.dnsmasq > expand-hosts > min-port=4096 > dhcp-range=192.168.1.101,192.168.1.250,255.255.255.0,10080m > dhcp-option=3,192.168.1.1 > dhcp-lease-max=255 > dhcp-authoritative > dhcp-host=00:E0:81:B3:12:FA,192.168.1.5,10080m > dhcp-host=00:1F:C6:09:BF:2F,192.168.1.101,10080m > dhcp-host=00:14:FD:12:50:54,192.168.1.114,10080m > local=/lan/ > domain=lan > dhcp-option=6,192.168.1.1 > dhcp-ignore-names=00:0C:29:CF:02:FC > dhcp-host=00:0C:29:CF:02:FC,192.168.1.206,fred > > > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From richardvoigt at gmail.com Mon Jul 27 08:21:06 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Mon, 27 Jul 2009 02:21:06 -0500 Subject: [Dnsmasq-discuss] Dnsmasq is not sending the hostname to the client. In-Reply-To: <200907252036.03233.james.meyer@operamail.com> References: <200907252036.03233.james.meyer@operamail.com> Message-ID: <2e59e6970907270021m5f178d19y523ccbbdfbf6c6c1@mail.gmail.com> On Sat, Jul 25, 2009 at 8:36 PM, james meyer wrote: > Hello, > I am attempting to make dnsmasq send hostnames to a dhcp client when it makes > a request. ? While working the Roy of dhcpcd fame we discovered that dnsmasq > doesn't send the hostname ?when the dhcp client sends a hostname to the > server. ?Howerver the the client doesn't send a hostname then dnsmasq will > respond with the correct hostname as defined in the dnsmasq.conf. > > I have run into a situation where I always want to know the hostname from > dnsmasq regardless of what the client is going to do with it. ?Is there a > setting within the dnsmasq.conf file to enable this ability? > > -james > Maybe the client doesn't request a name if it already has one? Look at the parameter request list and --dhcp-option-force. From carlos at fisica.ufpr.br Mon Jul 27 15:05:25 2009 From: carlos at fisica.ufpr.br (Carlos Carvalho) Date: Mon, 27 Jul 2009 11:05:25 -0300 Subject: [Dnsmasq-discuss] Dnsmasq is not sending the hostname to the client. In-Reply-To: <2e59e6970907270018n7774fdd2p9ac2c7d1e8864d2b@mail.gmail.com> References: <200907252036.03233.james.meyer@operamail.com> <4A6C8702.9080907@thekelleys.org.uk> <200907262034.22669.james.meyer@operamail.com> <2e59e6970907270018n7774fdd2p9ac2c7d1e8864d2b@mail.gmail.com> Message-ID: <19053.46117.484562.871265@fisica.ufpr.br> richardvoigt at gmail.com (richardvoigt at gmail.com) wrote on 27 July 2009 02:18: >> Simon, >> I tried adding the dhcp-ignore-names ?option as you suggested, but it didn't >> make a difference. > >I don't think that dhcp-ignore-names matches against a MAC address as >you've tried to do, it uses a "network-id" instead (although the >dhcp-host line can map between them). Have you tried ignoring all >names first to see if it has the desired effect? Then you can >restrict it if needed after you know whether it works. >> Running dhcpcd -Td eth0 doesn't print any suggested hostnames from dnsmasq, >> unless I tell the client to not send a hostname. >> >> Is it desired behaviour to only send the client a hostname under certain >> conditions? ?It would really help me out if it always sent it, and then let >> the client decide what to do with it. You might also try dhcp-option-force. From james.meyer at operamail.com Mon Jul 27 15:29:15 2009 From: james.meyer at operamail.com (james meyer) Date: Mon, 27 Jul 2009 09:29:15 -0500 Subject: [Dnsmasq-discuss] Dnsmasq is not sending the hostname to the client. In-Reply-To: <2e59e6970907270018n7774fdd2p9ac2c7d1e8864d2b@mail.gmail.com> References: <200907252036.03233.james.meyer@operamail.com> <200907262034.22669.james.meyer@operamail.com> <2e59e6970907270018n7774fdd2p9ac2c7d1e8864d2b@mail.gmail.com> Message-ID: <200907270929.16150.james.meyer@operamail.com> On Monday 27 July 2009, richardvoigt at gmail.com wrote: > > Simon, > > I tried adding the dhcp-ignore-names option as you suggested, but it didn't > > make a difference. > > I don't think that dhcp-ignore-names matches against a MAC address as > you've tried to do, it uses a "network-id" instead (although the > dhcp-host line can map between them). Have you tried ignoring all > names first to see if it has the desired effect? Then you can > restrict it if needed after you know whether it works. > Tried adding the line dhcp-ignore-names without any network-id's. It did start ignoring names for other hosts, but didn't help me out in this situation. From james.meyer at operamail.com Mon Jul 27 16:12:34 2009 From: james.meyer at operamail.com (james meyer) Date: Mon, 27 Jul 2009 10:12:34 -0500 Subject: [Dnsmasq-discuss] Dnsmasq is not sending the hostname to the client. In-Reply-To: <2e59e6970907270021m5f178d19y523ccbbdfbf6c6c1@mail.gmail.com> References: <200907252036.03233.james.meyer@operamail.com> <2e59e6970907270021m5f178d19y523ccbbdfbf6c6c1@mail.gmail.com> Message-ID: <200907271012.34871.james.meyer@operamail.com> On Monday 27 July 2009, richardvoigt at gmail.com wrote: > On Sat, Jul 25, 2009 at 8:36 PM, james meyer wrote: > > Hello, > > I am attempting to make dnsmasq send hostnames to a dhcp client when it makes > > a request. While working the Roy of dhcpcd fame we discovered that dnsmasq > > doesn't send the hostname when the dhcp client sends a hostname to the > > server. Howerver the the client doesn't send a hostname then dnsmasq will > > respond with the correct hostname as defined in the dnsmasq.conf. > > > > I have run into a situation where I always want to know the hostname from > > dnsmasq regardless of what the client is going to do with it. Is there a > > setting within the dnsmasq.conf file to enable this ability? > > > > -james > > > > Maybe the client doesn't request a name if it already has one? Look > at the parameter request list and --dhcp-option-force. > The client is requesting the hostname, or at least the capture with wireshark says it is. From richardvoigt at gmail.com Mon Jul 27 16:36:08 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Mon, 27 Jul 2009 10:36:08 -0500 Subject: [Dnsmasq-discuss] Dnsmasq is not sending the hostname to the client. In-Reply-To: <200907270929.16150.james.meyer@operamail.com> References: <200907252036.03233.james.meyer@operamail.com> <200907262034.22669.james.meyer@operamail.com> <2e59e6970907270018n7774fdd2p9ac2c7d1e8864d2b@mail.gmail.com> <200907270929.16150.james.meyer@operamail.com> Message-ID: <2e59e6970907270836o53c50317r81fdd305deada980@mail.gmail.com> On Mon, Jul 27, 2009 at 9:29 AM, james meyer wrote: > On Monday 27 July 2009, richardvoigt at gmail.com wrote: >> > Simon, >> > I tried adding the dhcp-ignore-names ?option as you suggested, but it > didn't >> > make a difference. >> >> I don't think that dhcp-ignore-names matches against a MAC address as >> you've tried to do, it uses a "network-id" instead (although the >> dhcp-host line can map between them). ?Have you tried ignoring all >> names first to see if it has the desired effect? ?Then you can >> restrict it if needed after you know whether it works. >> > Tried adding the line dhcp-ignore-names without any network-id's. > It did start ignoring names for other hosts, but didn't help me out in this > situation. What version of dnsmasq are you using? From james.meyer at operamail.com Mon Jul 27 17:02:54 2009 From: james.meyer at operamail.com (james meyer) Date: Mon, 27 Jul 2009 11:02:54 -0500 Subject: [Dnsmasq-discuss] Dnsmasq is not sending the hostname to the client. In-Reply-To: <2e59e6970907270836o53c50317r81fdd305deada980@mail.gmail.com> References: <200907252036.03233.james.meyer@operamail.com> <200907270929.16150.james.meyer@operamail.com> <2e59e6970907270836o53c50317r81fdd305deada980@mail.gmail.com> Message-ID: <200907271102.54274.james.meyer@operamail.com> On Monday 27 July 2009, richardvoigt at gmail.com wrote: > On Mon, Jul 27, 2009 at 9:29 AM, james meyer wrote: > > On Monday 27 July 2009, richardvoigt at gmail.com wrote: > >> > Simon, > >> > I tried adding the dhcp-ignore-names option as you suggested, but it > > didn't > >> > make a difference. > >> > >> I don't think that dhcp-ignore-names matches against a MAC address as > >> you've tried to do, it uses a "network-id" instead (although the > >> dhcp-host line can map between them). Have you tried ignoring all > >> names first to see if it has the desired effect? Then you can > >> restrict it if needed after you know whether it works. > >> > > Tried adding the line dhcp-ignore-names without any network-id's. > > It did start ignoring names for other hosts, but didn't help me out in this > > situation. > > What version of dnsmasq are you using? > I have tried both 2.47 and 2.49. 2.47 is my preference as it's on my router running the tomato firmware. 2.49 is installed on my desktop for testing. What appears to be happening is 1) dhcpcd is requesting the hostname from dnsmasq (can be seen in the network capture) 2) dnsmasq does not respond with a hostname, unless dhcpcd sends a null hostname in the request. This also can be seen in the network capture I would like to know the suggested hostname regardless of if the client already has a hostname. From larzuf at gmail.com Mon Jul 27 17:24:45 2009 From: larzuf at gmail.com (Spencer Clark) Date: Mon, 27 Jul 2009 10:24:45 -0600 Subject: [Dnsmasq-discuss] DHCP options 60 and 43 Message-ID: <5683a3f0907270924x532dd3c1lb89a146083cabf69@mail.gmail.com> Hi all - Is there a way to force dnsmasq 2.49 to not send DHCP options 60 and 43? I've updated from 2.47 to 2.49. We've got an altiris imaging server here, and our clients can't PXE boot to the altiris server since I've updated dnsmasq. I've done wireshark captures from both 2.47 and 2.49 and noticed that 2.49 always sends options 60 and 43 even if I don't have any PXE-related options in the configuration. I am hoping that I am overlooking something simple! Thanks in advance. -Spencer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090727/06d7559d/attachment.htm From stefano.bridi at gmail.com Thu Jul 30 17:23:11 2009 From: stefano.bridi at gmail.com (Stefano Bridi) Date: Thu, 30 Jul 2009 18:23:11 +0200 Subject: [Dnsmasq-discuss] "random" problem with name resolution In-Reply-To: <4A69972D.5090501@thekelleys.org.uk> References: <4A69972D.5090501@thekelleys.org.uk> Message-ID: On Fri, Jul 24, 2009 at 1:12 PM, Simon Kelley wrote: > Stefano Bridi wrote: [snip] > My guess is that when it goes wrong, the upstream server is returning the > CNAME record, but not the A record. That's the most likely explanationf for > the log messages you are seeing. > > I've never found an actual standard that says what the semantics of this > are, but practically, all resolvers, when they ask for the A record for > and get back > > CNAME > > without the corresponding > > A 1.2.3.4 > > treat this to mean the there is no A record for target, and don't try a > query for A > > Dnsmasq will just be passing this reply straight through, so the resolver > which made the query will behave in this way. > > This looks like an upstream server problem. Making the TTLs equal might be > enough to solve it. I'll try... >> P.S.: >> At the moment I'm trying to "patch" with dnsmasq that ask to a >> dedicated pdnsd that act as a recursive dns cache server. In the >> eventuality that this sandwich setup solve the problem... In your >> opinion can I gain other advantage/problem? > > Given the above, that may well be a good solution. At the moment it seems to work properly but I'm still crossing my fingers ;) thanks stef From esj at harvee.org Mon Aug 3 16:38:21 2009 From: esj at harvee.org (Eric S. Johansson) Date: Mon, 03 Aug 2009 11:38:21 -0400 Subject: [Dnsmasq-discuss] remember the split horizon DNS problem with open VPN and network manager? Message-ID: <4A77046D.1030708@harvee.org> where you need to route queries for a specific domain to a specific name server. I had to migrate from Linux to Windows 7 (Linux speech recognition support just isn't there yet) and now, I am having the same problem that I had almost fixed in Linux. please tell me that somebody has ported dnsmasq to Windows and the port doesn't suck From richardvoigt at gmail.com Mon Aug 3 22:13:36 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Mon, 3 Aug 2009 16:13:36 -0500 Subject: [Dnsmasq-discuss] remember the split horizon DNS problem with open VPN and network manager? In-Reply-To: <4A77046D.1030708@harvee.org> References: <4A77046D.1030708@harvee.org> Message-ID: <2e59e6970908031413h130639aybccc350c1bdf9c58@mail.gmail.com> virtual machine and/or colinux? On Mon, Aug 3, 2009 at 10:38 AM, Eric S. Johansson wrote: > where you need to route queries for a specific domain to a specific name server. > ?I had to migrate from Linux to Windows 7 (Linux speech recognition support > just isn't there yet) and now, I am having the same problem that I had almost > fixed in Linux. > > please tell me that somebody has ported dnsmasq to Windows and the port doesn't suck > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From tmetro+dnsmasq at gmail.com Mon Aug 3 22:37:16 2009 From: tmetro+dnsmasq at gmail.com (Tom Metro) Date: Mon, 03 Aug 2009 17:37:16 -0400 Subject: [Dnsmasq-discuss] remember the split horizon DNS problem with open VPN and network manager? In-Reply-To: <4A77046D.1030708@harvee.org> References: <4A77046D.1030708@harvee.org> Message-ID: <4A77588C.3000804@gmail.com> Eric S. Johansson wrote: > where you need to route queries for a specific domain to a specific name server. > I had to migrate from Linux to Windows 7 (Linux speech recognition support > just isn't there yet) and now, I am having the same problem that I had almost > fixed in Linux. Have you looked at the thread titled "VPN DNS prioritization" from last month? The poster who started that thread indicated that the VPN support in Windows applies some rules by default so your DNS lookups don't get completely hijacked by the VPN. > please tell me that somebody has ported dnsmasq to Windows... You could aways run DD-WRT (which includes Dnsmasq) on a $30 router. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ From jd1008 at gmail.com Thu Aug 6 17:49:26 2009 From: jd1008 at gmail.com (JD) Date: Thu, 06 Aug 2009 09:49:26 -0700 Subject: [Dnsmasq-discuss] dnsmask problems/questions Message-ID: <4A7B0996.5080804@gmail.com> On Fedora11, dnsmasq-2.46-2.fc11.i586 : I have restart dnsmasq several times per day because firefox fails to resolv the url, and thunderbird fail to connect to the mailserver (gmail). I have to repeatedly run sudo service dnsmasq restart in order to get things working again. My /etc/resolv.dnsmasq contains search sbcglobal.net nameserver 151.164.8.201 nameserver 65.68.49.6 nameserver 66.73.20.40 nameserver 68.94.157.1 nameserver 68.94.156.1 And /etc/resolv.conf contains nameserver 127.0.0.1 And /etc/dnsmasq.conf contains only one setting: resolv-file=/etc/resolv.dnsmasq When I first boot up, dnsmasq is running, but with arguments that are not set in the dnsmasq.conf file. I do not know where it is getting those arguments. Also, after bootup, I cannot resolve ANY internet address. As I stated above, I have to sudu service dnsmasq restart in order to be able to resolve addresses. After the restart, ps -wwef | grep dnsmasq shows it running without ANY command line args, but works for a while only. So, I do not know what is wrong with the conf file. Any help would be appreciated. Cheers, JD -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090806/f8c67cf3/attachment.htm From tmetro+dnsmasq at gmail.com Thu Aug 6 19:04:06 2009 From: tmetro+dnsmasq at gmail.com (Tom Metro) Date: Thu, 06 Aug 2009 14:04:06 -0400 Subject: [Dnsmasq-discuss] dnsmask problems/questions In-Reply-To: <4A7B0996.5080804@gmail.com> References: <4A7B0996.5080804@gmail.com> Message-ID: <4A7B1B16.9080706@gmail.com> JD wrote: > When I first boot up, dnsmasq is running, but with arguments > that are not set in the dnsmasq.conf file. I do not know > where it is getting those arguments. Also, after bootup, > I cannot resolve ANY internet address. > As I stated above, I have to sudu service dnsmasq restart > in order to be able to resolve addresses. > After the restart, ps -wwef | grep dnsmasq shows it > running without ANY command line args, but works for > a while only. Check the list archives for a thread I started last month titled "multiple programs using UDP port 53." There's a chance you might have multiple programs listening on the DNS port. Carefully examine the output of "netstat -anp" and see what is listening on UDP port 53. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ From jd1008 at gmail.com Fri Aug 7 09:07:51 2009 From: jd1008 at gmail.com (JD) Date: Fri, 07 Aug 2009 01:07:51 -0700 Subject: [Dnsmasq-discuss] dnsmask problems/questions In-Reply-To: <4A7B0996.5080804@gmail.com> References: <4A7B0996.5080804@gmail.com> Message-ID: <4A7BE0D7.3000003@gmail.com> On 08/06/2009 09:49 AM, JD wrote: > On Fedora11, dnsmasq-2.46-2.fc11.i586 : > I have restart dnsmasq several times per day > because firefox fails to resolv the url, and > thunderbird fail to connect to the mailserver (gmail). > > I have to repeatedly run > sudo service dnsmasq restart > > in order to get things working again. > > My /etc/resolv.dnsmasq contains > > search sbcglobal.net > nameserver 151.164.8.201 > nameserver 65.68.49.6 > nameserver 66.73.20.40 > nameserver 68.94.157.1 > nameserver 68.94.156.1 > > And /etc/resolv.conf contains > nameserver 127.0.0.1 > > And /etc/dnsmasq.conf contains only one setting: > resolv-file=/etc/resolv.dnsmasq > > > When I first boot up, dnsmasq is running, but with arguments > that are not set in the dnsmasq.conf file. I do not know > where it is getting those arguments. Also, after bootup, > I cannot resolve ANY internet address. > As I stated above, I have to sudu service dnsmasq restart > in order to be able to resolve addresses. > After the restart, ps -wwef | grep dnsmasq shows it > running without ANY command line args, but works for > a while only. > > So, I do not know what is wrong with the conf file. > Any help would be appreciated. > > Cheers, > > JD > Tom asked me to do netstat -anp --program to see if there were other proceses listening on port 53. Well, turns out NO. Only dnsmasq is the process doing that: Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 5059/dnsmasq tcp 0 0 :::53 :::* LISTEN 5059/dnsmasq udp 0 0 0.0.0.0:53 0.0.0.0:* 5059/dnsmasq udp 0 0 :::53 :::* 5059/dnsmasq So, I am still having the problem of dnsmasq stops working after a few minutes. Thanks, JD -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090807/89078b0f/attachment.htm From tmetro+dnsmasq at gmail.com Fri Aug 7 17:41:26 2009 From: tmetro+dnsmasq at gmail.com (Tom Metro) Date: Fri, 07 Aug 2009 12:41:26 -0400 Subject: [Dnsmasq-discuss] dnsmask problems/questions In-Reply-To: <4A7BE0D7.3000003@gmail.com> References: <4A7B0996.5080804@gmail.com> <4A7BE0D7.3000003@gmail.com> Message-ID: <4A7C5936.9060000@gmail.com> JD wrote: > Well, turns out NO. Only dnsmasq is the process doing that: OK, good. Did you read over the message I referenced and the bug it linked to? The evidence so far suggests you're experiencing something different, but the symptoms you describes are a very close match, so I'd still double check that the system isn't running one of the other common DNS proxies or servers, like bind. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ From jd1008 at gmail.com Fri Aug 7 18:10:37 2009 From: jd1008 at gmail.com (JD) Date: Fri, 07 Aug 2009 10:10:37 -0700 Subject: [Dnsmasq-discuss] dnsmask problems/questions In-Reply-To: <4A7C5936.9060000@gmail.com> References: <4A7B0996.5080804@gmail.com> <4A7BE0D7.3000003@gmail.com> <4A7C5936.9060000@gmail.com> Message-ID: <4A7C600D.7060403@gmail.com> On 08/07/2009 09:41 AM, Tom Metro wrote: > JD wrote: >> Well, turns out NO. Only dnsmasq is the process doing that: > > OK, good. Did you read over the message I referenced and the bug it > linked to? The evidence so far suggests you're experiencing something > different, but the symptoms you describes are a very close match, so > I'd still double check that the system isn't running one of the other > common DNS proxies or servers, like bind. > > -Tom > I did read the thread. I have checked several times. I have no other program listening on port 53. ps -ef | grep bind rpc 1356 1 0 09:37 ? 00:00:00 rpcbind In fact here is the entire output of ps -wwef UID PID PPID C STIME TTY TIME CMD root 1 0 0 09:37 ? 00:00:01 /sbin/init root 2 0 0 09:37 ? 00:00:00 [kthreadd] root 3 2 0 09:37 ? 00:00:00 [ksoftirqd/0] root 4 2 0 09:37 ? 00:00:00 [watchdog/0] root 5 2 0 09:37 ? 00:00:00 [events/0] root 6 2 0 09:37 ? 00:00:00 [khelper] root 7 2 0 09:37 ? 00:00:00 [netns] root 8 2 0 09:37 ? 00:00:00 [kintegrityd/0] root 9 2 0 09:37 ? 00:00:00 [kblockd/0] root 10 2 0 09:37 ? 00:00:00 [kacpid] root 11 2 0 09:37 ? 00:00:00 [kacpi_notify] root 12 2 0 09:37 ? 00:00:00 [cqueue] root 13 2 0 09:37 ? 00:00:00 [ata/0] root 14 2 0 09:37 ? 00:00:00 [ata_aux] root 15 2 0 09:37 ? 00:00:00 [ksuspend_usbd] root 16 2 0 09:37 ? 00:00:00 [khubd] root 17 2 0 09:37 ? 00:00:00 [kseriod] root 18 2 0 09:37 ? 00:00:00 [pdflush] root 19 2 0 09:37 ? 00:00:00 [pdflush] root 20 2 0 09:37 ? 00:00:00 [kswapd0] root 21 2 0 09:37 ? 00:00:00 [aio/0] root 26 2 0 09:37 ? 00:00:00 [kpsmoused] root 27 2 0 09:37 ? 00:00:00 [kstriped] root 28 2 0 09:37 ? 00:00:00 [ksnapd] root 41 2 0 09:37 ? 00:00:00 [scsi_eh_0] root 42 2 0 09:37 ? 00:00:00 [scsi_eh_1] root 47 2 0 09:37 ? 00:00:00 [kjournald] root 56 2 0 09:37 ? 00:00:00 [kauditd] root 132 1 0 09:37 ? 00:00:00 /sbin/udevd -d root 860 2 0 09:37 ? 00:00:00 [pccardd] root 917 2 0 09:37 ? 00:00:00 [pccardd] root 929 2 0 09:37 ? 00:00:00 [scsi_eh_2] root 931 2 0 09:37 ? 00:00:00 [scsi_eh_3] root 993 2 0 09:37 ? 00:00:00 [kmpathd/0] root 994 2 0 09:37 ? 00:00:00 [kmpath_handlerd] root 1031 1 0 09:37 ? 00:00:13 /sbin/mount.ntfs-3g /dev/sda1 /sda1 -o rw,noexec,nosuid,nodev,user,uid=1008,gid=1008 root 1032 2 0 09:37 ? 00:00:00 [kjournald] root 1033 2 0 09:37 ? 00:00:00 [kjournald] root 1306 1 0 09:37 ? 00:00:00 auditd root 1308 1306 0 09:37 ? 00:00:00 /sbin/audispd root 1309 1308 0 09:37 ? 00:00:00 /usr/sbin/sedispatch root 1333 1 0 09:37 ? 00:00:00 rsyslogd -c 3 rpc 1356 1 0 09:37 ? 00:00:00 rpcbind rpcuser 1369 1 0 09:37 ? 00:00:00 rpc.statd root 1397 2 0 09:37 ? 00:00:00 [rpciod/0] root 1405 1 0 09:37 ? 00:00:00 rpc.idmapd dbus 1418 1 0 09:37 ? 00:00:00 dbus-daemon --system root 1427 1 0 09:37 ? 00:00:00 wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -ira0 -Dwext -B -f /var/log/wpa_supplicant.log avahi 1436 1 0 09:37 ? 00:00:00 avahi-daemon: running [linux.local] avahi 1437 1436 0 09:37 ? 00:00:00 avahi-daemon: chroot helper root 1447 1 0 09:37 ? 00:00:00 cupsd -C /etc/cups/cupsd.conf root 1470 1 0 09:37 ? 00:00:00 /usr/sbin/acpid 68 1478 1 0 09:37 ? 00:00:00 hald root 1481 1 0 09:37 ? 00:00:00 /usr/sbin/console-kit-daemon root 1482 1478 0 09:37 ? 00:00:00 hald-runner root 1573 1482 0 09:37 ? 00:00:01 hald-addon-input: Listening on /dev/input/event2 /dev/input/event3 /dev/input/event10 /dev/input/event0 /dev/input/event8 /dev/input/event1 /dev/input/event7 /dev/input/event5 root 1603 1482 0 09:37 ? 00:00:00 /usr/libexec/hald-addon-generic-backlight root 1621 1482 0 09:37 ? 00:00:00 hald-addon-storage: polling /dev/sr0 (every 2 sec) 68 1625 1482 0 09:37 ? 00:00:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket root 1639 1 0 09:37 ? 00:00:00 pcscd root 1699 1 0 09:37 ? 00:00:00 /usr/sbin/bluetoothd root 1713 2 0 09:37 ? 00:00:00 [bluetooth] root 1717 1 0 09:37 ? 00:00:00 /usr/sbin/sshd ntp 1728 1 0 09:37 ? 00:00:00 ntpd -u ntp:ntp -p /var/run/ntpd.pid -g uuidd 1820 1 0 09:37 ? 00:00:00 /usr/sbin/uuidd root 1835 1 0 09:37 ? 00:00:00 sendmail: accepting connections smmsp 1843 1 0 09:37 ? 00:00:00 sendmail: Queue runner at 01:00:00 for /var/spool/clientmqueue root 1853 1 0 09:37 ? 00:00:00 /usr/sbin/gpm -m /dev/input/mice -t exps2 root 1864 1 0 09:37 ? 00:00:00 crond root 1877 1 0 09:37 ? 00:00:00 nmbd -D root 1886 1 0 09:37 ? 00:00:00 smbd -D root 1888 1886 0 09:37 ? 00:00:00 smbd -D root 1898 1 0 09:37 ? 00:00:00 /usr/sbin/atd root 1909 1 0 09:37 ? 00:00:00 libvirtd --daemon root 1967 1 0 09:37 ? 00:00:00 /usr/sbin/cimserver root 2004 1 0 09:37 ? 00:00:00 /usr/sbin/gdm-binary -nodaemon root 2006 1 0 09:37 tty4 00:00:00 /sbin/mingetty tty4 root 2010 1 0 09:37 tty5 00:00:00 /sbin/mingetty tty5 root 2011 1 0 09:37 tty2 00:00:00 /sbin/mingetty tty2 root 2014 1 0 09:37 tty3 00:00:00 /sbin/mingetty tty3 root 2016 1 0 09:37 tty6 00:00:00 /sbin/mingetty tty6 root 2092 2004 0 09:37 ? 00:00:00 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 --force-active-vt root 2093 2092 4 09:37 tty1 00:01:17 /usr/bin/Xorg :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-dtLaV1/database -nolisten tcp vt1 gdm 2117 1 0 09:37 ? 00:00:00 /usr/bin/dbus-launch --exit-with-session root 2167 1 0 09:37 ? 00:00:00 /usr/bin/python -tt /usr/sbin/yum-updatesd root 2171 1 0 09:37 ? 00:00:00 /usr/libexec/gam_server root 2178 1 0 09:37 ? 00:00:00 /usr/libexec/devkit-power-daemon root 2181 1 0 09:37 ? 00:00:00 /usr/libexec/devkit-daemon root 2209 2092 0 09:37 ? 00:00:00 pam: gdm-password jd 2225 1 0 09:38 ? 00:00:00 /usr/bin/gnome-keyring-daemon --daemonize --login jd 2231 2209 0 09:38 ? 00:00:00 gnome-session jd 2252 1 0 09:38 ? 00:00:00 dbus-launch --sh-syntax --exit-with-session jd 2255 1 0 09:38 ? 00:00:00 /bin/dbus-daemon --fork --print-pid 9 --print-address 11 --session jd 2359 1 0 09:38 ? 00:00:01 /usr/libexec/gconfd-2 jd 2362 1 0 09:38 ? 00:00:00 /usr/libexec/gnome-settings-daemon jd 2370 2231 0 09:38 ? 00:00:03 metacity jd 2372 1 0 09:38 ? 00:00:00 /usr/libexec/gvfsd jd 2378 1 0 09:38 ? 00:00:00 /usr/libexec//gvfs-fuse-daemon /home/jd/.gvfs jd 2381 2231 0 09:38 ? 00:00:02 gnome-panel jd 2383 2231 0 09:38 ? 00:00:02 nautilus jd 2393 1 0 09:38 ? 00:00:00 /usr/libexec/bonobo-activation-server --ac-activate --ior-output-fd=18 jd 2400 2231 0 09:38 ? 00:00:00 nm-applet --sm-disable jd 2401 2231 0 09:38 ? 00:00:00 /usr/bin/seapplet jd 2403 2231 0 09:38 ? 00:00:00 gnome-power-manager jd 2408 2231 0 09:38 ? 00:00:00 /usr/libexec/gdu-notification-daemon root 2413 1 0 09:38 ? 00:00:00 /usr/libexec/devkit-disks-daemon jd 2416 2231 0 09:38 ? 00:00:00 python /usr/share/system-config-printer/applet.py jd 2417 2231 0 09:38 ? 00:00:00 bluetooth-applet root 2419 2413 0 09:38 ? 00:00:00 devkit-disks-daemon: polling /dev/sr0 jd 2420 2231 0 09:38 ? 00:00:00 kerneloops-applet jd 2421 2231 0 09:38 ? 00:00:00 gpk-update-icon root 2426 1 0 09:38 ? 00:00:01 /usr/sbin/kerneloops --nodaemon jd 2435 1 0 09:38 ? 00:00:00 /usr/libexec/im-settings-daemon jd 2505 1 0 09:38 ? 00:00:00 /usr/libexec/notification-daemon jd 2548 1 0 09:38 ? 00:00:00 /usr/libexec/gconf-im-settings-daemon root 2556 1 0 09:38 ? 00:00:00 /usr/sbin/nm-system-settings --config /etc/NetworkManager/nm-system-settings.conf jd 2562 1 0 09:38 ? 00:00:00 /usr/libexec/gvfsd-trash --spawner :1.7 /org/gtk/gvfs/exec_spaw/0 jd 2565 1 0 09:38 ? 00:00:00 /usr/libexec/gvfs-gdu-volume-monitor jd 2569 1 0 09:38 ? 00:00:04 /usr/libexec/wnck-applet --oaf-activate-iid=OAFIID:GNOME_Wncklet_Factory --oaf-ior-fd=18 jd 2572 1 0 09:38 ? 00:00:00 /usr/libexec/gvfs-gphoto2-volume-monitor jd 2588 1 0 09:38 ? 00:00:00 /usr/libexec/gvfsd-burn --spawner :1.7 /org/gtk/gvfs/exec_spaw/1 jd 2590 1 0 09:38 ? 00:00:00 /usr/libexec/notification-area-applet --oaf-activate-iid=OAFIID:GNOME_NotificationAreaApplet_Factory --oaf-ior-fd=19 jd 2593 1 0 09:38 ? 00:00:02 /usr/libexec/clock-applet --oaf-activate-iid=OAFIID:GNOME_ClockApplet_Factory --oaf-ior-fd=26 jd 2647 1 0 09:38 ? 00:00:00 gnome-screensaver jd 3082 1 0 09:42 ? 00:00:00 /usr/bin/kwifimanager jd 3085 1 0 09:42 ? 00:00:00 kdeinit Running... jd 3089 1 0 09:42 ? 00:00:00 dcopserver --nosid --suicide jd 3091 3085 0 09:42 ? 00:00:00 klauncher [kdeinit] --new-startup jd 3093 1 0 09:42 ? 00:00:00 kded --new-startup jd 3197 1 0 09:43 ? 00:00:01 gnome-terminal jd 3202 3197 0 09:43 ? 00:00:00 gnome-pty-helper jd 3203 3197 0 09:43 pts/0 00:00:00 -ksh root 3267 3203 0 09:43 pts/0 00:00:00 /bin/ksh -o vi nobody 3318 1 0 09:44 ? 00:00:00 /usr/sbin/dnsmasq jd 3349 1 0 09:44 ? 00:00:00 /bin/sh /usr/lib/thunderbird-3.0b2/thunderbird jd 3354 3349 0 09:44 ? 00:00:00 /bin/sh /usr/lib/thunderbird-3.0b2/run-mozilla.sh /usr/lib/thunderbird-3.0b2/thunderbird-bin jd 3361 3354 2 09:44 ? 00:00:39 /usr/lib/thunderbird-3.0b2/thunderbird-bin jd 3475 1 0 09:48 ? 00:00:00 /bin/sh /usr/lib/firefox-3.5.2/run-mozilla.sh /usr/lib/firefox-3.5.2/firefox -ProfileManager jd 3492 3475 11 09:48 ? 00:02:06 /usr/lib/firefox-3.5.2/firefox -ProfileManager root 3792 1 0 10:01 ? 00:00:00 /usr/sbin/anacron -s Well, I had hoped the devs of this program were still actively trying to fix it's bugs. I'm giving up on it and will uninstall it. From tmetro+dnsmasq at gmail.com Fri Aug 7 18:41:17 2009 From: tmetro+dnsmasq at gmail.com (Tom Metro) Date: Fri, 07 Aug 2009 13:41:17 -0400 Subject: [Dnsmasq-discuss] dnsmask problems/questions In-Reply-To: <4A7C6305.7050807@gmail.com> References: <4A7B0996.5080804@gmail.com> <4A7BE0D7.3000003@gmail.com> <4A7C5936.9060000@gmail.com> <4A7C6305.7050807@gmail.com> Message-ID: <4A7C673D.6020004@gmail.com> JD wrote: > Well, avahai-daemon must be the culprit. I take it you stopped it and that fixed the problem? What inspired you to try that? > If I knew more about Avahi (does it cache dns entries?) perhaps > I would properly configure and use avahi-daemon instead > of dnsmasq. I haven't had close dealing with avahi-daemon and know little about it, but I can say I have it running on an Ubuntu desktop along with Dnsmasq with no DNS problems. The avahi-daemon man page says: The Avahi mDNS/DNS-SD daemon implements Apple's Zeroconf architecture (also known as "Rendezvous" or "Bonjour"). The daemon registers local IP addresses and static services using mDNS/DNS-SD and provides two IPC APIs for local programs to make use of the mDNS record cache the avahi-daemon maintains. Based on that I don't think it's going to be useful as a general purpose DNS cache. If that's all you want, you might want to try nscd. > Well, I had hoped the devs of this program were still actively > trying to fix it's bugs. They are. If you check the list archives you'll see that Simon Kelley is a frequent responder and regularly posts announcements of updates. You just need to have a bit more patience. Being without DNS obviously is problematic, so you either need to temporarily forgo caching or switch to an alternative solution until Simon can investigate. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ From weizen_42 at ipcop-forum.de Fri Aug 7 18:46:35 2009 From: weizen_42 at ipcop-forum.de (Olaf Westrik) Date: Fri, 07 Aug 2009 19:46:35 +0200 Subject: [Dnsmasq-discuss] dnsmask problems/questions In-Reply-To: <4A7C600D.7060403@gmail.com> References: <4A7B0996.5080804@gmail.com> <4A7BE0D7.3000003@gmail.com> <4A7C5936.9060000@gmail.com> <4A7C600D.7060403@gmail.com> Message-ID: <4A7C687B.5040101@ipcop-forum.de> JD wrote: > Well, I had hoped the devs of this program were still actively > trying to fix it's bugs. > They are. But you'll need to give slightly more time than 24 hours ... > On Fedora11, dnsmasq-2.46-2.fc11.i586 : > You did report and/or check Fedoras bugzilla right? Olaf -- A weizen a day helps keep the doctor away. From aaron at madebyai.com Mon Aug 10 22:39:50 2009 From: aaron at madebyai.com (Aaron Ten Clay) Date: Mon, 10 Aug 2009 14:39:50 -0700 Subject: [Dnsmasq-discuss] Forwarding local domain when not DHCP? Message-ID: <200908101439.50709.aaron@madebyai.com> Hello, I'm trying to configure dnsmasq to forward local domain queries to a windows box when the host requested was not DHCP. To start, I have a DNS configuration like this: --- local=/company.local/ domain=company.local expand-hosts server=/company.local/192.168.0.10 server=/company.com/192.168.0.10 no-resolv server=208.67.222.222 # OpenDNS primary server=208.67.220.220 # OpenDNS secondary --- Using the "local" (or "server") directive for company.local with no server IP address seems to cause dnsmasq to return NXDOMAIN if a host request is not found in DHCP/local hosts file. Can anyone point me in the right direction? I thought about removing the "domain" directive but that would prevent dhcphost1.company.local from resolving, right? Thanks! -- Aaron Ten Clay From aarcane at gmail.com Wed Aug 12 00:30:56 2009 From: aarcane at gmail.com (Christ Schlacta) Date: Tue, 11 Aug 2009 23:30:56 +0000 Subject: [Dnsmasq-discuss] router won't query itsself Message-ID: <4A81FF30.2040700@gmail.com> my router running dnsmasq won't query itsself. any machine on the network can run "ping oldbaz" and the router will return the proper IP address and pinging will ensue. when I run "ping oldbaz" from my router, no ping love occurs :( I've tried a number of things, including listing 127.0.0.1 and my router's IP address in the resolv.conf file, and none of it seems to help. From santiago at zarate.net.ve Wed Aug 12 05:08:02 2009 From: santiago at zarate.net.ve (Santiago Zarate) Date: Tue, 11 Aug 2009 23:38:02 -0430 Subject: [Dnsmasq-discuss] router won't query itsself In-Reply-To: <4A81FF30.2040700@gmail.com> References: <4A81FF30.2040700@gmail.com> Message-ID: <200908112338.04509.santiago@zarate.net.ve> Looks like to me, that in your resolv.conf there's no line pointing to the nameserver itself... Are you sure you have this line: nameserver 127.0.0.1 just in case... restart dnsmasq again :) On Mar 11 Ago 2009 19:00:56 Christ Schlacta escribi?: > my router running dnsmasq won't query itsself. any machine on the > network can run "ping oldbaz" and the router will return the proper IP > address and pinging will ensue. when I run "ping oldbaz" from my > router, no ping love occurs :( I've tried a number of things, including > listing 127.0.0.1 and my router's IP address in the resolv.conf file, > and none of it seems to help. > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Santiago Zarate santiago at zarate.net.ve (+58) 4129864175 (+58) 4241073905 From santiago at zarate.net.ve Wed Aug 12 07:08:22 2009 From: santiago at zarate.net.ve (Santiago Zarate) Date: Wed, 12 Aug 2009 01:38:22 -0430 Subject: [Dnsmasq-discuss] router won't query itsself In-Reply-To: <4A825692.808@gmail.com> References: <4A81FF30.2040700@gmail.com> <200908112338.04509.santiago@zarate.net.ve> <4A825692.808@gmail.com> Message-ID: <200908120138.34986.santiago@zarate.net.ve> I just tried this... and found out that my dnsmasq wont use specified address in my configuration: address=/test/192.168.1.150 but adding this entry to my /etc/hosts works perfectly... note that i have domain-needed and bogus-priv commented (also triied with them uncommented) If adding the "test" record to your /etc/hosts is fine for you... that's a good thing to do then... but to other dudes out there... is there a solution which implies no /etc/hosts interaction? On Mi? 12 Ago 2009 01:13:46 usted escribi?: > yeah, the router's IP is 10.0.0.108, and I've tried with all of the > following: > > nameserver 127.0.0.1 > > nameserver 10.0.0.108 > > nameserver 127.0.0.1 > nameserver 10.0.0.108 > > and also with all combinations of: > > domain aarcane.info > > search aarcane.info > > domain aarcane.info. > > domain .aarcane.info > > domain .aarcane.info. > > search aarcane.info, > > and so on, with every combination of dot before and after domain name, > search name, and mixing and matching both of those. I simply can't get > the local host names to resolve, though their full host.aarcane.info > forms resolve fine. > > Santiago Zarate wrote: > > Looks like to me, that in your resolv.conf there's no line pointing to > > the nameserver itself... > > > > Are you sure you have this line: nameserver 127.0.0.1 > > > > just in case... restart dnsmasq again > > > > :) > > > > On Mar 11 Ago 2009 19:00:56 Christ Schlacta escribi?: > >> my router running dnsmasq won't query itsself. any machine on the > >> network can run "ping oldbaz" and the router will return the proper IP > >> address and pinging will ensue. when I run "ping oldbaz" from my > >> router, no ping love occurs :( I've tried a number of things, including > >> listing 127.0.0.1 and my router's IP address in the resolv.conf file, > >> and none of it seems to help. > >> > >> _______________________________________________ > >> Dnsmasq-discuss mailing list > >> Dnsmasq-discuss at lists.thekelleys.org.uk > >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Santiago Zarate santiago at zarate.net.ve (+58) 4129864175 (+58) 4241073905 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. Url : http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090812/6befa69e/attachment.pgp From cl at isbd.net Wed Aug 12 15:58:05 2009 From: cl at isbd.net (Chris G) Date: Wed, 12 Aug 2009 15:58:05 +0100 Subject: [Dnsmasq-discuss] Strange (well, I can't udnerstand it) /etc/hosts effect Message-ID: <20090812145805.GA15820@chris> I run a fairly default version of dnsmasq on my xubuntu 9.04 Linux box so that I don't have to maintain losts of network (or hosts) configurations around our network. I have just added:- 127.0.0.1 www.google-analytics.com ssl.www.google-analytics.com to my /etc/hosts file. I'm not paranoid about snooping but I am fed up with having to wait for www.google-analytics.com to respond, it's often quite slow taking several seconds with the address displayed at the bottom of Firefox. So, it appears to work, but why does 'host' respond as follows:- chris$ host www.google-analytics.com www.google-analytics.com has address 127.0.0.1 www.google-analytics.com is an alias for www-google-analytics.l.google.com. www.google-analytics.com is an alias for www-google-analytics.l.google.com. Why don't the aliases disappear as well? -- Chris Green From cl at isbd.net Wed Aug 12 16:32:46 2009 From: cl at isbd.net (Chris G) Date: Wed, 12 Aug 2009 16:32:46 +0100 Subject: [Dnsmasq-discuss] Strange (well, I can't udnerstand it) /etc/hosts effect In-Reply-To: <20090812145805.GA15820@chris> References: <20090812145805.GA15820@chris> Message-ID: <20090812153246.GB15820@chris> On Wed, Aug 12, 2009 at 03:58:05PM +0100, Chris G wrote: > I run a fairly default version of dnsmasq on my xubuntu 9.04 Linux box > so that I don't have to maintain losts of network (or hosts) > configurations around our network. > Oh dear, "udnerstand", "losts", I expect you can follow it though. :-) > I have just added:- > > 127.0.0.1 www.google-analytics.com ssl.www.google-analytics.com > > to my /etc/hosts file. I'm not paranoid about snooping but I am fed > up with having to wait for www.google-analytics.com to respond, it's > often quite slow taking several seconds with the address displayed at > the bottom of Firefox. > > So, it appears to work, but why does 'host' respond as follows:- > > chris$ host www.google-analytics.com > www.google-analytics.com has address 127.0.0.1 > www.google-analytics.com is an alias for www-google-analytics.l.google.com. > www.google-analytics.com is an alias for www-google-analytics.l.google.com. > > Why don't the aliases disappear as well? > > -- > Chris Green > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > -- Chris Green From jd1008 at gmail.com Wed Aug 12 16:52:31 2009 From: jd1008 at gmail.com (JD) Date: Wed, 12 Aug 2009 08:52:31 -0700 Subject: [Dnsmasq-discuss] router won't query itsself In-Reply-To: <200908112338.04509.santiago@zarate.net.ve> References: <4A81FF30.2040700@gmail.com> <200908112338.04509.santiago@zarate.net.ve> Message-ID: <4A82E53F.3050604@gmail.com> On 08/11/2009 09:08 PM, Santiago Zarate wrote: > Looks like to me, that in your resolv.conf there's no line pointing to the nameserver > itself... > > Are you sure you have this line: nameserver 127.0.0.1 > > just in case... restart dnsmasq again > > :) > > > > On Mar 11 Ago 2009 19:00:56 Christ Schlacta escribi?: >> > my router running dnsmasq won't query itsself. any machine on the >> > network can run "ping oldbaz" and the router will return the proper IP >> > address and pinging will ensue. when I run "ping oldbaz" from my >> > router, no ping love occurs:( I've tried a number of things, including >> > listing 127.0.0.1 and my router's IP address in the resolv.conf file, >> > and none of it seems to help. >> > /etc/resolv.conf must ONLY contain nameserver 127.0.0.1 AND /etc/dnsmasq.conf must set resolv-file=/etc/resolv.dnsmasq Or whatever you decide to call that file, which contains the list of the real nameservers. If you do not want to set this in /etc/dnsmasq.conf , then you must specify it on the command line that starts dnsmasq. In /etc/init.d/dnsmasq, it is started as echo -n "Starting dnsmasq: " daemon $dnsmasq $OPTIONS In my case, it turns out that $OPTIONS is an empty string, and does not contain my domainname. So to specify the resolver file on the command line, just add daemon $dnsmasq -r /etc/resolv.dnsmasq $OPTIONS After that sudo service dnsmasq restart Good luck -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090812/301e521b/attachment.htm From richardvoigt at gmail.com Wed Aug 12 18:30:20 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Wed, 12 Aug 2009 13:30:20 -0400 Subject: [Dnsmasq-discuss] Strange (well, I can't udnerstand it) /etc/hosts effect In-Reply-To: <20090812145805.GA15820@chris> References: <20090812145805.GA15820@chris> Message-ID: <2e59e6970908121030q62e9d988u82789890cb56ea11@mail.gmail.com> On Wed, Aug 12, 2009 at 10:58 AM, Chris G wrote: > I run a fairly default version of dnsmasq on my xubuntu 9.04 Linux box > so that I don't have to maintain losts of network (or hosts) > configurations around our network. > > I have just added:- > > ? ?127.0.0.1 ? ? ? www.google-analytics.com ?ssl.www.google-analytics.com > > to my /etc/hosts file. ?I'm not paranoid about snooping but I am fed > up with having to wait for www.google-analytics.com to respond, it's > often quite slow taking several seconds with the address displayed at > the bottom of Firefox. > > So, it appears to work, but why does 'host' respond as follows:- > > ? ?chris$ host www.google-analytics.com > ? ?www.google-analytics.com has address 127.0.0.1 > ? ?www.google-analytics.com is an alias for www-google-analytics.l.google.com. > ? ?www.google-analytics.com is an alias for www-google-analytics.l.google.com. > > Why don't the aliases disappear as well? Did you clear your cache? > > -- > Chris Green > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From Hullen at t-online.de Wed Aug 12 19:07:00 2009 From: Hullen at t-online.de (Helmut Hullen) Date: 12 Aug 2009 20:07:00 +0200 Subject: [Dnsmasq-discuss] router won't query itsself In-Reply-To: <4A82E53F.3050604@gmail.com> Message-ID: Hallo, JD, jd1008 at gmail.com meinte am 12.08.09 in dnsmasq zum Thema Re: [Dnsmasq-discuss] router won't query itsself: > /etc/resolv.conf must ONLY contain > nameserver 127.0.0.1 > AND > /etc/dnsmasq.conf must set > resolv-file=/etc/resolv.dnsmasq > Or whatever you decide to call that file, which contains the list of > the real nameservers. Just a (not tested) idea: pppoe and router connections into the WAN lead (in many distributions) to a file "/etc/ppp/resolv.conf" which contains the 2 nameservers the ISP proposes. "resolv-file" may lead to this file. Viele Gruesse! Helmut From cl at isbd.net Wed Aug 12 19:23:44 2009 From: cl at isbd.net (Chris G) Date: Wed, 12 Aug 2009 19:23:44 +0100 Subject: [Dnsmasq-discuss] Strange (well, I can't udnerstand it) /etc/hosts effect In-Reply-To: <2e59e6970908121030q62e9d988u82789890cb56ea11@mail.gmail.com> References: <20090812145805.GA15820@chris> <2e59e6970908121030q62e9d988u82789890cb56ea11@mail.gmail.com> Message-ID: <20090812182344.GC15820@chris> On Wed, Aug 12, 2009 at 01:30:20PM -0400, richardvoigt at gmail.com wrote: > On Wed, Aug 12, 2009 at 10:58 AM, Chris G wrote: > > I run a fairly default version of dnsmasq on my xubuntu 9.04 Linux box > > so that I don't have to maintain losts of network (or hosts) > > configurations around our network. > > > > I have just added:- > > > > ? ?127.0.0.1 ? ? ? www.google-analytics.com ?ssl.www.google-analytics.com > > > > to my /etc/hosts file. ?I'm not paranoid about snooping but I am fed > > up with having to wait for www.google-analytics.com to respond, it's > > often quite slow taking several seconds with the address displayed at > > the bottom of Firefox. > > > > So, it appears to work, but why does 'host' respond as follows:- > > > > ? ?chris$ host www.google-analytics.com > > ? ?www.google-analytics.com has address 127.0.0.1 > > ? ?www.google-analytics.com is an alias for www-google-analytics.l.google.com. > > ? ?www.google-analytics.com is an alias for www-google-analytics.l.google.com. > > > > Why don't the aliases disappear as well? > > Did you clear your cache? > Whose cache? I restarted dnsmasq with a "kill -1", is there anything else? -- Chris Green From jd1008 at gmail.com Wed Aug 12 21:21:36 2009 From: jd1008 at gmail.com (JD) Date: Wed, 12 Aug 2009 13:21:36 -0700 Subject: [Dnsmasq-discuss] router won't query itsself In-Reply-To: References: Message-ID: <4A832450.4080401@gmail.com> On 08/12/2009 11:07 AM, Helmut Hullen wrote: > Hallo, JD, > > jd1008 at gmail.com meinte am 12.08.09 in dnsmasq zum Thema Re: [Dnsmasq-discuss] router won't query itsself: > > >> /etc/resolv.conf must ONLY contain >> nameserver 127.0.0.1 >> > > >> AND >> > > >> /etc/dnsmasq.conf must set >> > > >> resolv-file=/etc/resolv.dnsmasq >> > > >> Or whatever you decide to call that file, which contains the list of >> the real nameservers. >> > > > Just a (not tested) idea: > > pppoe and router connections into the WAN lead (in many distributions) > to a file "/etc/ppp/resolv.conf" which contains the 2 nameservers the > ISP proposes. > > "resolv-file" may lead to this file. > > Viele Gruesse! > Helmut > > __ Hi Helmut, Even so, I do not see the need to let the host be bothered by a changing IP address provided by the ISP. Let all that be handled by a cheap router, whose LAN ip address remains constant to the lan in it's subnet for which it is the gateway. You can always query the router for what IT'S nameservers (provided by the ISP) are. I am surprised that people are making work for themselves for nothing. Cheers, JD -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090812/364925dd/attachment.htm From aarcane at gmail.com Wed Aug 12 22:08:00 2009 From: aarcane at gmail.com (Christ Schlacta) Date: Wed, 12 Aug 2009 21:08:00 +0000 Subject: [Dnsmasq-discuss] Kinda like subnetting? Message-ID: <4A832F30.70802@gmail.com> I want to configure dnsmasq to issue IP addresses in various ranges based on client type or location. I have an entire /24 for my network, and want to keep it that way, however, I want to specify clients IP addresses based on various chriteria. server systems should recieve an IP address in the range of 10.0.0.1/26, and known wired and wireless clients (trusted laptops and workstations) in the range of 10.0.0.64/26. Finally, any un-known client should be issued an IP address in the range 10.0.0.192/26. as this is largely an organizational tool, and these systems are all in the same physical network, I want them to all be given their address in the 10.0.0.1/24 subnet, and know that as their broadcast domain. the question is, will dnsmasq let me configure it in this fassion? I'm fine with entering servers and trusted workstations manually. also, if anyone knows, will shorewall match IP addresses masked in that fassion as well? 10.0.0.64/26, when the interface is a /24.. From jd1008 at gmail.com Wed Aug 12 22:23:57 2009 From: jd1008 at gmail.com (JD) Date: Wed, 12 Aug 2009 14:23:57 -0700 Subject: [Dnsmasq-discuss] Strange (well, I can't udnerstand it) /etc/hosts effect In-Reply-To: <20090812182344.GC15820@chris> References: <20090812145805.GA15820@chris> <2e59e6970908121030q62e9d988u82789890cb56ea11@mail.gmail.com> <20090812182344.GC15820@chris> Message-ID: <4A8332ED.1060600@gmail.com> On 08/12/2009 11:23 AM, Chris G wrote: > On Wed, Aug 12, 2009 at 01:30:20PM -0400, richardvoigt at gmail.com wrote: > >> On Wed, Aug 12, 2009 at 10:58 AM, Chris G wrote: >> >>> I run a fairly default version of dnsmasq on my xubuntu 9.04 Linux box >>> so that I don't have to maintain losts of network (or hosts) >>> configurations around our network. >>> >>> I have just added:- >>> >>> 127.0.0.1 www.google-analytics.com ssl.www.google-analytics.com >>> >>> to my /etc/hosts file. I'm not paranoid about snooping but I am fed >>> up with having to wait for www.google-analytics.com to respond, it's >>> often quite slow taking several seconds with the address displayed at >>> the bottom of Firefox. >>> >>> So, it appears to work, but why does 'host' respond as follows:- >>> >>> chris$ host www.google-analytics.com >>> www.google-analytics.com has address 127.0.0.1 >>> www.google-analytics.com is an alias for www-google-analytics.l.google.com. >>> www.google-analytics.com is an alias for www-google-analytics.l.google.com. >>> >>> Why don't the aliases disappear as well? >>> >> Did you clear your cache? >> >> > Whose cache? I restarted dnsmasq with a "kill -1", is there anything else? > > The dnsmask man page says: . . . NOTES When it receives a SIGHUP, *dnsmasq clears its cache* and then re-loads /etc/hosts and /etc/ethers and any file given by --dhcp-hostsfile, --dhcp-optsfile or --addn-hosts. The dhcp lease change script is called for all existing DHCP leases. If --no-poll is set SIGHUP also re-reads /etc/resolv.conf. SIGHUP does NOT re-read the configuration file. When it receives a SIGUSR1, dnsmasq writes statistics to the system log. It writes the cache size, the number of names which have had to removed from the cache before they expired in order to make room for new names and the total number of names that have been inserted into the cache. For each upstream server it gives the number of queries sent, and the number which resulted in an error. In --no-daemon mode or when full logging is enabled (-q), a complete dump of the contents of the cache is made. When it receives SIGUSR2 and it is logging direct to a file (see --log- facility ) dnsmasq will close and reopen the log file. Note that during this operation, dnsmasq will not be running as root. When it first cre- ates the logfile dnsmasq changes the ownership of the file to the non- root user it will run as. Logrotate should be configured to create a new log file with the ownership which matches the existing one before sending SIGUSR2. If TCP DNS queries are in progress, the old logfile will remain open in child processes which are handling TCP queries and may continue to be written. There is a limit of 150 seconds, after which all existing TCP processes will have expired: for this reason, it is not wise to configure logfile compression for logfiles which have just been rotated. Using logrotate, the required options are create and delaycompress. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090812/7a57a3f3/attachment-0001.htm From jd1008 at gmail.com Wed Aug 12 22:31:12 2009 From: jd1008 at gmail.com (JD) Date: Wed, 12 Aug 2009 14:31:12 -0700 Subject: [Dnsmasq-discuss] Kinda like subnetting? In-Reply-To: <4A832F30.70802@gmail.com> References: <4A832F30.70802@gmail.com> Message-ID: <4A8334A0.40603@gmail.com> On 08/12/2009 02:08 PM, Christ Schlacta wrote: > I want to configure dnsmasq to issue IP addresses in various ranges > based on client type or location. > > I have an entire /24 for my network, and want to keep it that way, > however, I want to specify clients IP addresses based on various chriteria. > > server systems should recieve an IP address in the range of 10.0.0.1/26, > and known wired and wireless clients (trusted laptops and workstations) > in the range of 10.0.0.64/26. Finally, any un-known client should be > issued an IP address in the range 10.0.0.192/26. as this is largely an > organizational tool, and these systems are all in the same physical > network, I want them to all be given their address in the 10.0.0.1/24 > subnet, and know that as their broadcast domain. > > the question is, will dnsmasq let me configure it in this fassion? I'm > fine with entering servers and trusted workstations manually. > > also, if anyone knows, will shorewall match IP addresses masked in that > fassion as well? 10.0.0.64/26, when the interface is a /24.. > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > You can, but not along the lines you state. The man page says you can allocate IP addresses based on MAC addresses. i.e. -G, --dhcp- host=[][,id:|*][,net:][,][,][,][,ignore] Specify per host parameters for the DHCP server. This allows a machine with a particular hardware address to be always allo- cated the same hostname, IP address and lease time. A hostname specified like this overrides any supplied by the DHCP client on the machine. It is also allowable to ommit the hardware address and include the hostname, in which case the IP address and lease times will apply to any machine claiming that name. For example --dhcp-host=00:20:e0:3b:13:af,wap,infinite tells dnsmasq to give the machine with hardware address 00:20:e0:3b:13:af the name wap, and an infinite DHCP lease. --dhcp-host=lap,192.168.0.199 tells dnsmasq to always allocate the machine lap the IP address 192.168.0.199. Addresses allocated like this are not constrained to be in the range given by the --dhcp-range option, but they must be on the network being served by the DHCP server. It is allowed to use client identifiers rather than hardware addresses to identify hosts by prefixing with ?id:?. Thus: --dhcp- host=id:01:02:03:04,..... refers to the host with client iden- tifier 01:02:03:04. It is also allowed to specify the client ID as text, like this: --dhcp-host=id:clientidastext,..... The special option id:* means "ignore any client-id and use MAC addresses only." This is useful when a client presents a client- id sometimes but not others. If a name appears in /etc/hosts, the associated address can be allocated to a DHCP lease, but only if a --dhcp-host option specifying the name also exists. The special keyword "ignore" tells dnsmasq to never offer a DHCP lease to a machine. The machine can be specified by hardware address, client ID or host- name, for instance --dhcp-host=00:20:e0:3b:13:af,ignore This is useful when there is another DHCP server on the network which should be used by some machines. The net: sets the network-id tag whenever this dhcp- host directive is in use. This can be used to selectively send DHCP options just for this host. When a host matches any dhcp- host directive (or one implied by /etc/ethers) then the special network-id tag "known" is set. This allows dnsmasq to be config- ured to ignore requests from unknown machines using --dhcp- ignore=#known Ethernet addresses (but not client-ids) may have wildcard bytes, so for example --dhcp- host=00:20:e0:3b:13:*,ignore will cause dnsmasq to ignore a range of hardware addresses. Note that the "*" will need to be escaped or quoted on a command line, but not in the configura- tion file. Hardware addresses normally match any network (ARP) type, but it is possible to restrict them to a single ARP type by preceding them with the ARP-type (in HEX) and "-". so --dhcp- host=06-00:20:e0:3b:13:af,1.2.3.4 will only match a Token-Ring hardware address, since the ARP-address type for token ring is 6. As a special case, it is possible to include more than one hard- ware address. This allows an IP address to be associated with multiple hardware addresses, and gives dnsmasq permission to abandon a DHCP lease to one of the hardware addresses when another one asks for a lease. Beware that this is a dangerous thing to do, it will only work reliably if only one of the hard- ware addresses is active at any time and there is no way for dnsmasq to enforce this. It is, however useful, for instance to allocate a stable IP address to a laptop which has both wired and wireless interfaces. From karl at kgoetz.id.au Thu Aug 13 07:47:17 2009 From: karl at kgoetz.id.au (Karl Goetz) Date: Thu, 13 Aug 2009 16:17:17 +0930 Subject: [Dnsmasq-discuss] Strange (well, I can't udnerstand it) /etc/hosts effect In-Reply-To: <20090812145805.GA15820@chris> References: <20090812145805.GA15820@chris> Message-ID: <20090813161717.0e7c7be7@kgoetz.id.au> On Wed, 12 Aug 2009 15:58:05 +0100 Chris G wrote: > I run a fairly default version of dnsmasq on my xubuntu 9.04 Linux box > so that I don't have to maintain losts of network (or hosts) > configurations around our network. > > I have just added:- > > 127.0.0.1 www.google-analytics.com > ssl.www.google-analytics.com > > to my /etc/hosts file. I'm not paranoid about snooping but I am fed > up with having to wait for www.google-analytics.com to respond, it's > often quite slow taking several seconds with the address displayed at > the bottom of Firefox. > Have you considered using address= in the configuration file? I have a short list of addresses I poison in that way, and some time ago (2-3 months?) on this list someone included instructions on an automatically updating list + apache rewrite to avoid nasty messages. Fraid I can't find the message right now though :( kk > So, it appears to work, but why does 'host' respond as follows:- > > chris$ host www.google-analytics.com > www.google-analytics.com has address 127.0.0.1 > www.google-analytics.com is an alias for > www-google-analytics.l.google.com. www.google-analytics.com is an > alias for www-google-analytics.l.google.com. > > Why don't the aliases disappear as well? > -- Karl Goetz, (Kamping_Kaiser / VK5FOSS) Debian contributor / gNewSense Maintainer http://www.kgoetz.id.au No, I won't join your social networking group -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090813/28dfc681/attachment.pgp From Hullen at t-online.de Thu Aug 13 07:50:00 2009 From: Hullen at t-online.de (Helmut Hullen) Date: 13 Aug 2009 08:50:00 +0200 Subject: [Dnsmasq-discuss] router won't query itsself In-Reply-To: <4A832450.4080401@gmail.com> Message-ID: Hallo, JD, you wrote am 12.08.09 zum Thema Re: [Dnsmasq-discuss] router won't query itsself: > Even so, I do not see the need to let the host be bothered by a > changing IP address provided by the ISP. > Let all that be handled by a cheap router, whose LAN ip address > remains constant to the lan in it's Sorry: no. That "cheap router" is very often a black box with strange preconfigurations, with to few logs, etc. etc. That's a job a Linux server can do better. There I can read better documentations, man pages etc., there i can see better log files, there i can ask in newsgroups etc. In my special case: the server is (as a feature) disconnected every night for some hours. Thats's hard to realize with most external routers (and I know many of these chests). And I have to switch to many providers: DSL, ISDN, analogue Modem, broadband. Only DSL-Routers are cheap - I have to work with my special ISP configurations in all other cases. > I am surprised that people are making work for themselves for > nothing. I speak for my system, not for mouse clickers, not for "all in a box" consumers. If I would use an external router then why should I use dnsmasq? Please excuse my gerlish. Viele Gruesse! Helmut From cl at isbd.net Thu Aug 13 10:10:41 2009 From: cl at isbd.net (Chris G) Date: Thu, 13 Aug 2009 10:10:41 +0100 Subject: [Dnsmasq-discuss] Strange (well, I can't udnerstand it) /etc/hosts effect In-Reply-To: <20090813161717.0e7c7be7@kgoetz.id.au> References: <20090812145805.GA15820@chris> <20090813161717.0e7c7be7@kgoetz.id.au> Message-ID: <20090813091041.GA16821@chris> On Thu, Aug 13, 2009 at 04:17:17PM +0930, Karl Goetz wrote: > On Wed, 12 Aug 2009 15:58:05 +0100 > Chris G wrote: > > > I run a fairly default version of dnsmasq on my xubuntu 9.04 Linux box > > so that I don't have to maintain losts of network (or hosts) > > configurations around our network. > > > > I have just added:- > > > > 127.0.0.1 www.google-analytics.com > > ssl.www.google-analytics.com > > > > to my /etc/hosts file. I'm not paranoid about snooping but I am fed > > up with having to wait for www.google-analytics.com to respond, it's > > often quite slow taking several seconds with the address displayed at > > the bottom of Firefox. > > > > Have you considered using address= in the configuration file? > I have a short list of addresses I poison in that way, and some time > ago (2-3 months?) on this list someone included instructions on an > automatically updating list + apache rewrite to avoid nasty messages. Would that actually work any differently? I.e. does dnsmasq do anything different with an address= compared with an entry in /etc/hosts? > > > So, it appears to work, but why does 'host' respond as follows:- > > > > chris$ host www.google-analytics.com > > www.google-analytics.com has address 127.0.0.1 > > www.google-analytics.com is an alias for > > www-google-analytics.l.google.com. www.google-analytics.com is an > > alias for www-google-analytics.l.google.com. > > > > Why don't the aliases disappear as well? > > > > > -- > Karl Goetz, (Kamping_Kaiser / VK5FOSS) > Debian contributor / gNewSense Maintainer > http://www.kgoetz.id.au > No, I won't join your social networking group > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Chris Green From cl at isbd.net Thu Aug 13 10:14:22 2009 From: cl at isbd.net (Chris G) Date: Thu, 13 Aug 2009 10:14:22 +0100 Subject: [Dnsmasq-discuss] Strange (well, I can't udnerstand it) /etc/hosts effect In-Reply-To: <20090813161717.0e7c7be7@kgoetz.id.au> References: <20090812145805.GA15820@chris> <20090813161717.0e7c7be7@kgoetz.id.au> Message-ID: <20090813091422.GB16821@chris> On Thu, Aug 13, 2009 at 04:17:17PM +0930, Karl Goetz wrote: > On Wed, 12 Aug 2009 15:58:05 +0100 > Chris G wrote: > > > I run a fairly default version of dnsmasq on my xubuntu 9.04 Linux box > > so that I don't have to maintain losts of network (or hosts) > > configurations around our network. > > > > I have just added:- > > > > 127.0.0.1 www.google-analytics.com > > ssl.www.google-analytics.com > > > > to my /etc/hosts file. I'm not paranoid about snooping but I am fed > > up with having to wait for www.google-analytics.com to respond, it's > > often quite slow taking several seconds with the address displayed at > > the bottom of Firefox. > > > > Have you considered using address= in the configuration file? > I have a short list of addresses I poison in that way, and some time > ago (2-3 months?) on this list someone included instructions on an > automatically updating list + apache rewrite to avoid nasty messages. I have added:- address=/www.google-analytics.com/127.0.0.1 to the end of /etc/dnsmasq.conf and done 'kill -SIGHUP nnnn', no change, I still get the aliases appearing. -- Chris Green From richardvoigt at gmail.com Thu Aug 13 11:55:42 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Thu, 13 Aug 2009 06:55:42 -0400 Subject: [Dnsmasq-discuss] Strange (well, I can't udnerstand it) /etc/hosts effect In-Reply-To: <20090813091422.GB16821@chris> References: <20090812145805.GA15820@chris> <20090813161717.0e7c7be7@kgoetz.id.au> <20090813091422.GB16821@chris> Message-ID: <2e59e6970908130355r16b05f34naf4f3e1a035c50e6@mail.gmail.com> > I have added:- > > ? ?address=/www.google-analytics.com/127.0.0.1 > > to the end of /etc/dnsmasq.conf and done 'kill -SIGHUP nnnn', no > change, I still get the aliases appearing. JD posted the appropriate excerpt from the man page, which includes the sentence: SIGHUP does NOT re-read the configuration file. From cl at isbd.net Thu Aug 13 12:28:14 2009 From: cl at isbd.net (Chris G) Date: Thu, 13 Aug 2009 12:28:14 +0100 Subject: [Dnsmasq-discuss] Strange (well, I can't udnerstand it) /etc/hosts effect In-Reply-To: <2e59e6970908130355r16b05f34naf4f3e1a035c50e6@mail.gmail.com> References: <20090812145805.GA15820@chris> <20090813161717.0e7c7be7@kgoetz.id.au> <20090813091422.GB16821@chris> <2e59e6970908130355r16b05f34naf4f3e1a035c50e6@mail.gmail.com> Message-ID: <20090813112814.GA25196@chris> On Thu, Aug 13, 2009 at 06:55:42AM -0400, richardvoigt at gmail.com wrote: > > I have added:- > > > > ? ?address=/www.google-analytics.com/127.0.0.1 > > > > to the end of /etc/dnsmasq.conf and done 'kill -SIGHUP nnnn', no > > change, I still get the aliases appearing. > > JD posted the appropriate excerpt from the man page, which includes > the sentence: > > SIGHUP does NOT re-read the configuration file. > Ah, I missed that, sorry! I have killed and re-started dnsmasq, now I *don't* get those aliases. Phew! :-) -- Chris Green From cl at isbd.net Fri Aug 14 11:03:51 2009 From: cl at isbd.net (Chris G) Date: Fri, 14 Aug 2009 11:03:51 +0100 Subject: [Dnsmasq-discuss] DHCP options, in particular setting default route Message-ID: <20090814100351.GC27612@chris> I'm pretty sure dnsmasq can do what I want but I'd just like to confirm the details of how to do it. I want dnsmasq to set default routes for DHCP clients, so I need to use --dhcp-option, so far so good. However the extra bit I'm not quite clear about is that I want to set different default routes for different clients. So I need something like:- --dhcp-option = ,option:router, 192.168.1.1 for each client (or list of clients given by the network id) that needs to use default route 192.168.1.1. What I'm not quite clear about is what the network id looks like and/or if I need to set it myself using other dnsmasq arguments. Can someone elucidate this for me a little please. -- Chris Green From e1-7n32-h2qw-w2h3 at snugmail.com Sat Aug 15 18:50:36 2009 From: e1-7n32-h2qw-w2h3 at snugmail.com (L Forrister) Date: Sat, 15 Aug 2009 10:50:36 -0700 Subject: [Dnsmasq-discuss] My Emailiases: Emailias Reply-Generator for: dnsmasq-discuss@lists.thekelleys.org.uk In-Reply-To: <200908151734.n7FHYVnU018172@all.emailias.com> References: <200908151734.n7FHYVnU018172@all.emailias.com> Message-ID: Hello I just installed dnsmasq 2.49 on an Apple Xserve PPC G5 with OS/X 10.5.8 The make install was error free, but on running the executable I get localadmin$ /usr/local/sbin/dnsmasq -d -bash: /usr/local/sbin/dnsmasq: Bad CPU type in executable I assume this has something do with whether or not the executable is universal but I don't recall anything in the docs about it being restricted to Intel or any such. ?Can someone tell me what's happening? Thanks ?Larry From simon at thekelleys.org.uk Mon Aug 17 14:01:17 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Mon, 17 Aug 2009 14:01:17 +0100 Subject: [Dnsmasq-discuss] Dnsmasq is not sending the hostname to the client. In-Reply-To: <200907271102.54274.james.meyer@operamail.com> References: <200907252036.03233.james.meyer@operamail.com> <200907270929.16150.james.meyer@operamail.com> <2e59e6970907270836o53c50317r81fdd305deada980@mail.gmail.com> <200907271102.54274.james.meyer@operamail.com> Message-ID: <4A89549D.9040108@thekelleys.org.uk> james meyer wrote: > On Monday 27 July 2009, richardvoigt at gmail.com wrote: >> On Mon, Jul 27, 2009 at 9:29 AM, james meyer > wrote: >>> On Monday 27 July 2009, richardvoigt at gmail.com wrote: >>>>> Simon, >>>>> I tried adding the dhcp-ignore-names option as you suggested, but it >>> didn't >>>>> make a difference. >>>> I don't think that dhcp-ignore-names matches against a MAC address as >>>> you've tried to do, it uses a "network-id" instead (although the >>>> dhcp-host line can map between them). Have you tried ignoring all >>>> names first to see if it has the desired effect? Then you can >>>> restrict it if needed after you know whether it works. >>>> >>> Tried adding the line dhcp-ignore-names without any network-id's. >>> It did start ignoring names for other hosts, but didn't help me out in > this >>> situation. >> What version of dnsmasq are you using? >> > I have tried both 2.47 and 2.49. > 2.47 is my preference as it's on my router running the tomato firmware. > 2.49 is installed on my desktop for testing. > > What appears to be happening is > 1) dhcpcd is requesting the hostname from dnsmasq (can be seen in the network > capture) > 2) dnsmasq does not respond with a hostname, unless dhcpcd sends a null > hostname in the request. This also can be seen in the network capture > > I would like to know the suggested hostname regardless of if the client > already has a hostname. > James, What's the current status of this? The behaviour you describe is not the way it's supposed to work. Simon. From james.meyer at operamail.com Mon Aug 17 14:34:06 2009 From: james.meyer at operamail.com (james meyer) Date: Mon, 17 Aug 2009 08:34:06 -0500 Subject: [Dnsmasq-discuss] Dnsmasq is not sending the hostname to the client. In-Reply-To: <4A89549D.9040108@thekelleys.org.uk> References: <200907252036.03233.james.meyer@operamail.com> <200907271102.54274.james.meyer@operamail.com> <4A89549D.9040108@thekelleys.org.uk> Message-ID: <200908170834.06503.james.meyer@operamail.com> On Monday 17 August 2009, Simon Kelley wrote: > james meyer wrote: > > On Monday 27 July 2009, richardvoigt at gmail.com wrote: > >> On Mon, Jul 27, 2009 at 9:29 AM, james meyer > > wrote: > >>> On Monday 27 July 2009, richardvoigt at gmail.com wrote: > >>>>> Simon, > >>>>> I tried adding the dhcp-ignore-names option as you suggested, but it > >>> didn't > >>>>> make a difference. > >>>> I don't think that dhcp-ignore-names matches against a MAC address as > >>>> you've tried to do, it uses a "network-id" instead (although the > >>>> dhcp-host line can map between them). Have you tried ignoring all > >>>> names first to see if it has the desired effect? Then you can > >>>> restrict it if needed after you know whether it works. > >>>> > >>> Tried adding the line dhcp-ignore-names without any network-id's. > >>> It did start ignoring names for other hosts, but didn't help me out in > > this > >>> situation. > >> What version of dnsmasq are you using? > >> > > I have tried both 2.47 and 2.49. > > 2.47 is my preference as it's on my router running the tomato firmware. > > 2.49 is installed on my desktop for testing. > > > > What appears to be happening is > > 1) dhcpcd is requesting the hostname from dnsmasq (can be seen in the network > > capture) > > 2) dnsmasq does not respond with a hostname, unless dhcpcd sends a null > > hostname in the request. This also can be seen in the network capture > > > > I would like to know the suggested hostname regardless of if the client > > already has a hostname. > > > > James, > > What's the current status of this? The behaviour you describe is not the > way it's supposed to work. > > Simon. > Simon, I did not find a solution with dnsmasq, so I changed all my dhcpcd calls to send a null hostname. This was probably a better short term solution, as I can't expect my users to change thier dnsmasq configuration. -james From simon at thekelleys.org.uk Mon Aug 17 16:47:53 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Mon, 17 Aug 2009 16:47:53 +0100 Subject: [Dnsmasq-discuss] Dnsmasq switching to using secondary DNS exclusively In-Reply-To: <249105.38794.qm@web31806.mail.mud.yahoo.com> References: <249105.38794.qm@web31806.mail.mud.yahoo.com> Message-ID: <4A897BA9.4010807@thekelleys.org.uk> Michael Kraft wrote: > I have a WRT54GLv1 with Tomato 1.25 on it. Tomato uses Dnsmasq 2.47 for > DNS. I realize the latest Dnsmasq is 2.49, but I don't see anything in > the change log related to what I'm seeing. I have tomato set up to > cache DNS (150 entries) and handle the DNS queries itself. This results > in a dnsmasq.conf of: > > pid-file=/var/run/dnsmasq.pid > interface=br0 > resolv-file=/etc/resolv.dnsmasq > addn-hosts=/etc/hosts.dnsmasq > expand-hosts > min-port=4096 > dhcp-range=192.168.1.100,192.168.1.149,255.255.255.0,10080m > dhcp-option=3,192.168.1.1 > dhcp-lease-max=255 > dhcp-authoritative > dhcp-host=00:13:CE:2A:1E:82,192.168.1.6,10080m > > The resolv.dnsmasq is: > nameserver 68.87.64.146 > nameserver 68.87.75.194 > > resolv.conf is: > nameserver 127.0.0.1 > > So my primary DNS is 68.87.64.146 and my secondary DNS is 68.87.75.194. > > Every now and then the router starts using the secondary DNS > exclusively. During this time the dnsmasq.conf and resolv.dnsmasq don't > change. I can get the router to start using the primary DNS again by > killing and restarting Dnsmasq (or refreshing the DHCP release from my > ISP). > > It's my understanding that the secondary DNS should only be used if the > primary DNS doesn't answer the DNS query, but at the times I'm > experiencing the problem the primary DNS is responding to queries so > Dnsmasq should be using that. There is nothing in the logs that seem to > indicate any kind of problem as far as I can tell. The only log entries > I ever see relating to nameservers look like the following with the > secondary listed first and the primary listed second: > > Aug 11 23:55:55 ? daemon.info dnsmasq[23367]: using nameserver > 68.87.75.194#53 > Aug 11 23:55:55 ? daemon.info dnsmasq[23367]: using nameserver > 68.87.64.146#53 > > > Since my ISP's secondary DNS is a lot farther away geographically from > me than the primary, this not only slows down DNS queries, but causes > performance issues with Limelight, Akamai and any other server that > determines the server farm, by the DNS location. > > My question is why would Dnsmasq be switching to using the secondary DNS > exclusively and how (short of removing the secondary DNS server > manually) can I stop it from doing this? Dnsmasq doesn't treat these servers as primary and secondary - it considers them equal. The reason that the server in use changes is that dnsmasq sometimes sends a query to both servers, to see which one is fastest. Whichever replies first gets used until the next time the "race" gets run. You can change this behaviour with "strict-order", but be aware that will make performance much worse if the first server ever does fail. Cheers, Simon. From jd1008 at gmail.com Mon Aug 17 17:02:35 2009 From: jd1008 at gmail.com (JD) Date: Mon, 17 Aug 2009 09:02:35 -0700 Subject: [Dnsmasq-discuss] Dnsmasq switching to using secondary DNS exclusively In-Reply-To: <4A897BA9.4010807@thekelleys.org.uk> References: <249105.38794.qm@web31806.mail.mud.yahoo.com> <4A897BA9.4010807@thekelleys.org.uk> Message-ID: <4A897F1B.6030003@gmail.com> On 08/17/2009 08:47 AM, Simon Kelley wrote: > Michael Kraft wrote: > >> I have a WRT54GLv1 with Tomato 1.25 on it. Tomato uses Dnsmasq 2.47 for >> DNS. I realize the latest Dnsmasq is 2.49, but I don't see anything in >> the change log related to what I'm seeing. I have tomato set up to >> cache DNS (150 entries) and handle the DNS queries itself. This results >> in a dnsmasq.conf of: >> >> pid-file=/var/run/dnsmasq.pid >> interface=br0 >> resolv-file=/etc/resolv.dnsmasq >> addn-hosts=/etc/hosts.dnsmasq >> expand-hosts >> min-port=4096 >> dhcp-range=192.168.1.100,192.168.1.149,255.255.255.0,10080m >> dhcp-option=3,192.168.1.1 >> dhcp-lease-max=255 >> dhcp-authoritative >> dhcp-host=00:13:CE:2A:1E:82,192.168.1.6,10080m >> >> The resolv.dnsmasq is: >> nameserver 68.87.64.146 >> nameserver 68.87.75.194 >> >> resolv.conf is: >> nameserver 127.0.0.1 >> >> So my primary DNS is 68.87.64.146 and my secondary DNS is 68.87.75.194. >> >> Every now and then the router starts using the secondary DNS >> exclusively. During this time the dnsmasq.conf and resolv.dnsmasq don't >> change. I can get the router to start using the primary DNS again by >> killing and restarting Dnsmasq (or refreshing the DHCP release from my >> ISP). >> >> It's my understanding that the secondary DNS should only be used if the >> primary DNS doesn't answer the DNS query, but at the times I'm >> experiencing the problem the primary DNS is responding to queries so >> Dnsmasq should be using that. There is nothing in the logs that seem to >> indicate any kind of problem as far as I can tell. The only log entries >> I ever see relating to nameservers look like the following with the >> secondary listed first and the primary listed second: >> >> Aug 11 23:55:55 ? daemon.info dnsmasq[23367]: using nameserver >> 68.87.75.194#53 >> Aug 11 23:55:55 ? daemon.info dnsmasq[23367]: using nameserver >> 68.87.64.146#53 >> >> >> Since my ISP's secondary DNS is a lot farther away geographically from >> me than the primary, this not only slows down DNS queries, but causes >> performance issues with Limelight, Akamai and any other server that >> determines the server farm, by the DNS location. >> >> My question is why would Dnsmasq be switching to using the secondary DNS >> exclusively and how (short of removing the secondary DNS server >> manually) can I stop it from doing this? >> > > Dnsmasq doesn't treat these servers as primary and secondary - it > considers them equal. The reason that the server in use changes is that > dnsmasq sometimes sends a query to both servers, to see which one is > fastest. Whichever replies first gets used until the next time the > "race" gets run. > > You can change this behaviour with "strict-order", but be aware that > will make performance much worse if the first server ever does fail. > > > Cheers, > > Simon. > > That still does not explain why dnsmasq sticks with a nameserver that is slow??? Is it possible to have a config option that will force dnsmasq to switch server if no response comes within a user-settable timeout? JD From simon at thekelleys.org.uk Mon Aug 17 17:06:49 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Mon, 17 Aug 2009 17:06:49 +0100 Subject: [Dnsmasq-discuss] Dnsmasq switching to using secondary DNS exclusively In-Reply-To: <4A897F1B.6030003@gmail.com> References: <249105.38794.qm@web31806.mail.mud.yahoo.com> <4A897BA9.4010807@thekelleys.org.uk> <4A897F1B.6030003@gmail.com> Message-ID: <4A898019.90407@thekelleys.org.uk> JD wrote: > > On 08/17/2009 08:47 AM, Simon Kelley wrote: >> Michael Kraft wrote: >> >>> I have a WRT54GLv1 with Tomato 1.25 on it. Tomato uses Dnsmasq 2.47 for >>> DNS. I realize the latest Dnsmasq is 2.49, but I don't see anything in >>> the change log related to what I'm seeing. I have tomato set up to >>> cache DNS (150 entries) and handle the DNS queries itself. This results >>> in a dnsmasq.conf of: >>> >>> pid-file=/var/run/dnsmasq.pid >>> interface=br0 >>> resolv-file=/etc/resolv.dnsmasq >>> addn-hosts=/etc/hosts.dnsmasq >>> expand-hosts >>> min-port=4096 >>> dhcp-range=192.168.1.100,192.168.1.149,255.255.255.0,10080m >>> dhcp-option=3,192.168.1.1 >>> dhcp-lease-max=255 >>> dhcp-authoritative >>> dhcp-host=00:13:CE:2A:1E:82,192.168.1.6,10080m >>> >>> The resolv.dnsmasq is: >>> nameserver 68.87.64.146 >>> nameserver 68.87.75.194 >>> >>> resolv.conf is: >>> nameserver 127.0.0.1 >>> >>> So my primary DNS is 68.87.64.146 and my secondary DNS is 68.87.75.194. >>> >>> Every now and then the router starts using the secondary DNS >>> exclusively. During this time the dnsmasq.conf and resolv.dnsmasq don't >>> change. I can get the router to start using the primary DNS again by >>> killing and restarting Dnsmasq (or refreshing the DHCP release from my >>> ISP). >>> >>> It's my understanding that the secondary DNS should only be used if the >>> primary DNS doesn't answer the DNS query, but at the times I'm >>> experiencing the problem the primary DNS is responding to queries so >>> Dnsmasq should be using that. There is nothing in the logs that seem to >>> indicate any kind of problem as far as I can tell. The only log entries >>> I ever see relating to nameservers look like the following with the >>> secondary listed first and the primary listed second: >>> >>> Aug 11 23:55:55 ? daemon.info dnsmasq[23367]: using nameserver >>> 68.87.75.194#53 >>> Aug 11 23:55:55 ? daemon.info dnsmasq[23367]: using nameserver >>> 68.87.64.146#53 >>> >>> >>> Since my ISP's secondary DNS is a lot farther away geographically from >>> me than the primary, this not only slows down DNS queries, but causes >>> performance issues with Limelight, Akamai and any other server that >>> determines the server farm, by the DNS location. >>> >>> My question is why would Dnsmasq be switching to using the secondary DNS >>> exclusively and how (short of removing the secondary DNS server >>> manually) can I stop it from doing this? >>> >> Dnsmasq doesn't treat these servers as primary and secondary - it >> considers them equal. The reason that the server in use changes is that >> dnsmasq sometimes sends a query to both servers, to see which one is >> fastest. Whichever replies first gets used until the next time the >> "race" gets run. >> >> You can change this behaviour with "strict-order", but be aware that >> will make performance much worse if the first server ever does fail. >> >> >> Cheers, >> >> Simon. >> >> > > That still does not explain why dnsmasq sticks with a nameserver that is > slow??? > Is it possible to have a config option that will force dnsmasq to switch > server if no > response comes within a user-settable timeout? > > JD It does that test once, and uses which ever server is faster _for_that_query_. That could be affected by cache effects in the upstream server. The test is not run again until a query times-out then the retry is sent to both servers to see which one will reply first. Are you sure that your "secondary" is in fact slower? Cheers, Simon. From jd1008 at gmail.com Mon Aug 17 19:46:48 2009 From: jd1008 at gmail.com (JD) Date: Mon, 17 Aug 2009 11:46:48 -0700 Subject: [Dnsmasq-discuss] Dnsmasq switching to using secondary DNS exclusively In-Reply-To: <4A898001.5040207@thekelleys.org.uk> References: <249105.38794.qm@web31806.mail.mud.yahoo.com> <4A897BA9.4010807@thekelleys.org.uk> <4A897F1B.6030003@gmail.com> <4A898001.5040207@thekelleys.org.uk> Message-ID: <4A89A598.4030504@gmail.com> On 08/17/2009 09:06 AM, Simon Kelley wrote: > JD wrote: >> >> On 08/17/2009 08:47 AM, Simon Kelley wrote: >>> Michael Kraft wrote: >>>> I have a WRT54GLv1 with Tomato 1.25 on it. Tomato uses Dnsmasq >>>> 2.47 for >>>> DNS. I realize the latest Dnsmasq is 2.49, but I don't see >>>> anything in >>>> the change log related to what I'm seeing. I have tomato set up to >>>> cache DNS (150 entries) and handle the DNS queries itself. This >>>> results >>>> in a dnsmasq.conf of: >>>> >>>> pid-file=/var/run/dnsmasq.pid >>>> interface=br0 >>>> resolv-file=/etc/resolv.dnsmasq >>>> addn-hosts=/etc/hosts.dnsmasq >>>> expand-hosts >>>> min-port=4096 >>>> dhcp-range=192.168.1.100,192.168.1.149,255.255.255.0,10080m >>>> dhcp-option=3,192.168.1.1 >>>> dhcp-lease-max=255 >>>> dhcp-authoritative >>>> dhcp-host=00:13:CE:2A:1E:82,192.168.1.6,10080m >>>> >>>> The resolv.dnsmasq is: >>>> nameserver 68.87.64.146 >>>> nameserver 68.87.75.194 >>>> >>>> resolv.conf is: >>>> nameserver 127.0.0.1 >>>> >>>> So my primary DNS is 68.87.64.146 and my secondary DNS is >>>> 68.87.75.194. >>>> >>>> Every now and then the router starts using the secondary DNS >>>> exclusively. During this time the dnsmasq.conf and resolv.dnsmasq >>>> don't >>>> change. I can get the router to start using the primary DNS again by >>>> killing and restarting Dnsmasq (or refreshing the DHCP release from my >>>> ISP). >>>> >>>> It's my understanding that the secondary DNS should only be used if >>>> the >>>> primary DNS doesn't answer the DNS query, but at the times I'm >>>> experiencing the problem the primary DNS is responding to queries so >>>> Dnsmasq should be using that. There is nothing in the logs that >>>> seem to >>>> indicate any kind of problem as far as I can tell. The only log >>>> entries >>>> I ever see relating to nameservers look like the following with the >>>> secondary listed first and the primary listed second: >>>> >>>> Aug 11 23:55:55 ? daemon.info dnsmasq[23367]: using nameserver >>>> 68.87.75.194#53 >>>> Aug 11 23:55:55 ? daemon.info dnsmasq[23367]: using nameserver >>>> 68.87.64.146#53 >>>> >>>> >>>> Since my ISP's secondary DNS is a lot farther away geographically from >>>> me than the primary, this not only slows down DNS queries, but causes >>>> performance issues with Limelight, Akamai and any other server that >>>> determines the server farm, by the DNS location. >>>> >>>> My question is why would Dnsmasq be switching to using the >>>> secondary DNS >>>> exclusively and how (short of removing the secondary DNS server >>>> manually) can I stop it from doing this? >>> Dnsmasq doesn't treat these servers as primary and secondary - it >>> considers them equal. The reason that the server in use changes is that >>> dnsmasq sometimes sends a query to both servers, to see which one is >>> fastest. Whichever replies first gets used until the next time the >>> "race" gets run. >>> >>> You can change this behaviour with "strict-order", but be aware that >>> will make performance much worse if the first server ever does fail. >>> >>> >>> Cheers, >>> >>> Simon. >>> >> >> That still does not explain why dnsmasq sticks with a nameserver that >> is slow??? >> Is it possible to have a config option that will force dnsmasq to >> switch server if no >> response comes within a user-settable timeout? >> >> JD > > It does that test once, and uses which ever server is faster > _for_that_query_. That could be affected by cache effects in the > upstream server. The test is not run again until a query times-out > then the retry is sent to both servers to see which one will reply first. Yes indeed it is. I have run timings on the primary and the secondary. The secondary is always much much slower. This is why I think that the speed of response test ought to be run via a user settable option as far as test frequency, and timeout threshold. > > Are you sure that your "secondary" is in fact slower? > > > Cheers, > > Simon. > Regards, Joe From tim at theallinghams.com Mon Aug 17 22:57:12 2009 From: tim at theallinghams.com (Tim Allingham) Date: Tue, 18 Aug 2009 07:57:12 +1000 Subject: [Dnsmasq-discuss] using dchp-option 121 breaks default route used with public address range Message-ID: <1250546232.15061.6.camel@mini-tim> I'm not sure if this issue is being caused by my ignorance, or if its actually a bug/issue with dnsmasq what I'm trying to achieve is routing particular public addresses via a certain router - essentially need to push out a static route to a machine connected to 2 networks, both with internet access, and enforcing a connection to the mail server of one ISP to be routed via the correct connection. when I add the following line to dnsmasq dhcp-option=121,61.9.168.0/24,192.168.10.30 The default route is lost on the client, leaving me with no routing rules for public addresses outside of the 61.9.168.0/24 address range. adding the line dhcp-option=3,192.168.10.30 has no effect on the routing either. is there any reason that I can't force routing in this manner, or is there something else I'm missing? Cheers Tim Allingham -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090818/1376e7e8/attachment-0001.html From simon at thekelleys.org.uk Tue Aug 18 14:15:57 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Tue, 18 Aug 2009 14:15:57 +0100 Subject: [Dnsmasq-discuss] using dchp-option 121 breaks default route used with public address range In-Reply-To: <1250546232.15061.6.camel@mini-tim> References: <1250546232.15061.6.camel@mini-tim> Message-ID: <4A8AA98D.8010402@thekelleys.org.uk> Tim Allingham wrote: > I'm not sure if this issue is being caused by my ignorance, or if its > actually a bug/issue with dnsmasq > > what I'm trying to achieve is routing particular public addresses via a > certain router - essentially need to push out a static route to a > machine connected to 2 networks, both with internet access, and > enforcing a connection to the mail server of one ISP to be routed via > the correct connection. > > when I add the following line to dnsmasq > dhcp-option=121,61.9.168.0/24,192.168.10.30 > > The default route is lost on the client, leaving me with no routing > rules for public addresses outside of the 61.9.168.0/24 address range. > adding the line > dhcp-option=3,192.168.10.30 > > has no effect on the routing either. is there any reason that I can't > force routing in this manner, or is there something else I'm missing? > The only role dnsmasq has in this is to include the information you supply into the DHCP packets its sends. The interesting and variable bit is what the client on the other end does with the information. What OS is the client running, and what DHCP client? Note that sending option 121 will not stop dnsmasq sending the normal default route as option 3, but it may well cause the client to ignore that. Have you tried setting a general default route in the option 121 with something like dhcp-option=121,61.9.168.0/24,192.168.10.30,0.0.0.0/0, Cheers, Simon. From simon at thekelleys.org.uk Tue Aug 18 14:20:55 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Tue, 18 Aug 2009 14:20:55 +0100 Subject: [Dnsmasq-discuss] Dnsmasq switching to using secondary DNS exclusively In-Reply-To: <4A89A598.4030504@gmail.com> References: <249105.38794.qm@web31806.mail.mud.yahoo.com> <4A897BA9.4010807@thekelleys.org.uk> <4A897F1B.6030003@gmail.com> <4A898001.5040207@thekelleys.org.uk> <4A89A598.4030504@gmail.com> Message-ID: <4A8AAAB7.5020401@thekelleys.org.uk> JD wrote: > > Yes indeed it is. I have run timings on the primary and the secondary. > The secondary is always much much slower. > This is why I think that the speed of response test ought to be run > via a user settable option as far as test frequency, and timeout > threshold. > Adding another tuning knob is probably not sensible - who will ever bother to change it? Unconditionally running the test every 10 seconds or 100 queries is an easy and unobtrusive change that will improve behaviour in this sort of circumstance - I'll look into that. Cheers, Simon. From ottuzzi at gmail.com Thu Aug 20 13:48:13 2009 From: ottuzzi at gmail.com (Piero) Date: Thu, 20 Aug 2009 14:48:13 +0200 Subject: [Dnsmasq-discuss] DNSMasq not using UDP Message-ID: <41a6fe740908200548k1a726044x1769b8381586f0f3@mail.gmail.com> Hi there, how can I make dnsmasq listen also to UDP? It looks like it is binding on port 53/TCP only but I need it on port 53/UDP. [root at opaplnx23 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.2 (Tikanga) [root at opaplnx23 ~]# rpm -qa | grep dnsmasq dnsmasq-2.45-1.el5_2.1 [root at opaplnx23 ~]# netstat -tlpn | grep dnsmasq tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 6365/dnsmasq tcp 0 0 :::53 :::* LISTEN 6365/dnsmasq I'm not seeing something obvious? Thanks Bye Piero -- Stupid is as stupid does. Forrest Gump From ottuzzi at gmail.com Thu Aug 20 14:10:07 2009 From: ottuzzi at gmail.com (Piero) Date: Thu, 20 Aug 2009 15:10:07 +0200 Subject: [Dnsmasq-discuss] DNSMasq not using UDP In-Reply-To: <4A8D47BA.30109@thekelleys.org.uk> References: <41a6fe740908200548k1a726044x1769b8381586f0f3@mail.gmail.com> <4A8D47BA.30109@thekelleys.org.uk> Message-ID: <41a6fe740908200610r496ec268mff7adc6a8f1e9bc2@mail.gmail.com> You are so right! [root at opaplnx23 ~]# netstat -lpn | grep dnsmasq tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 6365/dnsmasq tcp 0 0 :::53 :::* LISTEN 6365/dnsmasq udp 0 0 0.0.0.0:53 0.0.0.0:* 6365/dnsmasq udp 0 0 :::53 :::* 6365/dnsmasq Sorry for the stupid question. Thanks Piero 2009/8/20 Simon Kelley : > Piero wrote: >> >> Hi there, >> >> ? how can I make dnsmasq listen also to UDP? It looks like it is >> binding on port 53/TCP only but I need it on port 53/UDP. >> >> [root at opaplnx23 ~]# cat /etc/redhat-release >> Red Hat Enterprise Linux Server release 5.2 (Tikanga) >> [root at opaplnx23 ~]# rpm -qa | grep dnsmasq >> dnsmasq-2.45-1.el5_2.1 >> [root at opaplnx23 ~]# netstat -tlpn | grep dnsmasq >> tcp ? ? ? ?0 ? ? ?0 0.0.0.0:53 ? ? ? ? ? ? ? ? ?0.0.0.0:* >> ? ? LISTEN ? ? ?6365/dnsmasq >> tcp ? ? ? ?0 ? ? ?0 :::53 ? ? ? ? ? ? ? ? ? ? ? :::* >> ? ? LISTEN ? ? ?6365/dnsmasq >> >> I'm not seeing something obvious? >> > Err, you're giving netstat the -t flag, which tells it to show only TCP > sockets? > > thekelleys:/home/srk# netstat -lpn | grep dnsmasq > tcp ? ? ? ?0 ? ? ?0 0.0.0.0:53 ? ? ? ? ? ? ?0.0.0.0:* LISTEN > 11262/dnsmasq > udp ? ? ? ?0 ? ? ?0 0.0.0.0:53 ? ? ? ? ? ? ?0.0.0.0:* ? ? ? 11262/dnsmasq > udp ? ? ? ?0 ? ? ?0 0.0.0.0:67 ? ? ? ? ? ? ?0.0.0.0:* ? ? ? 11262/dnsmasq > udp ? ? ? ?0 ? ? ?0 0.0.0.0:69 ? ? ? ? ? ? ?0.0.0.0:* ? ? ? 11262/dnsmasq > > > That instance is running DHCP and TFTP too, BTW, hence ports 67 and 69. > > > Cheers, > > Simon. > -- Stupid is as stupid does. Forrest Gump From philippe at faure.ca Thu Aug 20 21:28:29 2009 From: philippe at faure.ca (Philippe Faure) Date: Thu, 20 Aug 2009 16:28:29 -0400 Subject: [Dnsmasq-discuss] TFTP boot Message-ID: <20090820162829.210039kp9eioqp6o@mail.faure.ca> Hello, I am trying to us DNSMASQ to install Ubuntu Server a new machine, but it isn't working. HEre is what I have dhcp-boot=pxelinux.0,fileserver,192.168.0.34 enable-tftp tftp-root=/var/lib/tftpboot dir /var/lib/tftpboot/ drwxrwxrwx 3 nobody nogroup 4.0K 2009-04-17 12:08 . drwxr-xr-x 37 root root 4.0K 2009-06-08 15:22 .. lrwxrwxrwx 1 nobody nogroup 33 2009-06-08 15:24 pxelinux.0 -> ubuntu-installer/amd64/pxelinux.0 lrwxrwxrwx 1 nobody nogroup 35 2009-06-08 15:24 pxelinux.cfg -> ubuntu-installer/amd64/pxelinux.cfg drwxr-xr-x 3 nobody nogroup 4.0K 2009-04-17 12:08 ubuntu-installer -rw-r--r-- 1 nobody nogroup 56 2009-04-17 12:08 version.info Contents of pxelinux.cfg include ubuntu-installer/amd64/boot-screens/menu.cfg default ubuntu-installer/amd64/boot-screens/vesamenu.c32 prompt 0 timeout 0 DNSMASQ.log results Aug 20 16:12:26 dnsmasq[4418]: TFTP sent /var/lib/tftpboot/pxelinux.0 to 192.168.0.60 Aug 20 16:12:26 dnsmasq[4418]: TFTP error 0 TFTP Aborted received from 192.168.0.60 Aug 20 16:12:26 dnsmasq[4418]: TFTP failed sending /var/lib/tftpboot/pxelinux.0 to 192.168.0.60 Aug 20 16:12:26 dnsmasq[4418]: TFTP sent /var/lib/tftpboot/pxelinux.0 to 192.168.0.60 The display on the new box states the following: PXE-T04: Unsupoort Request from 192.168.0.60 PXE-E36: Error Received from TFTP server PXE-M0F: Exiting NVIDIA Boot Agent Does anyone have any idea of what the problem is, or where to start looking to fix it? I know that the new box is getting the IP address from the dHCP server, 192.168.0.60, so it is something with the TFTP server. Thank you Philippe From carlos at fisica.ufpr.br Thu Aug 20 22:43:02 2009 From: carlos at fisica.ufpr.br (Carlos Carvalho) Date: Thu, 20 Aug 2009 18:43:02 -0300 Subject: [Dnsmasq-discuss] DHCP options, in particular setting default route In-Reply-To: <20090814100351.GC27612@chris> References: <20090814100351.GC27612@chris> Message-ID: <19085.50022.957304.12421@fisica.ufpr.br> Chris G (cl at isbd.net) wrote on 14 August 2009 11:03: >I'm pretty sure dnsmasq can do what I want but I'd just like to >confirm the details of how to do it. > >I want dnsmasq to set default routes for DHCP clients, so I need to >use --dhcp-option, so far so good. However the extra bit I'm not >quite clear about is that I want to set different default routes for >different clients. > >So I need something like:- > > --dhcp-option = ,option:router, 192.168.1.1 > >for each client (or list of clients given by the network id) that >needs to use default route 192.168.1.1. > >What I'm not quite clear about is what the network id looks like >and/or if I need to set it myself using other dnsmasq arguments. You have to give the netid for the machine in the dhcp-host declaration. From jd1008 at gmail.com Thu Aug 20 23:01:31 2009 From: jd1008 at gmail.com (JD) Date: Thu, 20 Aug 2009 15:01:31 -0700 Subject: [Dnsmasq-discuss] DHCP options, in particular setting default route In-Reply-To: <19085.50022.957304.12421@fisica.ufpr.br> References: <20090814100351.GC27612@chris> <19085.50022.957304.12421@fisica.ufpr.br> Message-ID: <4A8DC7BB.3080600@gmail.com> On 08/20/2009 02:43 PM, Carlos Carvalho wrote: > Chris G (cl at isbd.net) wrote on 14 August 2009 11:03: > >I'm pretty sure dnsmasq can do what I want but I'd just like to > >confirm the details of how to do it. > > > >I want dnsmasq to set default routes for DHCP clients, so I need to > >use --dhcp-option, so far so good. However the extra bit I'm not > >quite clear about is that I want to set different default routes for > >different clients. > > > >So I need something like:- > > > > --dhcp-option =,option:router, 192.168.1.1 > > > >for each client (or list of clients given by the network id) that > >needs to use default route 192.168.1.1. > > > >What I'm not quite clear about is what the network id looks like > >and/or if I need to set it myself using other dnsmasq arguments. > > You have to give the netid for the machine in the dhcp-host declaration. > > The network ID can be the MAC address of the machine. From carlos at fisica.ufpr.br Fri Aug 21 01:32:04 2009 From: carlos at fisica.ufpr.br (Carlos Carvalho) Date: Thu, 20 Aug 2009 21:32:04 -0300 Subject: [Dnsmasq-discuss] DHCP options, in particular setting default route In-Reply-To: <4A8DC7BB.3080600@gmail.com> References: <20090814100351.GC27612@chris> <19085.50022.957304.12421@fisica.ufpr.br> <4A8DC7BB.3080600@gmail.com> Message-ID: <19085.60164.965275.956982@fisica.ufpr.br> JD (jd1008 at gmail.com) wrote on 20 August 2009 15:01: > >On 08/20/2009 02:43 PM, Carlos Carvalho wrote: >> Chris G (cl at isbd.net) wrote on 14 August 2009 11:03: >> >I'm pretty sure dnsmasq can do what I want but I'd just like to >> >confirm the details of how to do it. >> > >> >I want dnsmasq to set default routes for DHCP clients, so I need to >> >use --dhcp-option, so far so good. However the extra bit I'm not >> >quite clear about is that I want to set different default routes for >> >different clients. >> > >> >So I need something like:- >> > >> > --dhcp-option =,option:router, 192.168.1.1 >> > >> >for each client (or list of clients given by the network id) that >> >needs to use default route 192.168.1.1. >> > >> >What I'm not quite clear about is what the network id looks like >> >and/or if I need to set it myself using other dnsmasq arguments. >> >> You have to give the netid for the machine in the dhcp-host declaration. >> >> >The network ID can be the MAC address of the machine. I'm not sure what you mean. The net-id can be set to the mac yes, but I think it must be done explicitly in the dhcp-host declaration; the manual doesn't say it defaults to the mac if omitted. I'd rather use something easier to recognize; here I set it to the hostname. From taig at melbpc.org.au Fri Aug 21 03:34:52 2009 From: taig at melbpc.org.au (GaryT) Date: Fri, 21 Aug 2009 12:34:52 +1000 Subject: [Dnsmasq-discuss] Where is dnsmasq? In-Reply-To: <4A8AA98D.8010402@thekelleys.org.uk> References: <1250546232.15061.6.camel@mini-tim> <4A8AA98D.8010402@thekelleys.org.uk> Message-ID: <4A8E07CC.5040408@melbpc.org.au> I'm very new to Linux Some of your messages would seem to indicate dnsmasq is on a computer being programmed; I found it in the Router log, which would indicate it's embedded in firmware. Where can I find the elements of the language, or equally convenient if anyone knows, where does one find a reference enabling the unscrambling (interpretation) of a Sagem 1201 Router log? There are many sometimes obvious, sometimes obscure lines in this Log. A large number begin with dnsmasq[225]... also I want to work out what's happening here ie. being read/written and what's in the scratch pad warn kernel: Read Flash: part=[SCRATCH_PAD] warn kernel: Write Flash: part=[SCRATCH_PAD] Is someone altering router settings? More kernel: Enter kerSysFactoryInfoGet: strLen[1024],offset[0] kernel: FactoryInfo[1-10]=[002 090503] Info appreciated Gary From jd1008 at gmail.com Fri Aug 21 06:09:46 2009 From: jd1008 at gmail.com (JD) Date: Thu, 20 Aug 2009 22:09:46 -0700 Subject: [Dnsmasq-discuss] DHCP options, in particular setting default route In-Reply-To: <19085.60164.965275.956982@fisica.ufpr.br> References: <20090814100351.GC27612@chris> <19085.50022.957304.12421@fisica.ufpr.br> <4A8DC7BB.3080600@gmail.com> <19085.60164.965275.956982@fisica.ufpr.br> Message-ID: <4A8E2C1A.2070603@gmail.com> On 08/20/2009 05:32 PM, Carlos Carvalho wrote: > JD (jd1008 at gmail.com) wrote on 20 August 2009 15:01: > > > >On 08/20/2009 02:43 PM, Carlos Carvalho wrote: > >> Chris G (cl at isbd.net) wrote on 14 August 2009 11:03: > >> >I'm pretty sure dnsmasq can do what I want but I'd just like to > >> >confirm the details of how to do it. > >> > > >> >I want dnsmasq to set default routes for DHCP clients, so I need to > >> >use --dhcp-option, so far so good. However the extra bit I'm not > >> >quite clear about is that I want to set different default routes for > >> >different clients. > >> > > >> >So I need something like:- > >> > > >> > --dhcp-option =,option:router, 192.168.1.1 > >> > > >> >for each client (or list of clients given by the network id) that > >> >needs to use default route 192.168.1.1. > >> > > >> >What I'm not quite clear about is what the network id looks like > >> >and/or if I need to set it myself using other dnsmasq arguments. > >> > >> You have to give the netid for the machine in the dhcp-host declaration. > >> > >> > >The network ID can be the MAC address of the machine. > > I'm not sure what you mean. The net-id can be set to the mac yes, but > I think it must be done explicitly in the dhcp-host declaration; the > manual doesn't say it defaults to the mac if omitted. I'd rather use > something easier to recognize; here I set it to the hostname. Well and good - I assumed Chris already knew "it must be done explicitly in the dhcp-host declaration". Also, I did not say it cannot be something like the hostname - I only stated what it can be, and not what it MUST be. Cheers, JD From simon at thekelleys.org.uk Fri Aug 21 09:42:21 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Fri, 21 Aug 2009 09:42:21 +0100 Subject: [Dnsmasq-discuss] TFTP boot In-Reply-To: <20090820162829.210039kp9eioqp6o@mail.faure.ca> References: <20090820162829.210039kp9eioqp6o@mail.faure.ca> Message-ID: <4A8E5DED.1070205@thekelleys.org.uk> Philippe Faure wrote: > Hello, > > I am trying to us DNSMASQ to install Ubuntu Server a new machine, but > it isn't working. HEre is what I have > > dhcp-boot=pxelinux.0,fileserver,192.168.0.34 > enable-tftp > tftp-root=/var/lib/tftpboot > > dir /var/lib/tftpboot/ > drwxrwxrwx 3 nobody nogroup 4.0K 2009-04-17 12:08 . > drwxr-xr-x 37 root root 4.0K 2009-06-08 15:22 .. > lrwxrwxrwx 1 nobody nogroup 33 2009-06-08 15:24 pxelinux.0 -> > ubuntu-installer/amd64/pxelinux.0 > lrwxrwxrwx 1 nobody nogroup 35 2009-06-08 15:24 pxelinux.cfg -> > ubuntu-installer/amd64/pxelinux.cfg > drwxr-xr-x 3 nobody nogroup 4.0K 2009-04-17 12:08 ubuntu-installer > -rw-r--r-- 1 nobody nogroup 56 2009-04-17 12:08 version.info > > Contents of pxelinux.cfg > include ubuntu-installer/amd64/boot-screens/menu.cfg > default ubuntu-installer/amd64/boot-screens/vesamenu.c32 > prompt 0 > timeout 0 > > DNSMASQ.log results > Aug 20 16:12:26 dnsmasq[4418]: TFTP sent /var/lib/tftpboot/pxelinux.0 > to 192.168.0.60 > Aug 20 16:12:26 dnsmasq[4418]: TFTP error 0 TFTP Aborted received from > 192.168.0.60 > Aug 20 16:12:26 dnsmasq[4418]: TFTP failed sending > /var/lib/tftpboot/pxelinux.0 to 192.168.0.60 > Aug 20 16:12:26 dnsmasq[4418]: TFTP sent /var/lib/tftpboot/pxelinux.0 > to 192.168.0.60 > > The display on the new box states the following: > PXE-T04: Unsupoort Request from 192.168.0.60 > PXE-E36: Error Received from TFTP server > PXE-M0F: Exiting NVIDIA Boot Agent > > Does anyone have any idea of what the problem is, or where to start > looking to fix it? I know that the new box is getting the IP address > from the dHCP server, 192.168.0.60, so it is something with the TFTP > server. > > Thank you > > Philippe What version of dnsmasq are you using? It's possible that the boot agent is requesting a transfer in netascii mode, and this will fail in dnsmasq versions before 2.42. Is the failure message really misspelled or is that a copying error? dnsmasq will return the error unsupported request from to the client but I would expect it to log the error too. Exec summary: if you're using a version before 2.42, update. otherwise try and get a packet capture of the interaction using tcpdump and send it to me. Cheers, Simon. From cl at isbd.net Fri Aug 21 10:13:28 2009 From: cl at isbd.net (Chris G) Date: Fri, 21 Aug 2009 10:13:28 +0100 Subject: [Dnsmasq-discuss] DHCP options, in particular setting default route In-Reply-To: <4A8E2C1A.2070603@gmail.com> References: <20090814100351.GC27612@chris> <19085.50022.957304.12421@fisica.ufpr.br> <4A8DC7BB.3080600@gmail.com> <19085.60164.965275.956982@fisica.ufpr.br> <4A8E2C1A.2070603@gmail.com> Message-ID: <20090821091328.GA29310@chris> On Thu, Aug 20, 2009 at 10:09:46PM -0700, JD wrote: > > > On 08/20/2009 05:32 PM, Carlos Carvalho wrote: > > JD (jd1008 at gmail.com) wrote on 20 August 2009 15:01: > > > > > >On 08/20/2009 02:43 PM, Carlos Carvalho wrote: > > >> Chris G (cl at isbd.net) wrote on 14 August 2009 11:03: > > >> >I'm pretty sure dnsmasq can do what I want but I'd just like to > > >> >confirm the details of how to do it. > > >> > > > >> >I want dnsmasq to set default routes for DHCP clients, so I need to > > >> >use --dhcp-option, so far so good. However the extra bit I'm not > > >> >quite clear about is that I want to set different default routes for > > >> >different clients. > > >> > > > >> >So I need something like:- > > >> > > > >> > --dhcp-option =,option:router, 192.168.1.1 > > >> > > > >> >for each client (or list of clients given by the network id) that > > >> >needs to use default route 192.168.1.1. > > >> > > > >> >What I'm not quite clear about is what the network id looks like > > >> >and/or if I need to set it myself using other dnsmasq arguments. > > >> > > >> You have to give the netid for the machine in the dhcp-host declaration. > > >> > > >> > > >The network ID can be the MAC address of the machine. > > > > I'm not sure what you mean. The net-id can be set to the mac yes, but > > I think it must be done explicitly in the dhcp-host declaration; the > > manual doesn't say it defaults to the mac if omitted. I'd rather use > > something easier to recognize; here I set it to the hostname. > Well and good - I assumed Chris already knew > "it must be done explicitly in the dhcp-host declaration". > No I didn't, it was some of what I was asking as it wasn't clear (to me amnyway) what a network ID was. At first glance it *could* have been the system's host name. > Also, I did not say it cannot be something like the hostname - > I only stated what it can be, and not what it MUST be. > Thanks to you both I think I now know that the Network ID is an arbitrary name that *I* give to a system and which can then be used in other DHCP options (and elsewhere maybe). -- Chris Green From da_audiophile at yahoo.com Sat Aug 22 10:30:18 2009 From: da_audiophile at yahoo.com (Audio Phile) Date: Sat, 22 Aug 2009 02:30:18 -0700 (PDT) Subject: [Dnsmasq-discuss] location of cached addresses Message-ID: <333252.62939.qm@web36608.mail.mud.yahoo.com> I read the man page for dnsmasq but still have no idea where dnsmasq stores its list of cached addresses. If the answer is in RAM, is there an option I can use in my /etc/dnsmasq.conf to allow this to be on my file system so that the list survives a reboot? From da_audiophile at yahoo.com Sat Aug 22 10:39:59 2009 From: da_audiophile at yahoo.com (Audio Phile) Date: Sat, 22 Aug 2009 02:39:59 -0700 (PDT) Subject: [Dnsmasq-discuss] dnsmasq question - running as root or user Message-ID: <843901.66667.qm@web36608.mail.mud.yahoo.com> 1) What is the advantage of having dnsmasq run as a non-root user? 2) Is there any kernel module required to do so on 2.6.30? According to some old docs, there was a requirement CONFIG_SECURITY_CAPABILITIES parameter, but it obsolete on kernel versions >2.6.26 (reference 1). Nor does it appear in the config documentation for the latest kernel (reference 2). 1) http://cateee.net/lkddb/web-lkddb/SECURITY_CAPABILITIES.html 2) http://www.kernel.org/doc/menuconfig/x86.html From jd1008 at gmail.com Sat Aug 22 16:57:37 2009 From: jd1008 at gmail.com (JD) Date: Sat, 22 Aug 2009 08:57:37 -0700 Subject: [Dnsmasq-discuss] location of cached addresses In-Reply-To: <333252.62939.qm@web36608.mail.mud.yahoo.com> References: <333252.62939.qm@web36608.mail.mud.yahoo.com> Message-ID: <4A901571.906@gmail.com> On 08/22/2009 02:30 AM, Audio Phile wrote: > I read the man page for dnsmasq but still have no idea where dnsmasq stores its list of cached addresses. If the answer is in RAM, is there an option I can use in my /etc/dnsmasq.conf to allow this to be on my file system so that the list survives a reboot? > > This looks like a man page deficiency. If it is a file, it should be listed under the man page section FILES JD From richardvoigt at gmail.com Sat Aug 22 17:03:08 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Sat, 22 Aug 2009 11:03:08 -0500 Subject: [Dnsmasq-discuss] dnsmasq question - running as root or user In-Reply-To: <843901.66667.qm@web36608.mail.mud.yahoo.com> References: <843901.66667.qm@web36608.mail.mud.yahoo.com> Message-ID: <2e59e6970908220903q654a2773ue5c58f5182f839ae@mail.gmail.com> On Sat, Aug 22, 2009 at 4:39 AM, Audio Phile wrote: > 1) What is the advantage of having dnsmasq run as a non-root user? If someone found an exploitable bug in dnsmasq and you were running it as root, your system would be toast. If running as another user, damage would be limited. In the most secure scenario, where dnsmasq has a dedicated user, an attacker could only affect the dhcp leases file. > 2) Is there any kernel module required to do so on 2.6.30? Nope. setuid doesn't require any kernel extensions, although some extensions could interfere with it. > > According to some old docs, there was a requirement CONFIG_SECURITY_CAPABILITIES parameter, but it obsolete on kernel versions >2.6.26 (reference 1). ?Nor does it appear in the config documentation for the latest kernel (reference 2). > > 1) ?http://cateee.net/lkddb/web-lkddb/SECURITY_CAPABILITIES.html > 2) ?http://www.kernel.org/doc/menuconfig/x86.html There is definitely no requirement to use security-enhanced linux to run dnsmasq. But if you do use selinux, make sure to configure the capabilities correctly. From carlos at fisica.ufpr.br Sat Aug 22 17:22:40 2009 From: carlos at fisica.ufpr.br (Carlos Carvalho) Date: Sat, 22 Aug 2009 13:22:40 -0300 Subject: [Dnsmasq-discuss] location of cached addresses In-Reply-To: <333252.62939.qm@web36608.mail.mud.yahoo.com> References: <333252.62939.qm@web36608.mail.mud.yahoo.com> Message-ID: <19088.6992.154038.956771@fisica.ufpr.br> Audio Phile (da_audiophile at yahoo.com) wrote on 22 August 2009 02:30: >I read the man page for dnsmasq but still have no idea where dnsmasq >stores its list of cached addresses. If the answer is in RAM, is >there an option I can use in my /etc/dnsmasq.conf to allow this to >be on my file system so that the list survives a reboot? It's a file on disk. You can specify dhcp-leasefile= in dnsmasq.conf if you want. If not given the default depends on the system; the most common case is probably /var/lib/misc/dnsmasq.leases. From carlos at fisica.ufpr.br Sat Aug 22 17:25:02 2009 From: carlos at fisica.ufpr.br (Carlos Carvalho) Date: Sat, 22 Aug 2009 13:25:02 -0300 Subject: [Dnsmasq-discuss] location of cached addresses In-Reply-To: <333252.62939.qm@web36608.mail.mud.yahoo.com> References: <333252.62939.qm@web36608.mail.mud.yahoo.com> Message-ID: <19088.7134.189390.358797@fisica.ufpr.br> Audio Phile (da_audiophile at yahoo.com) wrote on 22 August 2009 02:30: >I read the man page for dnsmasq but still have no idea where dnsmasq >stores its list of cached addresses. If the answer is in RAM, is >there an option I can use in my /etc/dnsmasq.conf to allow this to >be on my file system so that the list survives a reboot? Oops, it seems you mean the dns name/ip pairs, not dhcp ones... These are only in ram, and cannot be saved/restored. From cquike at arcor.de Sat Aug 22 22:51:42 2009 From: cquike at arcor.de (Enrique) Date: Sat, 22 Aug 2009 23:51:42 +0200 Subject: [Dnsmasq-discuss] dnsmasq replies with 127.0.01 Message-ID: <200908222351.42311.cquike@arcor.de> Hi, I am using dnsmasq in the context of the virt-manager software. My server contains the virtualization software, including dnsmasq. I have an issue when client of dnsmasq (one of the virtual machines) tries to resolve the name of the server. Because dnsmasq runs in the server and it reads the /etc/hosts file, it returns 127.0.0.1 as the IP of the server, instead of the IP associated to eth0. Is there an easy workaround to solve this issue? I think that in general, dnsmasq should avoid replying 127.0.0.1 to remote clients, or alternatively not to resolve hostname, even if it is in /etc/hosts. Regards, Enrique From carlos at fisica.ufpr.br Sun Aug 23 01:07:46 2009 From: carlos at fisica.ufpr.br (Carlos Carvalho) Date: Sat, 22 Aug 2009 21:07:46 -0300 Subject: [Dnsmasq-discuss] dnsmasq replies with 127.0.01 In-Reply-To: <200908222351.42311.cquike@arcor.de> References: <200908222351.42311.cquike@arcor.de> Message-ID: <19088.34898.724018.490515@fisica.ufpr.br> Enrique (cquike at arcor.de) wrote on 22 August 2009 23:51: > I am using dnsmasq in the context of the virt-manager software. My server >contains the virtualization software, including dnsmasq. I have an issue when >client of dnsmasq (one of the virtual machines) tries to resolve the name of >the server. Because dnsmasq runs in the server and it reads the /etc/hosts >file, it returns 127.0.0.1 as the IP of the server, instead of the IP >associated to eth0. How does dnsmasq discover that name-of-the-server is 127.0.0.1? In the machines I run dnsmasq it's not able to guess that much. The only way I can imagine is that you put this entry in /etc/hosts. If so, don't. The only entry pointing to 127.0.0.1 should be localhost. Just put IP-of-the-server name-of-the-server; no need to worry about routing, the kernel is smart enough to discover it's local and send it to the internal IP. From cquike at arcor.de Mon Aug 24 22:40:01 2009 From: cquike at arcor.de (Enrique) Date: Mon, 24 Aug 2009 23:40:01 +0200 Subject: [Dnsmasq-discuss] dnsmasq replies with 127.0.01 In-Reply-To: <19088.34898.724018.490515@fisica.ufpr.br> References: <200908222351.42311.cquike@arcor.de> <19088.34898.724018.490515@fisica.ufpr.br> Message-ID: <200908242340.01512.cquike@arcor.de> Hi, yes, that right, the hostname is assigned to 127.0.0.1 via the /etc/hosts. Since the server gets its IP using DHCP, I could not hardcode the IP in /etc/hosts. However, the master DNS resolves my hostname properly, so that solved the problem. At home, however, where I have another setup, my ISP doesn't resolve my hostname, of course. That forces me to put my hostname in /etc/hosts bound to 127.0.0.1, so the problem persists... Anyway, in my home setup it is not so important. El Domingo, 23 de Agosto de 2009, Carlos Carvalho escribi?: > Enrique (cquike at arcor.de) wrote on 22 August 2009 23:51: > > I am using dnsmasq in the context of the virt-manager software. My > > server contains the virtualization software, including dnsmasq. I have > > an issue when client of dnsmasq (one of the virtual machines) tries to > > resolve the name of the server. Because dnsmasq runs in the server and > > it reads the /etc/hosts file, it returns 127.0.0.1 as the IP of the > > server, instead of the IP associated to eth0. > > How does dnsmasq discover that name-of-the-server is 127.0.0.1? In the > machines I run dnsmasq it's not able to guess that much. The only way > I can imagine is that you put this entry in /etc/hosts. If so, don't. > The only entry pointing to 127.0.0.1 should be localhost. Just put > IP-of-the-server name-of-the-server; no need to worry about routing, > the kernel is smart enough to discover it's local and send it to the > internal IP. > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss From richardvoigt at gmail.com Mon Aug 24 23:26:38 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Mon, 24 Aug 2009 17:26:38 -0500 Subject: [Dnsmasq-discuss] dnsmasq replies with 127.0.01 In-Reply-To: <200908242340.01512.cquike@arcor.de> References: <200908222351.42311.cquike@arcor.de> <19088.34898.724018.490515@fisica.ufpr.br> <200908242340.01512.cquike@arcor.de> Message-ID: <2e59e6970908241526v6575707ei71c0ea4f060a6d30@mail.gmail.com> On Mon, Aug 24, 2009 at 4:40 PM, Enrique wrote: > > ?Hi, > ?yes, that right, the hostname is assigned to 127.0.0.1 via the /etc/hosts. > Since the server gets its IP using DHCP, I could not hardcode the IP > in /etc/hosts. However, the master DNS resolves my hostname properly, so that > solved the problem. > ?At home, however, where I have another setup, my ISP doesn't resolve my > hostname, of course. That forces me to put my hostname in /etc/hosts bound to > 127.0.0.1, so the problem persists... Anyway, in my home setup it is not so > important. For dynamic addresses, this is the option you want: --interface-name=, Return a DNS record associating the name with the primary address on the given interface. This flag specifies an A record for the given name in the same way as an /etc/hosts line, except that the address is not constant, but taken from the given interface. If the interface is down, not configured or non-existent, an empty record is returned. The matching PTR record is also created, mapping the interface address to the name. More than one name may be associated with an interface address by repeating the flag; in that case the first instance is used for the reverse address-to-name mapping. http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html > > > El Domingo, 23 de Agosto de 2009, Carlos Carvalho escribi?: >> Enrique (cquike at arcor.de) wrote on 22 August 2009 23:51: >> ?> I am using dnsmasq in the context of the virt-manager software. My >> ?> server contains the virtualization software, including dnsmasq. I have >> ?> an issue when client of dnsmasq (one of the virtual machines) tries to >> ?> resolve the name of the server. Because dnsmasq runs in the server and >> ?> it reads the /etc/hosts file, it returns 127.0.0.1 as the IP of the >> ?> server, instead of the IP associated to eth0. >> >> How does dnsmasq discover that name-of-the-server is 127.0.0.1? In the >> machines I run dnsmasq it's not able to guess that much. The only way >> I can imagine is that you put this entry in /etc/hosts. If so, don't. >> The only entry pointing to 127.0.0.1 should be localhost. Just put >> IP-of-the-server name-of-the-server; no need to worry about routing, >> the kernel is smart enough to discover it's local and send it to the >> internal IP. >> >> _______________________________________________ >> Dnsmasq-discuss mailing list >> Dnsmasq-discuss at lists.thekelleys.org.uk >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From philippe at faure.ca Tue Aug 25 02:01:09 2009 From: philippe at faure.ca (Philippe Faure) Date: Mon, 24 Aug 2009 21:01:09 -0400 Subject: [Dnsmasq-discuss] TFTP Boot update "for those who find this problem in the future" Message-ID: <20090824210109.535670rwlfs9iccg@mail.faure.ca> It would seem that the network MTU was my limiting factor. With Simon's Help, we were able to find the problem and solution. My config file didn't mention (being that it was too old) the switch, tftp-no-blocksize Adding it, and restarting dnsmasq, the new system booted straight to the install page. I am using a boot client that is part of the motherboard. MB: Asus, M4N78 Pro Nvidia Boot Agent version: 249.0542. Snip from Simon's Email > OK, it looks like the client is asking for a blocksize (ie packetsize) > of 1456 bytes, and that's too big for your network. Because of that the > packets are getting fragmented and that's really confusing the client: > in the end the client does something really strange which provokes the > "unsupported request" error. > > Try adding > tftp-no-blocksize > > to /etc/dnsmasq.conf. That will cause dnsmasq to reject the request from > the client for bigger blocks, and may be enough to make it all work. > Alternatively if you can increase the MTU on the network that might fix > things. Philippe From richardvoigt at gmail.com Tue Aug 25 05:14:55 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Mon, 24 Aug 2009 23:14:55 -0500 Subject: [Dnsmasq-discuss] TFTP Boot update "for those who find this problem in the future" In-Reply-To: <20090824210109.535670rwlfs9iccg@mail.faure.ca> References: <20090824210109.535670rwlfs9iccg@mail.faure.ca> Message-ID: <2e59e6970908242114y60154b5bv2ac51275a3b7a466@mail.gmail.com> I can't think of a single circumstance where a manufacturer-provided boot PROM would have more appropriate network-specific settings than the TFTP server configuration. Maybe tftp-no-blocksize should be set by default (with a tftp-honor-blocksize to negate it). But I don't use BOOTP remote booting, so Simon probably has good reasons for doing things the way they are. On Mon, Aug 24, 2009 at 8:01 PM, Philippe Faure wrote: > It would seem that the network MTU was my limiting factor. ?With > Simon's Help, we were able to find the problem and solution. > > My config file didn't mention (being that it was too old) the switch, > tftp-no-blocksize > > Adding it, and restarting dnsmasq, the new system booted straight to > the install page. > > I am using a boot client that is part of the motherboard. > MB: Asus, M4N78 Pro > Nvidia Boot Agent version: 249.0542. > > Snip from Simon's Email > >> OK, it looks like the client is asking for a blocksize (ie packetsize) >> of 1456 bytes, and that's too big for your network. Because of that the >> packets are getting fragmented and that's really confusing the client: >> in the end the client does something really strange which provokes the >> "unsupported request" error. >> >> Try adding >> tftp-no-blocksize >> >> to /etc/dnsmasq.conf. That will cause dnsmasq to reject the request from >> the client for bigger blocks, and may be enough to make it all work. >> Alternatively if you can increase the MTU on the network that might fix >> things. > > > Philippe > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From simon at thekelleys.org.uk Tue Aug 25 10:31:00 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Tue, 25 Aug 2009 10:31:00 +0100 Subject: [Dnsmasq-discuss] TFTP Boot update "for those who find this problem in the future" In-Reply-To: <2e59e6970908242114y60154b5bv2ac51275a3b7a466@mail.gmail.com> References: <20090824210109.535670rwlfs9iccg@mail.faure.ca> <2e59e6970908242114y60154b5bv2ac51275a3b7a466@mail.gmail.com> Message-ID: <4A93AF54.2060909@thekelleys.org.uk> richardvoigt at gmail.com wrote: > I can't think of a single circumstance where a manufacturer-provided > boot PROM would have more appropriate network-specific settings than > the TFTP server configuration. > > Maybe tftp-no-blocksize should be set by default (with a > tftp-honor-blocksize to negate it). > > But I don't use BOOTP remote booting, so Simon probably has good > reasons for doing things the way they are. > Setting tftp-no-blocksize forces 512-byte blocks and makes the already-slow TFTP transfer three times slower. Since most netbooting happens over a local net which is a physical ethernet with well-known MTU, it makes sense for the client to request a blocksize suitable for that media. It's not clear to me why the MTU on Philippe's network is smaller, but I think a small MTU is a fairly rare occurrence. Even when it does happen, it shouldn't be a show stopper: that takes badly broken client firmware that has clearly never had any code-paths other than the most common ones tested. Cheers, Simon. From richardvoigt at gmail.com Tue Aug 25 14:52:23 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Tue, 25 Aug 2009 08:52:23 -0500 Subject: [Dnsmasq-discuss] TFTP Boot update "for those who find this problem in the future" In-Reply-To: <4A93AF54.2060909@thekelleys.org.uk> References: <20090824210109.535670rwlfs9iccg@mail.faure.ca> <2e59e6970908242114y60154b5bv2ac51275a3b7a466@mail.gmail.com> <4A93AF54.2060909@thekelleys.org.uk> Message-ID: <2e59e6970908250652r3dc7ab9n51d9cff76e3cf451@mail.gmail.com> On Tue, Aug 25, 2009 at 4:31 AM, Simon Kelley wrote: > richardvoigt at gmail.com wrote: >> >> I can't think of a single circumstance where a manufacturer-provided >> boot PROM would have more appropriate network-specific settings than >> the TFTP server configuration. >> >> Maybe tftp-no-blocksize should be set by default (with a >> tftp-honor-blocksize to negate it). >> >> But I don't use BOOTP remote booting, so Simon probably has good >> reasons for doing things the way they are. >> > > Setting tftp-no-blocksize forces 512-byte blocks and makes the already-slow > TFTP transfer three times slower. Since most netbooting happens over a local > net which is a physical ethernet with well-known MTU, it makes sense for the > client to request a blocksize suitable for that media. Is that 512 adjustable? b/c the local dnsmasq admin can surely make a better choice than the PROM developer. Plus I think most tcp/ip stacks automatically determine path MTU, don't know if dnsmasq could retrieve the value estimated for some other local host on the same interface as a reasonable default in the absence of configuration. There's probably no portable way to do that though. Also, a quick look at the protocol indicates that "only one packet may be in-flight at a time" but that data packets and acknowledgements all carry sequence numbers, I'm not sure what exactly about the format requires stop-and-wait. > > It's not clear to me why the MTU on Philippe's network is smaller, but I > ?think a small MTU is a fairly rare occurrence. Even when it does happen, it > shouldn't be a show stopper: that takes badly broken client firmware that > has clearly never had any code-paths other than the most common ones tested. Passing through a switch which adds VLAN marking often causes fragmentation of maximally sized payloads. Wireless hops could change MSS as well. But maybe the best solution would just be to mention tftp-no-blocksize in the error message as a possible fix. > > Cheers, > > Simon. > From philippe at faure.ca Tue Aug 25 14:54:37 2009 From: philippe at faure.ca (Philippe Faure) Date: Tue, 25 Aug 2009 09:54:37 -0400 Subject: [Dnsmasq-discuss] TFTP Boot update "for those who find this problem in the future" In-Reply-To: <2e59e6970908242114y60154b5bv2ac51275a3b7a466@mail.gmail.com> References: <20090824210109.535670rwlfs9iccg@mail.faure.ca> <2e59e6970908242114y60154b5bv2ac51275a3b7a466@mail.gmail.com> Message-ID: <20090825095437.2080503saclziakg@mail.faure.ca> The issue isn't really with the boot client, but with my network. I had to pair back the MTU size, so the blocks being handed out are smaller than what is normal (set to 1400). There is something "fishy" with my router, ISP and work network, that it wouldn't let me access the my home server from work. I completely forgot about this limitation till Simon mentioned blocksizes while debugging this problem. (I am going to be replacing the router soon). Because of this limitation, the TFTP had problems. I would suggest to leave things the way they are, but have the tftp-no-blocksize as an option. Since my case is the special case, probably not the norm. Philippe Quoting "richardvoigt at gmail.com" : > I can't think of a single circumstance where a manufacturer-provided > boot PROM would have more appropriate network-specific settings than > the TFTP server configuration. > > Maybe tftp-no-blocksize should be set by default (with a > tftp-honor-blocksize to negate it). > > But I don't use BOOTP remote booting, so Simon probably has good > reasons for doing things the way they are. > > On Mon, Aug 24, 2009 at 8:01 PM, Philippe Faure wrote: >> It would seem that the network MTU was my limiting factor. ?With >> Simon's Help, we were able to find the problem and solution. >> >> My config file didn't mention (being that it was too old) the switch, >> tftp-no-blocksize >> >> Adding it, and restarting dnsmasq, the new system booted straight to >> the install page. >> >> I am using a boot client that is part of the motherboard. >> MB: Asus, M4N78 Pro >> Nvidia Boot Agent version: 249.0542. >> >> Snip from Simon's Email >> >>> OK, it looks like the client is asking for a blocksize (ie packetsize) >>> of 1456 bytes, and that's too big for your network. Because of that the >>> packets are getting fragmented and that's really confusing the client: >>> in the end the client does something really strange which provokes the >>> "unsupported request" error. >>> >>> Try adding >>> tftp-no-blocksize >>> >>> to /etc/dnsmasq.conf. That will cause dnsmasq to reject the request from >>> the client for bigger blocks, and may be enough to make it all work. >>> Alternatively if you can increase the MTU on the network that might fix >>> things. >> >> >> Philippe >> >> >> _______________________________________________ >> Dnsmasq-discuss mailing list >> Dnsmasq-discuss at lists.thekelleys.org.uk >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >> > From simon at thekelleys.org.uk Tue Aug 25 15:07:32 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Tue, 25 Aug 2009 15:07:32 +0100 Subject: [Dnsmasq-discuss] TFTP Boot update "for those who find this problem in the future" In-Reply-To: <2e59e6970908250652r3dc7ab9n51d9cff76e3cf451@mail.gmail.com> References: <20090824210109.535670rwlfs9iccg@mail.faure.ca> <2e59e6970908242114y60154b5bv2ac51275a3b7a466@mail.gmail.com> <4A93AF54.2060909@thekelleys.org.uk> <2e59e6970908250652r3dc7ab9n51d9cff76e3cf451@mail.gmail.com> Message-ID: <4A93F024.3090102@thekelleys.org.uk> richardvoigt at gmail.com wrote: > On Tue, Aug 25, 2009 at 4:31 AM, Simon Kelley wrote: >> richardvoigt at gmail.com wrote: >>> I can't think of a single circumstance where a manufacturer-provided >>> boot PROM would have more appropriate network-specific settings than >>> the TFTP server configuration. >>> >>> Maybe tftp-no-blocksize should be set by default (with a >>> tftp-honor-blocksize to negate it). >>> >>> But I don't use BOOTP remote booting, so Simon probably has good >>> reasons for doing things the way they are. >>> >> Setting tftp-no-blocksize forces 512-byte blocks and makes the already-slow >> TFTP transfer three times slower. Since most netbooting happens over a local >> net which is a physical ethernet with well-known MTU, it makes sense for the >> client to request a blocksize suitable for that media. > > Is that 512 adjustable? b/c the local dnsmasq admin can surely make a > better choice than the PROM developer. Sort of. If the client doesn't invoke the blocksize extension, then it has to be 512. If the client says "I want blocksize x" then the server can reply "you can have blocksize y" where y Plus I think most tcp/ip > stacks automatically determine path MTU, don't know if dnsmasq could > retrieve the value estimated for some other local host on the same > interface as a reasonable default in the absence of configuration. > There's probably no portable way to do that though. Path-MTU discovery is turned off for the UDP socket used for TFTP, because the presence of the don't fraqment bit confuses some PXE ROMs. Sadly it looks like receiving fragmented packets confuses other PXE ROMS! > > Also, a quick look at the protocol indicates that "only one packet may > be in-flight at a time" but that data packets and acknowledgements all > carry sequence numbers, I'm not sure what exactly about the format > requires stop-and-wait. It's specified in the RFC: the T in TFTP stands for "trivial". > >> It's not clear to me why the MTU on Philippe's network is smaller, but I >> think a small MTU is a fairly rare occurrence. Even when it does happen, it >> shouldn't be a show stopper: that takes badly broken client firmware that >> has clearly never had any code-paths other than the most common ones tested. > > Passing through a switch which adds VLAN marking often causes > fragmentation of maximally sized payloads. Wireless hops could change > MSS as well. A possible fix for some (but not all) situations is to check the MTU on the interface handling the TFTP traffic and scale back blocksize requests to match that. > > But maybe the best solution would just be to mention tftp-no-blocksize > in the error message as a possible fix. Easier said than done: the sequence we saw with the NVIDIA PXE ROM was PXE asks for data { PXE gets data (fragmented) and ignores it server times out and retries } repeat PXE times out and send completely nonsense ACK packet to the wrong port dnsmasq generates "unsupported request" because it doesn't understand the packet. The extent of broken-ness in netboot firmware is astonishing. Cheers, Simon. From ottuzzi at gmail.com Tue Aug 25 15:32:37 2009 From: ottuzzi at gmail.com (Piero) Date: Tue, 25 Aug 2009 16:32:37 +0200 Subject: [Dnsmasq-discuss] DNSMasq caching DNS query after restart? Message-ID: <41a6fe740908250732n2f6e4df7jb39599c27a689654@mail.gmail.com> Hi there, I have a strange issue with DNSMasq: it looks like it saves dns cached query and keep them after a restart. Here is the problem: the host opaplnx13 didn't reverse lookup and I saw this in DNSMasq logs. I fixed the problem in "master DNS servers" and they actually reverse lookup opaplnx13 correctly but DNSMasq actually does not. It doesn't even after a restart. 10.145.3.71 and 10.145.3.72 are DNSMasq servers 10.145.1.121 is a master server [root at opaplnx23 etc]# nslookup > server 10.145.3.71 Default server: 10.145.3.71 Address: 10.145.3.71#53 > 10.145.3.41 Server: 10.145.3.71 Address: 10.145.3.71#53 ** server can't find 41.3.145.10.in-addr.arpa: NXDOMAIN > server 10.145.3.72 Default server: 10.145.3.72 Address: 10.145.3.72#53 > 10.145.3.41 Server: 10.145.3.72 Address: 10.145.3.72#53 ** server can't find 41.3.145.10.in-addr.arpa: NXDOMAIN > server 10.145.1.121 Default server: 10.145.1.121 Address: 10.145.1.121#53 > 10.145.3.41 Server: 10.145.1.121 Address: 10.145.1.121#53 41.3.145.10.in-addr.arpa name = opaplnx13.intra.azosp.vr.it. In DNSMasq log I can see: Aug 25 16:21:06 dnsmasq[6373]: query[PTR] 41.3.145.10.in-addr.arpa from 10.145.3.69 Aug 25 16:21:06 dnsmasq[6373]: config 10.145.3.41 is NXDOMAIN-IPv4 How is it possible? Is there a cache file somewhere? Many thanks Piero -- Stupid is as stupid does. Forrest Gump From simon at thekelleys.org.uk Tue Aug 25 15:58:33 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Tue, 25 Aug 2009 15:58:33 +0100 Subject: [Dnsmasq-discuss] DNSMasq caching DNS query after restart? In-Reply-To: <41a6fe740908250732n2f6e4df7jb39599c27a689654@mail.gmail.com> References: <41a6fe740908250732n2f6e4df7jb39599c27a689654@mail.gmail.com> Message-ID: <4A93FC19.3040505@thekelleys.org.uk> Piero wrote: > Hi there, > > I have a strange issue with DNSMasq: it looks like it saves dns > cached query and keep them after a restart. > Here is the problem: the host opaplnx13 didn't reverse lookup and I > saw this in DNSMasq logs. I fixed the problem in "master DNS servers" > and they actually reverse lookup opaplnx13 correctly but DNSMasq > actually does not. It doesn't even after a restart. > > 10.145.3.71 and 10.145.3.72 are DNSMasq servers > 10.145.1.121 is a master server > > [root at opaplnx23 etc]# nslookup >> server 10.145.3.71 > Default server: 10.145.3.71 > Address: 10.145.3.71#53 >> 10.145.3.41 > Server: 10.145.3.71 > Address: 10.145.3.71#53 > > ** server can't find 41.3.145.10.in-addr.arpa: NXDOMAIN >> server 10.145.3.72 > Default server: 10.145.3.72 > Address: 10.145.3.72#53 >> 10.145.3.41 > Server: 10.145.3.72 > Address: 10.145.3.72#53 > > ** server can't find 41.3.145.10.in-addr.arpa: NXDOMAIN >> server 10.145.1.121 > Default server: 10.145.1.121 > Address: 10.145.1.121#53 >> 10.145.3.41 > Server: 10.145.1.121 > Address: 10.145.1.121#53 > > 41.3.145.10.in-addr.arpa name = opaplnx13.intra.azosp.vr.it. > > In DNSMasq log I can see: > Aug 25 16:21:06 dnsmasq[6373]: query[PTR] 41.3.145.10.in-addr.arpa > from 10.145.3.69 > Aug 25 16:21:06 dnsmasq[6373]: config 10.145.3.41 is NXDOMAIN-IPv4 ^^^^^^^ It's not cached, there's something in your dnsmasq configuration that's causing it to answer in that way, > > How is it possible? Is there a cache file somewhere? > No cache file, something in /etc/dnsmasq.conf Cheers, Simon. From matthias.andree at gmx.de Tue Aug 25 16:26:21 2009 From: matthias.andree at gmx.de (Matthias Andree) Date: Tue, 25 Aug 2009 17:26:21 +0200 Subject: [Dnsmasq-discuss] DNSMasq caching DNS query after restart? In-Reply-To: <41a6fe740908250732n2f6e4df7jb39599c27a689654@mail.gmail.com> References: <41a6fe740908250732n2f6e4df7jb39599c27a689654@mail.gmail.com> Message-ID: <4A94029D.6030808@gmx.de> Piero schrieb: > Hi there, > > I have a strange issue with DNSMasq: it looks like it saves dns > cached query and keep them after a restart. > Here is the problem: the host opaplnx13 didn't reverse lookup and I > saw this in DNSMasq logs. I fixed the problem in "master DNS servers" > and they actually reverse lookup opaplnx13 correctly but DNSMasq > actually does not. It doesn't even after a restart. > > 10.145.3.71 and 10.145.3.72 are DNSMasq servers > 10.145.1.121 is a master server > > [root at opaplnx23 etc]# nslookup >> server 10.145.3.71 > Default server: 10.145.3.71 > Address: 10.145.3.71#53 >> 10.145.3.41 > Server: 10.145.3.71 > Address: 10.145.3.71#53 > > ** server can't find 41.3.145.10.in-addr.arpa: NXDOMAIN >> server 10.145.3.72 > Default server: 10.145.3.72 > Address: 10.145.3.72#53 >> 10.145.3.41 > Server: 10.145.3.72 > Address: 10.145.3.72#53 > > ** server can't find 41.3.145.10.in-addr.arpa: NXDOMAIN >> server 10.145.1.121 > Default server: 10.145.1.121 > Address: 10.145.1.121#53 >> 10.145.3.41 > Server: 10.145.1.121 > Address: 10.145.1.121#53 > > 41.3.145.10.in-addr.arpa name = opaplnx13.intra.azosp.vr.it. > > In DNSMasq log I can see: > Aug 25 16:21:06 dnsmasq[6373]: query[PTR] 41.3.145.10.in-addr.arpa > from 10.145.3.69 > Aug 25 16:21:06 dnsmasq[6373]: config 10.145.3.41 is NXDOMAIN-IPv4 > > How is it possible? Is there a cache file somewhere? 1. don't use nslookup for any kind of testing, you often get very strange results. Use dig instead, or host. dig for instance will also show the TTL, which can be rather useful when dealing with "is this data cached" sort of questions. 2. dnsmasq is a forwarder, and if the upstream server caches the result, then dnsmasq will get a cached result. From cl at isbd.net Tue Aug 25 17:44:33 2009 From: cl at isbd.net (Chris G) Date: Tue, 25 Aug 2009 17:44:33 +0100 Subject: [Dnsmasq-discuss] One client gets my domain name appended, another gets .local, why? Message-ID: <20090825164433.GB29922@chris> I have dnsmasq running with a fairly basic configuration but (among other things) it does have:- expand-hosts domain=isbd.net Two clients do as I expected and their host names have isbd.net appended:- maxine.isbd.net ether 00:50:8d:93:fd:09 C eth0 C475IP.isbd.net ether 00:01:e3:9d:8b:b5 C eth0 But one doesn't:- MyBookWorld.local ether 00:90:a9:70:06:ff C eth0 Can anyone explain why that one gets .local appended rather than .isbd.net and more to the point how can I fix it (apart from hard coding it somewhere)? MyBookWorld.local is a Western Digital NAS running some sort of Linux, I have command line root access to it but would prefer not to modify it if there's a better way to make it get the domain name. The MyBookWorld.local system does know it's on isbd.net because it's resolv.conf file has:- search isbd.net nameserver 192.168.1.4 -- Chris Green From richardvoigt at gmail.com Tue Aug 25 18:33:44 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Tue, 25 Aug 2009 12:33:44 -0500 Subject: [Dnsmasq-discuss] TFTP Boot update "for those who find this problem in the future" In-Reply-To: <4A93F024.3090102@thekelleys.org.uk> References: <20090824210109.535670rwlfs9iccg@mail.faure.ca> <2e59e6970908242114y60154b5bv2ac51275a3b7a466@mail.gmail.com> <4A93AF54.2060909@thekelleys.org.uk> <2e59e6970908250652r3dc7ab9n51d9cff76e3cf451@mail.gmail.com> <4A93F024.3090102@thekelleys.org.uk> Message-ID: <2e59e6970908251033n656612a0i17e86bf16fa12b53@mail.gmail.com> >> But maybe the best solution would just be to mention tftp-no-blocksize >> in the error message as a possible fix. > > Easier said than done: the sequence we saw with the NVIDIA PXE ROM was > > PXE asks for data > { > ?PXE gets data (fragmented) and ignores it > ?server times out and retries what if, if the very first block times out, dnsmasq automatically reduces the blocksize when retrying? > } repeat > PXE times out and send completely nonsense ACK packet to the wrong port > dnsmasq generates "unsupported request" because it doesn't understand the > packet. > > The extent of broken-ness in netboot firmware is astonishing. > > Cheers, > Simon. > > > > From simon at thekelleys.org.uk Tue Aug 25 18:46:59 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Tue, 25 Aug 2009 18:46:59 +0100 Subject: [Dnsmasq-discuss] TFTP Boot update "for those who find this problem in the future" In-Reply-To: <2e59e6970908251033n656612a0i17e86bf16fa12b53@mail.gmail.com> References: <20090824210109.535670rwlfs9iccg@mail.faure.ca> <2e59e6970908242114y60154b5bv2ac51275a3b7a466@mail.gmail.com> <4A93AF54.2060909@thekelleys.org.uk> <2e59e6970908250652r3dc7ab9n51d9cff76e3cf451@mail.gmail.com> <4A93F024.3090102@thekelleys.org.uk> <2e59e6970908251033n656612a0i17e86bf16fa12b53@mail.gmail.com> Message-ID: <4A942393.30302@thekelleys.org.uk> richardvoigt at gmail.com wrote: >> PXE asks for data >> { >> PXE gets data (fragmented) and ignores it >> server times out and retries > > what if, if the very first block times out, dnsmasq automatically > reduces the blocksize when retrying? > No, it can't do that because it has no way to re-negotiate the blocksize with the client and a packet whose size is less than the blocksize is the EOF marker in TFTP. Cheers, Simon. From dnsmasq at basjes.nl Tue Aug 25 22:29:47 2009 From: dnsmasq at basjes.nl (Niels Basjes) Date: Tue, 25 Aug 2009 22:29:47 +0100 Subject: [Dnsmasq-discuss] Ignoring unknown clients in Proxy DHCP mode? Message-ID: Hi, I would like to run a Proxy DHCP (PXE) server next to the corporate DHCP server. I would also like the Pxory DHCP to ONLY respond to "my" systems and ignore everyone else. So I tried this config: domain=lan.basjes.nl,172.21.13.0/24 dhcp-range=172.21.13.0,proxy dhcp-host=00:0c:29:99:4E:92,pxetest dhcp-ignore=#known pxe-service=x86PC, "Boot PXElinux", pxelinux The booting works fine .... for EVERY client. How do I correctly do the ignoring? -- Best regards, Niels Basjes From mattmatteh at gmail.com Wed Aug 26 03:09:57 2009 From: mattmatteh at gmail.com (mattmatteh at gmail.com) Date: Tue, 25 Aug 2009 21:09:57 -0500 (CDT) Subject: [Dnsmasq-discuss] default lease time when using /etc/ethers Message-ID: I have these 2 settings: dhcp-range=192.168.168.200,192.168.168.250,4h read-ethers Is it possible that i can set the lease time for the ip given from etc/ethers to something different from the dhcp-range ? I have a home network here and want the known computers to have a long or infinite lease and visitors or unknown clients to have a much shorter lease time. thanks matt From richardvoigt at gmail.com Wed Aug 26 06:12:23 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Wed, 26 Aug 2009 00:12:23 -0500 Subject: [Dnsmasq-discuss] default lease time when using /etc/ethers In-Reply-To: References: Message-ID: <2e59e6970908252212k4a23d375u19d4da9edd264bc2@mail.gmail.com> use two dhcp-range lines, one with known, one with #known (the # is negation) On Tue, Aug 25, 2009 at 9:09 PM, wrote: > I have these 2 settings: > > dhcp-range=192.168.168.200,192.168.168.250,4h > read-ethers > > Is it possible that i can set the lease time for the ip given from > etc/ethers to something different from the dhcp-range ? ?I have a home > network here and want the known computers to have a long or infinite lease > and visitors or unknown clients to have a much shorter lease time. > > thanks > > matt > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From dnsmasq at basjes.nl Wed Aug 26 07:53:09 2009 From: dnsmasq at basjes.nl (Niels Basjes) Date: Wed, 26 Aug 2009 08:53:09 +0200 Subject: [Dnsmasq-discuss] Ignoring unknown clients in Proxy DHCP mode? In-Reply-To: <2e59e6970908251518i6a83c933t1f320ba3f0d395f@mail.gmail.com> References: <2e59e6970908251518i6a83c933t1f320ba3f0d395f@mail.gmail.com> Message-ID: Hi Richard, >> I would like to run a Proxy DHCP (PXE) server next to the corporate DHCP server. >> I would also like the Pxory DHCP to ONLY respond to "my" systems and >> ignore everyone else. >> >> So I tried this config: >> >> domain=lan.basjes.nl,172.21.13.0/24 >> dhcp-range=172.21.13.0,proxy >> dhcp-host=00:0c:29:99:4E:92,pxetest >> dhcp-ignore=#known >> pxe-service=x86PC, "Boot PXElinux", pxelinux >> >> The booting works fine .... for EVERY client. >> >> How do I correctly do the ignoring? > pxe-service=net:known, x86PC, "Boot PXElinux", pxelinux I tried our suggestion. The effect of this is that the client DOES receive some boot information. Only the menu item is held back. I checked with wireshark and it seems that an 'empty' PXE menu is returned. The VMware Server bios fails with "PXE-E76: Bad or missing multicast discovery address". Your suggestion does mean I can create tags for groups of clients and customize the menu by hiding/showing options. Very usefull feature for the future. I've also tried this: domain=lan.basjes.nl,172.21.13.0/24 dhcp-range=net:known,172.21.13.0,proxy dhcp-host=00:0c:29:99:4E:92 dhcp-ignore=#known dhcp-boot=net:known,pxelinux.0 But that had the same effect as pxe-service=net:known, x86PC, "Boot PXElinux", pxelinux -- Met vriendelijke groeten, Niels Basjes From simon at thekelleys.org.uk Wed Aug 26 09:21:04 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Wed, 26 Aug 2009 09:21:04 +0100 Subject: [Dnsmasq-discuss] Ignoring unknown clients in Proxy DHCP mode? In-Reply-To: References: Message-ID: <4A94F070.8030709@thekelleys.org.uk> Niels Basjes wrote: > Hi, > > I would like to run a Proxy DHCP (PXE) server next to the corporate DHCP server. > I would also like the Pxory DHCP to ONLY respond to "my" systems and > ignore everyone else. > > So I tried this config: > > domain=lan.basjes.nl,172.21.13.0/24 > dhcp-range=172.21.13.0,proxy > dhcp-host=00:0c:29:99:4E:92,pxetest > dhcp-ignore=#known > pxe-service=x86PC, "Boot PXElinux", pxelinux > > The booting works fine .... for EVERY client. > > How do I correctly do the ignoring? > You can't, at the moment. Your configuration is absolutely fine, but there's an oversight in the (newish) proxy-PXE code which stops it from working. The fix is fairly trivial: I'll try and get patch to you in the next couple of days. Cheers, Simon. From ottuzzi at gmail.com Wed Aug 26 09:31:15 2009 From: ottuzzi at gmail.com (Piero) Date: Wed, 26 Aug 2009 10:31:15 +0200 Subject: [Dnsmasq-discuss] DNSMasq caching DNS query after restart? In-Reply-To: <4A94029D.6030808@gmx.de> References: <41a6fe740908250732n2f6e4df7jb39599c27a689654@mail.gmail.com> <4A94029D.6030808@gmx.de> Message-ID: <41a6fe740908260131x43dc6538s627fe7d56af73010@mail.gmail.com> 2009/8/25 Matthias Andree : > Piero schrieb: >> Hi there, >> >> ? ?I have a strange issue with DNSMasq: it looks like it saves dns >> cached query and keep them after a restart. >> Here is the problem: the host opaplnx13 didn't reverse lookup and I >> saw this in DNSMasq logs. I fixed the problem in "master DNS servers" >> and they actually reverse lookup opaplnx13 correctly but DNSMasq >> actually does not. It doesn't even after a restart. >> >> 10.145.3.71 and 10.145.3.72 are DNSMasq servers >> 10.145.1.121 is a master server >> >> [root at opaplnx23 etc]# nslookup >>> server 10.145.3.71 >> Default server: 10.145.3.71 >> Address: 10.145.3.71#53 >>> 10.145.3.41 >> Server: ? ? ? ? 10.145.3.71 >> Address: ? ? ? ?10.145.3.71#53 >> >> ** server can't find 41.3.145.10.in-addr.arpa: NXDOMAIN >>> server 10.145.3.72 >> Default server: 10.145.3.72 >> Address: 10.145.3.72#53 >>> 10.145.3.41 >> Server: ? ? ? ? 10.145.3.72 >> Address: ? ? ? ?10.145.3.72#53 >> >> ** server can't find 41.3.145.10.in-addr.arpa: NXDOMAIN >>> server 10.145.1.121 >> Default server: 10.145.1.121 >> Address: 10.145.1.121#53 >>> 10.145.3.41 >> Server: ? ? ? ? 10.145.1.121 >> Address: ? ? ? ?10.145.1.121#53 >> >> 41.3.145.10.in-addr.arpa ? ? ? ?name = opaplnx13.intra.azosp.vr.it. >> >> In DNSMasq log I can see: >> Aug 25 16:21:06 dnsmasq[6373]: query[PTR] 41.3.145.10.in-addr.arpa >> from 10.145.3.69 >> Aug 25 16:21:06 dnsmasq[6373]: config 10.145.3.41 is NXDOMAIN-IPv4 >> >> How is it possible? Is there a cache file somewhere? > > 1. don't use nslookup for any kind of testing, you often get very strange > results. Use dig instead, or host. dig for instance will also show the TTL, > which can be rather useful when dealing with "is this data cached" sort of > questions. > > 2. dnsmasq is a forwarder, and if the upstream server caches the result, then > dnsmasq will get a cached result. > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > Hi there, do you know the famous RTFM? I had bogus-priv option enabled and I'm in a private 10.x.x.x network! Many thanks for your replies! Ciaoo Piero -- Stupid is as stupid does. Forrest Gump From cl at isbd.net Wed Aug 26 22:20:34 2009 From: cl at isbd.net (Chris G) Date: Wed, 26 Aug 2009 22:20:34 +0100 Subject: [Dnsmasq-discuss] One client gets my domain name appended, another gets .local, why? In-Reply-To: <20090825164433.GB29922@chris> References: <20090825164433.GB29922@chris> Message-ID: <20090826212034.GB30318@chris> On Tue, Aug 25, 2009 at 05:44:33PM +0100, Chris G wrote: > I have dnsmasq running with a fairly basic configuration but (among > other things) it does have:- > > expand-hosts > domain=isbd.net > > Two clients do as I expected and their host names have isbd.net appended:- > > maxine.isbd.net ether 00:50:8d:93:fd:09 C eth0 > C475IP.isbd.net ether 00:01:e3:9d:8b:b5 C eth0 > > But one doesn't:- > > MyBookWorld.local ether 00:90:a9:70:06:ff C eth0 > > > Can anyone explain why that one gets .local appended rather than > .isbd.net and more to the point how can I fix it (apart from hard > coding it somewhere)? MyBookWorld.local is a Western Digital NAS > running some sort of Linux, I have command line root access to it but > would prefer not to modify it if there's a better way to make it get > the domain name. > > The MyBookWorld.local system does know it's on isbd.net because it's > resolv.conf file has:- > > search isbd.net > nameserver 192.168.1.4 > No ideas anyone? I'm still stuck, I have changed the system's name to 'garage' now and have even managed to add a domain line to resolv.conf so it now has:- domain isbd.net search isbd.net nameserver 192.168.1.4 .... but the system *still* gets called garage.local by dnsmasq. Is there any way I can tell dnsmasq to simply force the name to 'garage' regardless of what it tells dnsmasq? I've just tried 'uname -a' on the system and that reports its name as garage.isbd.net so why dnsmasq thinks it's garage.local I don't know. In addition for some reason all the other systems on the network can be addressed as .local as well as .isbd.net, it's just the garage system that only works as .local. Help! -- Chris Green From sakutz at gmail.com Thu Aug 27 15:03:19 2009 From: sakutz at gmail.com (Schley Andrew Kutz) Date: Thu, 27 Aug 2009 09:03:19 -0500 Subject: [Dnsmasq-discuss] dhcp not working Message-ID: <60C1F140-F8CD-40EE-A79E-FA7005F0936F@gmail.com> I am attempting to use dnsmasq to more fully supply functionality for my own project, akin (http://akutz.wordpress.com/2009/08/20/building-a-better-os-x-firewall-or-how-i-solved-the-nat-problem-for-virtualbox ). The DNS portion is working great, but DHCP requests are stuck in an endless loop of DISCOVER,OFFER. The options I use are: sudo ./dnsmasq -a 192.168.3.1 -b -f -F 192.168.3.15,192.168.3.254,255.255.255.0,192.168.3.255,1h -K -l /opt/ akin/dnsmasq.leases -d I thought it might be an IP tables issue, but I set my deny rule to log and no packets are getting dropped. Besides, I have a static allowance for all traffic on the virtual interface that dns masq is operating on. Thoughts? -- -a "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -- Einstein From simon at thekelleys.org.uk Thu Aug 27 16:53:37 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Thu, 27 Aug 2009 16:53:37 +0100 Subject: [Dnsmasq-discuss] dhcp not working In-Reply-To: <60C1F140-F8CD-40EE-A79E-FA7005F0936F@gmail.com> References: <60C1F140-F8CD-40EE-A79E-FA7005F0936F@gmail.com> Message-ID: <4A96AC01.2030700@thekelleys.org.uk> Schley Andrew Kutz wrote: > I am attempting to use dnsmasq to more fully supply functionality for > my own project, akin (http://akutz.wordpress.com/2009/08/20/building-a-better-os-x-firewall-or-how-i-solved-the-nat-problem-for-virtualbox > ). The DNS portion is working great, but DHCP requests are stuck in an > endless loop of DISCOVER,OFFER. > > The options I use are: > > sudo ./dnsmasq -a 192.168.3.1 -b -f -F > 192.168.3.15,192.168.3.254,255.255.255.0,192.168.3.255,1h -K -l /opt/ > akin/dnsmasq.leases -d > > I thought it might be an IP tables issue, but I set my deny rule to > log and no packets are getting dropped. Besides, I have a static > allowance for all traffic on the virtual interface that dns masq is > operating on. > > Thoughts? > Look at the logs on the clients to see if they are getting the OFFERs. If not look again at iptables. Simon. From sakutz at gmail.com Thu Aug 27 21:03:59 2009 From: sakutz at gmail.com (Schley Andrew Kutz) Date: Thu, 27 Aug 2009 15:03:59 -0500 Subject: [Dnsmasq-discuss] dhcp not working In-Reply-To: <4A96AC01.2030700@thekelleys.org.uk> References: <60C1F140-F8CD-40EE-A79E-FA7005F0936F@gmail.com> <4A96AC01.2030700@thekelleys.org.uk> Message-ID: Simon, Okay. It doesn't appear to be the IP tables, but I did some digging. If I run tcpdump on the host I get: [0]akutz at legacy:~$ sudo tcpdump -ni en1 'udp port 67 and udp port 68' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes 14:57:16.591186 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:18:8b:3e:29:3c, length 272 14:57:32.873143 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:23:df:58:53:3a, length 300 14:57:32.879882 IP 172.25.0.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 303 14:58:20.489057 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:18:8b:3e:29:3c, length 272 ^C 4 packets captured 1086 packets received by filter 0 packets dropped by kernel So it appears as if the VM's NIC, (coming from 0.0.0.0.68) is sending a DHCP request to the broadcast address of the host's subnet and getting a response from the DHCP server on the host's subnet, not the DHCP server included with dnsmasq. I can verify this by looking at the logs in the VM (OpenSUSE 11) in /var/log/messages. This line appears over and over again: linux dhclient; DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval x I would think that this is a fairly normal set up, so what am I doing incorrectly that the dnsmasq server isn't catching the DHCP request? For completeness, here is the output from dnsmasq: [130]akutz at legacy:src$ sudo ./dnsmasq -a 192.168.3.1 -b -f -F 192.168.3.15,192.168.3.254,255.255.255.0,192.168.3.255,1h -K -l /opt/ akin/dnsmasq.leases -d dnsmasq: started, version 2.49 cachesize 150 dnsmasq: compile time options: IPv6 no-GNU-getopt no-DBus no-I18N DHCP TFTP dnsmasq: setting --bind-interfaces option because of OS limitations dnsmasq-dhcp: DHCP, IP range 192.168.3.15 -- 192.168.3.254, lease time 1h dnsmasq: reading /etc/resolv.conf dnsmasq: using nameserver 172.16.100.250#53 dnsmasq: using nameserver 172.25.0.2#53 dnsmasq: read /etc/hosts - 5 addresses dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 Thanks! -- -a "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -- Einstein On Aug 27, 2009, at 10:53 AM, Simon Kelley wrote: > Schley Andrew Kutz wrote: >> I am attempting to use dnsmasq to more fully supply functionality >> for my own project, akin (http://akutz.wordpress.com/2009/08/20/building-a-better-os-x-firewall-or-how-i-solved-the-nat-problem-for-virtualbox >> ). The DNS portion is working great, but DHCP requests are stuck >> in an endless loop of DISCOVER,OFFER. >> The options I use are: >> sudo ./dnsmasq -a 192.168.3.1 -b -f -F >> 192.168.3.15,192.168.3.254,255.255.255.0,192.168.3.255,1h -K -l / >> opt/ akin/dnsmasq.leases -d >> I thought it might be an IP tables issue, but I set my deny rule >> to log and no packets are getting dropped. Besides, I have a >> static allowance for all traffic on the virtual interface that dns >> masq is operating on. >> Thoughts? > > > Look at the logs on the clients to see if they are getting the > OFFERs. If not look again at iptables. > > Simon. > > From sakutz at gmail.com Thu Aug 27 21:06:43 2009 From: sakutz at gmail.com (Schley Andrew Kutz) Date: Thu, 27 Aug 2009 15:06:43 -0500 Subject: [Dnsmasq-discuss] dhcp not working In-Reply-To: References: <60C1F140-F8CD-40EE-A79E-FA7005F0936F@gmail.com> <4A96AC01.2030700@thekelleys.org.uk> Message-ID: Okay, I just realized that the MAC addresses in the "Request from..." lines do not match ANY MAC address on my machine or any MAC address in the VM I'm running. That's definitely odd... -- -a "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -- Einstein On Aug 27, 2009, at 3:03 PM, Schley Andrew Kutz wrote: > Simon, > > Okay. It doesn't appear to be the IP tables, but I did some digging. > If I run tcpdump on the host I get: > > [0]akutz at legacy:~$ sudo tcpdump -ni en1 'udp port 67 and udp port 68' > tcpdump: verbose output suppressed, use -v or -vv for full protocol > decode > listening on en1, link-type EN10MB (Ethernet), capture size 65535 > bytes > 14:57:16.591186 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, > Request from 00:18:8b:3e:29:3c, length 272 > 14:57:32.873143 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, > Request from 00:23:df:58:53:3a, length 300 > 14:57:32.879882 IP 172.25.0.2.67 > 255.255.255.255.68: BOOTP/DHCP, > Reply, length 303 > 14:58:20.489057 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, > Request from 00:18:8b:3e:29:3c, length 272 > ^C > 4 packets captured > 1086 packets received by filter > 0 packets dropped by kernel > > So it appears as if the VM's NIC, (coming from 0.0.0.0.68) is > sending a DHCP request to the broadcast address of the host's subnet > and getting a response from the DHCP server on the host's subnet, > not the DHCP server included with dnsmasq. I can verify this by > looking at the logs in the VM (OpenSUSE 11) in /var/log/messages. > This line appears over and over again: > > linux dhclient; DHCPDISCOVER on eth0 to 255.255.255.255 port 67 > interval x > > I would think that this is a fairly normal set up, so what am I > doing incorrectly that the dnsmasq server isn't catching the DHCP > request? For completeness, here is the output from dnsmasq: > > [130]akutz at legacy:src$ sudo ./dnsmasq -a 192.168.3.1 -b -f -F > 192.168.3.15,192.168.3.254,255.255.255.0,192.168.3.255,1h -K -l /opt/ > akin/dnsmasq.leases -d > dnsmasq: started, version 2.49 cachesize 150 > dnsmasq: compile time options: IPv6 no-GNU-getopt no-DBus no-I18N > DHCP TFTP > dnsmasq: setting --bind-interfaces option because of OS limitations > dnsmasq-dhcp: DHCP, IP range 192.168.3.15 -- 192.168.3.254, lease > time 1h > dnsmasq: reading /etc/resolv.conf > dnsmasq: using nameserver 172.16.100.250#53 > dnsmasq: using nameserver 172.25.0.2#53 > dnsmasq: read /etc/hosts - 5 addresses > dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 > dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 > dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 > dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 > dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 > dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 > dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 > dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 > dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 > dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 > dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 > dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 > dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 > dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 > dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 > dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 > > Thanks! > > -- > -a > > "Only two things are infinite, the universe and human stupidity, and > I'm not sure about the former." -- Einstein > > On Aug 27, 2009, at 10:53 AM, Simon Kelley wrote: > >> Schley Andrew Kutz wrote: >>> I am attempting to use dnsmasq to more fully supply functionality >>> for my own project, akin (http://akutz.wordpress.com/2009/08/20/building-a-better-os-x-firewall-or-how-i-solved-the-nat-problem-for-virtualbox >>> ). The DNS portion is working great, but DHCP requests are stuck >>> in an endless loop of DISCOVER,OFFER. >>> The options I use are: >>> sudo ./dnsmasq -a 192.168.3.1 -b -f -F >>> 192.168.3.15,192.168.3.254,255.255.255.0,192.168.3.255,1h -K -l / >>> opt/ akin/dnsmasq.leases -d >>> I thought it might be an IP tables issue, but I set my deny rule >>> to log and no packets are getting dropped. Besides, I have a >>> static allowance for all traffic on the virtual interface that >>> dns masq is operating on. >>> Thoughts? >> >> >> Look at the logs on the clients to see if they are getting the >> OFFERs. If not look again at iptables. >> >> Simon. >> >> > From sakutz at gmail.com Thu Aug 27 21:07:49 2009 From: sakutz at gmail.com (Schley Andrew Kutz) Date: Thu, 27 Aug 2009 15:07:49 -0500 Subject: [Dnsmasq-discuss] dhcp not working In-Reply-To: References: <60C1F140-F8CD-40EE-A79E-FA7005F0936F@gmail.com> <4A96AC01.2030700@thekelleys.org.uk> Message-ID: <9032F3CB-269B-429F-9984-DAD7927A80B0@gmail.com> One more update, the MAC address in the logs from dnsmasq DOES match the MAC address of the VM, so it does appear as if the VM is communicating in some way with the dnsmasq server. -- -a "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -- Einstein On Aug 27, 2009, at 3:06 PM, Schley Andrew Kutz wrote: > Okay, I just realized that the MAC addresses in the "Request > from..." lines do not match ANY MAC address on my machine or any MAC > address in the VM I'm running. That's definitely odd... > > -- > -a > > "Only two things are infinite, the universe and human stupidity, and > I'm not sure about the former." -- Einstein > > On Aug 27, 2009, at 3:03 PM, Schley Andrew Kutz wrote: > >> Simon, >> >> Okay. It doesn't appear to be the IP tables, but I did some >> digging. If I run tcpdump on the host I get: >> >> [0]akutz at legacy:~$ sudo tcpdump -ni en1 'udp port 67 and udp port 68' >> tcpdump: verbose output suppressed, use -v or -vv for full protocol >> decode >> listening on en1, link-type EN10MB (Ethernet), capture size 65535 >> bytes >> 14:57:16.591186 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, >> Request from 00:18:8b:3e:29:3c, length 272 >> 14:57:32.873143 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, >> Request from 00:23:df:58:53:3a, length 300 >> 14:57:32.879882 IP 172.25.0.2.67 > 255.255.255.255.68: BOOTP/DHCP, >> Reply, length 303 >> 14:58:20.489057 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, >> Request from 00:18:8b:3e:29:3c, length 272 >> ^C >> 4 packets captured >> 1086 packets received by filter >> 0 packets dropped by kernel >> >> So it appears as if the VM's NIC, (coming from 0.0.0.0.68) is >> sending a DHCP request to the broadcast address of the host's >> subnet and getting a response from the DHCP server on the host's >> subnet, not the DHCP server included with dnsmasq. I can verify >> this by looking at the logs in the VM (OpenSUSE 11) in /var/log/ >> messages. This line appears over and over again: >> >> linux dhclient; DHCPDISCOVER on eth0 to 255.255.255.255 port 67 >> interval x >> >> I would think that this is a fairly normal set up, so what am I >> doing incorrectly that the dnsmasq server isn't catching the DHCP >> request? For completeness, here is the output from dnsmasq: >> >> [130]akutz at legacy:src$ sudo ./dnsmasq -a 192.168.3.1 -b -f -F >> 192.168.3.15,192.168.3.254,255.255.255.0,192.168.3.255,1h -K -l / >> opt/akin/dnsmasq.leases -d >> dnsmasq: started, version 2.49 cachesize 150 >> dnsmasq: compile time options: IPv6 no-GNU-getopt no-DBus no-I18N >> DHCP TFTP >> dnsmasq: setting --bind-interfaces option because of OS limitations >> dnsmasq-dhcp: DHCP, IP range 192.168.3.15 -- 192.168.3.254, lease >> time 1h >> dnsmasq: reading /etc/resolv.conf >> dnsmasq: using nameserver 172.16.100.250#53 >> dnsmasq: using nameserver 172.25.0.2#53 >> dnsmasq: read /etc/hosts - 5 addresses >> dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 >> dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 >> dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 >> dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 >> dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 >> dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 >> dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 >> dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 >> dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 >> dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 >> dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 >> dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 >> dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 >> dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 >> dnsmasq-dhcp: DHCPDISCOVER(vboxnet0) 08:00:27:3f:36:92 >> dnsmasq-dhcp: DHCPOFFER(vboxnet0) 192.168.3.165 08:00:27:3f:36:92 >> >> Thanks! >> >> -- >> -a >> >> "Only two things are infinite, the universe and human stupidity, >> and I'm not sure about the former." -- Einstein >> >> On Aug 27, 2009, at 10:53 AM, Simon Kelley wrote: >> >>> Schley Andrew Kutz wrote: >>>> I am attempting to use dnsmasq to more fully supply functionality >>>> for my own project, akin (http://akutz.wordpress.com/2009/08/20/building-a-better-os-x-firewall-or-how-i-solved-the-nat-problem-for-virtualbox >>>> ). The DNS portion is working great, but DHCP requests are stuck >>>> in an endless loop of DISCOVER,OFFER. >>>> The options I use are: >>>> sudo ./dnsmasq -a 192.168.3.1 -b -f -F >>>> 192.168.3.15,192.168.3.254,255.255.255.0,192.168.3.255,1h -K -l / >>>> opt/ akin/dnsmasq.leases -d >>>> I thought it might be an IP tables issue, but I set my deny rule >>>> to log and no packets are getting dropped. Besides, I have a >>>> static allowance for all traffic on the virtual interface that >>>> dns masq is operating on. >>>> Thoughts? >>> >>> >>> Look at the logs on the clients to see if they are getting the >>> OFFERs. If not look again at iptables. >>> >>> Simon. >>> >>> >> > From simon at thekelleys.org.uk Fri Aug 28 18:03:51 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Fri, 28 Aug 2009 18:03:51 +0100 Subject: [Dnsmasq-discuss] dhcp not working In-Reply-To: References: <60C1F140-F8CD-40EE-A79E-FA7005F0936F@gmail.com> <4A96AC01.2030700@thekelleys.org.uk> Message-ID: <4A980DF7.1020902@thekelleys.org.uk> Schley Andrew Kutz wrote: > Okay, I just realized that the MAC addresses in the "Request from..." > lines do not match ANY MAC address on my machine or any MAC address in > the VM I'm running. That's definitely odd... > Since some DHCP packets are broadcast, they can end up in strange places. Mac address ranges are allocated to manufacturers, which might give you some clue as to what's going on. http://www.coffer.com/mac_find/ will tell you which: it looks like you have one from Dell and one from Apple there. Simon. From lars.curator at gmail.com Sun Aug 30 17:07:57 2009 From: lars.curator at gmail.com (Lars Nooden) Date: Sun, 30 Aug 2009 19:07:57 +0300 Subject: [Dnsmasq-discuss] serving grub2 and pxegrub Message-ID: <4A9AA3DD.6010603@gmail.com> Is there any existing documentation on using dnsmasq with pxegrub? The idea is that dnsmasq could point to grub for the user to then choose from a list of netbook images. Regards, -Lars From simon at thekelleys.org.uk Mon Aug 31 17:46:23 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Mon, 31 Aug 2009 17:46:23 +0100 Subject: [Dnsmasq-discuss] dnsmasq SECURITY problem. Message-ID: <4A9BFE5F.3030107@thekelleys.org.uk> A couple of security problems have been found in dnsmasq. One by CORE security and one by Steve Grubb at Red Hat. Both problems affect the same bit of code and one vulnerability is a subset of the other, so I'm treating them as a unit for remediation purposes. Bug dicovered by the Steve Grubb at Red Hat: Bugtraq id: 36120 CVE: 2009-2958 This allows a crafted malformed TFTP packet to crash dnsmasq with a NULL pointer dereference. Bug discovered by Core: Bugtraq id: 36121 CVE: 2009-2957 This allows a crafted TFTP packet to overflow the heap by the length of the tftp-prefix. This may be exploitable to gain control of the daemon with non-root privileges, depending on the exact layout of memory. No exploits for either of these are known in the wild: both were found by code inspection. Only dnsmasq daemons which have TFTP enabled with --enable-tftp are vulnerable, and an attack must come from an address which is allowed to do TFTP (ie, NOT the wider internet, in general). I have made a new release, 2.50, which is available at http://www.thekelleys.org.uk/dnsmasq/dnsmasq-2.50.tar.gz and is simply version 2.49 plus the patch required to fix this. Patches which apply to dnsmasq 2.42 and later, and one for earlier versions are also available for download from the dnsmasq download directory. Major Linux and *BSD distros will be releasing security updates very soon. The rest will, I hope, follow in due course. Cheers, Simon. From simon at thekelleys.org.uk Mon Aug 31 18:01:14 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Mon, 31 Aug 2009 18:01:14 +0100 Subject: [Dnsmasq-discuss] Announce: dnsmasq-2.50 Message-ID: <4A9C01DA.6010904@thekelleys.org.uk> This is a security update to 2.49 only. The CHANGELOG: version 2.50 Fix security problem which allowed any host permitted to do TFTP to possibly compromise dnsmasq by remote buffer overflow when TFTP enabled. Thanks to Core Security Technologies and Iv?n Arce, Pablo Hern?n Jorge, Alejandro Pablo Rodriguez, Mart?n Coco, Alberto Soli?o Testa and Pablo Annetta. This problem has Bugtraq id: 36121 and CVE: 2009-2957 Fix a problem which allowed a malicious TFTP client to crash dnsmasq. Thanks to Steve Grubb at Red Hat for spotting this. This problem has Bugtraq id: 36120 and CVE: 2009-2958 Cheers, Simon. From gcoady.lk at gmail.com Tue Sep 1 01:41:43 2009 From: gcoady.lk at gmail.com (Grant) Date: Tue, 01 Sep 2009 10:41:43 +1000 Subject: [Dnsmasq-discuss] Announce: dnsmasq-2.50 In-Reply-To: <4A9C01DA.6010904@thekelleys.org.uk> References: <4A9C01DA.6010904@thekelleys.org.uk> Message-ID: <4dro95p8jcet0ekbq89guihu85i1dlan7v@4ax.com> On Mon, 31 Aug 2009 18:01:14 +0100, you wrote: >This is a security update to 2.49 only. > >The CHANGELOG: > >version 2.50 > Fix security problem which allowed any host permitted to > do TFTP to possibly compromise dnsmasq by remote buffer > overflow when TFTP enabled. Thanks to Core Security > Technologies and Iv?n Arce, Pablo Hern?n Jorge, Alejandro > Pablo Rodriguez, Mart?n Coco, Alberto Soli?o Testa and > Pablo Annetta. This problem has Bugtraq id: 36121 > and CVE: 2009-2957 > > Fix a problem which allowed a malicious TFTP client to > crash dnsmasq. Thanks to Steve Grubb at Red Hat for > spotting this. This problem has Bugtraq id: 36120 and > CVE: 2009-2958 Compiled, up and running fine here :) Grant. -- http://bugsplatter.id.au From simon at thekelleys.org.uk Tue Sep 1 20:04:26 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Tue, 01 Sep 2009 20:04:26 +0100 Subject: [Dnsmasq-discuss] serving grub2 and pxegrub In-Reply-To: <4A9AA3DD.6010603@gmail.com> References: <4A9AA3DD.6010603@gmail.com> Message-ID: <4A9D703A.8060806@thekelleys.org.uk> Lars Nooden wrote: > Is there any existing documentation on using dnsmasq with pxegrub? No, I don't think so. If you can point us at some pxegrub docs, it should be fairly easy to adapt them to dnsmasq. > > The idea is that dnsmasq could point to grub for the user to then choose > from a list of netbook images. > It's possible to do that just using dnsmasq and the PXE firmware in the netbook. You need an up-to-date version of dnsmasq and the pxe-prompt and pxe-service configuration options. Cheers, Simon. > Regards, > -Lars > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From simon at thekelleys.org.uk Tue Sep 1 20:14:12 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Tue, 01 Sep 2009 20:14:12 +0100 Subject: [Dnsmasq-discuss] Ignoring unknown clients in Proxy DHCP mode? In-Reply-To: References: <2e59e6970908251518i6a83c933t1f320ba3f0d395f@mail.gmail.com> Message-ID: <4A9D7284.9090009@thekelleys.org.uk> Niels Basjes wrote: > Hi Richard, > >>> I would like to run a Proxy DHCP (PXE) server next to the corporate DHCP server. >>> I would also like the Pxory DHCP to ONLY respond to "my" systems and >>> ignore everyone else. >>> >>> So I tried this config: >>> >>> domain=lan.basjes.nl,172.21.13.0/24 >>> dhcp-range=172.21.13.0,proxy >>> dhcp-host=00:0c:29:99:4E:92,pxetest >>> dhcp-ignore=#known >>> pxe-service=x86PC, "Boot PXElinux", pxelinux >>> >>> The booting works fine .... for EVERY client. >>> >>> How do I correctly do the ignoring? > >> pxe-service=net:known, x86PC, "Boot PXElinux", pxelinux > > I tried our suggestion. > The effect of this is that the client DOES receive some boot > information. Only the menu item is held back. > I checked with wireshark and it seems that an 'empty' PXE menu is returned. > The VMware Server bios fails with "PXE-E76: Bad or missing multicast > discovery address". > Your suggestion does mean I can create tags for groups of clients and > customize the menu by hiding/showing options. Very usefull feature > for the future. > > I've also tried this: > domain=lan.basjes.nl,172.21.13.0/24 > dhcp-range=net:known,172.21.13.0,proxy > dhcp-host=00:0c:29:99:4E:92 > dhcp-ignore=#known > dhcp-boot=net:known,pxelinux.0 > > But that had the same effect as > pxe-service=net:known, x86PC, "Boot PXElinux", pxelinux > Niels, Please could you download and try http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.51test3.tar.gz which should work OK with the first configuration you tried. Cheers, Simon. From dnsmasq at basjes.nl Wed Sep 2 09:32:49 2009 From: dnsmasq at basjes.nl (Niels Basjes) Date: Wed, 2 Sep 2009 10:32:49 +0200 Subject: [Dnsmasq-discuss] Ignoring unknown clients in Proxy DHCP mode? In-Reply-To: <4A9D7284.9090009@thekelleys.org.uk> References: <2e59e6970908251518i6a83c933t1f320ba3f0d395f@mail.gmail.com> <4A9D7284.9090009@thekelleys.org.uk> Message-ID: Hi Simon, 2009/9/1 Simon Kelley Please could you download and try > http://www.thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.51test3.tar.gz > which should work OK with the first configuration you tried. > I just tested your version and it looks very good. I'm using cobbler for installing systems. This is the actual config file I tested with: read-ethers addn-hosts = /var/lib/cobbler/cobbler_hosts dhcp-range=10.10.0.0,proxy dhcp-ignore=#known expand-hosts domain=test.basjes.nl,10.10.0.0 pxe-service=x86PC, "Boot PXELinux (=Cobbler controlled)", pxelinux ,10.10.15.2 I tested by booting a new VMware Server system via PXE --> As expected no PXE info. Then I added the system to cobbler which effectively places its MAC and IP in /etc/ethers and its IP and hostname in /var/lib/cobbler/cobbler_hosts ) Now I booted the same VM again and it immediately booted using the provided PXE information. So for my purposes this works perfectly. Thank you very much! -- Met vriendelijke groeten, Niels Basjes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090902/88a2bd13/attachment.html From cl at isbd.net Wed Sep 2 17:20:39 2009 From: cl at isbd.net (Chris G) Date: Wed, 2 Sep 2009 17:20:39 +0100 Subject: [Dnsmasq-discuss] Can dnsmasq 'alias' a host name? Message-ID: <20090902162039.GA28116@chris> Can dnsmasq provide an alternative name for a client? This is going on from my problem with a system that insists on calling itself garage.local when I want it to be called garage. Is there a way that I can tell dnsmasq that garage.local is also garage so that requests for the address of garage will get the address of garage.local? -- Chris Green From simon at thekelleys.org.uk Wed Sep 2 17:51:15 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Wed, 02 Sep 2009 17:51:15 +0100 Subject: [Dnsmasq-discuss] Can dnsmasq 'alias' a host name? In-Reply-To: <20090902162039.GA28116@chris> References: <20090902162039.GA28116@chris> Message-ID: <4A9EA283.7080505@thekelleys.org.uk> Chris G wrote: > Can dnsmasq provide an alternative name for a client? > > This is going on from my problem with a system that insists on calling > itself garage.local when I want it to be called garage. > > Is there a way that I can tell dnsmasq that garage.local is also > garage so that requests for the address of garage will get the address > of garage.local? > yes. cname=garage,garage.local should do it. Cheers, Simon. From perette at barella.org Wed Sep 2 18:55:00 2009 From: perette at barella.org (Perette Barella) Date: Wed, 2 Sep 2009 13:55:00 -0400 Subject: [Dnsmasq-discuss] Can dnsmasq 'alias' a host name? In-Reply-To: <4A9EA283.7080505@thekelleys.org.uk> References: <20090902162039.GA28116@chris> <4A9EA283.7080505@thekelleys.org.uk> Message-ID: <420DD7E2-8FDF-4890-8E29-8277B3D0DFE6@barella.org> A note on the on the .local pseudo-top-level-domain: It's used by multicast DNS, implemented on Macs primarily I think. mDNS is used by machines forming an ad-hoc network, and works in parallel with DNS. Although I can't remember my problem now, I recall a name-related race condition battle on my network when my local DNS domain also used .local . The .local entry at Wikipedia gives a similar warning: "Name resolution issues may arise if Bonjour, Avahi, or other Multicast DNS software is used in conjunction with a network that implements the local toplevel DNS domain." [Source: http://en.wikipedia.org/wiki/.local] Best, Perette Chris G wrote: > Can dnsmasq provide an alternative name for a client? > > This is going on from my problem with a system that insists on calling > itself garage.local when I want it to be called garage. > > Is there a way that I can tell dnsmasq that garage.local is also > garage so that requests for the address of garage will get the address > of garage.local? > From cl at isbd.net Wed Sep 2 19:54:26 2009 From: cl at isbd.net (Chris G) Date: Wed, 2 Sep 2009 19:54:26 +0100 Subject: [Dnsmasq-discuss] Can dnsmasq 'alias' a host name? In-Reply-To: <4A9EA283.7080505@thekelleys.org.uk> References: <20090902162039.GA28116@chris> <4A9EA283.7080505@thekelleys.org.uk> Message-ID: <20090902185426.GB28116@chris> On Wed, Sep 02, 2009 at 05:51:15PM +0100, Simon Kelley wrote: > Chris G wrote: > > Can dnsmasq provide an alternative name for a client? > > > > This is going on from my problem with a system that insists on calling > > itself garage.local when I want it to be called garage. > > > > Is there a way that I can tell dnsmasq that garage.local is also > > garage so that requests for the address of garage will get the address > > of garage.local? > > > > yes. > > > cname=garage,garage.local > > should do it. > > Excellent, exactly what I wanted. I hunted through the man page but couldn't find it. Thank you. -- Chris Green From cl at isbd.net Wed Sep 2 20:00:45 2009 From: cl at isbd.net (Chris G) Date: Wed, 2 Sep 2009 20:00:45 +0100 Subject: [Dnsmasq-discuss] Can dnsmasq 'alias' a host name? In-Reply-To: <420DD7E2-8FDF-4890-8E29-8277B3D0DFE6@barella.org> References: <20090902162039.GA28116@chris> <4A9EA283.7080505@thekelleys.org.uk> <420DD7E2-8FDF-4890-8E29-8277B3D0DFE6@barella.org> Message-ID: <20090902190045.GC28116@chris> On Wed, Sep 02, 2009 at 01:55:00PM -0400, Perette Barella wrote: > A note on the on the .local pseudo-top-level-domain: It's used by > multicast DNS, implemented on Macs primarily I think. mDNS is used by > machines forming an ad-hoc network, and works in parallel with DNS. > Although I can't remember my problem now, I recall a name-related race > condition battle on my network when my local DNS domain also > used .local . The .local entry at Wikipedia gives a similar warning: > Yes, I *really* wanted the garage.local system to report its name as garage but even though I have full (i.e. root) access to the system I can't make it change its name. Other systems on my LAN report as expected without the .local. The system that insists on .local is a Western Digital NAS which runs Linux. > "Name resolution issues may arise if Bonjour, Avahi, or other > Multicast DNS software is used in conjunction with a network that > implements the local toplevel DNS domain." > [Source: http://en.wikipedia.org/wiki/.local] > My *network* does nothing of the sort, it has a proper registered TLD. > Best, > > Perette > > Chris G wrote: > > Can dnsmasq provide an alternative name for a client? > > > > This is going on from my problem with a system that insists on calling > > itself garage.local when I want it to be called garage. > > > > Is there a way that I can tell dnsmasq that garage.local is also > > garage so that requests for the address of garage will get the address > > of garage.local? > > > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > -- Chris Green From cl at isbd.net Wed Sep 2 20:22:10 2009 From: cl at isbd.net (Chris G) Date: Wed, 2 Sep 2009 20:22:10 +0100 Subject: [Dnsmasq-discuss] Can dnsmasq 'alias' a host name? In-Reply-To: <4A9EA283.7080505@thekelleys.org.uk> References: <20090902162039.GA28116@chris> <4A9EA283.7080505@thekelleys.org.uk> Message-ID: <20090902192210.GD28116@chris> On Wed, Sep 02, 2009 at 05:51:15PM +0100, Simon Kelley wrote: > Chris G wrote: > > Can dnsmasq provide an alternative name for a client? > > > > This is going on from my problem with a system that insists on calling > > itself garage.local when I want it to be called garage. > > > > Is there a way that I can tell dnsmasq that garage.local is also > > garage so that requests for the address of garage will get the address > > of garage.local? > > > > yes. > > > cname=garage,garage.local > > should do it. > It doesn't seem to work though. I have added the following to the end of /etc/dnsmasq.conf :- cname=garage,garage.local I have killed and restarted dnsmasq (it's still providing DNS OK). However I can't ping or ssh to garage, but I can ping and ssh to garage.local. -- Chris Green From simon at thekelleys.org.uk Wed Sep 2 20:46:01 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Wed, 02 Sep 2009 20:46:01 +0100 Subject: [Dnsmasq-discuss] Can dnsmasq 'alias' a host name? In-Reply-To: <20090902192210.GD28116@chris> References: <20090902162039.GA28116@chris> <4A9EA283.7080505@thekelleys.org.uk> <20090902192210.GD28116@chris> Message-ID: <4A9ECB79.3030801@thekelleys.org.uk> Chris G wrote: > On Wed, Sep 02, 2009 at 05:51:15PM +0100, Simon Kelley wrote: >> Chris G wrote: >>> Can dnsmasq provide an alternative name for a client? >>> >>> This is going on from my problem with a system that insists on calling >>> itself garage.local when I want it to be called garage. >>> >>> Is there a way that I can tell dnsmasq that garage.local is also >>> garage so that requests for the address of garage will get the address >>> of garage.local? >>> >> yes. >> >> >> cname=garage,garage.local >> >> should do it. >> > It doesn't seem to work though. I have added the following to the end > of /etc/dnsmasq.conf :- > > cname=garage,garage.local > > I have killed and restarted dnsmasq (it's still providing DNS OK). > > However I can't ping or ssh to garage, but I can ping and ssh to > garage.local. > > The fact that this thing is putting .local on the end of its name suggests that is might be doing mDNS, and that the host you are testing it with is also configured to use mDNS as a name-resolution method. Since dnsmasq doesn't have anything to do with mDNS, it can't affect that. Some things to check: 1) /var/lib/misc/dnsmasq.leases. Does the garage.local name appear there, it will if the NAS is announcing that name in its DHCP requests. 2) /etc/nsswitch.conf does mdns appear in the hosts: line? 3) Try "dig garage.local" which just does a DNS query and doesn't try the other name-resolution methods. There are ways around this, but we need to know exactly what's going on first. Cheers, Simon. From cl at isbd.net Wed Sep 2 20:52:50 2009 From: cl at isbd.net (Chris G) Date: Wed, 2 Sep 2009 20:52:50 +0100 Subject: [Dnsmasq-discuss] Can dnsmasq 'alias' a host name? In-Reply-To: <4A9ECB79.3030801@thekelleys.org.uk> References: <20090902162039.GA28116@chris> <4A9EA283.7080505@thekelleys.org.uk> <20090902192210.GD28116@chris> <4A9ECB79.3030801@thekelleys.org.uk> Message-ID: <20090902195250.GF28116@chris> On Wed, Sep 02, 2009 at 08:46:01PM +0100, Simon Kelley wrote: > Chris G wrote: > > On Wed, Sep 02, 2009 at 05:51:15PM +0100, Simon Kelley wrote: > >> Chris G wrote: > >>> Can dnsmasq provide an alternative name for a client? > >>> > >>> This is going on from my problem with a system that insists on calling > >>> itself garage.local when I want it to be called garage. > >>> > >>> Is there a way that I can tell dnsmasq that garage.local is also > >>> garage so that requests for the address of garage will get the address > >>> of garage.local? > >>> > >> yes. > >> > >> > >> cname=garage,garage.local > >> > >> should do it. > >> > > It doesn't seem to work though. I have added the following to the end > > of /etc/dnsmasq.conf :- > > > > cname=garage,garage.local > > > > I have killed and restarted dnsmasq (it's still providing DNS OK). > > > > However I can't ping or ssh to garage, but I can ping and ssh to > > garage.local. > > > > > > The fact that this thing is putting .local on the end of its name > suggests that is might be doing mDNS, and that the host you are testing > it with is also configured to use mDNS as a name-resolution method. > Since dnsmasq doesn't have anything to do with mDNS, it can't affect that. > > Some things to check: > > 1) /var/lib/misc/dnsmasq.leases. Does the garage.local name appear > there, it will if the NAS is announcing that name in its DHCP requests. > /var/lib/misc/dnsmasq.leases contains:- 1251924290 00:0b:5d:7f:56:e0 192.168.1.90 MAXLAPTOP 01:00:0b:5d:7f:56:e0 1251923804 00:01:e3:9d:8b:b5 192.168.1.129 C475IP * 1251923525 08:00:27:24:d0:9c 192.168.1.144 xp 01:08:00:27:24:d0:9c 1251922953 00:90:a9:70:06:ff 192.168.1.88 * 01:00:90:a9:70:06:ff 1251923251 00:e0:4c:c0:a9:60 192.168.1.89 lounge * 1251923827 00:50:8d:93:fd:09 192.168.1.83 maxine * That 192.168.1.88 is the garage system. > 2) /etc/nsswitch.conf does mdns appear in the hosts: line? > Yes:- hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 > 3) Try "dig garage.local" which just does a DNS query and doesn't try > the other name-resolution methods. > ; <<>> DiG 9.5.1-P2 <<>> garage.local ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10135 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;garage.local. IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Sep 2 20:49:35 2009 ;; MSG SIZE rcvd: 30 > There are ways around this, but we need to know exactly what's going on > first. > Thanks for all the help so far. Yes, I think mDNS may be getting in the way. Turning it off is fine, especially if I can just persuade the garage system to be 'normal'! :-) The garage system has the following running:- 3817 root 1024 S /usr/bin/mDNSResponder -f /etc/mDNSResponder.conf 3818 root 1024 S /usr/bin/mDNSResponder -f /etc/mDNSResponder.conf 3819 root 1024 S /usr/bin/mDNSResponder -f /etc/mDNSResponder.conf -- Chris Green From simon at thekelleys.org.uk Wed Sep 2 20:59:54 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Wed, 02 Sep 2009 20:59:54 +0100 Subject: [Dnsmasq-discuss] Can dnsmasq 'alias' a host name? In-Reply-To: <20090902195250.GF28116@chris> References: <20090902162039.GA28116@chris> <4A9EA283.7080505@thekelleys.org.uk> <20090902192210.GD28116@chris> <4A9ECB79.3030801@thekelleys.org.uk> <20090902195250.GF28116@chris> Message-ID: <4A9ECEBA.8030306@thekelleys.org.uk> Chris G wrote: > On Wed, Sep 02, 2009 at 08:46:01PM +0100, Simon Kelley wrote: >> Chris G wrote: >>> On Wed, Sep 02, 2009 at 05:51:15PM +0100, Simon Kelley wrote: >>>> Chris G wrote: >>>>> Can dnsmasq provide an alternative name for a client? >>>>> >>>>> This is going on from my problem with a system that insists on calling >>>>> itself garage.local when I want it to be called garage. >>>>> >>>>> Is there a way that I can tell dnsmasq that garage.local is also >>>>> garage so that requests for the address of garage will get the address >>>>> of garage.local? >>>>> >>>> yes. >>>> >>>> >>>> cname=garage,garage.local >>>> >>>> should do it. >>>> >>> It doesn't seem to work though. I have added the following to the end >>> of /etc/dnsmasq.conf :- >>> >>> cname=garage,garage.local >>> >>> I have killed and restarted dnsmasq (it's still providing DNS OK). >>> >>> However I can't ping or ssh to garage, but I can ping and ssh to >>> garage.local. >>> >>> >> The fact that this thing is putting .local on the end of its name >> suggests that is might be doing mDNS, and that the host you are testing >> it with is also configured to use mDNS as a name-resolution method. >> Since dnsmasq doesn't have anything to do with mDNS, it can't affect that. >> >> Some things to check: >> >> 1) /var/lib/misc/dnsmasq.leases. Does the garage.local name appear >> there, it will if the NAS is announcing that name in its DHCP requests. >> > /var/lib/misc/dnsmasq.leases contains:- > > 1251924290 00:0b:5d:7f:56:e0 192.168.1.90 MAXLAPTOP 01:00:0b:5d:7f:56:e0 > 1251923804 00:01:e3:9d:8b:b5 192.168.1.129 C475IP * > 1251923525 08:00:27:24:d0:9c 192.168.1.144 xp 01:08:00:27:24:d0:9c > 1251922953 00:90:a9:70:06:ff 192.168.1.88 * 01:00:90:a9:70:06:ff > 1251923251 00:e0:4c:c0:a9:60 192.168.1.89 lounge * > 1251923827 00:50:8d:93:fd:09 192.168.1.83 maxine * > > That 192.168.1.88 is the garage system. > > >> 2) /etc/nsswitch.conf does mdns appear in the hosts: line? >> > Yes:- > > hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 > > >> 3) Try "dig garage.local" which just does a DNS query and doesn't try >> the other name-resolution methods. >> > ; <<>> DiG 9.5.1-P2 <<>> garage.local > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10135 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;garage.local. IN A > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Wed Sep 2 20:49:35 2009 > ;; MSG SIZE rcvd: 30 > >> There are ways around this, but we need to know exactly what's going on >> first. >> > Thanks for all the help so far. Yes, I think mDNS may be getting in > the way. Turning it off is fine, especially if I can just persuade > the garage system to be 'normal'! :-) > > The garage system has the following running:- > 3817 root 1024 S /usr/bin/mDNSResponder -f /etc/mDNSResponder.conf > 3818 root 1024 S /usr/bin/mDNSResponder -f /etc/mDNSResponder.conf > 3819 root 1024 S /usr/bin/mDNSResponder -f /etc/mDNSResponder.conf > Yes, that name is coming from mDNS, and not from the NAS announcing its name when it does DHCP. You need to stop using mDNS for name resolution (edit /etc/nsswitch.conf) and then, since the NAS doesn't tell dnsmasq its name, you need to tell dnsmasq that the host with MAC address 00:90:a9:70:06:ff is "garage". dhcp-host=00:90:a9:70:06:ff,garage you can remove the CNAME line too, it's not needed. Cheers, Simon. From cl at isbd.net Wed Sep 2 21:38:55 2009 From: cl at isbd.net (Chris G) Date: Wed, 2 Sep 2009 21:38:55 +0100 Subject: [Dnsmasq-discuss] Can dnsmasq 'alias' a host name? In-Reply-To: <4A9ECEBA.8030306@thekelleys.org.uk> References: <20090902162039.GA28116@chris> <4A9EA283.7080505@thekelleys.org.uk> <20090902192210.GD28116@chris> <4A9ECB79.3030801@thekelleys.org.uk> <20090902195250.GF28116@chris> <4A9ECEBA.8030306@thekelleys.org.uk> Message-ID: <20090902203855.GA5071@chris> On Wed, Sep 02, 2009 at 08:59:54PM +0100, Simon Kelley wrote: > Chris G wrote: > > > >> There are ways around this, but we need to know exactly what's going on > >> first. > >> > > Thanks for all the help so far. Yes, I think mDNS may be getting in > > the way. Turning it off is fine, especially if I can just persuade > > the garage system to be 'normal'! :-) > > > > The garage system has the following running:- > > 3817 root 1024 S /usr/bin/mDNSResponder -f /etc/mDNSResponder.conf > > 3818 root 1024 S /usr/bin/mDNSResponder -f /etc/mDNSResponder.conf > > 3819 root 1024 S /usr/bin/mDNSResponder -f /etc/mDNSResponder.conf > > > > Yes, that name is coming from mDNS, and not from the NAS announcing its > name when it does DHCP. > > You need to stop using mDNS for name resolution (edit > /etc/nsswitch.conf) and then, since the NAS doesn't tell dnsmasq its > name, you need to tell dnsmasq that the host with MAC address > 00:90:a9:70:06:ff is "garage". > It appears that just turning off mdns in the dnsmasq server system has done all I need! :-) I.e. I have changed:- hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4 to:- hosts: files dns in /etc/nsswitch.conf and now the garage system is 'garage'. > > dhcp-host=00:90:a9:70:06:ff,garage > > you can remove the CNAME line too, it's not needed. > Both currently commented out and, after a reboot, as I said garage is just garage. Brilliant, thank you! Will removing those mdns4_minimal and mdns4 entries from nsswitch.conf have done anything much, except making my system more unfriendly to Apple Macs and such? -- Chris Green From post at bushbaby.nl Thu Sep 3 22:10:35 2009 From: post at bushbaby.nl (B. Kamer) Date: Thu, 3 Sep 2009 23:10:35 +0200 Subject: [Dnsmasq-discuss] macport installation not starting Message-ID: Hi all, new to dnsmasq and run into a few questions that I can't seem to find an answer for.... I'm on OSX Snow Leopard and have installed the latest version via macports First problem, dnsmasq does not start automatically I have run the following command to install the startup script : sudo launchctl load -w /Library/LaunchDaemons/ org.macports.dnsmasq.plist however that script references a wrapper script that references the following non existing file. /opt/local/etc/startup/dnsmasq.sh I have search for examples of such a file, but can't seem to find anything... What need to be in this file? And why wouldn't that be included with the macports installation? I can start dnsmasq manually with sudo dnsmasq how would I stop/restart it manually? Second issue : with the default installation macport installation dnsmasq tries to load /opt/local/etc/resolv.conf which should be /etc/resolv.conf so i've uncommented in /opt/local/etc/dnsmasq.conf to override that resolv-file=/etc/resolv.conf anyway could this be automated for macports installations? thanks bas From perette at barella.org Fri Sep 4 08:52:23 2009 From: perette at barella.org (Perette Barella) Date: Fri, 4 Sep 2009 03:52:23 -0400 Subject: [Dnsmasq-discuss] macport installation not starting In-Reply-To: References: Message-ID: <56B21887-B89F-4960-BB4E-8AD197E0C91C@barella.org> I've just done a port install dnsmasq on my desktop (Leopard) and it doesn't try to invoke that script. Maybe the /Library/LaunchDaemons/ org.macports.dnsmasq.plist file got munged in the SnowLeopard transition and hasn't been fixed in MacPorts yet? Here's the Leopard contents... I'd suggest trying plugging this in and see what happens, worst case is just still doesn't work: Labelorg.macports.dnsmasq ProgramArguments /opt/local/bin/daemondo --label=dnsmasq --start-cmd /opt/local/etc/LaunchDaemons/org.macports.dnsmasq/ dnsmasq.wrapper start ; --stop-cmd /opt/local/etc/LaunchDaemons/org.macports.dnsmasq/ dnsmasq.wrapper stop ; --restart-cmd /opt/local/etc/LaunchDaemons/org.macports.dnsmasq/ dnsmasq.wrapper restart ; --pid=none Debug Disabled OnDemand RunAtLoad If that doesn't work, maybe put the file back to the SnowLeopard state and try to find the missing script... maybe it's just misplaced. Try a 'find / -name dnsmasq.sh -print'. You might also want to check the MacPorts bug tracker to see if this has been reported and if there's any workaround for it. If not, then it probably should get added along with anything you figure out. As far as the second issue... I know my dnsmasq points to its own resolv.conf, not the actual one. Automating this for you probably means it's going to break things for others. Perette On 2009?09?03?, at 17:10, B. Kamer wrote: > Hi all, new to dnsmasq and run into a few questions that I can't seem > to find an answer for.... > > I'm on OSX Snow Leopard and have installed the latest version via > macports > > > First problem, dnsmasq does not start automatically > > I have run the following command to install the startup script : > > sudo launchctl load -w /Library/LaunchDaemons/ > org.macports.dnsmasq.plist > > however that script references a wrapper script that references the > following non existing file. > > /opt/local/etc/startup/dnsmasq.sh > > I have search for examples of such a file, but can't seem to find > anything... What need to be in this file? And why wouldn't that be > included with the macports installation? > > I can start dnsmasq manually with > > sudo dnsmasq > > how would I stop/restart it manually? > > > > Second issue : > > with the default installation macport installation dnsmasq tries to > load /opt/local/etc/resolv.conf which should be /etc/resolv.conf > > so i've uncommented in /opt/local/etc/dnsmasq.conf to override that > > resolv-file=/etc/resolv.conf > > anyway could this be automated for macports installations? > > > thanks > > bas > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss From perette at barella.org Fri Sep 4 15:19:57 2009 From: perette at barella.org (Perette Barella) Date: Fri, 4 Sep 2009 10:19:57 -0400 Subject: [Dnsmasq-discuss] macport installation not starting In-Reply-To: References: <56B21887-B89F-4960-BB4E-8AD197E0C91C@barella.org> Message-ID: On 2009?09?04?, at 7:10, B. Kamer wrote: > Perhaps things are different on your system or it seems you didn't > quite got my explanation of the problem. Sorry about that, I missed a level of indirection. You are right, the dnsmasq.wrapper does try to call the missing script on Leopard too. The MacPort people probably know more about this... the whole plist invokes daemondo which runs dnsmasq.wrapper which runs dnsmasq.sh which finally invokes dnsmasq seems bizarrely complex. On my server, I don't use the MacPorts dnsmasq and rolled my own plist file: Label uk.org.thekelleys.dnsmasq ProgramArguments /opt/local/sbin/dnsmasq -k RunAtLoad AbandonProcessGroup KeepAlive NetworkState Give that a try. If you have bound to a particular interface, though, this won't work reliably because there's a race condition between dnsmasq starting and the interfaces being up. A workaround is to replace the in the above: /bin/bash -c sleep 10 && exec /usr/local/sbin/dnsmasq -k Perette From tyler.reese at taqua.com Fri Sep 4 18:23:25 2009 From: tyler.reese at taqua.com (Tyler Reese) Date: Fri, 4 Sep 2009 12:23:25 -0500 Subject: [Dnsmasq-discuss] Setting BOOTP "magic cookie" Message-ID: I'm trying to construct a dnsmasq BOOTP reply to match what I am getting using the bootp-dd2 server. In a wireshark BOOTP trace, it shows a "Magic cookie" attribute which are the first 4 bytes of the "Bootp vendor specific options". When using bootpd, I can use 'vm=rfc1084' in the desired entry in /etc/bootptab. This results in the 4 bytes being set to 0x63825363. After these 4 bytes, the rest of the options follow...and they are decoded in the wireshark packet view. Using dnsmasq, what is the equivalent way to set those first 4 bytes to 0x63825363? I am able to set the rest of the following options using dhcp-option, but I can't figure out how to set those first 4 bytes. Thanks, Tyler ________________________________ The information contained within this e-mail message, including the information contained in any attachments, is considered confidential information of Taqua, LLC, and intended only for the named recipient(s). If you have received this message in error, or are not the named recipient(s), please immediately delete this e-mail and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090904/c0956fa8/attachment.htm From robert.boerner at gmail.com Fri Sep 4 21:08:54 2009 From: robert.boerner at gmail.com (Robert Boerner) Date: Fri, 4 Sep 2009 12:08:54 -0800 Subject: [Dnsmasq-discuss] MAN Page Link Broken? and redundancy question Message-ID: Hello, First, it appears (at least to me) that as of right now the link to the online version of the MAN page simply leads to a blank page (http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html). Can anyone else confirm? Second, I tried looking through the mailing list and other pages but I have (what I hope) a simple question about configuring dnsmasq: I have the software running (very well I might add) on a Marvell Sheevaplug. I ideally would like to have two of these inexpensive devices running to provide redundancy. Is there a way to configure two concurrently running instances of dnsmasq (one each on a physically separate device) for the same DHCP scope so that if one instance fails the other takes over? I saw this can be done with the ISC DHCP daemon but I like dnsmasq better :-) Thanks in advance for any help and thanks for your work on this application. Bob Boerner From richardvoigt at gmail.com Fri Sep 4 21:23:32 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Fri, 4 Sep 2009 15:23:32 -0500 Subject: [Dnsmasq-discuss] MAN Page Link Broken? and redundancy question In-Reply-To: References: Message-ID: <2e59e6970909041323u2f7b80a3mfd77baf7ea296b65@mail.gmail.com> On Fri, Sep 4, 2009 at 3:08 PM, Robert Boerner wrote: > Hello, > > First, it appears (at least to me) that as of right now the link to > the online version of the MAN page simply leads to a blank page > (http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html). Can > anyone else confirm? I have the same result (no content on that page). > > Second, I tried looking through the mailing list and other pages but I > have (what I hope) a simple question about configuring dnsmasq: > > I have the software running (very well I might add) on a Marvell > Sheevaplug. I ideally would like to have two of these inexpensive > devices running to provide redundancy. Is there a way to configure two > concurrently running instances of dnsmasq (one each on a physically > separate device) for the same DHCP scope so that if one instance fails > the other takes over? I saw this can be done with the ISC DHCP daemon > but I like dnsmasq better :-) You could split the address pool into two and configure half on each. Then during normal operations there will be a race to offer an address, the client will accept only one. If one fails, the other will continue offering addresses. If one runs out of addresses, the other continues to work fine. The only problem would be if one fails and the other runs out of addresses. Are you using the dnsmasq machines as the gateway, or another router? That could become pretty important if you want redundancy (you actually have to transfer the address of the failed unit). > > Thanks in advance for any help and thanks for your work on this application. > > Bob Boerner > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From robert.boerner at gmail.com Fri Sep 4 22:18:04 2009 From: robert.boerner at gmail.com (Robert Boerner) Date: Fri, 4 Sep 2009 13:18:04 -0800 Subject: [Dnsmasq-discuss] MAN Page Link Broken? and redundancy question In-Reply-To: <2e59e6970909041323u2f7b80a3mfd77baf7ea296b65@mail.gmail.com> References: <2e59e6970909041323u2f7b80a3mfd77baf7ea296b65@mail.gmail.com> Message-ID: Hi Richard, Thanks for the quick response. I am in fact using a separate router as the gateway. I like the idea of splitting the pool, but that brings up a follow-on question...what about static reservations I have set? Can I simply have them on both? That also brings up yet another question...is it 'wrong' to have static reservations assigned to addresses that are within the normal scope? I know best practice is to have them designated outside, but I am trying to replace a Windows box in an environment where people have been assigning static reservations within the regular DHCP scope for years. I don't want to have to redo everything. Thanks again for the help. On Fri, Sep 4, 2009 at 12:23 PM, richardvoigt at gmail.com wrote: > On Fri, Sep 4, 2009 at 3:08 PM, Robert Boerner wrote: >> Hello, >> >> First, it appears (at least to me) that as of right now the link to >> the online version of the MAN page simply leads to a blank page >> (http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html). Can >> anyone else confirm? > > I have the same result (no content on that page). > >> >> Second, I tried looking through the mailing list and other pages but I >> have (what I hope) a simple question about configuring dnsmasq: >> >> I have the software running (very well I might add) on a Marvell >> Sheevaplug. I ideally would like to have two of these inexpensive >> devices running to provide redundancy. Is there a way to configure two >> concurrently running instances of dnsmasq (one each on a physically >> separate device) for the same DHCP scope so that if one instance fails >> the other takes over? I saw this can be done with the ISC DHCP daemon >> but I like dnsmasq better :-) > > You could split the address pool into two and configure half on each. > Then during normal operations there will be a race to offer an > address, the client will accept only one. ?If one fails, the other > will continue offering addresses. ?If one runs out of addresses, the > other continues to work fine. ?The only problem would be if one fails > and the other runs out of addresses. > > Are you using the dnsmasq machines as the gateway, or another router? > That could become pretty important if you want redundancy (you > actually have to transfer the address of the failed unit). > >> >> Thanks in advance for any help and thanks for your work on this application. >> >> Bob Boerner >> >> _______________________________________________ >> Dnsmasq-discuss mailing list >> Dnsmasq-discuss at lists.thekelleys.org.uk >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >> > From richardvoigt at gmail.com Sat Sep 5 00:40:18 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Fri, 4 Sep 2009 18:40:18 -0500 Subject: [Dnsmasq-discuss] MAN Page Link Broken? and redundancy question In-Reply-To: References: <2e59e6970909041323u2f7b80a3mfd77baf7ea296b65@mail.gmail.com> Message-ID: <2e59e6970909041640p2d17c8ect86edb973764bc5d8@mail.gmail.com> On Fri, Sep 4, 2009 at 4:18 PM, Robert Boerner wrote: > Hi Richard, > > Thanks for the quick response. > > I am in fact using a separate router as the gateway. I like the idea > of splitting the pool, but that brings up a follow-on question...what > about static reservations I have set? Can I simply have them on both? AFAIK, yes. > > That also brings up yet another question...is it 'wrong' to have > static reservations assigned to addresses that are within the normal > scope? I know best practice is to have them designated outside, but I > am trying to replace a Windows box in an environment where people have > been assigning static reservations within the regular DHCP scope for > years. I don't want to have to redo everything. Some people may frown upon it, but my experience is that dnsmasq will reserve any address corresponding to a static assignment and not give it away to any other client. So you should be fine. Something simple (and nearly stateless) Simon could do to make this use-case work a little better -- a configuration parameter load-balancer k of N, where dnsmasq responds immediately if hash(client address) % N == k and delays by a second otherwise. That way instead of the fastest hardware always responding first and running out of addresses, the clients would be more evenly spread among the subpools and you'd have more runtime following a failure before all clients get moved into (and exhaust) the surviving pool(s). > > Thanks again for the help. > > On Fri, Sep 4, 2009 at 12:23 PM, > richardvoigt at gmail.com wrote: >> On Fri, Sep 4, 2009 at 3:08 PM, Robert Boerner wrote: >>> Hello, >>> >>> First, it appears (at least to me) that as of right now the link to >>> the online version of the MAN page simply leads to a blank page >>> (http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html). Can >>> anyone else confirm? >> >> I have the same result (no content on that page). >> >>> >>> Second, I tried looking through the mailing list and other pages but I >>> have (what I hope) a simple question about configuring dnsmasq: >>> >>> I have the software running (very well I might add) on a Marvell >>> Sheevaplug. I ideally would like to have two of these inexpensive >>> devices running to provide redundancy. Is there a way to configure two >>> concurrently running instances of dnsmasq (one each on a physically >>> separate device) for the same DHCP scope so that if one instance fails >>> the other takes over? I saw this can be done with the ISC DHCP daemon >>> but I like dnsmasq better :-) >> >> You could split the address pool into two and configure half on each. >> Then during normal operations there will be a race to offer an >> address, the client will accept only one. ?If one fails, the other >> will continue offering addresses. ?If one runs out of addresses, the >> other continues to work fine. ?The only problem would be if one fails >> and the other runs out of addresses. >> >> Are you using the dnsmasq machines as the gateway, or another router? >> That could become pretty important if you want redundancy (you >> actually have to transfer the address of the failed unit). >> >>> >>> Thanks in advance for any help and thanks for your work on this application. >>> >>> Bob Boerner >>> >>> _______________________________________________ >>> Dnsmasq-discuss mailing list >>> Dnsmasq-discuss at lists.thekelleys.org.uk >>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >>> >> > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From carlos at fisica.ufpr.br Sat Sep 5 01:04:14 2009 From: carlos at fisica.ufpr.br (Carlos Carvalho) Date: Fri, 4 Sep 2009 21:04:14 -0300 Subject: [Dnsmasq-discuss] MAN Page Link Broken? and redundancy question In-Reply-To: <2e59e6970909041323u2f7b80a3mfd77baf7ea296b65@mail.gmail.com> References: <2e59e6970909041323u2f7b80a3mfd77baf7ea296b65@mail.gmail.com> Message-ID: <19105.43774.190683.16818@fisica.ufpr.br> richardvoigt at gmail.com (richardvoigt at gmail.com) wrote on 4 September 2009 15:23: >You could split the address pool into two and configure half on each. >Then during normal operations there will be a race to offer an >address, the client will accept only one. If one fails, the other >will continue offering addresses. If one runs out of addresses, the >other continues to work fine. The only problem would be if one fails >and the other runs out of addresses. Perhaps you can configure the full pool in both, provided you don't use no-ping. This way each server will send a ping and if it gets an answer it won't offer that address, even if it's not in its list of leases because the client chose the other server. From richardvoigt at gmail.com Sat Sep 5 02:21:31 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Fri, 4 Sep 2009 20:21:31 -0500 Subject: [Dnsmasq-discuss] MAN Page Link Broken? and redundancy question In-Reply-To: <19105.43774.190683.16818@fisica.ufpr.br> References: <2e59e6970909041323u2f7b80a3mfd77baf7ea296b65@mail.gmail.com> <19105.43774.190683.16818@fisica.ufpr.br> Message-ID: <2e59e6970909041821n4afd22d9v4edc29f88e59d98@mail.gmail.com> On Fri, Sep 4, 2009 at 7:04 PM, Carlos Carvalho wrote: > richardvoigt at gmail.com (richardvoigt at gmail.com) wrote on 4 September 2009 15:23: > ?>You could split the address pool into two and configure half on each. > ?>Then during normal operations there will be a race to offer an > ?>address, the client will accept only one. ?If one fails, the other > ?>will continue offering addresses. ?If one runs out of addresses, the > ?>other continues to work fine. ?The only problem would be if one fails > ?>and the other runs out of addresses. > > Perhaps you can configure the full pool in both, provided you don't > use no-ping. This way each server will send a ping and if it gets an > answer it won't offer that address, even if it's not in its list of > leases because the client chose the other server. I wouldn't rely on the ping feature, you're almost certain to end up with address conflicts any time one client becomes temporarily unreachable for any reason (such as rebooting, etc, etc). > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From carlos at fisica.ufpr.br Sat Sep 5 03:12:35 2009 From: carlos at fisica.ufpr.br (Carlos Carvalho) Date: Fri, 4 Sep 2009 23:12:35 -0300 Subject: [Dnsmasq-discuss] MAN Page Link Broken? and redundancy question In-Reply-To: <2e59e6970909041821n4afd22d9v4edc29f88e59d98@mail.gmail.com> References: <2e59e6970909041323u2f7b80a3mfd77baf7ea296b65@mail.gmail.com> <19105.43774.190683.16818@fisica.ufpr.br> <2e59e6970909041821n4afd22d9v4edc29f88e59d98@mail.gmail.com> Message-ID: <19105.51475.548472.64879@fisica.ufpr.br> richardvoigt at gmail.com (richardvoigt at gmail.com) wrote on 4 September 2009 20:21: >On Fri, Sep 4, 2009 at 7:04 PM, Carlos Carvalho wrote: >> richardvoigt at gmail.com (richardvoigt at gmail.com) wrote on 4 September 2009 15:23: >> ?>You could split the address pool into two and configure half on each. >> ?>Then during normal operations there will be a race to offer an >> ?>address, the client will accept only one. ?If one fails, the other >> ?>will continue offering addresses. ?If one runs out of addresses, the >> ?>other continues to work fine. ?The only problem would be if one fails >> ?>and the other runs out of addresses. >> >> Perhaps you can configure the full pool in both, provided you don't >> use no-ping. This way each server will send a ping and if it gets an >> answer it won't offer that address, even if it's not in its list of >> leases because the client chose the other server. > >I wouldn't rely on the ping feature, you're almost certain to end up >with address conflicts any time one client becomes temporarily >unreachable for any reason (such as rebooting, etc, etc). Yes, that's why I said perhaps. Note however that this also happens with a single server if it has to give an address not in the current (known) leases to a different machine than it was allocated to before. Servers usually do the ping test before the change but if the previous machine is still using the address and doesn't answer the ping a conflict will happen. The admin has to decide which is better for his particular case. I suspect your suggestion of splitting will be better in the majority of situations. From simon at thekelleys.org.uk Sun Sep 6 21:31:54 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Sun, 06 Sep 2009 21:31:54 +0100 Subject: [Dnsmasq-discuss] Setting BOOTP "magic cookie" In-Reply-To: References: Message-ID: <4AA41C3A.6090904@thekelleys.org.uk> Tyler Reese wrote: > I'm trying to construct a dnsmasq BOOTP reply to match what I am > getting using the bootp-dd2 server. > > In a wireshark BOOTP trace, it shows a "Magic cookie" attribute which > are the first 4 bytes of the "Bootp vendor specific options". When > using bootpd, I can use 'vm=rfc1084' in the desired entry in > /etc/bootptab. This results in the 4 bytes being set to 0x63825363. > After these 4 bytes, the rest of the options follow...and they are > decoded in the wireshark packet view. > > Using dnsmasq, what is the equivalent way to set those first 4 bytes > to 0x63825363? I am able to set the rest of the following options > using dhcp-option, but I can't figure out how to set those first 4 > bytes. > This isn't configurable in dnsmasq, from a quick reading of the bootptab man page, I thing the behaviour is equivalent to vm=auto, ie just echo back whatever the client sent. For DHCP, client requests which don't have the correct magic number are dropped, but for BOOTP that check isn't enforced. What client are you using? Cheers, Simon. From tyler.reese at taqua.com Sun Sep 6 22:32:33 2009 From: tyler.reese at taqua.com (Tyler Reese) Date: Sun, 6 Sep 2009 16:32:33 -0500 Subject: [Dnsmasq-discuss] Setting BOOTP "magic cookie" In-Reply-To: <4AA41C3A.6090904@thekelleys.org.uk> References: , <4AA41C3A.6090904@thekelleys.org.uk> Message-ID: It's a proprietary client that doesn't populate the vendor magic cookie. A request was made to change the client to just ignore the magic cookie and start parsing vendor options at the 5th byte. The change could have just as well been to make the client send the magic cookie and then dnsmasq would send it back. In the end, the same thing is accomplished. Thanks for the reply, Tyler ________________________________________ From: Simon Kelley [simon at thekelleys.org.uk] Sent: Sunday, September 06, 2009 3:31 PM To: Tyler Reese Cc: dnsmasq-discuss at lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Setting BOOTP "magic cookie" Tyler Reese wrote: > I'm trying to construct a dnsmasq BOOTP reply to match what I am > getting using the bootp-dd2 server. > > In a wireshark BOOTP trace, it shows a "Magic cookie" attribute which > are the first 4 bytes of the "Bootp vendor specific options". When > using bootpd, I can use 'vm=rfc1084' in the desired entry in > /etc/bootptab. This results in the 4 bytes being set to 0x63825363. > After these 4 bytes, the rest of the options follow...and they are > decoded in the wireshark packet view. > > Using dnsmasq, what is the equivalent way to set those first 4 bytes > to 0x63825363? I am able to set the rest of the following options > using dhcp-option, but I can't figure out how to set those first 4 > bytes. > This isn't configurable in dnsmasq, from a quick reading of the bootptab man page, I thing the behaviour is equivalent to vm=auto, ie just echo back whatever the client sent. For DHCP, client requests which don't have the correct magic number are dropped, but for BOOTP that check isn't enforced. What client are you using? Cheers, Simon. The information contained within this e-mail message, including the information contained in any attachments, is considered confidential information of Taqua, LLC, and intended only for the named recipient(s). If you have received this message in error, or are not the named recipient(s), please immediately delete this e-mail and any attachments. From post at bushbaby.nl Mon Sep 7 11:48:32 2009 From: post at bushbaby.nl (B. Kamer) Date: Mon, 7 Sep 2009 12:48:32 +0200 Subject: [Dnsmasq-discuss] macport installation not starting In-Reply-To: References: <56B21887-B89F-4960-BB4E-8AD197E0C91C@barella.org> Message-ID: Thanks, that works beautiful! I have no use for your second section about particular interfaces, so can't test that... Bas On 4 sep 2009, at 16:19, Perette Barella wrote: > > On 2009?09?04?, at 7:10, B. Kamer wrote: >> > You are right, the > dnsmasq.wrapper does try to call the missing script on Leopard too. > The MacPort people probably know more about this... the whole plist > invokes daemondo which runs dnsmasq.wrapper which runs dnsmasq.sh > which finally invokes dnsmasq seems bizarrely complex. On my server, > I don't use the MacPorts dnsmasq and rolled my own plist file: > > > "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> > > > Label > uk.org.thekelleys.dnsmasq > ProgramArguments > > /opt/local/sbin/dnsmasq > -k > > RunAtLoad > AbandonProcessGroup > KeepAlive > > NetworkState > > > > > Give that a try. If you have bound to a particular interface, though, > this won't work reliably because there's a race condition between > dnsmasq starting and the interfaces being up. A workaround is to > replace the in the above: > > > /bin/bash > -c > sleep 10 && exec /usr/local/sbin/dnsmasq -k > > > Perette > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss From cjsthompson at gmail.com Tue Sep 8 13:09:42 2009 From: cjsthompson at gmail.com (Christoph .J Thompson) Date: Tue, 8 Sep 2009 14:09:42 +0200 Subject: [Dnsmasq-discuss] cname apparently not working In-Reply-To: <20090902162039.GA28116@chris> References: <20090902162039.GA28116@chris> Message-ID: <20090908140942.26137398.cjsthompson@gmail.com> Hi, I can't seem to get cname to work for me. Maybe I'm doing something I'm not suposed to, but it's not obvious to me. I'm running Linux 2.6. Any help to fix this issue would be greatly appreciated. Regards, --- dnsmasq.conf domain-needed bogus-priv local=/eth/ except-interface=eth0 expand-hosts domain=mylan.eth #eth1 dhcp-range=192.168.7.5,192.168.7.254,12h #eth2 dhcp-range=192.168.8.5,192.168.8.254,12h #wlan0 dhcp-range=192.168.9.5,192.168.9.254,12h dhcp-option=option:ntp-server,192.168.7.4 dhcp-host=00:1e:8c:44:b7:a2,machineone cname=www,machine cname=wiki,machine cname=forum,machine dhcp-host=00:1b:5e:ee:ca:b5,00:22:33:a2:b5:d6,machinetwo dhcp-host=00:99:aa:a2:4d:6e,machinethree --- hosts 127.0.0.1 localhost 192.168.7.1 gw2 192.168.7.3 router 192.168.7.4 ntp 192.168.8.1 gw3 192.168.9.1 gw4 192.168.6.1 dsl --- command line $ host machineone machineone.mylan.eth A 192.168.7.222 !!! machineone.mylan.eth A record has zero TTL $ host machinethree machinethree.mylan.eth A 192.168.8.132 !!! machinethree.mylan.eth A record has zero TTL $ host www !!! www.mylan.eth does not exist, try an authoritative server $ host wiki !!! wiki.mylan.eth does not exist, try an authoritative server -- PGP: 0xC189F229 From simon at thekelleys.org.uk Tue Sep 8 15:27:25 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Tue, 08 Sep 2009 15:27:25 +0100 Subject: [Dnsmasq-discuss] cname apparently not working In-Reply-To: <20090908140942.26137398.cjsthompson@gmail.com> References: <20090902162039.GA28116@chris> <20090908140942.26137398.cjsthompson@gmail.com> Message-ID: <4AA669CD.1070608@thekelleys.org.uk> Christoph .J Thompson wrote: > Hi, > > I can't seem to get cname to work for me. Maybe I'm doing something I'm not > suposed to, but it's not obvious to me. I'm running Linux 2.6. Any help to > fix this issue would be greatly appreciated. > > Regards, > > --- dnsmasq.conf > > domain-needed > bogus-priv > > local=/eth/ > > except-interface=eth0 > > expand-hosts > > domain=mylan.eth > > #eth1 > dhcp-range=192.168.7.5,192.168.7.254,12h > #eth2 > dhcp-range=192.168.8.5,192.168.8.254,12h > #wlan0 > dhcp-range=192.168.9.5,192.168.9.254,12h > > dhcp-option=option:ntp-server,192.168.7.4 > > dhcp-host=00:1e:8c:44:b7:a2,machineone > cname=www,machine > cname=wiki,machine > cname=forum,machine > > dhcp-host=00:1b:5e:ee:ca:b5,00:22:33:a2:b5:d6,machinetwo > > dhcp-host=00:99:aa:a2:4d:6e,machinethree > > --- hosts > > 127.0.0.1 localhost > 192.168.7.1 gw2 > 192.168.7.3 router > 192.168.7.4 ntp > 192.168.8.1 gw3 > 192.168.9.1 gw4 > 192.168.6.1 dsl > > --- command line > > $ host machineone > machineone.mylan.eth A 192.168.7.222 > !!! machineone.mylan.eth A record has zero TTL > > $ host machinethree > machinethree.mylan.eth A 192.168.8.132 > !!! machinethree.mylan.eth A record has zero TTL > > $ host www > !!! www.mylan.eth does not exist, try an authoritative server > > $ host wiki > !!! wiki.mylan.eth does not exist, try an authoritative server > > expand-hosts doesn't apply to CNAMEs, you need to provide the FQDN in the cname cname=forum.mylan.eth,machine etc,etc HTH Simon. From v_cadet at yahoo.fr Sun Sep 13 11:15:50 2009 From: v_cadet at yahoo.fr (Vincent Cadet) Date: Sun, 13 Sep 2009 10:15:50 +0000 (GMT) Subject: [Dnsmasq-discuss] dnsmasq seems to ignore or not wait for DNS servers behind a VPN Message-ID: <201005.28726.qm@web28205.mail.ukl.yahoo.com> Hi people. I've installed *dnsmasq-2.49* under Gentoo. It runs concurrently with OpenResolv, which I need to add DNS server IP's to the resolver when I use my VPN connections. Actually OpenResolv acts upon */etc/dnsmasq-resolv.conf* and */etc/dnsmasq-resolvconf.conf*. The former holds the list of DNS servers, just like */etc/resolv.conf*. When I connect to a remote VPN server through "pon", everything goes fine: the connection is established, routes are set and the IP addresses of the remote network DNS servers are added to /etc/resolv.conf and /etc/dnsmasq-resolv.conf so that the remote DNS server IP's appear *first*, i.e. before the IP of my local DNS server. However name resolution doesn't work against machines on the remote network as long as the IP address of my local network DNS server is present in /etc/dnsmasq-resolv.conf. As long as the IP address of my local DNS server is present in /etc/dnsmasq-resolv.conf none of the remote machines can be contacted with their name. Name resolution always falls back against my local DNS server. I must do the following to solve the issue: a) comment out my local DNS server IP, which is last in /etc/dnsmasq-resolv.conf b) reload dnsmasq configuration (/etc/init.d/dnsmasq reload) c) ping a remote machine with its name d) uncomment my local DNS server (/etc/dnsmasq-resolv.conf) e) reload dnsmasq configuration Only then will I be able to ping _any other remote machine_ with its name. Running "/etc/init.d/dnsmasq reload" right after the VPN connection is made doesn't solve anything. Is this a problem with the metric? Is there something more I should check? Thanks for any hint/suggestion. Vince C. From tim at theallinghams.com Sun Sep 13 12:33:42 2009 From: tim at theallinghams.com (Tim Allingham) Date: Sun, 13 Sep 2009 21:33:42 +1000 Subject: [Dnsmasq-discuss] dnsmasq seems to ignore or not wait for DNS servers behind a VPN In-Reply-To: <201005.28726.qm@web28205.mail.ukl.yahoo.com> References: <201005.28726.qm@web28205.mail.ukl.yahoo.com> Message-ID: <1252841622.8303.2.camel@mini-tim> I know I've had a similar issue with openVPN paired with a local dnsmasq server, but the issue didn't seem to be with dnsmasq in the end, I found that if I tried to use the shortform (ie some-laptop) it would fail, but with the full domain (some-laptop.mydomain.com) it would succeed with the lookup, not sure if this helps but it solved the problem for me both in a dnsmasq and a dhcpd network. Cheers Tim -----Original Message----- From: Vincent Cadet To: dnsmasq-discuss at lists.thekelleys.org.uk Subject: [Dnsmasq-discuss] dnsmasq seems to ignore or not wait for DNS servers behind a VPN Date: Sun, 13 Sep 2009 10:15:50 +0000 (GMT) Hi people. I've installed *dnsmasq-2.49* under Gentoo. It runs concurrently with OpenResolv, which I need to add DNS server IP's to the resolver when I use my VPN connections. Actually OpenResolv acts upon */etc/dnsmasq-resolv.conf* and */etc/dnsmasq-resolvconf.conf*. The former holds the list of DNS servers, just like */etc/resolv.conf*. When I connect to a remote VPN server through "pon", everything goes fine: the connection is established, routes are set and the IP addresses of the remote network DNS servers are added to /etc/resolv.conf and /etc/dnsmasq-resolv.conf so that the remote DNS server IP's appear *first*, i.e. before the IP of my local DNS server. However name resolution doesn't work against machines on the remote network as long as the IP address of my local network DNS server is present in /etc/dnsmasq-resolv.conf. As long as the IP address of my local DNS server is present in /etc/dnsmasq-resolv.conf none of the remote machines can be contacted with their name. Name resolution always falls back against my local DNS server. I must do the following to solve the issue: a) comment out my local DNS server IP, which is last in /etc/dnsmasq-resolv.conf b) reload dnsmasq configuration (/etc/init.d/dnsmasq reload) c) ping a remote machine with its name d) uncomment my local DNS server (/etc/dnsmasq-resolv.conf) e) reload dnsmasq configuration Only then will I be able to ping _any other remote machine_ with its name. Running "/etc/init.d/dnsmasq reload" right after the VPN connection is made doesn't solve anything. Is this a problem with the metric? Is there something more I should check? Thanks for any hint/suggestion. Vince C. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss at lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090913/cc41435d/attachment.html From richardvoigt at gmail.com Sun Sep 13 22:51:00 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Sun, 13 Sep 2009 16:51:00 -0500 Subject: [Dnsmasq-discuss] dnsmasq seems to ignore or not wait for DNS servers behind a VPN In-Reply-To: <201005.28726.qm@web28205.mail.ukl.yahoo.com> References: <201005.28726.qm@web28205.mail.ukl.yahoo.com> Message-ID: <2e59e6970909131451v610d9b41ya16046fc348946d0@mail.gmail.com> On Sun, Sep 13, 2009 at 5:15 AM, Vincent Cadet wrote: > Hi people. > > I've installed *dnsmasq-2.49* under Gentoo. It runs concurrently with OpenResolv, which I need to add DNS server IP's to the resolver when I use my VPN connections. Actually OpenResolv acts upon */etc/dnsmasq-resolv.conf* and */etc/dnsmasq-resolvconf.conf*. The former holds the list of DNS servers, just like */etc/resolv.conf*. > > When I connect to a remote VPN server through "pon", everything goes fine: the connection is established, routes are set and the IP addresses of the remote network DNS servers are added to /etc/resolv.conf and /etc/dnsmasq-resolv.conf so that the remote DNS server IP's appear *first*, i.e. before the IP of my local DNS server. However name resolution doesn't work against machines on the remote network as long as the IP address of my local network DNS server is present in /etc/dnsmasq-resolv.conf. dnsmasq doesn't try the list of servers in order (unless you set an obsolete option), instead it treats them all as equal, global servers, and uses whichever is fastest. When connecting to a VPN, you probably don't want other machines on the network to see the new connection (that's why it's called virtual "private" network), while dnsmasq treats local and remote queries the same. So maybe you want openvpn to go ahead and update /etc/resolv.conf so that for the local machine only, addresses are tested against the VPN server while the VPN is up, and afterwards dnsmasq is used. Or perhaps you want to put server= lines in your dnsmasq config to direct certain domains to use the VPN servers when available. From david at howes.net.nz Wed Sep 16 10:59:46 2009 From: david at howes.net.nz (David Howes) Date: Wed, 16 Sep 2009 21:59:46 +1200 Subject: [Dnsmasq-discuss] Disabling "Recursive Query Refusal Detection" and a comment on MX caching. Message-ID: Hi! Thanks for a great utility! We're using DNSMasq as a caching server in front of four DNS servers. These DNS servers process a very large number of queries. 1) I can see from the list that you've previously answered the issue that DNSMasq doesn't cache MX records, is this on the schedule at all, or is this unlikely to ever become a feature? I ask as MX records are one of the main reocrd types we see, the lack of this caching hurts. 2) More critically, when DNSMasq decides a nameserver is not allowing recursive queries it puts "refused to do a recursive query" and seems to stop using that DNS server? This breaks *everything*. :) Is there a switch or option to turn this off as DNSMasq seems to do this when a server doesn't respond correctly (or at all) for a period of time... - David Howes. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090916/f1b747a5/attachment.htm From richardvoigt at gmail.com Wed Sep 16 14:53:45 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Wed, 16 Sep 2009 08:53:45 -0500 Subject: [Dnsmasq-discuss] Disabling "Recursive Query Refusal Detection" and a comment on MX caching. In-Reply-To: References: Message-ID: <2e59e6970909160653v59285213h5bd10d87a740cf12@mail.gmail.com> On Wed, Sep 16, 2009 at 4:59 AM, David Howes wrote: > Hi! > Thanks for a great utility! > Simon has done a marvelous job, truly. > We're using DNSMasq as a caching server in front of four DNS servers. > These DNS servers process a very large number of queries. That may be your problem, if I'm understanding your setup correctly. dnsmasq is really intended as a client-side cache, not server-side. > > 1) I can see from the list that you've previously answered the issue that > DNSMasq doesn't cache MX records, is this on the schedule at all, or is this > unlikely to ever become a feature?? I ask as MX records are one of the main > reocrd types we see, the lack of this caching hurts. Only Simon can answer that, but doesn't your SMTP agent have caching settings? Most e-mail servers store far more than just the DNS data in their cache anyway, things like rate of receipt are frequently used to detect spam attacks. > > 2) More critically, when DNSMasq decides a nameserver is not allowing > recursive queries it puts "refused to do a recursive query" and seems to > stop using that DNS server?? This breaks *everything*. :) > Is there a switch or option to turn this off as DNSMasq seems to do this > when a server doesn't respond correctly (or at all) for a period of time... You've misconfigured dnsmasq. This is a really common question recently, did you search the mailing list archives at all? The set of servers in resolv-file (e.g. /etc/resolv.conf) are NOT a list to be tried in order until one succeeds. They are a connection to a public recursive DNS server, with any number of backups to use in case the first fails (actually dnsmasq initially picks the active one based on response time, not the first in the list). If you have some servers with unique information (private DNS entries for your domain) then you need to use "server=[/[]/[domain/]][[#][@|[#]]" configuration lines in dnsmasq.conf according to the man page, so that these addresses are always queried on that server. Hope this helps. > > - David Howes. > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > From philippe at faure.ca Sat Sep 19 19:05:30 2009 From: philippe at faure.ca (Philippe Faure) Date: Sat, 19 Sep 2009 14:05:30 -0400 Subject: [Dnsmasq-discuss] Dnsmasq In-Reply-To: References: Message-ID: <20090919140530.287839aaxutfe3r4@mail.faure.ca> Quoting dnsmasq-discuss-request at lists.thekelleys.org.uk: > Send Dnsmasq-discuss mailing list submissions to > dnsmasq-discuss at lists.thekelleys.org.uk > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > or, via email, send a message with subject or body 'help' to > dnsmasq-discuss-request at lists.thekelleys.org.uk > > You can reach the person managing the list at > dnsmasq-discuss-owner at lists.thekelleys.org.uk > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Dnsmasq-discuss digest..." > > > Today's Topics: > > 1. location of cached addresses (Audio Phile) > 2. dnsmasq question - running as root or user (Audio Phile) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 22 Aug 2009 02:30:18 -0700 (PDT) > From: Audio Phile > Subject: [Dnsmasq-discuss] location of cached addresses > To: dnsmasq-discuss at lists.thekelleys.org.uk > Message-ID: <333252.62939.qm at web36608.mail.mud.yahoo.com> > Content-Type: text/plain; charset=us-ascii > > I read the man page for dnsmasq but still have no idea where dnsmasq > stores its list of cached addresses. If the answer is in RAM, is > there an option I can use in my /etc/dnsmasq.conf to allow this to > be on my file system so that the list survives a reboot? > > > > > > > ------------------------------ > > Message: 2 > Date: Sat, 22 Aug 2009 02:39:59 -0700 (PDT) > From: Audio Phile > Subject: [Dnsmasq-discuss] dnsmasq question - running as root or user > To: dnsmasq-discuss at lists.thekelleys.org.uk > Message-ID: <843901.66667.qm at web36608.mail.mud.yahoo.com> > Content-Type: text/plain; charset=us-ascii > > 1) What is the advantage of having dnsmasq run as a non-root user? > 2) Is there any kernel module required to do so on 2.6.30? > > According to some old docs, there was a requirement > CONFIG_SECURITY_CAPABILITIES parameter, but it obsolete on kernel > versions >2.6.26 (reference 1). Nor does it appear in the config > documentation for the latest kernel (reference 2). > > 1) http://cateee.net/lkddb/web-lkddb/SECURITY_CAPABILITIES.html > 2) http://www.kernel.org/doc/menuconfig/x86.html > > > > > > > ------------------------------ > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > End of Dnsmasq-discuss Digest, Vol 51, Issue 13 > *********************************************** > From ross at biostat.ucsf.edu Tue Sep 22 01:05:48 2009 From: ross at biostat.ucsf.edu (Ross Boylan) Date: Mon, 21 Sep 2009 17:05:48 -0700 Subject: [Dnsmasq-discuss] dnsmasq dynamic DNS? Message-ID: <1253577948.31794.57.camel@corn.betterworld.us> dnsmasq seems to be handing out IPs and domains OK, but querying it does not return the newly registered machine. Is this supposed to work? If so, how can I diagnose and fix it? I'm running 2.45-1+lenny1 on a Debian amd64 system. It is running on a real machine, but serving a vde2 network running kvm virtual machines (also Debian Lenny). dnsmasq does return IPs of public systems. It seems to be what is listening: tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 1456/dnsmasq tcp 0 0 0.0.0.0:39153 0.0.0.0:* LISTEN 4020/rpc.statd tcp6 0 0 :::53 :::* LISTEN 1456/dnsmasq udp 0 0 0.0.0.0:53 0.0.0.0:* 1456/dnsmasq udp 0 0 0.0.0.0:5353 0.0.0.0:* 4456/avahi-daemon: udp6 0 0 :::53 :::* 1456/dnsmasq udp6 0 0 :::5353 :::* 4456/avahi-daemon: udp6 0 0 :::38532 :::* 4456/avahi-daemon: (from netstat on the host system). I'm using dig to query the server, from both the host and virtual machine. The queries are both forward and reverse. The VM says its FQDN is vm-lenny06BCU.kvm.lan (could that particular name be a problem because it is long or has a dash?). It's at 192.168.8.139. So dig vm-lenny06BCU.kvm.lan dig vm-lenny06BCU (from the VM only; kvm.lan is not the host machine's natural domain) dig -x 192.168.8.139. Also dig @127.0.0.1 from the host, dig @192.168.8.1 from VM (since resolv.conf seems to say that is where to find the server). I'd appreciate being cc'd. Thanks. Ross Boylan From simon at thekelleys.org.uk Tue Sep 22 07:44:15 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Tue, 22 Sep 2009 07:44:15 +0100 Subject: [Dnsmasq-discuss] dnsmasq dynamic DNS? In-Reply-To: <1253577948.31794.57.camel@corn.betterworld.us> References: <1253577948.31794.57.camel@corn.betterworld.us> Message-ID: <4AB8723F.9050701@thekelleys.org.uk> Ross Boylan wrote: > dnsmasq seems to be handing out IPs and domains OK, but querying it does > not return the newly registered machine. Is this supposed to work? If > so, how can I diagnose and fix it? > > I'm running 2.45-1+lenny1 on a Debian amd64 system. It is running on a > real machine, but serving a vde2 network running kvm virtual machines > (also Debian Lenny). > > dnsmasq does return IPs of public systems. It seems to be what is > listening: > tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 1456/dnsmasq > tcp 0 0 0.0.0.0:39153 0.0.0.0:* LISTEN 4020/rpc.statd > tcp6 0 0 :::53 :::* LISTEN 1456/dnsmasq > udp 0 0 0.0.0.0:53 0.0.0.0:* 1456/dnsmasq > udp 0 0 0.0.0.0:5353 0.0.0.0:* 4456/avahi-daemon: > udp6 0 0 :::53 :::* 1456/dnsmasq > udp6 0 0 :::5353 :::* 4456/avahi-daemon: > udp6 0 0 :::38532 :::* 4456/avahi-daemon: > (from netstat on the host system). > > I'm using dig to query the server, from both the host and virtual > machine. The queries are both forward and reverse. The VM says its FQDN > is vm-lenny06BCU.kvm.lan (could that particular name be a problem > because it is long or has a dash?). It's at 192.168.8.139. So > dig vm-lenny06BCU.kvm.lan > dig vm-lenny06BCU (from the VM only; kvm.lan is not the host machine's > natural domain) > dig -x 192.168.8.139. > > Also dig @127.0.0.1 from the host, dig @192.168.8.1 from VM (since > resolv.conf seems to say that is where to find the server). > > I'd appreciate being cc'd. > > Thanks. > Ross Boylan > Two things to check: 1) Add log-queries to /etc/dnsmasq.conf and restart it. You should be able to see test queries in the syslog. That confirms that the DNS replies are coming from where you think they are. 2) Look at /var/lib/misc/dnsmasq.leases. The line for your VM should have its name. If there's only an asterix in the name field, then the DHCP client in the VM is not supplying a name when it asks for a DHCP lease. A quick re-configuration in /etc/dhclient.conf should fix that. Cheers, Simon. From philippe at faure.ca Tue Sep 22 23:48:00 2009 From: philippe at faure.ca (Philippe Faure) Date: Tue, 22 Sep 2009 18:48:00 -0400 Subject: [Dnsmasq-discuss] DNS search Order In-Reply-To: References: Message-ID: <20090922184800.21650wfvqicmy528@mail.faure.ca> Hello, I was wondering how does DNSMASQ use the DNS servers that it knows about. If "strict-order" is enabled, it uses them in the order found in the dnsmasq.conf file. If the first server doesn't reply, or can't answer, then it goes and tries the next one and so on. But if "strict-order" isn't enabled. How does DNSMASQ know which server(s) to contact? Does it use them all all the time? If not how does it determine which server to contact? How long does an entry in the cache remain valid before it checks again? thank you Philippe From ross at biostat.ucsf.edu Wed Sep 23 02:41:04 2009 From: ross at biostat.ucsf.edu (Ross Boylan) Date: Tue, 22 Sep 2009 18:41:04 -0700 Subject: [Dnsmasq-discuss] dnsmasq dynamic DNS? In-Reply-To: <4AB8723F.9050701@thekelleys.org.uk> References: <1253577948.31794.57.camel@corn.betterworld.us> <4AB8723F.9050701@thekelleys.org.uk> Message-ID: <1253670064.22433.3.camel@markov.biostat.ucsf.edu> On Tue, 2009-09-22 at 07:44 +0100, Simon Kelley wrote: > Ross Boylan wrote: > > dnsmasq seems to be handing out IPs and domains OK, but querying it does > > not return the newly registered machine. Is this supposed to work? If > > so, how can I diagnose and fix it? ..... > Two things to check: > > 1) Add log-queries to /etc/dnsmasq.conf and restart it. You should be > able to see test queries in the syslog. That confirms that the DNS > replies are coming from where you think they are. > > 2) Look at /var/lib/misc/dnsmasq.leases. The line for your VM should > have its name. If there's only an asterix in the name field, There was. > then the > DHCP client in the VM is not supplying a name when it asks for a DHCP > lease. A quick re-configuration in /etc/dhclient.conf should fix that. It did. Thank you very much. I'm not sure why dhcp3-client wasn't picking up the hostname from the general system; the documents seem to imply it should. Ross From simon at thekelleys.org.uk Wed Sep 23 20:17:45 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Wed, 23 Sep 2009 20:17:45 +0100 Subject: [Dnsmasq-discuss] DNS search Order In-Reply-To: <20090922184800.21650wfvqicmy528@mail.faure.ca> References: <20090922184800.21650wfvqicmy528@mail.faure.ca> Message-ID: <4ABA7459.4030109@thekelleys.org.uk> Philippe Faure wrote: > Hello, > > I was wondering how does DNSMASQ use the DNS servers that it knows about. > > If "strict-order" is enabled, it uses them in the order found in the > dnsmasq.conf file. If the first server doesn't reply, or can't answer, > then it goes and tries the next one and so on. > > But if "strict-order" isn't enabled. How does DNSMASQ know which > server(s) to contact? Does it use them all all the time? If not how > does it determine which server to contact? > How long does an entry in the cache remain valid before it checks again? > > thank you > > Philippe This is probably a FAQ, so I'll write this in a way which can go into the FAQ later. The algorithm for determining which server to use goes like this. In the start state, dnsmasq sends the query to all the servers. When the first server replies, it becomes the preferred server and dnsmasq moves into a state where only the preferred server is used. It remains in that state until one of three conditions occur, when dnsmasq moves back to the initial state and a query is again sent to all the servers. The conditions are. 1) A SERVFAIL or REFUSED return code is received. 2) More than 50 queries or 10 seconds have elapsed (version 2.51 only) 3) No reply is received and a client times-out and retries a query. You will see that the actual server used for any query is quite random. There's a strong assumption in the design that all the available servers are equivalent and will give the same answers, but that some may be slow or unavailable. If different servers know different answers, it's necessary to direct queries to the correct server with the server=/domain/ syntax. It is also worth pointing out that your first statement about "strict-order" is not quite true. Dnsmasq can't keep trying servers in order, since, after it has sent the query to the first server, it throws it away. (Dnsmasq doesn't keep copies of queries for all in-progress queries, that's one reason it has a low memory footprint). It will move onto the next server when the client times-out and retries the query, but typically a client will only time-out and retry once, so it only makes sense to have two servers with "strict-order" unless the clients are reconfigured for more retries. That's one reason why "strict-order" is broken and not recommended. The other is that the DNS protocol has no way of distinguishing a reply which says "this domain does not exist" from one which says "I know nothing about this domain". If dnsmasq gets "no such domain" from the first server it tries, that's a valid answer which will be passed back to the client, the query will not be tried on the second server. There do exist patches which change this behaviour, but they make strict-order even more broken, and have never been added to the official code-base. Cheers, Simon. From david at howes.net.nz Wed Sep 23 21:25:23 2009 From: david at howes.net.nz (David Howes) Date: Thu, 24 Sep 2009 08:25:23 +1200 Subject: [Dnsmasq-discuss] How to set the timeout dnsmasq uses for upstream queries... Message-ID: Hi again! Question 1) Upstream Forwarder/Server request timeout. In the resolve.conf of the servers running dnsmasq we have the following line: options timeout:15 Does dnsmasq obey this? If not how can I set a specific timeout so that DNSMasq will wait "x seconds" before giving up on the upsteam server. Question 2) Are there any other "Split DNS" servers? Out of curiosity, does any one know of any other DNS Servers that will serve DNS from the 'hosts' file before checking the upstream forwarder? - David. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090924/46721df3/attachment.htm From simon at thekelleys.org.uk Wed Sep 23 21:35:48 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Wed, 23 Sep 2009 21:35:48 +0100 Subject: [Dnsmasq-discuss] How to set the timeout dnsmasq uses for upstream queries... In-Reply-To: References: Message-ID: <4ABA86A4.8060102@thekelleys.org.uk> David Howes wrote: > Hi again! > > Question 1) Upstream Forwarder/Server request timeout. > In the resolve.conf of the servers running dnsmasq we have the following > line: > options timeout:15 > Does dnsmasq obey this? > If not how can I set a specific timeout so that DNSMasq will wait "x > seconds" before giving up on the upsteam server. Yes, that timeout is valid, since it's really the client which gives up. If dnsmasq doesn't get a reply from the upstream server, it will never reply to the client, so the timeout in the client is the valid one. There are timeouts in dnsmasq too, which are only changeable by re-compiling. Under very heavy load, dnsmasq will only hold onto a query for 10 seconds. It always drops unanswered queries after 4 times that (ie 40 seconds.) This is set in src/config.h Cheers, Simon. From simon at thekelleys.org.uk Thu Sep 24 12:31:04 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Thu, 24 Sep 2009 12:31:04 +0100 Subject: [Dnsmasq-discuss] DNS search Order In-Reply-To: <20090923195705.10043wq3zp4kn0e8@mail.faure.ca> References: <20090922184800.21650wfvqicmy528@mail.faure.ca> <4ABA7459.4030109@thekelleys.org.uk> <20090923195705.10043wq3zp4kn0e8@mail.faure.ca> Message-ID: <4ABB5878.8000700@thekelleys.org.uk> Philippe Faure wrote: > thank you Simon, > > I was wondering with version 2.51, will the 10 seconds, and 50 queries > be configurable? No easily, it's in the set of parameters at the start of src/config,h that can be changed by recompilation (I wonder if anyone has ever tunned any of those: I doubt it) > I can see in some situations where 50 queries is > reached very quickly, for example in corporate applications. On the > other hand, home networks, where little traffic is produced during the > day, a much longer time frame or quantity of queries may be acceptable. > Under heavy load, where the 50 queries limit is reached first, the effect will be to increase the total load on upstream servers by ~2%, assuming that there are two of them. (every 50th query will be sent to both servers.) That doesn't seem to me to be a big enough hit to worry about. The aim is to track which server is best and subjectively, it does seem to work with my ISPs slightly dodgy servers. Cheers, Simon. From philippe at faure.ca Thu Sep 24 14:58:52 2009 From: philippe at faure.ca (Philippe Faure) Date: Thu, 24 Sep 2009 09:58:52 -0400 Subject: [Dnsmasq-discuss] DNS search Order In-Reply-To: <4ABB5878.8000700@thekelleys.org.uk> References: <20090922184800.21650wfvqicmy528@mail.faure.ca> <4ABA7459.4030109@thekelleys.org.uk> <20090923195705.10043wq3zp4kn0e8@mail.faure.ca> <4ABB5878.8000700@thekelleys.org.uk> Message-ID: <20090924095852.12352p0rvfawkk5c@mail.faure.ca> >> I was wondering with version 2.51, will the 10 seconds, and 50 >> queries be configurable? > > No easily, it's in the set of parameters at the start of > src/config,h that can be changed by recompilation (I wonder if > anyone has ever tunned any of those: I doubt it) I am thinking under a light load, where requests are sent out less than once every 10 seconds, then I am sending to every DNS server every time. Just a thought. Philippe From richardvoigt at gmail.com Fri Sep 25 00:26:45 2009 From: richardvoigt at gmail.com (richardvoigt at gmail.com) Date: Thu, 24 Sep 2009 18:26:45 -0500 Subject: [Dnsmasq-discuss] DNS search Order In-Reply-To: <20090924095852.12352p0rvfawkk5c@mail.faure.ca> References: <20090922184800.21650wfvqicmy528@mail.faure.ca> <4ABA7459.4030109@thekelleys.org.uk> <20090923195705.10043wq3zp4kn0e8@mail.faure.ca> <4ABB5878.8000700@thekelleys.org.uk> <20090924095852.12352p0rvfawkk5c@mail.faure.ca> Message-ID: <2e59e6970909241626s4b91f510vd53441dbfd314dcd@mail.gmail.com> Not "more than 10 seconds between requests" but "more than 10 seconds between request and response". That should certainly not be a problem under conditions of light load. On Thu, Sep 24, 2009 at 8:58 AM, Philippe Faure wrote: >>> I was wondering with version 2.51, will the 10 seconds, and 50 >>> queries be configurable? >> >> No easily, it's in the set of parameters at the start of >> src/config,h that can be changed by recompilation (I wonder if >> anyone has ever tunned any of those: I doubt it) > > I am thinking under a light load, where requests are sent out less > than once every 10 seconds, then I am sending to every DNS server > every time. > > Just a thought. > > Philippe > > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From tmetro+dnsmasq at gmail.com Sun Sep 27 00:47:05 2009 From: tmetro+dnsmasq at gmail.com (Tom Metro) Date: Sat, 26 Sep 2009 19:47:05 -0400 Subject: [Dnsmasq-discuss] cname apparently not working In-Reply-To: <4AA669CD.1070608@thekelleys.org.uk> References: <20090902162039.GA28116@chris> <20090908140942.26137398.cjsthompson@gmail.com> <4AA669CD.1070608@thekelleys.org.uk> Message-ID: <4ABEA7F9.2030906@gmail.com> Simon Kelley wrote: > Christoph .J Thompson wrote: >> I can't seem to get cname to work for me. Maybe I'm doing something I'm not >> suposed to, but it's not obvious to me. I'm running Linux 2.6. Any help to >> fix this issue would be greatly appreciated. > > expand-hosts doesn't apply to CNAMEs, you need to provide the FQDN in > the cname > > cname=forum.mylan.eth,machine > > etc,etc The OP didn't post a follow-up, so your response probably addressed his problem, but isn't it also worth noting that the 'cname' option was only introduced in version 2.46? (I remember looking for a feature like this a while ago, so when I saw mention of it in this thread, I suspected it was a recent addition, and checked the change log.) Chris G wrote: > I hunted through the man page but couldn't find it. Maybe your version of Dnsmasq was too old to support it. (Does Dnsmasq complain visibly if it doesn't recognize a config directive?) -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ From ken at netfunctional.ca Mon Sep 28 15:45:52 2009 From: ken at netfunctional.ca (Ken Bantoft) Date: Mon, 28 Sep 2009 10:45:52 -0400 Subject: [Dnsmasq-discuss] dnsmasq forwarding queries over VPN/IPSec Message-ID: <1ECF7368-FE98-4300-ABE3-A76AE60A6A6C@netfunctional.ca> Hi, I've run into a case where I'd like dnsmasq to forward queries over an IPSec VPN tunnel to nameservers on the far side, but this doesn't seem to work as expected. I've got 2 Interfaces - br-lan (192.168.1.1) and ppp0 (PPPoE - 216.x.x.x). IPsec is terminated on the same machine, so it has a tunnel from 192.168.0.0/24 to 10.0.0.0/8. dnsmasq is set to forward all queries to 10.x.x.10 and 10.x.y.10 nameservers, which are across the tunnel in the datacenter. What I'm seeing with tcpdump is the requests going out the ppp0 interface, with the 216.x.x.x IP address. I've tried a variety of options (bind- interfaces, listen-address), as I really want dnsmasq to bind only to the br-lan interface, and use that address as the Source IP for the forwarded queries, but no combination I've tried does the trick. Any suggestions? Ken From simon at thekelleys.org.uk Mon Sep 28 16:03:33 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Mon, 28 Sep 2009 16:03:33 +0100 Subject: [Dnsmasq-discuss] dnsmasq forwarding queries over VPN/IPSec In-Reply-To: <1ECF7368-FE98-4300-ABE3-A76AE60A6A6C@netfunctional.ca> References: <1ECF7368-FE98-4300-ABE3-A76AE60A6A6C@netfunctional.ca> Message-ID: <4AC0D045.1070507@thekelleys.org.uk> Ken Bantoft wrote: > Hi, > > I've run into a case where I'd like dnsmasq to forward queries over an > IPSec VPN tunnel to nameservers on the far side, but this doesn't seem > to work as expected. > > I've got 2 Interfaces - br-lan (192.168.1.1) and ppp0 (PPPoE - > 216.x.x.x). IPsec is terminated on the same machine, so it has a > tunnel from 192.168.0.0/24 to 10.0.0.0/8. > > dnsmasq is set to forward all queries to 10.x.x.10 and 10.x.y.10 > nameservers, which are across the tunnel in the datacenter. What I'm > seeing with tcpdump is the requests going out the ppp0 interface, with > the 216.x.x.x IP address. I've tried a variety of options (bind- > interfaces, listen-address), as I really want dnsmasq to bind only to > the br-lan interface, and use that address as the Source IP for the > forwarded queries, but no combination I've tried does the trick. > > Any suggestions? > Stop dnsmasq from looking for servers in /etc/resolv.conf with no-resolv in /etc/dnsmasq.conf and then specify them using "server=" lines in /etc/dnsmasq.conf like this server=10.x.x.10 at br-lan server=10.x.y.10 at br-lan We've been here before.... Cheers, Simon. From ken at netfunctional.ca Mon Sep 28 16:08:26 2009 From: ken at netfunctional.ca (Ken Bantoft) Date: Mon, 28 Sep 2009 11:08:26 -0400 Subject: [Dnsmasq-discuss] dnsmasq forwarding queries over VPN/IPSec In-Reply-To: <4AC0D045.1070507@thekelleys.org.uk> References: <1ECF7368-FE98-4300-ABE3-A76AE60A6A6C@netfunctional.ca> <4AC0D045.1070507@thekelleys.org.uk> Message-ID: On 28-Sep-09, at 11:03 AM, Simon Kelley wrote: > Ken Bantoft wrote: >> Hi, >> I've run into a case where I'd like dnsmasq to forward queries over >> an IPSec VPN tunnel to nameservers on the far side, but this >> doesn't seem to work as expected. >> I've got 2 Interfaces - br-lan (192.168.1.1) and ppp0 (PPPoE - >> 216.x.x.x). IPsec is terminated on the same machine, so it has a >> tunnel from 192.168.0.0/24 to 10.0.0.0/8. >> dnsmasq is set to forward all queries to 10.x.x.10 and 10.x.y.10 >> nameservers, which are across the tunnel in the datacenter. What >> I'm seeing with tcpdump is the requests going out the ppp0 >> interface, with the 216.x.x.x IP address. I've tried a variety of >> options (bind- interfaces, listen-address), as I really want >> dnsmasq to bind only to the br-lan interface, and use that address >> as the Source IP for the forwarded queries, but no combination >> I've tried does the trick. >> Any suggestions? > > Stop dnsmasq from looking for servers in /etc/resolv.conf with > > no-resolv > > in /etc/dnsmasq.conf and then specify them using "server=" lines in / > etc/dnsmasq.conf like this > > server=10.x.x.10 at br-lan > server=10.x.y.10 at br-lan > > > We've been here before.... That was my 1st step... so I do see it sending the requests to 10.x.x. 10 and 10.x.y.10 as expected - just out the wrong interface... Ken From simon at thekelleys.org.uk Mon Sep 28 16:12:47 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Mon, 28 Sep 2009 16:12:47 +0100 Subject: [Dnsmasq-discuss] dnsmasq forwarding queries over VPN/IPSec In-Reply-To: References: <1ECF7368-FE98-4300-ABE3-A76AE60A6A6C@netfunctional.ca> <4AC0D045.1070507@thekelleys.org.uk> Message-ID: <4AC0D26F.8010704@thekelleys.org.uk> Ken Bantoft wrote: > > On 28-Sep-09, at 11:03 AM, Simon Kelley wrote: > >> Ken Bantoft wrote: >>> Hi, >>> I've run into a case where I'd like dnsmasq to forward queries over >>> an IPSec VPN tunnel to nameservers on the far side, but this doesn't >>> seem to work as expected. >>> I've got 2 Interfaces - br-lan (192.168.1.1) and ppp0 (PPPoE - >>> 216.x.x.x). IPsec is terminated on the same machine, so it has a >>> tunnel from 192.168.0.0/24 to 10.0.0.0/8. >>> dnsmasq is set to forward all queries to 10.x.x.10 and 10.x.y.10 >>> nameservers, which are across the tunnel in the datacenter. What >>> I'm seeing with tcpdump is the requests going out the ppp0 >>> interface, with the 216.x.x.x IP address. I've tried a variety of >>> options (bind- interfaces, listen-address), as I really want dnsmasq >>> to bind only to the br-lan interface, and use that address as the >>> Source IP for the forwarded queries, but no combination I've tried >>> does the trick. >>> Any suggestions? >> >> Stop dnsmasq from looking for servers in /etc/resolv.conf with >> >> no-resolv >> >> in /etc/dnsmasq.conf and then specify them using "server=" lines in >> /etc/dnsmasq.conf like this >> >> server=10.x.x.10 at br-lan >> server=10.x.y.10 at br-lan >> >> >> We've been here before.... > > That was my 1st step... so I do see it sending the requests to 10.x.x.10 > and 10.x.y.10 as expected - just out the wrong interface... > > > Ken > > > If this a routing problem? Dnsmasq can control the source address of the packets, and the destination address is straightforward, but it can't control how the kernel routes the packets: do you have a route to 10.0.0.0/8 via the tunnel? Cheers, Simon. From ken at netfunctional.ca Mon Sep 28 16:25:41 2009 From: ken at netfunctional.ca (Ken Bantoft) Date: Mon, 28 Sep 2009 11:25:41 -0400 Subject: [Dnsmasq-discuss] dnsmasq forwarding queries over VPN/IPSec In-Reply-To: <4AC0D26F.8010704@thekelleys.org.uk> References: <1ECF7368-FE98-4300-ABE3-A76AE60A6A6C@netfunctional.ca> <4AC0D045.1070507@thekelleys.org.uk> <4AC0D26F.8010704@thekelleys.org.uk> Message-ID: <1E3D1CBB-B1AE-4599-8FFC-A815E896C6E3@netfunctional.ca> On 28-Sep-09, at 11:12 AM, Simon Kelley wrote: > Ken Bantoft wrote: >> On 28-Sep-09, at 11:03 AM, Simon Kelley wrote: >>> Ken Bantoft wrote: >>>> Hi, >>>> I've run into a case where I'd like dnsmasq to forward queries >>>> over an IPSec VPN tunnel to nameservers on the far side, but >>>> this doesn't seem to work as expected. >>>> I've got 2 Interfaces - br-lan (192.168.1.1) and ppp0 (PPPoE - >>>> 216.x.x.x). IPsec is terminated on the same machine, so it has >>>> a tunnel from 192.168.0.0/24 to 10.0.0.0/8. >>>> dnsmasq is set to forward all queries to 10.x.x.10 and 10.x.y.10 >>>> nameservers, which are across the tunnel in the datacenter. What >>>> I'm seeing with tcpdump is the requests going out the ppp0 >>>> interface, with the 216.x.x.x IP address. I've tried a variety >>>> of options (bind- interfaces, listen-address), as I really want >>>> dnsmasq to bind only to the br-lan interface, and use that >>>> address as the Source IP for the forwarded queries, but no >>>> combination I've tried does the trick. >>>> Any suggestions? >>> >>> Stop dnsmasq from looking for servers in /etc/resolv.conf with >>> >>> no-resolv >>> >>> in /etc/dnsmasq.conf and then specify them using "server=" lines >>> in /etc/dnsmasq.conf like this >>> >>> server=10.x.x.10 at br-lan >>> server=10.x.y.10 at br-lan >>> >>> >>> We've been here before.... >> That was my 1st step... so I do see it sending the requests to >> 10.x.x.10 and 10.x.y.10 as expected - just out the wrong interface... >> Ken > If this a routing problem? Dnsmasq can control the source address of > the packets, and the destination address is straightforward, but it > can't control how the kernel routes the packets: do you have a > route to 10.0.0.0/8 via the tunnel? > No route - it's Linux Kernel netkey IPsec stack, so no nice ipsec0 interface - it's all done with the ip xfrm policies... which might be causing some grief, but it's difficult to tell. Any debugging options for dnsmasq to have it printout the packets before it puts them on a wire? Ken From simon at thekelleys.org.uk Mon Sep 28 16:30:51 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Mon, 28 Sep 2009 16:30:51 +0100 Subject: [Dnsmasq-discuss] dnsmasq forwarding queries over VPN/IPSec In-Reply-To: <1E3D1CBB-B1AE-4599-8FFC-A815E896C6E3@netfunctional.ca> References: <1ECF7368-FE98-4300-ABE3-A76AE60A6A6C@netfunctional.ca> <4AC0D045.1070507@thekelleys.org.uk> <4AC0D26F.8010704@thekelleys.org.uk> <1E3D1CBB-B1AE-4599-8FFC-A815E896C6E3@netfunctional.ca> Message-ID: <4AC0D6AB.20904@thekelleys.org.uk> Ken Bantoft wrote: > > On 28-Sep-09, at 11:12 AM, Simon Kelley wrote: > >> Ken Bantoft wrote: >>> On 28-Sep-09, at 11:03 AM, Simon Kelley wrote: >>>> Ken Bantoft wrote: >>>>> Hi, >>>>> I've run into a case where I'd like dnsmasq to forward queries over >>>>> an IPSec VPN tunnel to nameservers on the far side, but this >>>>> doesn't seem to work as expected. >>>>> I've got 2 Interfaces - br-lan (192.168.1.1) and ppp0 (PPPoE - >>>>> 216.x.x.x). IPsec is terminated on the same machine, so it has a >>>>> tunnel from 192.168.0.0/24 to 10.0.0.0/8. >>>>> dnsmasq is set to forward all queries to 10.x.x.10 and 10.x.y.10 >>>>> nameservers, which are across the tunnel in the datacenter. What >>>>> I'm seeing with tcpdump is the requests going out the ppp0 >>>>> interface, with the 216.x.x.x IP address. I've tried a variety of >>>>> options (bind- interfaces, listen-address), as I really want >>>>> dnsmasq to bind only to the br-lan interface, and use that address >>>>> as the Source IP for the forwarded queries, but no combination >>>>> I've tried does the trick. >>>>> Any suggestions? >>>> >>>> Stop dnsmasq from looking for servers in /etc/resolv.conf with >>>> >>>> no-resolv >>>> >>>> in /etc/dnsmasq.conf and then specify them using "server=" lines in >>>> /etc/dnsmasq.conf like this >>>> >>>> server=10.x.x.10 at br-lan >>>> server=10.x.y.10 at br-lan >>>> >>>> >>>> We've been here before.... >>> That was my 1st step... so I do see it sending the requests to >>> 10.x.x.10 and 10.x.y.10 as expected - just out the wrong interface... >>> Ken >> If this a routing problem? Dnsmasq can control the source address of >> the packets, and the destination address is straightforward, but it >> can't control how the kernel routes the packets: do you have a route >> to 10.0.0.0/8 via the tunnel? >> > > > No route - it's Linux Kernel netkey IPsec stack, so no nice ipsec0 > interface - it's all done with the ip xfrm policies... which might be > causing some grief, but it's difficult to tell. Any debugging options > for dnsmasq to have it printout the packets before it puts them on a wire? > > Oh, you're well outside my comfort zone now. No debugging options, but strace might help - you can see the system calls that send the packets. You can set the source address for packets with something like: server=10.x.x.10 at 192.168.0.1, that might work where binding to an interface doesn't. Cheers, Simon. From ken at netfunctional.ca Mon Sep 28 16:34:36 2009 From: ken at netfunctional.ca (Ken Bantoft) Date: Mon, 28 Sep 2009 11:34:36 -0400 Subject: [Dnsmasq-discuss] dnsmasq forwarding queries over VPN/IPSec In-Reply-To: <4AC0D6AB.20904@thekelleys.org.uk> References: <1ECF7368-FE98-4300-ABE3-A76AE60A6A6C@netfunctional.ca> <4AC0D045.1070507@thekelleys.org.uk> <4AC0D26F.8010704@thekelleys.org.uk> <1E3D1CBB-B1AE-4599-8FFC-A815E896C6E3@netfunctional.ca> <4AC0D6AB.20904@thekelleys.org.uk> Message-ID: <202A3455-2BFD-4DF1-81DB-0CC64C3B0E94@netfunctional.ca> On 28-Sep-09, at 11:30 AM, Simon Kelley wrote: > Ken Bantoft wrote: >> On 28-Sep-09, at 11:12 AM, Simon Kelley wrote: >>> Ken Bantoft wrote: >>>> On 28-Sep-09, at 11:03 AM, Simon Kelley wrote: >>>>> Ken Bantoft wrote: >>>>>> Hi, >>>>>> I've run into a case where I'd like dnsmasq to forward queries >>>>>> over an IPSec VPN tunnel to nameservers on the far side, but >>>>>> this doesn't seem to work as expected. >>>>>> I've got 2 Interfaces - br-lan (192.168.1.1) and ppp0 (PPPoE - >>>>>> 216.x.x.x). IPsec is terminated on the same machine, so it has >>>>>> a tunnel from 192.168.0.0/24 to 10.0.0.0/8. >>>>>> dnsmasq is set to forward all queries to 10.x.x.10 and 10.x.y. >>>>>> 10 nameservers, which are across the tunnel in the >>>>>> datacenter. What I'm seeing with tcpdump is the requests >>>>>> going out the ppp0 interface, with the 216.x.x.x IP address. >>>>>> I've tried a variety of options (bind- interfaces, listen- >>>>>> address), as I really want dnsmasq to bind only to the br-lan >>>>>> interface, and use that address as the Source IP for the >>>>>> forwarded queries, but no combination I've tried does the trick. >>>>>> Any suggestions? >>>>> >>>>> Stop dnsmasq from looking for servers in /etc/resolv.conf with >>>>> >>>>> no-resolv >>>>> >>>>> in /etc/dnsmasq.conf and then specify them using "server=" lines >>>>> in /etc/dnsmasq.conf like this >>>>> >>>>> server=10.x.x.10 at br-lan >>>>> server=10.x.y.10 at br-lan >>>>> >>>>> >>>>> We've been here before.... >>>> That was my 1st step... so I do see it sending the requests to >>>> 10.x.x.10 and 10.x.y.10 as expected - just out the wrong >>>> interface... >>>> Ken >>> If this a routing problem? Dnsmasq can control the source address >>> of the packets, and the destination address is straightforward, >>> but it can't control how the kernel routes the packets: do you >>> have a route to 10.0.0.0/8 via the tunnel? >>> >> No route - it's Linux Kernel netkey IPsec stack, so no nice ipsec0 >> interface - it's all done with the ip xfrm policies... which might >> be causing some grief, but it's difficult to tell. Any debugging >> options for dnsmasq to have it printout the packets before it puts >> them on a wire? > Oh, you're well outside my comfort zone now. No debugging options, > but strace might help - you can see the system calls that send the > packets. You can set the source address for packets with something > like: > > server=10.x.x.10 at 192.168.0.1, that might work where binding to an > interface doesn't. Yea, I was trying that... and depending on the options I'd either see the packet go out ppp0 with the External IP, or see no packet at all (!). I'll keep digging and let you know what I find.... just surprised no one else has run into this yet. My workaround to-date has been to have dnsmasq issue the 10.x.x.10 IP via DHCP to the clients, which is fine until the IPsec tunnel goes down and then none of the clients have DNS service anymore :( Ken From simon at thekelleys.org.uk Mon Sep 28 16:41:01 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Mon, 28 Sep 2009 16:41:01 +0100 Subject: [Dnsmasq-discuss] dnsmasq forwarding queries over VPN/IPSec In-Reply-To: <202A3455-2BFD-4DF1-81DB-0CC64C3B0E94@netfunctional.ca> References: <1ECF7368-FE98-4300-ABE3-A76AE60A6A6C@netfunctional.ca> <4AC0D045.1070507@thekelleys.org.uk> <4AC0D26F.8010704@thekelleys.org.uk> <1E3D1CBB-B1AE-4599-8FFC-A815E896C6E3@netfunctional.ca> <4AC0D6AB.20904@thekelleys.org.uk> <202A3455-2BFD-4DF1-81DB-0CC64C3B0E94@netfunctional.ca> Message-ID: <4AC0D90D.2050800@thekelleys.org.uk> Ken Bantoft wrote: > > > On 28-Sep-09, at 11:30 AM, Simon Kelley wrote: > >> Ken Bantoft wrote: >>> On 28-Sep-09, at 11:12 AM, Simon Kelley wrote: >>>> Ken Bantoft wrote: >>>>> On 28-Sep-09, at 11:03 AM, Simon Kelley wrote: >>>>>> Ken Bantoft wrote: >>>>>>> Hi, >>>>>>> I've run into a case where I'd like dnsmasq to forward queries >>>>>>> over an IPSec VPN tunnel to nameservers on the far side, but >>>>>>> this doesn't seem to work as expected. >>>>>>> I've got 2 Interfaces - br-lan (192.168.1.1) and ppp0 (PPPoE - >>>>>>> 216.x.x.x). IPsec is terminated on the same machine, so it has >>>>>>> a tunnel from 192.168.0.0/24 to 10.0.0.0/8. >>>>>>> dnsmasq is set to forward all queries to 10.x.x.10 and 10.x.y.10 >>>>>>> nameservers, which are across the tunnel in the datacenter. What >>>>>>> I'm seeing with tcpdump is the requests going out the ppp0 >>>>>>> interface, with the 216.x.x.x IP address. I've tried a variety >>>>>>> of options (bind- interfaces, listen-address), as I really want >>>>>>> dnsmasq to bind only to the br-lan interface, and use that >>>>>>> address as the Source IP for the forwarded queries, but no >>>>>>> combination I've tried does the trick. >>>>>>> Any suggestions? >>>>>> >>>>>> Stop dnsmasq from looking for servers in /etc/resolv.conf with >>>>>> >>>>>> no-resolv >>>>>> >>>>>> in /etc/dnsmasq.conf and then specify them using "server=" lines >>>>>> in /etc/dnsmasq.conf like this >>>>>> >>>>>> server=10.x.x.10 at br-lan >>>>>> server=10.x.y.10 at br-lan >>>>>> >>>>>> >>>>>> We've been here before.... >>>>> That was my 1st step... so I do see it sending the requests to >>>>> 10.x.x.10 and 10.x.y.10 as expected - just out the wrong interface... >>>>> Ken >>>> If this a routing problem? Dnsmasq can control the source address of >>>> the packets, and the destination address is straightforward, but it >>>> can't control how the kernel routes the packets: do you have a >>>> route to 10.0.0.0/8 via the tunnel? >>>> >>> No route - it's Linux Kernel netkey IPsec stack, so no nice ipsec0 >>> interface - it's all done with the ip xfrm policies... which might be >>> causing some grief, but it's difficult to tell. Any debugging >>> options for dnsmasq to have it printout the packets before it puts >>> them on a wire? >> Oh, you're well outside my comfort zone now. No debugging options, but >> strace might help - you can see the system calls that send the >> packets. You can set the source address for packets with something like: >> >> server=10.x.x.10 at 192.168.0.1, that might work where binding to an >> interface doesn't. > > > Yea, I was trying that... and depending on the options I'd either see > the packet go out ppp0 with the External IP, or see no packet at all > (!). I'll keep digging and let you know what I find.... just surprised > no one else has run into this yet. My workaround to-date has been to > have dnsmasq issue the 10.x.x.10 IP via DHCP to the clients, which is > fine until the IPsec tunnel goes down and then none of the clients have > DNS service anymore :( > > > Ken > I can't see how it can be a a dnsmasq-specific thing: it has to be down to the routing to 10.x.x.10. What happens to ICMP packets to that address sent by "ping"? Cheers, Simon. From mlim at bbn.com Tue Sep 29 21:09:42 2009 From: mlim at bbn.com (Melissa Lim) Date: Tue, 29 Sep 2009 16:09:42 -0400 Subject: [Dnsmasq-discuss] load balancing using round robin dns Message-ID: <4AC26986.3020705@bbn.com> An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090929/caea6f7c/attachment.htm From simon at thekelleys.org.uk Tue Sep 29 21:08:11 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Tue, 29 Sep 2009 21:08:11 +0100 Subject: [Dnsmasq-discuss] Announce: dnsmasq-2.51rc1 Message-ID: <4AC2692B.8090703@thekelleys.org.uk> The development branch of dnsmasq has amassed quite a few changes, going back 3 months in some cases: most of the work was done before the 2.50 security-only release. I think it's time therefore to make a new release, and I'm making a first release-candidate available at http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.51rc1.tar.gz http://www.thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.51rc1.tar.lzma Please test this, and/or translate it, as appropriate. (Translators, drop me a note if you're working and I'll hold off a final release until you're done.) version 2.51 Add support for internationalised DNS. Non-ASCII characters in domain names found in /etc/hosts, /etc/ethers and /etc/dnsmasq.conf will be correctly handled by translation to punycode, as specified in RFC3490. This function is only available if dnsmasq is compiled with internationalisation support, and adds a dependency on GNU libidn. Without i18n support, dnsmasq continues to be compilable with just standard tools. Thanks to Yves Dorfsman for the suggestion. Add two more environment variables for lease-change scripts: First, DNSMASQ_SUPPLIED_HOSTNAME; this is set to the hostname supplied by a client, even if the actual hostname used is over-ridden by dhcp-host or dhcp-ignore-names directives. Also DNSMASQ_RELAY_ADDRESS which gives the address of a DHCP relay, if used. Suggestions from Michael Rack. Fix regression which broke echo of relay-agent options. Thanks to Michael Rack for spotting this. Don't treat option 67 as being interchangeable with dhcp-boot parameters if it's specified as dhcp-option-force. Make the code to call scripts on lease-change compile-time optional. It can be switched off by editing src/config.h or building with "make COPTS=-DNO_SCRIPT". Make the TFTP server cope with filenames from Windows/DOS which use '\' as pathname separator. Thanks to Ralf for the patch. Updated Polish translation. Thanks to Jan Psota. Warn if an IP address is duplicated in /etc/ethers. Thanks to Felix Schwarz for pointing this out. Teach --conf-dir to take an option list of file suffices which will be ignored when scanning the directory. Useful for backup files etc. Thanks to Helmut Hullen for the suggestion. Add new DHCP option named tftpserver-address, which corresponds to the third argument of dhcp-boot. This allows the complete functionality of dhcp-boot to be replicated with dhcp-option. Useful when using dhcp-optsfile. Test which upstream nameserver to use every 10 seconds or 50 queries and not just when a query times out and is retried. This should improve performance when there is a slow nameserver in the list. Thanks to Joe for the suggestion. Don't do any PXE processing, even for clients with the correct vendorclass, unless at least one pxe-prompt or pxe-service option is given. This stops dnsmasq interfering with proxy PXE subsystems when it is just the DHCP server. Thanks to Spencer Clark for spotting this. Limit the blocksize used for TFTP transfers to a value which avoids packet fragmentation, based on the MTU of the local interface. Many netboot ROMs can't cope with fragmented packets. Honour dhcp-ignore configuration for PXE and proxy-PXE requests. Thanks to Niels Basjes for the bug report. Cheers, Simon. From simon at thekelleys.org.uk Tue Sep 29 21:17:35 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Tue, 29 Sep 2009 21:17:35 +0100 Subject: [Dnsmasq-discuss] load balancing using round robin dns In-Reply-To: <4AC26986.3020705@bbn.com> References: <4AC26986.3020705@bbn.com> Message-ID: <4AC26B5F.1090401@thekelleys.org.uk> Melissa Lim wrote: > Hello: > > I'm trying to get Round Robin DNS with dnsmasq working on my embedded system. > But it's not quite working. I have 4 boards (1 controller and 3 web servers) in > my system each with a static IP address. I have dnsmasq running on the > controller board and lighttpd (web server) running on the 3 web server boards. > > In my /etc/hosts file I have: > > 192.1.253.162 controller.test.local > 192.1.253.163 server.test.local > 192.1.253.164 server.test.local > 192.1.253.165 server.test.local > > I've added the controller board's IP address to my laptop's DNS adresses, so > when I access server.test.local from my web browser on my laptop, I see my test > web page. > > Each time I access the web page, I'd like for dnsmasq to load balance the > request to the 3 web servers in a round robin fashion. Is this supported? How > do I know which web server is actually being used? Is this information provided > in a certain mode? I'm running in daemon mode and I see the following: > > dnsmasq: query[A] server.test.local from 192.1.255.186 > dnsmasq: /etc/hosts server.test.local is 192.1.253.165 > dnsmasq: /etc/hosts server.test.local is 192.1.253.163 > dnsmasq: /etc/hosts server.test.local is 192.1.253.164 That's expected: dnsmasq will supply all three addresses for server.test.local each time it's queried. It implements round-robin by shuffling the order in which the addresses appear in the reply - the resolver library used by the web browser will always take the first one. > > This infomation is NOT provided everytime the web page is accessed - only when > it switches web server. Round robin does appear to be working, but not for > every access. How do I set it up so that it occurs for every access? Is the > load balancing feature doing a redirect or is the data always going through the > controller board? Probably the the name->address mapping is being cached in the browser, this is a limitation of DNS based load-balancing. > > Also, is there a way to have load balancing occur when I access the IP address > of the controller? (i.e. have http://192.1.253.162 look like > http://server.test.local and access the web server boards). Maybe via the > dnsmasq config file??? Dnsmasq can't help you here: it's only doing DNS, and can't influence anything that doesn't do a DNS lookup. There are other ways of doing load-balancing, via fancy switches or reverse-proxies, but I know nothing about them, other than that they exist. There's probably an O'Reilly book that will help...... Cheers, Simon. From aweber at comcast.net Tue Sep 29 22:46:07 2009 From: aweber at comcast.net (AJ Weber) Date: Tue, 29 Sep 2009 17:46:07 -0400 Subject: [Dnsmasq-discuss] load balancing using round robin dns References: <4AC26986.3020705@bbn.com> <4AC26B5F.1090401@thekelleys.org.uk> Message-ID: <000301ca414e$41bd9b00$9c01a8c0@webtekllc.com> Yeah, you're probably better installing something like pen or another readily-available load-balancer. Some of them are very lightweight, but would require you to send all traffic back to your controller (set server.test.local as an alias of controller.test.local), and then the load-balancer would redirect to the individual servers that are available. It would also solve the problem you might run into if one of the embedded servers is down, dnsmasq (or any pure DNS round-robin implementation) will still reply to every 3rd client's request with the down server's address. And as Simon says (no pun intended), that client's browser or OS may cache the resolution and not try any of the other servers...they'll just think the website is completely down. Not a lot of work to change-around and should be much more robust. I love dnsmasq, and have used it on various platforms for a long time, but you should look to a different solution for this kind of load-balancing. -AJ ----- Original Message ----- From: "Simon Kelley" To: "Melissa Lim" Cc: Sent: Tuesday, September 29, 2009 4:17 PM Subject: Re: [Dnsmasq-discuss] load balancing using round robin dns > Melissa Lim wrote: >> Hello: >> >> I'm trying to get Round Robin DNS with dnsmasq working on my embedded >> system. >> But it's not quite working. I have 4 boards (1 controller and 3 web >> servers) in >> my system each with a static IP address. I have dnsmasq running on the >> controller board and lighttpd (web server) running on the 3 web server >> boards. >> >> In my /etc/hosts file I have: >> >> 192.1.253.162 controller.test.local >> 192.1.253.163 server.test.local >> 192.1.253.164 server.test.local >> 192.1.253.165 server.test.local >> >> I've added the controller board's IP address to my laptop's DNS adresses, >> so >> when I access server.test.local from my web browser on my laptop, I see >> my test >> web page. >> >> Each time I access the web page, I'd like for dnsmasq to load balance the >> request to the 3 web servers in a round robin fashion. Is this >> supported? How >> do I know which web server is actually being used? Is this information >> provided >> in a certain mode? I'm running in daemon mode and I see the following: >> >> dnsmasq: query[A] server.test.local from 192.1.255.186 >> dnsmasq: /etc/hosts server.test.local is 192.1.253.165 >> dnsmasq: /etc/hosts server.test.local is 192.1.253.163 >> dnsmasq: /etc/hosts server.test.local is 192.1.253.164 > > > That's expected: dnsmasq will supply all three addresses for > server.test.local each time it's queried. It implements round-robin by > shuffling the order in which the addresses appear in the reply - the > resolver library used by the web browser will always take the first one. >> >> This infomation is NOT provided everytime the web page is accessed - only >> when >> it switches web server. Round robin does appear to be working, but not >> for >> every access. How do I set it up so that it occurs for every access? Is >> the >> load balancing feature doing a redirect or is the data always going >> through the >> controller board? > > Probably the the name->address mapping is being cached in the browser, > this is a limitation of DNS based load-balancing. > >> >> Also, is there a way to have load balancing occur when I access the IP >> address >> of the controller? (i.e. have http://192.1.253.162 look like >> http://server.test.local and access the web server boards). Maybe via >> the >> dnsmasq config file??? > > Dnsmasq can't help you here: it's only doing DNS, and can't influence > anything that doesn't do a DNS lookup. There are other ways of doing > load-balancing, via fancy switches or reverse-proxies, but I know > nothing about them, other than that they exist. There's probably an > O'Reilly book that will help...... > > Cheers, > > Simon. > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From tij at gmx.de Wed Sep 30 11:17:40 2009 From: tij at gmx.de (Tom) Date: Wed, 30 Sep 2009 12:17:40 +0200 Subject: [Dnsmasq-discuss] dns forwarding on port 53 and 110 (resolv.dnsmasq nameserver) In-Reply-To: <9860ae3f3281dfd8b77103bd778be2fd@rennradler.de> References: <9860ae3f3281dfd8b77103bd778be2fd@rennradler.de> Message-ID: <7ca0cec9215938a7055fd3eb5b216dc7@rennradler.de> Hi, I would like to use different nameservers. Some of them are listening on port 53, others on port 110. I tried the following in resolv.dnsmasq but it does not work: nameserver 87.118.100.175#53 nameserver 85.25.149.144#110 How can I configuere it? Regards, Tom From simon at thekelleys.org.uk Wed Sep 30 11:54:32 2009 From: simon at thekelleys.org.uk (Simon Kelley) Date: Wed, 30 Sep 2009 11:54:32 +0100 Subject: [Dnsmasq-discuss] dns forwarding on port 53 and 110 (resolv.dnsmasq nameserver) In-Reply-To: <7ca0cec9215938a7055fd3eb5b216dc7@rennradler.de> References: <9860ae3f3281dfd8b77103bd778be2fd@rennradler.de> <7ca0cec9215938a7055fd3eb5b216dc7@rennradler.de> Message-ID: <4AC338E8.1040009@thekelleys.org.uk> Tom wrote: > Hi, > > I would like to use different nameservers. Some of them are listening on > port 53, others on port 110. > > I tried the following in resolv.dnsmasq but it does not work: > > nameserver 87.118.100.175#53 > nameserver 85.25.149.144#110 > > How can I configuere it? > You can't use the "#" syntax in /etc/resolv.conf. You need to remove the nameserver lines from /etc/resolv.conf and add server=87.118.100.175#53 server=85.25.149.144#110 to /etc/dnsmasq.conf, instead. HTH Simon. From mlim at bbn.com Wed Sep 30 14:25:14 2009 From: mlim at bbn.com (Melissa Lim) Date: Wed, 30 Sep 2009 09:25:14 -0400 Subject: [Dnsmasq-discuss] load balancing using round robin dns In-Reply-To: <000301ca414e$41bd9b00$9c01a8c0@webtekllc.com> References: <4AC26986.3020705@bbn.com> <4AC26B5F.1090401@thekelleys.org.uk> <000301ca414e$41bd9b00$9c01a8c0@webtekllc.com> Message-ID: <4AC35C3A.40003@bbn.com> An HTML attachment was scrubbed... URL: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20090930/37c95222/attachment.htm From bogus@does.not.exist.com Mon Sep 7 11:48:48 2009 From: bogus@does.not.exist.com () Date: Mon, 07 Sep 2009 10:48:48 -0000 Subject: No subject Message-ID: l (quote) Also permitted is a -S flag which gives a domain but no IP address; this tells dnsmasq that a domain is local and it may answer queries from /etc/hosts or DHCP but should never forward queries on that domain to any upstream servers. local is a synonym for server to make configuration files clearer in this case. (/quote) I think that's what you want, a line local=3D/war.pcsd/ with no IP address > > Is this intended? > > Or do I have something in one of my configs that is helping me shoot > myself in the foot.. > > :) > > Thanks in advance. > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss at lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > From bogus@does.not.exist.com Mon Sep 7 11:48:48 2009 From: bogus@does.not.exist.com () Date: Mon, 07 Sep 2009 10:48:48 -0000 Subject: No subject Message-ID: out addresses from the pool which are already in use even when they aren't listed in /etc/ethers, by checking for a response to ping. This isn't 100% effective since many systems don't respond to ping (especially while turned off). So if any addresses inside the dhcp-range are used, help dnsmasq out with a dhcp-host or /etc/ethers entry so it doesn't have to rely on ping. From bogus@does.not.exist.com Mon Sep 7 11:48:48 2009 From: bogus@does.not.exist.com () Date: Mon, 07 Sep 2009 10:48:48 -0000 Subject: No subject Message-ID: match. Any thoughts? Linked below is a log file with a successful boot (when there wasn't a network specification based on matching vendor class substrings) and an uncessful one (when I did have the network specification there). As well as my config file with both configurations. Thanks again! Max http://notes.maxmusings.net/dnsmasq.conf http://notes.maxmusings.net/boot-fail.txt http://notes.maxmusings.net/boot-success.txt On Sun, Jan 31, 2010 at 11:02 AM, Simon Kelley wrote: > Max Turkewitz wrote: > > Thanks for your quick response Simon. I had to move to a different > system > > to get some diagnostic output (DD-WRT doesn't seem to support some > options > > or just isn't giving me output at the terminal). > > > > using the --test option I found that DNSMasq didn't like the line: > > dhcp-vendor=apple-boot,AAPLBSDPC/i386 > > > > Without that line it accepts the configuration file but my Mac will still > > not NetBoot. > > Humble apologies, should be > > dhcp-vendorclass=apple-boot,AAPLBSDPC/i386 > > (This sets the tag "apple-boot" which the client sends the AA.... string > as its vendorclass, that's used in the other lines to only send the > apple-specific options to apple clients. > > You can omit that line completely, but you have to remove the > "apple-boot" tags from the option lines so that are sent always, rather > than being sent never, because there's nothing to set the tag. > > If you can see log output, it's very useful to set --log-dhcp which logs > lots of stuff about what's going on with DHCP options. > > Cheers, > > Simon > > > --001517477fe63ecbc5047e7dcedd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
(resending this because the list put it on hold due to its l= arge size, so I hosted the files instead of attaching them)
=
No apologies needed, your helping me for free as fumble ar= ound trying to get this working and I appreciate it. =A0I got a little fart= her and appear to be stuck again. =A0By commenting out all of the lines for= my Non-Apple PXE boot configuration, removing the vendor class specificati= on and changing the options, the machine finally network booted my Apple Ne= tBoot set.

Here is the working configuration:
dhcp-option-force=3D43,08:0= 4:81:00:00:67
dhcp-option-force=3D60,"AAPLBSDPC/i386"
dhcp-option-force=3D17,"nfs:192.168.33.1:/var/lib/tftpboot:Diag10= 6NetBoot.nbi/NetBoot.dmg"
dhcp-option-force=3D67,"Diag1= 06NetBoot.nbi/i386/booter"

After that I chang= ed the configuration to add the vendor class specification
dhcp-vendorclass=3Dapple-boot,"APPLBSDPC/i386"
dhcp-option-force=3Dapple-boot,43,08:04:81:00:00:67
dhcp-option= -force=3Dapple-boot,60,"AAPLBSDPC/i386"
dhcp-option-for= ce=3Dapple-boot,17,"nfs:192.168.33.1:/var/lib/tftpboot:Diag106NetBoot.= nbi/NetBoot.dmg"
dhcp-option-force=3Dapple-boot,67,"Diag106NetBoot.nbi/i386/boot

I tried=A0"APPLBSDPC/i386",=A0APPLBSDPC/i= 386,=A0APPLBSDPC/i386/*,"APPLBSDPC/i386/*
None of them work.=
I have been watching the output from syslog after adding --log-d= hcp as you suggested and can see that my Mac is returning:=A0AAPLBSDPC/i386= /MacBook5,1
dnsmasq-dhcp[7702]: 24437 Vendor class: AAPLBSDPC/i38= 6/MacBook5,1
From the DNSMasq man page it looks like the vendor class option should= still match.

Any thoughts?
Linked= below is a log file with a successful boot (when there wasn't a networ= k specification based on matching vendor class substrings) and an uncessful= one (when I did have the network specification there). =A0As well as my co= nfig file with both configurations.

Thanks again!
=A0=A0 =A0 =A0Max

On Sun, Jan 31, 2010 at 11:02 AM, Simon Kelley=A0<simon at thekelleys.org.uk>=A0wrote:
Max Turkewitz wrote:
> Thanks for your quick response Simon. =A0= I had to move to a different system
> to get some diagnostic output (= DD-WRT doesn't seem to support some options
> or just isn't g= iving me output at the terminal).
>
> using the --test option I found that DNSMasq didn't like t= he line:
> dhcp-vendor=3Dapple-boot,AAPLBSDPC/i386
>
> Wi= thout that line it accepts the configuration file but my Mac will still
> not NetBoot.

Humble apologies, should be

dhcp-vend= orclass=3Dapple-boot,AAPLBSDPC/i386

(This sets the tag "apple-b= oot" which the client sends the AA.... string
as its vendorclass, t= hat's used in the other lines to only send the
apple-specific options to apple clients.

You can omit that line comp= letely, but you have to remove the
"apple-boot" tags from the = option lines so that are sent always, rather
than being sent never, beca= use there's nothing to set the tag.

If you can see log output, it's very useful to set --log-dhcp which= logs
lots of stuff about what's going on with DHCP options.

= Cheers,

Simon

=


--001517477fe63ecbc5047e7dcedd-- From bogus@does.not.exist.com Mon Sep 7 11:48:48 2009 From: bogus@does.not.exist.com () Date: Mon, 07 Sep 2009 10:48:48 -0000 Subject: No subject Message-ID: match. Any thoughts? Attached is a log file with a successful boot (when there wasn't a network specification based on matching vendor class substrings) and an uncessful one (when I did have the network specification there). As well as my config file with both configurations. Thanks again! Max On Sun, Jan 31, 2010 at 11:02 AM, Simon Kelley wrote: > Max Turkewitz wrote: > > Thanks for your quick response Simon. I had to move to a different > system > > to get some diagnostic output (DD-WRT doesn't seem to support some > options > > or just isn't giving me output at the terminal). > > > > using the --test option I found that DNSMasq didn't like the line: > > dhcp-vendor=apple-boot,AAPLBSDPC/i386 > > > > Without that line it accepts the configuration file but my Mac will still > > not NetBoot. > > Humble apologies, should be > > dhcp-vendorclass=apple-boot,AAPLBSDPC/i386 > > (This sets the tag "apple-boot" which the client sends the AA.... string > as its vendorclass, that's used in the other lines to only send the > apple-specific options to apple clients. > > You can omit that line completely, but you have to remove the > "apple-boot" tags from the option lines so that are sent always, rather > than being sent never, because there's nothing to set the tag. > > If you can see log output, it's very useful to set --log-dhcp which logs > lots of stuff about what's going on with DHCP options. > > Cheers, > > Simon > > > > I now am testing this in my virtual machine environment with > > DNSMasq to rule out any differences in the two environments (except for > the > > DHCP server) causing the problem. > > I have to step away for a couple hours, but next I will try adding: > > dhcp-option-force=apple-boot,60,AAPLBSDPCi/i386 > > > > which DNSMasq doesn't find any problems with when I run the configuration > > through DNSMasq with the --test argument. > > > > Helmut - > >> Your "root-path" option looks strange (for me): must be a directory, > > no file. > >> Is "NetBoot.dmg" a directory? > >> Is "tftpboot:Diag106NetBoot.nbi" a subdirectory? > > This is part of how Apple does its network booting. Diag106NetBoot.nbi > is a > > folder in the root directory accessible via tftp, and NetBoot.dmg is the > > root filesystem for the machine. Maybe it means the path to the root > > filesystem. > > > > Thanks guys! I'll do some more testing later and let you know how it > goes. > > -Max > > > > > > > > On Sun, Jan 31, 2010 at 7:30 AM, Simon Kelley >wrote: > > > >> Max Turkewitz wrote: > >> > >>> Hi guys, > >>> For sometime now I've been using DNSMasq off a DD-WRT router to PXE > boot > >>> machines on my network to run diagnostics and OS installers. Recently > I got > >>> the drive to set this up for my Intel Mac, I got it working with the > ISC > >>> dhcp server in my virtual machine environment, but can't seem to > understand > >>> how to translate the options to DNSMasq in order to run it on my local > >>> network. Below is the pertinent section: > >>> class "AppleNBI-i386"{ > >>> match if substring (option vendor-class-identifier, 0, 14) = > >>> "AAPLBSDPC/i386"; > >>> option dhcp-parameter-request-list 1,3,17,43,60; > >>> if (option dhcp-message-type = 1) { option vendor-class-identifier > >>> "AAPLBSDPC/i386"; } > >>> if (option dhcp-message-type = 1) { option vendor-encapsulated-options > >>> 08:04:81:00:00:67; } > >>> # The Apple Boot Loader binary image. This file will in turn TFTP the > >>> kernel image and extension cache. > >>> filename "Diag106NetBoot.nbi/i386/booter"; > >>> ## NOTE: Try to keep the root path as short as possible. I copy the DMG > >>> files to /nbi and export that folder. > >>> option root-path "nfs:192.168.33.1: > >>> /var/lib/tftpboot:Diag106NetBoot.nbi/NetBoot.dmg"; > >>> } > >>> > >>> > >> Even better: > >> > >> dhcp-vendor=apple-boot,AAPLBSDPC/i386 > >> dhcp-option-force=apple-boot,vendor:AAPLBSDPC/i386,8,81:00:00:67 > >> dhcp-option-force=apple-boot,option:root-path,"nfs:192.168.33.1: > >> /var/lib/tftpboot:Diag106NetBoot.nbi/NetBoot.dmg" > >> dhcp-boot=net:apple-boot,"Diag106NetBoot.nbi/i386/booter" > >> > >> > >> HTH > >> > >> Simon. > >> > >> This came from > http://www.afp548.com/article.php?story=20061220102102611 > >>> I was wondering if you guys could help me. So far I have: > >>> dhcp-vendorclass=AppleNBI-i386,"AAPLBSDPC/i386" > >>> dhcp-option=net:AppleNBI-i386,option-vendor,"AAPLBSDPC/i386" > >>> > >>> > dhcp-option=net:AppleNBI-i386,option:filename,"Diag106NetBoot.nbi/i386/booter" > >>> dhcp-option=net:AppleNBI-i386,option:root-path,"nfs:192.168.33.1: > >>> /var/lib/tftpboot:Diag106NetBoot.nbi/NetBoot.dmg" > >>> > >>> But this actually seems to have broken DNSMasq. Do you guys think you > can > >>> help me translate this ISC configuration to a DNSMasq configuration? > >>> If the Developers are out there on the list I really enjoy the product, > >>> thanks for the great work! > >>> > >>> -Max > >>> > >>> > >>> > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> Dnsmasq-discuss mailing list > >>> Dnsmasq-discuss at lists.thekelleys.org.uk > >>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > >>> > >> > >> > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss at lists.thekelleys.org.uk > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > --002354530710bfb2a3047e7be982 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No apologies needed, your helping me for free as fumble around trying to ge= t this working and I appreciate it. =A0I got a little farther and appear to= be stuck again. =A0By commenting out all of the lines for my Non-Apple PXE= boot configuration, removing the vendor class specification and changing t= he options, the machine finally network booted my Apple NetBoot set.

Here is the working configuration:
dhcp-optio= n-force=3D43,08:04:81:00:00:67
dhcp-option-force=3D60,"AAPLB= SDPC/i386"
dhcp-option-force=3D17,"nfs:192.168.33.1:/va= r/lib/tftpboot:Diag106NetBoot.nbi/NetBoot.dmg"
dhcp-option-force=3D67,"Diag106NetBoot.nbi/i386/booter"

After that I changed the configuration to add the vend= or class specification
dhcp-vendorclass=3Dapple-boot,"A= PPLBSDPC/i386"
dhcp-option-force=3Dapple-boot,43,08:04:81:00:00:67
dhcp-opt= ion-force=3Dapple-boot,60,"AAPLBSDPC/i386"
dhcp-option-= force=3Dapple-boot,17,"nfs:192.168.33.1:/var/lib/tftpboot:Diag106NetBo= ot.nbi/NetBoot.dmg"
dhcp-option-force=3Dapple-boot,67,"Diag106NetBoot.nbi/i386/boot

I tried=A0"APPLBSDPC/i386",=A0APPLBSDPC/i= 386,=A0APPLBSDPC/i386/*,"APPLBSDPC/i386/*
None of them work.=
I have been watching the output from syslog after adding --log-d= hcp as you suggested and can see that my Mac is returning:=A0AAPLBSDPC/i386= /MacBook5,1
dnsmasq-dhcp[7702]: 24437 Vendor class: AAPLBSDPC/i38= 6/MacBook5,1
From the DNSMasq man page it looks like the vendor class option should= still match.

Any thoughts?
Attached is = a log file with a successful boot (when there wasn't a network specific= ation based on matching vendor class substrings) and an uncessful one (when= I did have the network specification there). =A0As well as my config file = with both configurations.

Thanks again!
=A0=A0 =A0 =A0Max

On Sun, Jan 31, 2010 at 11:02 AM, Simon Kell= ey <simon at thekelleys.org.uk> wrote:
Max Turkewitz wrote:
> Thanks for your quick response Simon. =A0I had to move to a different = system
> to get some diagnostic output (DD-WRT doesn't seem to support some= options
> or just isn't giving me output at the terminal).
>
> using the --test option I found that DNSMasq didn't like the line:=
> dhcp-vendor=3Dapple-boot,AAPLBSDPC/i386
>
> Without that line it accepts the configuration file but my Mac will st= ill
> not NetBoot.

Humble apologies, should be

dhcp-vendorclass=3Dapple-boot,AAPLBSDPC/i386

(This sets the tag "apple-boot" which the client sends the AA....= string
as its vendorclass, that's used in the other lines to only send the
apple-specific options to apple clients.

You can omit that line completely, but you have to remove the
"apple-boot" tags from the option lines so that are sent always, = rather
than being sent never, because there's nothing to set the tag.

If you can see log output, it's very useful to set --log-dhcp which log= s
lots of stuff about what's going on with DHCP options.

Cheers,

Simon



=A0I now am testing this in my virtual machine environment with
> DNSMasq to rule out any differences in the two environments (except fo= r the
> DHCP server) causing the problem.
> I have to step away for a couple hours, but next I will try adding: > dhcp-option-force=3Dapple-boot,60,AAPLBSDPCi/i386
>
> which DNSMasq doesn't find any problems with when I run the config= uration
> through DNSMasq with the --test argument.
>
> Helmut -
>> Your "root-path" option looks strange (for me): must be = a directory,
> no file.
>> Is "NetBoot.dmg" a directory?
>> Is "tftpboot:Diag106NetBoot.nbi" a subdirectory?
> This is part of how Apple does its network booting. =A0Diag106NetBoot.= nbi is a
> folder in the root directory accessible via tftp, and NetBoot.dmg is t= he
> root filesystem for the machine. =A0Maybe it means the path to the roo= t
> filesystem.
>
> Thanks guys! =A0I'll do some more testing later and let you know h= ow it goes.
> -Max
>
>
>
> On Sun, Jan 31, 2010 at 7:30 AM, Simon Kelley <simon at thekelleys.org.uk>wro= te:
>
>> Max Turkewitz wrote:
>>
>>> Hi guys,
>>> =A0 For sometime now I've been using DNSMasq off a DD-WRT = router to PXE boot
>>> machines on my network to run diagnostics and OS installers. = =A0Recently I got
>>> the drive to set this up for my Intel Mac, I got it working wi= th the ISC
>>> dhcp server in my virtual machine environment, but can't s= eem to understand
>>> how to translate the options to DNSMasq in order to run it on = my local
>>> network. =A0Below is the pertinent section:
>>> class "AppleNBI-i386"{
>>> match if substring (option vendor-class-identifier, 0, 14) =3D=
>>> "AAPLBSDPC/i386";
>>> option dhcp-parameter-request-list 1,3,17,43,60;
>>> if (option dhcp-message-type =3D 1) { option vendor-class-iden= tifier
>>> "AAPLBSDPC/i386"; }
>>> if (option dhcp-message-type =3D 1) { option vendor-encapsulat= ed-options
>>> 08:04:81:00:00:67; }
>>> # The Apple Boot Loader binary image. This file will in turn T= FTP the
>>> kernel image and extension cache.
>>> filename "Diag106NetBoot.nbi/i386/booter";
>>> ## NOTE: Try to keep the root path as short as possible. I cop= y the DMG
>>> files to /nbi and export that folder.
>>> option root-path "nfs:192.168.33.1:
>>> /var/lib/tftpboot:Diag106NetBoot.nbi/NetBoot.dmg";
>>> }
>>>
>>>
>> Even better:
>>
>> dhcp-vendor=3Dapple-boot,AAPLBSDPC/i386
>> dhcp-option-force=3Dapple-boot,vendor:AAPLBSDPC/i386,8,81:00:00:67=
>> dhcp-option-force=3Dapple-boot,option:root-path,"nfs:192.168.33.1:
>> /var/lib/tftpboot:Diag106NetBoot.nbi/NetBoot.dmg"
>> dhcp-boot=3Dnet:apple-boot,"Diag106NetBoot.nbi/i386/booter&qu= ot;
>>
>>
>> HTH
>>
>> Simon.
>>
>> =A0This came from http://www.afp548.com/article.php= ?story=3D20061220102102611
>>> I was wondering if you guys could help me. =A0So far I have: >>> dhcp-vendorclass=3DAppleNBI-i386,"AAPLBSDPC/i386" >>> dhcp-option=3Dnet:AppleNBI-i386,option-vendor,"AAPLBSDPC/= i386"
>>>
>>> dhcp-option=3Dnet:AppleNBI-i386,option:filename,"Diag106N= etBoot.nbi/i386/booter"
>>> dhcp-option=3Dnet:AppleNBI-i386,option:root-path,"nfs:192.168.33.1:
>>> /var/lib/tftpboot:Diag106NetBoot.nbi/NetBoot.dmg"
>>>
>>> But this actually seems to have broken DNSMasq. =A0Do you guys= think you can
>>> help me translate this ISC configuration to a DNSMasq configur= ation?
>>> If the Developers are out there on the list I really enjoy the= product,
>>> thanks for the great work!
>>>
>>> -Max
>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------= ----------
>>>
>>> _______________________________________________
>>> Dnsmasq-discuss mailing list
>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>> http://lists.thekelleys.org.uk/mailman/list= info/dnsmasq-discuss
>>>
>>
>>
>
>
> ----------------------------------------------------------------------= --
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dns= masq-discuss


--002354530710bfb2a3047e7be982-- --002354530710bfb2b0047e7be984 Content-Type: text/plain; charset=US-ASCII; name="boot-fail.txt" Content-Disposition: attachment; filename="boot-fail.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g54ao1fm1 IyMjIyMjIyMjIyMjIyMjIyMjIyMjIwojQmVsb3cgaXMgYW4gdW5zdWNjZXNzZnVsIGJvb3QsIGFm dGVyIGEgcGVyaW9kIG9mIHRpbWUgSSBzaHV0IG9mZiB0aGUgbWFjaGluZQojcmF0aGVyIHRoYW4g bGV0IGl0IGJvb3QgdGhlIE9TIGZyb20gdGhlIGhhcmQgZHJpdmUKIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIwpKYW4gMzEgMTU6MjI6MDAgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNw WzU0NThdOiBESENQLCBJUCByYW5nZSAxOTIuMTY4LjMzLjEwMCAtLSAxOTIuMTY4LjMzLjE0OSwg bGVhc2UgdGltZSAxZApKYW4gMzEgMTU6MjI6NDMgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNw WzU0NThdOiAyODU4MiBBdmFpbGFibGUgREhDUCByYW5nZTogMTkyLjE2OC4zMy4xMDAgLS0gMTky LjE2OC4zMy4xNDkKSmFuIDMxIDE1OjIyOjQzIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1 NDU4XTogMjg1ODIgVmVuZG9yIGNsYXNzOiBBQVBMQlNEUEMvaTM4Ni9NYWNCb29rNSwxCkphbiAz MSAxNToyMjo0NiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgyIERIQ1BE SVNDT1ZFUihldGgwKSAwMDoyMzpkZjphYjo2YjozMiAKSmFuIDMxIDE1OjIyOjQ2IG1pZ2h0eWpv ZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODIgREhDUE9GRkVSKGV0aDApIDE5Mi4xNjgu MzMuMTQ4IDAwOjIzOmRmOmFiOjZiOjMyIApKYW4gMzEgMTU6MjI6NDYgbWlnaHR5am9leW91bmcg ZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MiByZXF1ZXN0ZWQgb3B0aW9uczogMTpuZXRtYXNrLCAz OnJvdXRlciwgNjc6Ym9vdGZpbGUtbmFtZSwgNDM6dmVuZG9yLWVuY2FwLCAKSmFuIDMxIDE1OjIy OjQ2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODIgcmVxdWVzdGVkIG9w dGlvbnM6IDYwOnZlbmRvci1jbGFzcwpKYW4gMzEgMTU6MjI6NDYgbWlnaHR5am9leW91bmcgZG5z bWFzcS1kaGNwWzU0NThdOiAyODU4MiB0YWdzOiBsYW4sIGV0aDAKSmFuIDMxIDE1OjIyOjQ2IG1p Z2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODIgbmV4dCBzZXJ2ZXI6IDE5Mi4x NjguMzMuMQpKYW4gMzEgMTU6MjI6NDYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThd OiAyODU4MiBzZW50IHNpemU6ICAxIG9wdGlvbjogNTM6bWVzc2FnZS10eXBlICAwMgpKYW4gMzEg MTU6MjI6NDYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MiBzZW50IHNp emU6ICA0IG9wdGlvbjogNTQ6c2VydmVyLWlkZW50aWZpZXIgIDE5Mi4xNjguMzMuMQpKYW4gMzEg MTU6MjI6NDYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MiBzZW50IHNp emU6ICA0IG9wdGlvbjogNTE6bGVhc2UtdGltZSAgMDA6MDE6NTE6ODAKSmFuIDMxIDE1OjIyOjQ2 IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODIgc2VudCBzaXplOiAgNCBv cHRpb246IDU4OlQxICAwMDowMDphODpjMApKYW4gMzEgMTU6MjI6NDYgbWlnaHR5am9leW91bmcg ZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MiBzZW50IHNpemU6ICA0IG9wdGlvbjogNTk6VDIgIDAw OjAxOjI3OjUwCkphbiAzMSAxNToyMjo0NiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1 OF06IDI4NTgyIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiAgMTpuZXRtYXNrICAyNTUuMjU1LjI1NS4w CkphbiAzMSAxNToyMjo0NiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgy IHNlbnQgc2l6ZTogIDQgb3B0aW9uOiAyODpicm9hZGNhc3QgIDE5Mi4xNjguMzMuMjU1CkphbiAz MSAxNToyMjo0NiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgyIHNlbnQg c2l6ZTogIDQgb3B0aW9uOiAgMzpyb3V0ZXIgIDE5Mi4xNjguMzMuMQpKYW4gMzEgMTU6MjI6NDYg bWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MiBBdmFpbGFibGUgREhDUCBy YW5nZTogMTkyLjE2OC4zMy4xMDAgLS0gMTkyLjE2OC4zMy4xNDkKSmFuIDMxIDE1OjIyOjQ2IG1p Z2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODIgVmVuZG9yIGNsYXNzOiBBQVBM QlNEUEMvaTM4Ni9NYWNCb29rNSwxCkphbiAzMSAxNToyMjo0NiBtaWdodHlqb2V5b3VuZyBkbnNt YXNxLWRoY3BbNTQ1OF06IDI4NTgyIERIQ1BESVNDT1ZFUihldGgwKSAwMDoyMzpkZjphYjo2Yjoz MiAKSmFuIDMxIDE1OjIyOjQ2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1 ODIgREhDUE9GRkVSKGV0aDApIDE5Mi4xNjguMzMuMTQ4IDAwOjIzOmRmOmFiOjZiOjMyIApKYW4g MzEgMTU6MjI6NDYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MiByZXF1 ZXN0ZWQgb3B0aW9uczogMTpuZXRtYXNrLCAzOnJvdXRlciwgNjc6Ym9vdGZpbGUtbmFtZSwgNDM6 dmVuZG9yLWVuY2FwLCAKSmFuIDMxIDE1OjIyOjQ2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhj cFs1NDU4XTogMjg1ODIgcmVxdWVzdGVkIG9wdGlvbnM6IDYwOnZlbmRvci1jbGFzcwpKYW4gMzEg MTU6MjI6NDYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MiB0YWdzOiBs YW4sIGV0aDAKSmFuIDMxIDE1OjIyOjQ2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4 XTogMjg1ODIgbmV4dCBzZXJ2ZXI6IDE5Mi4xNjguMzMuMQpKYW4gMzEgMTU6MjI6NDYgbWlnaHR5 am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MiBzZW50IHNpemU6ICAxIG9wdGlvbjog NTM6bWVzc2FnZS10eXBlICAwMgpKYW4gMzEgMTU6MjI6NDYgbWlnaHR5am9leW91bmcgZG5zbWFz cS1kaGNwWzU0NThdOiAyODU4MiBzZW50IHNpemU6ICA0IG9wdGlvbjogNTQ6c2VydmVyLWlkZW50 aWZpZXIgIDE5Mi4xNjguMzMuMQpKYW4gMzEgMTU6MjI6NDYgbWlnaHR5am9leW91bmcgZG5zbWFz cS1kaGNwWzU0NThdOiAyODU4MiBzZW50IHNpemU6ICA0IG9wdGlvbjogNTE6bGVhc2UtdGltZSAg MDA6MDE6NTE6ODAKSmFuIDMxIDE1OjIyOjQ2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1 NDU4XTogMjg1ODIgc2VudCBzaXplOiAgNCBvcHRpb246IDU4OlQxICAwMDowMDphODpjMApKYW4g MzEgMTU6MjI6NDYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MiBzZW50 IHNpemU6ICA0IG9wdGlvbjogNTk6VDIgIDAwOjAxOjI3OjUwCkphbiAzMSAxNToyMjo0NiBtaWdo dHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgyIHNlbnQgc2l6ZTogIDQgb3B0aW9u OiAgMTpuZXRtYXNrICAyNTUuMjU1LjI1NS4wCkphbiAzMSAxNToyMjo0NiBtaWdodHlqb2V5b3Vu ZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgyIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiAyODpicm9h ZGNhc3QgIDE5Mi4xNjguMzMuMjU1CkphbiAzMSAxNToyMjo0NiBtaWdodHlqb2V5b3VuZyBkbnNt YXNxLWRoY3BbNTQ1OF06IDI4NTgyIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiAgMzpyb3V0ZXIgIDE5 Mi4xNjguMzMuMQpKYW4gMzEgMTU6MjI6NDcgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0 NThdOiAyODU4MiBBdmFpbGFibGUgREhDUCByYW5nZTogMTkyLjE2OC4zMy4xMDAgLS0gMTkyLjE2 OC4zMy4xNDkKSmFuIDMxIDE1OjIyOjQ3IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4 XTogMjg1ODIgVmVuZG9yIGNsYXNzOiBBQVBMQlNEUEMvaTM4Ni9NYWNCb29rNSwxCkphbiAzMSAx NToyMjo0NyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgyIERIQ1BSRVFV RVNUKGV0aDApIDE5Mi4xNjguMzMuMTQ4IDAwOjIzOmRmOmFiOjZiOjMyIApKYW4gMzEgMTU6MjI6 NDcgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MiBESENQQUNLKGV0aDAp IDE5Mi4xNjguMzMuMTQ4IDAwOjIzOmRmOmFiOjZiOjMyIApKYW4gMzEgMTU6MjI6NDcgbWlnaHR5 am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MiByZXF1ZXN0ZWQgb3B0aW9uczogMTpu ZXRtYXNrLCAzOnJvdXRlciwgNjc6Ym9vdGZpbGUtbmFtZSwgNDM6dmVuZG9yLWVuY2FwLCAKSmFu IDMxIDE1OjIyOjQ3IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODIgcmVx dWVzdGVkIG9wdGlvbnM6IDYwOnZlbmRvci1jbGFzcwpKYW4gMzEgMTU6MjI6NDcgbWlnaHR5am9l eW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MiB0YWdzOiBsYW4sIGV0aDAKSmFuIDMxIDE1 OjIyOjQ3IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODIgbmV4dCBzZXJ2 ZXI6IDE5Mi4xNjguMzMuMQpKYW4gMzEgMTU6MjI6NDcgbWlnaHR5am9leW91bmcgZG5zbWFzcS1k aGNwWzU0NThdOiAyODU4MiBzZW50IHNpemU6ICAxIG9wdGlvbjogNTM6bWVzc2FnZS10eXBlICAw NQpKYW4gMzEgMTU6MjI6NDcgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4 MiBzZW50IHNpemU6ICA0IG9wdGlvbjogNTQ6c2VydmVyLWlkZW50aWZpZXIgIDE5Mi4xNjguMzMu MQpKYW4gMzEgMTU6MjI6NDcgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4 MiBzZW50IHNpemU6ICA0IG9wdGlvbjogNTE6bGVhc2UtdGltZSAgMDA6MDE6NTE6ODAKSmFuIDMx IDE1OjIyOjQ3IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODIgc2VudCBz aXplOiAgNCBvcHRpb246IDU4OlQxICAwMDowMDphODpjMApKYW4gMzEgMTU6MjI6NDcgbWlnaHR5 am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MiBzZW50IHNpemU6ICA0IG9wdGlvbjog NTk6VDIgIDAwOjAxOjI3OjUwCkphbiAzMSAxNToyMjo0NyBtaWdodHlqb2V5b3VuZyBkbnNtYXNx LWRoY3BbNTQ1OF06IDI4NTgyIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiAgMTpuZXRtYXNrICAyNTUu MjU1LjI1NS4wCkphbiAzMSAxNToyMjo0NyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1 OF06IDI4NTgyIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiAyODpicm9hZGNhc3QgIDE5Mi4xNjguMzMu MjU1CkphbiAzMSAxNToyMjo0NyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4 NTgyIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiAgMzpyb3V0ZXIgIDE5Mi4xNjguMzMuMQpKYW4gMzEg MTU6MjI6NDggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MyBBdmFpbGFi bGUgREhDUCByYW5nZTogMTkyLjE2OC4zMy4xMDAgLS0gMTkyLjE2OC4zMy4xNDkKSmFuIDMxIDE1 OjIyOjQ4IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODMgVmVuZG9yIGNs YXNzOiBBQVBMQlNEUEMvaTM4Ni9NYWNCb29rNSwxCkphbiAzMSAxNToyMjo0OCBtaWdodHlqb2V5 b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgzIERIQ1BJTkZPUk0oZXRoMCkgMTkyLjE2OC4z My4xNDggMDA6MjM6ZGY6YWI6NmI6MzIgCkphbiAzMSAxNToyMjo0OCBtaWdodHlqb2V5b3VuZyBk bnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgzIERIQ1BBQ0soZXRoMCkgMTkyLjE2OC4zMy4xNDggMDA6 MjM6ZGY6YWI6NmI6MzIgCkphbiAzMSAxNToyMjo0OCBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRo Y3BbNTQ1OF06IDI4NTgzIHJlcXVlc3RlZCBvcHRpb25zOiA0Mzp2ZW5kb3ItZW5jYXAsIDYwOnZl bmRvci1jbGFzcwpKYW4gMzEgMTU6MjI6NDggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0 NThdOiAyODU4MyB0YWdzOiBsYW4sIGV0aDAKSmFuIDMxIDE1OjIyOjQ4IG1pZ2h0eWpvZXlvdW5n IGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODMgbmV4dCBzZXJ2ZXI6IDE5Mi4xNjguMzMuMQpKYW4g MzEgMTU6MjI6NDggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MyBzZW50 IHNpemU6ICAxIG9wdGlvbjogNTM6bWVzc2FnZS10eXBlICAwNQpKYW4gMzEgMTU6MjI6NDggbWln aHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MyBzZW50IHNpemU6ICA0IG9wdGlv bjogNTQ6c2VydmVyLWlkZW50aWZpZXIgIDE5Mi4xNjguMzMuMQpKYW4gMzEgMTU6MjI6NDggbWln aHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MyBzZW50IHNpemU6ICA0IG9wdGlv bjogNTE6bGVhc2UtdGltZSAgMDA6MDE6NTE6N2YKSmFuIDMxIDE1OjIyOjQ4IG1pZ2h0eWpvZXlv dW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODMgc2VudCBzaXplOiAgNCBvcHRpb246ICAxOm5l dG1hc2sgIDI1NS4yNTUuMjU1LjAKSmFuIDMxIDE1OjIyOjQ4IG1pZ2h0eWpvZXlvdW5nIGRuc21h c3EtZGhjcFs1NDU4XTogMjg1ODMgc2VudCBzaXplOiAgNCBvcHRpb246IDI4OmJyb2FkY2FzdCAg MTkyLjE2OC4zMy4yNTUKSmFuIDMxIDE1OjIyOjQ5IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhj cFs1NDU4XTogMjg1ODMgQXZhaWxhYmxlIERIQ1AgcmFuZ2U6IDE5Mi4xNjguMzMuMTAwIC0tIDE5 Mi4xNjguMzMuMTQ5CkphbiAzMSAxNToyMjo0OSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3Bb NTQ1OF06IDI4NTgzIFZlbmRvciBjbGFzczogQUFQTEJTRFBDL2kzODYvTWFjQm9vazUsMQpKYW4g MzEgMTU6MjI6NDkgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MyBESENQ SU5GT1JNKGV0aDApIDE5Mi4xNjguMzMuMTQ4IDAwOjIzOmRmOmFiOjZiOjMyIApKYW4gMzEgMTU6 MjI6NDkgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MyBESENQQUNLKGV0 aDApIDE5Mi4xNjguMzMuMTQ4IDAwOjIzOmRmOmFiOjZiOjMyIApKYW4gMzEgMTU6MjI6NDkgbWln aHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MyByZXF1ZXN0ZWQgb3B0aW9uczog NDM6dmVuZG9yLWVuY2FwLCA2MDp2ZW5kb3ItY2xhc3MKSmFuIDMxIDE1OjIyOjQ5IG1pZ2h0eWpv ZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODMgdGFnczogbGFuLCBldGgwCkphbiAzMSAx NToyMjo0OSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgzIG5leHQgc2Vy dmVyOiAxOTIuMTY4LjMzLjEKSmFuIDMxIDE1OjIyOjQ5IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3Et ZGhjcFs1NDU4XTogMjg1ODMgc2VudCBzaXplOiAgMSBvcHRpb246IDUzOm1lc3NhZ2UtdHlwZSAg MDUKSmFuIDMxIDE1OjIyOjQ5IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1 ODMgc2VudCBzaXplOiAgNCBvcHRpb246IDU0OnNlcnZlci1pZGVudGlmaWVyICAxOTIuMTY4LjMz LjEKSmFuIDMxIDE1OjIyOjQ5IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1 ODMgc2VudCBzaXplOiAgNCBvcHRpb246IDUxOmxlYXNlLXRpbWUgIDAwOjAxOjUxOjdlCkphbiAz MSAxNToyMjo0OSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgzIHNlbnQg c2l6ZTogIDQgb3B0aW9uOiAgMTpuZXRtYXNrICAyNTUuMjU1LjI1NS4wCkphbiAzMSAxNToyMjo0 OSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgzIHNlbnQgc2l6ZTogIDQg b3B0aW9uOiAyODpicm9hZGNhc3QgIDE5Mi4xNjguMzMuMjU1CkphbiAzMSAxNToyMjo1MSBtaWdo dHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgzIEF2YWlsYWJsZSBESENQIHJhbmdl OiAxOTIuMTY4LjMzLjEwMCAtLSAxOTIuMTY4LjMzLjE0OQpKYW4gMzEgMTU6MjI6NTEgbWlnaHR5 am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MyBWZW5kb3IgY2xhc3M6IEFBUExCU0RQ Qy9pMzg2L01hY0Jvb2s1LDEKSmFuIDMxIDE1OjIyOjUxIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3Et ZGhjcFs1NDU4XTogMjg1ODMgREhDUElORk9STShldGgwKSAxOTIuMTY4LjMzLjE0OCAwMDoyMzpk ZjphYjo2YjozMiAKSmFuIDMxIDE1OjIyOjUxIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1 NDU4XTogMjg1ODMgREhDUEFDSyhldGgwKSAxOTIuMTY4LjMzLjE0OCAwMDoyMzpkZjphYjo2Yjoz MiAKSmFuIDMxIDE1OjIyOjUxIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1 ODMgcmVxdWVzdGVkIG9wdGlvbnM6IDQzOnZlbmRvci1lbmNhcCwgNjA6dmVuZG9yLWNsYXNzCkph biAzMSAxNToyMjo1MSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgzIHRh Z3M6IGxhbiwgZXRoMApKYW4gMzEgMTU6MjI6NTEgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNw WzU0NThdOiAyODU4MyBuZXh0IHNlcnZlcjogMTkyLjE2OC4zMy4xCkphbiAzMSAxNToyMjo1MSBt aWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgzIHNlbnQgc2l6ZTogIDEgb3B0 aW9uOiA1MzptZXNzYWdlLXR5cGUgIDA1CkphbiAzMSAxNToyMjo1MSBtaWdodHlqb2V5b3VuZyBk bnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgzIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiA1NDpzZXJ2ZXIt aWRlbnRpZmllciAgMTkyLjE2OC4zMy4xCkphbiAzMSAxNToyMjo1MSBtaWdodHlqb2V5b3VuZyBk bnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgzIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiA1MTpsZWFzZS10 aW1lICAwMDowMTo1MTo3YwpKYW4gMzEgMTU6MjI6NTEgbWlnaHR5am9leW91bmcgZG5zbWFzcS1k aGNwWzU0NThdOiAyODU4MyBzZW50IHNpemU6ICA0IG9wdGlvbjogIDE6bmV0bWFzayAgMjU1LjI1 NS4yNTUuMApKYW4gMzEgMTU6MjI6NTEgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThd OiAyODU4MyBzZW50IHNpemU6ICA0IG9wdGlvbjogMjg6YnJvYWRjYXN0ICAxOTIuMTY4LjMzLjI1 NQpKYW4gMzEgMTU6MjI6NTUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4 MyBBdmFpbGFibGUgREhDUCByYW5nZTogMTkyLjE2OC4zMy4xMDAgLS0gMTkyLjE2OC4zMy4xNDkK SmFuIDMxIDE1OjIyOjU1IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODMg VmVuZG9yIGNsYXNzOiBBQVBMQlNEUEMvaTM4Ni9NYWNCb29rNSwxCkphbiAzMSAxNToyMjo1NSBt aWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgzIERIQ1BJTkZPUk0oZXRoMCkg MTkyLjE2OC4zMy4xNDggMDA6MjM6ZGY6YWI6NmI6MzIgCkphbiAzMSAxNToyMjo1NSBtaWdodHlq b2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgzIERIQ1BBQ0soZXRoMCkgMTkyLjE2OC4z My4xNDggMDA6MjM6ZGY6YWI6NmI6MzIgCkphbiAzMSAxNToyMjo1NSBtaWdodHlqb2V5b3VuZyBk bnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgzIHJlcXVlc3RlZCBvcHRpb25zOiA0Mzp2ZW5kb3ItZW5j YXAsIDYwOnZlbmRvci1jbGFzcwpKYW4gMzEgMTU6MjI6NTUgbWlnaHR5am9leW91bmcgZG5zbWFz cS1kaGNwWzU0NThdOiAyODU4MyB0YWdzOiBsYW4sIGV0aDAKSmFuIDMxIDE1OjIyOjU1IG1pZ2h0 eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODMgbmV4dCBzZXJ2ZXI6IDE5Mi4xNjgu MzMuMQpKYW4gMzEgMTU6MjI6NTUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAy ODU4MyBzZW50IHNpemU6ICAxIG9wdGlvbjogNTM6bWVzc2FnZS10eXBlICAwNQpKYW4gMzEgMTU6 MjI6NTUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MyBzZW50IHNpemU6 ICA0IG9wdGlvbjogNTQ6c2VydmVyLWlkZW50aWZpZXIgIDE5Mi4xNjguMzMuMQpKYW4gMzEgMTU6 MjI6NTUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MyBzZW50IHNpemU6 ICA0IG9wdGlvbjogNTE6bGVhc2UtdGltZSAgMDA6MDE6NTE6NzgKSmFuIDMxIDE1OjIyOjU1IG1p Z2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODMgc2VudCBzaXplOiAgNCBvcHRp b246ICAxOm5ldG1hc2sgIDI1NS4yNTUuMjU1LjAKSmFuIDMxIDE1OjIyOjU1IG1pZ2h0eWpvZXlv dW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODMgc2VudCBzaXplOiAgNCBvcHRpb246IDI4OmJy b2FkY2FzdCAgMTkyLjE2OC4zMy4yNTUKSmFuIDMxIDE1OjIzOjAzIG1pZ2h0eWpvZXlvdW5nIGRu c21hc3EtZGhjcFs1NDU4XTogMjg1ODMgQXZhaWxhYmxlIERIQ1AgcmFuZ2U6IDE5Mi4xNjguMzMu MTAwIC0tIDE5Mi4xNjguMzMuMTQ5CkphbiAzMSAxNToyMzowMyBtaWdodHlqb2V5b3VuZyBkbnNt YXNxLWRoY3BbNTQ1OF06IDI4NTgzIFZlbmRvciBjbGFzczogQUFQTEJTRFBDL2kzODYvTWFjQm9v azUsMQpKYW4gMzEgMTU6MjM6MDMgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAy ODU4MyBESENQSU5GT1JNKGV0aDApIDE5Mi4xNjguMzMuMTQ4IDAwOjIzOmRmOmFiOjZiOjMyIApK YW4gMzEgMTU6MjM6MDMgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MyBE SENQQUNLKGV0aDApIDE5Mi4xNjguMzMuMTQ4IDAwOjIzOmRmOmFiOjZiOjMyIApKYW4gMzEgMTU6 MjM6MDMgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODU4MyByZXF1ZXN0ZWQg b3B0aW9uczogNDM6dmVuZG9yLWVuY2FwLCA2MDp2ZW5kb3ItY2xhc3MKSmFuIDMxIDE1OjIzOjAz IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODMgdGFnczogbGFuLCBldGgw CkphbiAzMSAxNToyMzowMyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgz IG5leHQgc2VydmVyOiAxOTIuMTY4LjMzLjEKSmFuIDMxIDE1OjIzOjAzIG1pZ2h0eWpvZXlvdW5n IGRuc21hc3EtZGhjcFs1NDU4XTogMjg1ODMgc2VudCBzaXplOiAgMSBvcHRpb246IDUzOm1lc3Nh Z2UtdHlwZSAgMDUKSmFuIDMxIDE1OjIzOjAzIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1 NDU4XTogMjg1ODMgc2VudCBzaXplOiAgNCBvcHRpb246IDU0OnNlcnZlci1pZGVudGlmaWVyICAx OTIuMTY4LjMzLjEKSmFuIDMxIDE1OjIzOjAzIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1 NDU4XTogMjg1ODMgc2VudCBzaXplOiAgNCBvcHRpb246IDUxOmxlYXNlLXRpbWUgIDAwOjAxOjUx OjcwCkphbiAzMSAxNToyMzowMyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4 NTgzIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiAgMTpuZXRtYXNrICAyNTUuMjU1LjI1NS4wCkphbiAz MSAxNToyMzowMyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NTgzIHNlbnQg c2l6ZTogIDQgb3B0aW9uOiAyODpicm9hZGNhc3QgIDE5Mi4xNjguMzMuMjU1CkphbiAzMSAxNToy MzoxOSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDMzOTYyNzIxMjggQXZhaWxh YmxlIERIQ1AgcmFuZ2U6IDE5Mi4xNjguMzMuMTAwIC0tIDE5Mi4xNjguMzMuMTQ5CkphbiAzMSAx NToyMzoxOSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDMzOTYyNzIxMjggVmVu ZG9yIGNsYXNzOiBQWEVDbGllbnQ6QXJjaDowMDAwMDpVTkRJOjAwMzAxNgpKYW4gMzEgMTU6MjM6 MTkgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAzMzk2MjcyMTI4IERIQ1BESVND T1ZFUihldGgwKSAwMDoyMzpkZjphYjo2YjozMiAKSmFuIDMxIDE1OjIzOjE5IG1pZ2h0eWpvZXlv dW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMzM5NjI3MjEyOCBESENQT0ZGRVIoZXRoMCkgMTkyLjE2 OC4zMy4xNDggMDA6MjM6ZGY6YWI6NmI6MzIgCkphbiAzMSAxNToyMzoxOSBtaWdodHlqb2V5b3Vu ZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDMzOTYyNzIxMjggcmVxdWVzdGVkIG9wdGlvbnM6IDE6bmV0 bWFzaywgMjp0aW1lLW9mZnNldCwgMzpyb3V0ZXIsIDQsIDUsIApKYW4gMzEgMTU6MjM6MTkgbWln aHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAzMzk2MjcyMTI4IHJlcXVlc3RlZCBvcHRp b25zOiA2OmRucy1zZXJ2ZXIsIDEyOmhvc3RuYW1lLCAxMzpib290LWZpbGUtc2l6ZSwgCkphbiAz MSAxNToyMzoxOSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDMzOTYyNzIxMjgg cmVxdWVzdGVkIG9wdGlvbnM6IDE1OmRvbWFpbi1uYW1lLCAxNzpyb290LXBhdGgsIDE4OmV4dGVu c2lvbi1wYXRoLCAKSmFuIDMxIDE1OjIzOjE5IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1 NDU4XTogMzM5NjI3MjEyOCByZXF1ZXN0ZWQgb3B0aW9uczogMjI6bWF4LWRhdGFncmFtLXJlYXNz ZW1ibHksIDIzOmRlZmF1bHQtdHRsLCAKSmFuIDMxIDE1OjIzOjE5IG1pZ2h0eWpvZXlvdW5nIGRu c21hc3EtZGhjcFs1NDU4XTogMzM5NjI3MjEyOCByZXF1ZXN0ZWQgb3B0aW9uczogMjg6YnJvYWRj YXN0LCA0MDpuaXMtZG9tYWluLCA0MTpuaXMtc2VydmVyLCAKSmFuIDMxIDE1OjIzOjE5IG1pZ2h0 eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMzM5NjI3MjEyOCByZXF1ZXN0ZWQgb3B0aW9u czogNDI6bnRwLXNlcnZlciwgNDM6dmVuZG9yLWVuY2FwLCA1MDpyZXF1ZXN0ZWQtYWRkcmVzcywg CkphbiAzMSAxNToyMzoxOSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDMzOTYy NzIxMjggcmVxdWVzdGVkIG9wdGlvbnM6IDUxOmxlYXNlLXRpbWUsIDU0OnNlcnZlci1pZGVudGlm aWVyLCA1ODpUMSwgCkphbiAzMSAxNToyMzoxOSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3Bb NTQ1OF06IDMzOTYyNzIxMjggcmVxdWVzdGVkIG9wdGlvbnM6IDU5OlQyLCA2MDp2ZW5kb3ItY2xh c3MsIDY2OnRmdHAtc2VydmVyLCA2Nzpib290ZmlsZS1uYW1lLCAKSmFuIDMxIDE1OjIzOjE5IG1p Z2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMzM5NjI3MjEyOCByZXF1ZXN0ZWQgb3B0 aW9uczogOTc6Y2xpZW50LW1hY2hpbmUtaWQsIDEyOCwgMTI5LCAxMzAsIDEzMSwgCkphbiAzMSAx NToyMzoxOSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDMzOTYyNzIxMjggcmVx dWVzdGVkIG9wdGlvbnM6IDEzMiwgMTMzLCAxMzQsIDEzNQpKYW4gMzEgMTU6MjM6MTkgbWlnaHR5 am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAzMzk2MjcyMTI4IHRhZ3M6IGxhbiwgZXRoMApK YW4gMzEgMTU6MjM6MTkgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAzMzk2Mjcy MTI4IG5leHQgc2VydmVyOiAxOTIuMTY4LjMzLjEKSmFuIDMxIDE1OjIzOjE5IG1pZ2h0eWpvZXlv dW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMzM5NjI3MjEyOCBzZW50IHNpemU6ICAxIG9wdGlvbjog NTM6bWVzc2FnZS10eXBlICAwMgpKYW4gMzEgMTU6MjM6MTkgbWlnaHR5am9leW91bmcgZG5zbWFz cS1kaGNwWzU0NThdOiAzMzk2MjcyMTI4IHNlbnQgc2l6ZTogIDQgb3B0aW9uOiA1NDpzZXJ2ZXIt aWRlbnRpZmllciAgMTkyLjE2OC4zMy4xCkphbiAzMSAxNToyMzoxOSBtaWdodHlqb2V5b3VuZyBk bnNtYXNxLWRoY3BbNTQ1OF06IDMzOTYyNzIxMjggc2VudCBzaXplOiAgNCBvcHRpb246IDUxOmxl YXNlLXRpbWUgIDAwOjAxOjUxOjgwCkphbiAzMSAxNToyMzoxOSBtaWdodHlqb2V5b3VuZyBkbnNt YXNxLWRoY3BbNTQ1OF06IDMzOTYyNzIxMjggc2VudCBzaXplOiAgNCBvcHRpb246IDU4OlQxICAw MDowMDphODpjMApKYW4gMzEgMTU6MjM6MTkgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0 NThdOiAzMzk2MjcyMTI4IHNlbnQgc2l6ZTogIDQgb3B0aW9uOiA1OTpUMiAgMDA6MDE6Mjc6NTAK SmFuIDMxIDE1OjIzOjE5IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMzM5NjI3 MjEyOCBzZW50IHNpemU6ICA0IG9wdGlvbjogIDE6bmV0bWFzayAgMjU1LjI1NS4yNTUuMApKYW4g MzEgMTU6MjM6MTkgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAzMzk2MjcyMTI4 IHNlbnQgc2l6ZTogIDQgb3B0aW9uOiAyODpicm9hZGNhc3QgIDE5Mi4xNjguMzMuMjU1CkphbiAz MSAxNToyMzoxOSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDMzOTYyNzIxMjgg c2VudCBzaXplOiAgOCBvcHRpb246ICA2OmRucy1zZXJ2ZXIgIDY4Ljg3LjcxLjIyNiwgNjguODcu NzMuMjQyCkphbiAzMSAxNToyMzoxOSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06 IDMzOTYyNzIxMjggc2VudCBzaXplOiAgNCBvcHRpb246ICAzOnJvdXRlciAgMTkyLjE2OC4zMy4x CkphbiAzMSAxNToyMzoxOSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDMzOTYy NzIxMjggc2VudCBzaXplOiAgOSBvcHRpb246IDYwOnZlbmRvci1jbGFzcyAgNTA6NTg6NDU6NDM6 NmM6Njk6NjU6NmU6NzQKSmFuIDMxIDE1OjIzOjE5IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhj cFs1NDU4XTogMzM5NjI3MjEyOCBzZW50IHNpemU6IDE3IG9wdGlvbjogOTc6Y2xpZW50LW1hY2hp bmUtaWQgIDAwOjIwOjBhOjU0OjYyOjA2OjlhOmRiOjRmOjkwOmMxOjkzOjBkLi4uCkphbiAzMSAx NToyMzoxOSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDMzOTYyNzIxMjggc2Vu dCBzaXplOiAxMCBvcHRpb246IDQzOnZlbmRvci1lbmNhcCAgMDY6MDE6MDg6MGE6MDQ6MDA6NTA6 NTg6NDU6ZmYKSmFuIDMxIDE1OjIzOjIwIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4 XTogMjQ3MDM3OTUyMCBBdmFpbGFibGUgREhDUCByYW5nZTogMTkyLjE2OC4zMy4xMDAgLS0gMTky LjE2OC4zMy4xNDkKSmFuIDMxIDE1OjIzOjIwIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1 NDU4XTogMjQ3MDM3OTUyMCBWZW5kb3IgY2xhc3M6IFBYRUNsaWVudDpBcmNoOjAwMDAwOlVOREk6 MDAzMDE2CkphbiAzMSAxNToyMzoyMCBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06 IDI0NzAzNzk1MjAgREhDUERJU0NPVkVSKGV0aDApIDAwOjIzOmRmOmFiOjZiOjMyIApKYW4gMzEg MTU6MjM6MjAgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyNDcwMzc5NTIwIERI Q1BPRkZFUihldGgwKSAxOTIuMTY4LjMzLjE0OCAwMDoyMzpkZjphYjo2YjozMiAKSmFuIDMxIDE1 OjIzOjIwIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjQ3MDM3OTUyMCByZXF1 ZXN0ZWQgb3B0aW9uczogMTpuZXRtYXNrLCAyOnRpbWUtb2Zmc2V0LCAzOnJvdXRlciwgNCwgNSwg CkphbiAzMSAxNToyMzoyMCBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI0NzAz Nzk1MjAgcmVxdWVzdGVkIG9wdGlvbnM6IDY6ZG5zLXNlcnZlciwgMTI6aG9zdG5hbWUsIDEzOmJv b3QtZmlsZS1zaXplLCAKSmFuIDMxIDE1OjIzOjIwIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhj cFs1NDU4XTogMjQ3MDM3OTUyMCByZXF1ZXN0ZWQgb3B0aW9uczogMTU6ZG9tYWluLW5hbWUsIDE3 OnJvb3QtcGF0aCwgMTg6ZXh0ZW5zaW9uLXBhdGgsIApKYW4gMzEgMTU6MjM6MjAgbWlnaHR5am9l eW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyNDcwMzc5NTIwIHJlcXVlc3RlZCBvcHRpb25zOiAy MjptYXgtZGF0YWdyYW0tcmVhc3NlbWJseSwgMjM6ZGVmYXVsdC10dGwsIApKYW4gMzEgMTU6MjM6 MjAgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyNDcwMzc5NTIwIHJlcXVlc3Rl ZCBvcHRpb25zOiAyODpicm9hZGNhc3QsIDQwOm5pcy1kb21haW4sIDQxOm5pcy1zZXJ2ZXIsIApK YW4gMzEgMTU6MjM6MjAgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyNDcwMzc5 NTIwIHJlcXVlc3RlZCBvcHRpb25zOiA0MjpudHAtc2VydmVyLCA0Mzp2ZW5kb3ItZW5jYXAsIDUw OnJlcXVlc3RlZC1hZGRyZXNzLCAKSmFuIDMxIDE1OjIzOjIwIG1pZ2h0eWpvZXlvdW5nIGRuc21h c3EtZGhjcFs1NDU4XTogMjQ3MDM3OTUyMCByZXF1ZXN0ZWQgb3B0aW9uczogNTE6bGVhc2UtdGlt ZSwgNTQ6c2VydmVyLWlkZW50aWZpZXIsIDU4OlQxLCAKSmFuIDMxIDE1OjIzOjIwIG1pZ2h0eWpv ZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjQ3MDM3OTUyMCByZXF1ZXN0ZWQgb3B0aW9uczog NTk6VDIsIDYwOnZlbmRvci1jbGFzcywgNjY6dGZ0cC1zZXJ2ZXIsIDY3OmJvb3RmaWxlLW5hbWUs IApKYW4gMzEgMTU6MjM6MjAgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyNDcw Mzc5NTIwIHJlcXVlc3RlZCBvcHRpb25zOiA5NzpjbGllbnQtbWFjaGluZS1pZCwgMTI4LCAxMjks IDEzMCwgMTMxLCAKSmFuIDMxIDE1OjIzOjIwIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1 NDU4XTogMjQ3MDM3OTUyMCByZXF1ZXN0ZWQgb3B0aW9uczogMTMyLCAxMzMsIDEzNCwgMTM1Ckph biAzMSAxNToyMzoyMCBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI0NzAzNzk1 MjAgdGFnczogbGFuLCBldGgwCkphbiAzMSAxNToyMzoyMCBtaWdodHlqb2V5b3VuZyBkbnNtYXNx LWRoY3BbNTQ1OF06IDI0NzAzNzk1MjAgbmV4dCBzZXJ2ZXI6IDE5Mi4xNjguMzMuMQpKYW4gMzEg MTU6MjM6MjAgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyNDcwMzc5NTIwIHNl bnQgc2l6ZTogIDEgb3B0aW9uOiA1MzptZXNzYWdlLXR5cGUgIDAyCkphbiAzMSAxNToyMzoyMCBt aWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI0NzAzNzk1MjAgc2VudCBzaXplOiAg NCBvcHRpb246IDU0OnNlcnZlci1pZGVudGlmaWVyICAxOTIuMTY4LjMzLjEKSmFuIDMxIDE1OjIz OjIwIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjQ3MDM3OTUyMCBzZW50IHNp emU6ICA0IG9wdGlvbjogNTE6bGVhc2UtdGltZSAgMDA6MDE6NTE6ODAKSmFuIDMxIDE1OjIzOjIw IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjQ3MDM3OTUyMCBzZW50IHNpemU6 ICA0IG9wdGlvbjogNTg6VDEgIDAwOjAwOmE4OmMwCkphbiAzMSAxNToyMzoyMCBtaWdodHlqb2V5 b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI0NzAzNzk1MjAgc2VudCBzaXplOiAgNCBvcHRpb246 IDU5OlQyICAwMDowMToyNzo1MApKYW4gMzEgMTU6MjM6MjAgbWlnaHR5am9leW91bmcgZG5zbWFz cS1kaGNwWzU0NThdOiAyNDcwMzc5NTIwIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiAgMTpuZXRtYXNr ICAyNTUuMjU1LjI1NS4wCkphbiAzMSAxNToyMzoyMCBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRo Y3BbNTQ1OF06IDI0NzAzNzk1MjAgc2VudCBzaXplOiAgNCBvcHRpb246IDI4OmJyb2FkY2FzdCAg MTkyLjE2OC4zMy4yNTUKSmFuIDMxIDE1OjIzOjIwIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhj cFs1NDU4XTogMjQ3MDM3OTUyMCBzZW50IHNpemU6ICA4IG9wdGlvbjogIDY6ZG5zLXNlcnZlciAg NjguODcuNzEuMjI2LCA2OC44Ny43My4yNDIKSmFuIDMxIDE1OjIzOjIwIG1pZ2h0eWpvZXlvdW5n IGRuc21hc3EtZGhjcFs1NDU4XTogMjQ3MDM3OTUyMCBzZW50IHNpemU6ICA0IG9wdGlvbjogIDM6 cm91dGVyICAxOTIuMTY4LjMzLjEKSmFuIDMxIDE1OjIzOjIwIG1pZ2h0eWpvZXlvdW5nIGRuc21h c3EtZGhjcFs1NDU4XTogMjQ3MDM3OTUyMCBzZW50IHNpemU6ICA5IG9wdGlvbjogNjA6dmVuZG9y LWNsYXNzICA1MDo1ODo0NTo0Mzo2Yzo2OTo2NTo2ZTo3NApKYW4gMzEgMTU6MjM6MjAgbWlnaHR5 am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyNDcwMzc5NTIwIHNlbnQgc2l6ZTogMTcgb3B0 aW9uOiA5NzpjbGllbnQtbWFjaGluZS1pZCAgMDA6MjA6MGE6NTQ6NjI6MDY6OWE6ZGI6NGY6OTA6 YzE6OTM6MGQuLi4KSmFuIDMxIDE1OjIzOjIwIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1 NDU4XTogMjQ3MDM3OTUyMCBzZW50IHNpemU6IDEwIG9wdGlvbjogNDM6dmVuZG9yLWVuY2FwICAw NjowMTowODowYTowNDowMDo1MDo1ODo0NTpmZgpKYW4gMzEgMTU6MjM6MjIgbWlnaHR5am9leW91 bmcgZG5zbWFzcS1kaGNwWzU0NThdOiA4Mjc0NTc1MzYgQXZhaWxhYmxlIERIQ1AgcmFuZ2U6IDE5 Mi4xNjguMzMuMTAwIC0tIDE5Mi4xNjguMzMuMTQ5CkphbiAzMSAxNToyMzoyMiBtaWdodHlqb2V5 b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDgyNzQ1NzUzNiBWZW5kb3IgY2xhc3M6IFBYRUNsaWVu dDpBcmNoOjAwMDAwOlVOREk6MDAzMDE2CkphbiAzMSAxNToyMzoyMiBtaWdodHlqb2V5b3VuZyBk bnNtYXNxLWRoY3BbNTQ1OF06IDgyNzQ1NzUzNiBESENQRElTQ09WRVIoZXRoMCkgMDA6MjM6ZGY6 YWI6NmI6MzIgCkphbiAzMSAxNToyMzoyMiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1 OF06IDgyNzQ1NzUzNiBESENQT0ZGRVIoZXRoMCkgMTkyLjE2OC4zMy4xNDggMDA6MjM6ZGY6YWI6 NmI6MzIgCkphbiAzMSAxNToyMzoyMiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06 IDgyNzQ1NzUzNiByZXF1ZXN0ZWQgb3B0aW9uczogMTpuZXRtYXNrLCAyOnRpbWUtb2Zmc2V0LCAz OnJvdXRlciwgNCwgNSwgCkphbiAzMSAxNToyMzoyMiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRo Y3BbNTQ1OF06IDgyNzQ1NzUzNiByZXF1ZXN0ZWQgb3B0aW9uczogNjpkbnMtc2VydmVyLCAxMjpo b3N0bmFtZSwgMTM6Ym9vdC1maWxlLXNpemUsIApKYW4gMzEgMTU6MjM6MjIgbWlnaHR5am9leW91 bmcgZG5zbWFzcS1kaGNwWzU0NThdOiA4Mjc0NTc1MzYgcmVxdWVzdGVkIG9wdGlvbnM6IDE1OmRv bWFpbi1uYW1lLCAxNzpyb290LXBhdGgsIDE4OmV4dGVuc2lvbi1wYXRoLCAKSmFuIDMxIDE1OjIz OjIyIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogODI3NDU3NTM2IHJlcXVlc3Rl ZCBvcHRpb25zOiAyMjptYXgtZGF0YWdyYW0tcmVhc3NlbWJseSwgMjM6ZGVmYXVsdC10dGwsIApK YW4gMzEgMTU6MjM6MjIgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiA4Mjc0NTc1 MzYgcmVxdWVzdGVkIG9wdGlvbnM6IDI4OmJyb2FkY2FzdCwgNDA6bmlzLWRvbWFpbiwgNDE6bmlz LXNlcnZlciwgCkphbiAzMSAxNToyMzoyMiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1 OF06IDgyNzQ1NzUzNiByZXF1ZXN0ZWQgb3B0aW9uczogNDI6bnRwLXNlcnZlciwgNDM6dmVuZG9y LWVuY2FwLCA1MDpyZXF1ZXN0ZWQtYWRkcmVzcywgCkphbiAzMSAxNToyMzoyMiBtaWdodHlqb2V5 b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDgyNzQ1NzUzNiByZXF1ZXN0ZWQgb3B0aW9uczogNTE6 bGVhc2UtdGltZSwgNTQ6c2VydmVyLWlkZW50aWZpZXIsIDU4OlQxLCAKSmFuIDMxIDE1OjIzOjIy IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogODI3NDU3NTM2IHJlcXVlc3RlZCBv cHRpb25zOiA1OTpUMiwgNjA6dmVuZG9yLWNsYXNzLCA2Njp0ZnRwLXNlcnZlciwgNjc6Ym9vdGZp bGUtbmFtZSwgCkphbiAzMSAxNToyMzoyMiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1 OF06IDgyNzQ1NzUzNiByZXF1ZXN0ZWQgb3B0aW9uczogOTc6Y2xpZW50LW1hY2hpbmUtaWQsIDEy OCwgMTI5LCAxMzAsIDEzMSwgCkphbiAzMSAxNToyMzoyMiBtaWdodHlqb2V5b3VuZyBkbnNtYXNx LWRoY3BbNTQ1OF06IDgyNzQ1NzUzNiByZXF1ZXN0ZWQgb3B0aW9uczogMTMyLCAxMzMsIDEzNCwg MTM1CkphbiAzMSAxNToyMzoyMiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDgy NzQ1NzUzNiB0YWdzOiBsYW4sIGV0aDAKSmFuIDMxIDE1OjIzOjIyIG1pZ2h0eWpvZXlvdW5nIGRu c21hc3EtZGhjcFs1NDU4XTogODI3NDU3NTM2IG5leHQgc2VydmVyOiAxOTIuMTY4LjMzLjEKSmFu IDMxIDE1OjIzOjIyIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogODI3NDU3NTM2 IHNlbnQgc2l6ZTogIDEgb3B0aW9uOiA1MzptZXNzYWdlLXR5cGUgIDAyCkphbiAzMSAxNToyMzoy MiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDgyNzQ1NzUzNiBzZW50IHNpemU6 ICA0IG9wdGlvbjogNTQ6c2VydmVyLWlkZW50aWZpZXIgIDE5Mi4xNjguMzMuMQpKYW4gMzEgMTU6 MjM6MjIgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiA4Mjc0NTc1MzYgc2VudCBz aXplOiAgNCBvcHRpb246IDUxOmxlYXNlLXRpbWUgIDAwOjAxOjUxOjgwCkphbiAzMSAxNToyMzoy MiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDgyNzQ1NzUzNiBzZW50IHNpemU6 ICA0IG9wdGlvbjogNTg6VDEgIDAwOjAwOmE4OmMwCkphbiAzMSAxNToyMzoyMiBtaWdodHlqb2V5 b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDgyNzQ1NzUzNiBzZW50IHNpemU6ICA0IG9wdGlvbjog NTk6VDIgIDAwOjAxOjI3OjUwCkphbiAzMSAxNToyMzoyMiBtaWdodHlqb2V5b3VuZyBkbnNtYXNx LWRoY3BbNTQ1OF06IDgyNzQ1NzUzNiBzZW50IHNpemU6ICA0IG9wdGlvbjogIDE6bmV0bWFzayAg MjU1LjI1NS4yNTUuMApKYW4gMzEgMTU6MjM6MjIgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNw WzU0NThdOiA4Mjc0NTc1MzYgc2VudCBzaXplOiAgNCBvcHRpb246IDI4OmJyb2FkY2FzdCAgMTky LjE2OC4zMy4yNTUKSmFuIDMxIDE1OjIzOjIyIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1 NDU4XTogODI3NDU3NTM2IHNlbnQgc2l6ZTogIDggb3B0aW9uOiAgNjpkbnMtc2VydmVyICA2OC44 Ny43MS4yMjYsIDY4Ljg3LjczLjI0MgpKYW4gMzEgMTU6MjM6MjIgbWlnaHR5am9leW91bmcgZG5z bWFzcS1kaGNwWzU0NThdOiA4Mjc0NTc1MzYgc2VudCBzaXplOiAgNCBvcHRpb246ICAzOnJvdXRl ciAgMTkyLjE2OC4zMy4xCkphbiAzMSAxNToyMzoyMiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRo Y3BbNTQ1OF06IDgyNzQ1NzUzNiBzZW50IHNpemU6ICA5IG9wdGlvbjogNjA6dmVuZG9yLWNsYXNz ICA1MDo1ODo0NTo0Mzo2Yzo2OTo2NTo2ZTo3NApKYW4gMzEgMTU6MjM6MjIgbWlnaHR5am9leW91 bmcgZG5zbWFzcS1kaGNwWzU0NThdOiA4Mjc0NTc1MzYgc2VudCBzaXplOiAxNyBvcHRpb246IDk3 OmNsaWVudC1tYWNoaW5lLWlkICAwMDoyMDowYTo1NDo2MjowNjo5YTpkYjo0Zjo5MDpjMTo5Mzow ZC4uLgpKYW4gMzEgMTU6MjM6MjIgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiA4 Mjc0NTc1MzYgc2VudCBzaXplOiAxMCBvcHRpb246IDQzOnZlbmRvci1lbmNhcCAgMDY6MDE6MDg6 MGE6MDQ6MDA6NTA6NTg6NDU6ZmYKSmFuIDMxIDE1OjIzOjI2IG1pZ2h0eWpvZXlvdW5nIGRuc21h c3EtZGhjcFs1NDU4XTogMjU3NDQ1MDY4OCBBdmFpbGFibGUgREhDUCByYW5nZTogMTkyLjE2OC4z My4xMDAgLS0gMTkyLjE2OC4zMy4xNDkKSmFuIDMxIDE1OjIzOjI2IG1pZ2h0eWpvZXlvdW5nIGRu c21hc3EtZGhjcFs1NDU4XTogMjU3NDQ1MDY4OCBWZW5kb3IgY2xhc3M6IFBYRUNsaWVudDpBcmNo OjAwMDAwOlVOREk6MDAzMDE2CkphbiAzMSAxNToyMzoyNiBtaWdodHlqb2V5b3VuZyBkbnNtYXNx LWRoY3BbNTQ1OF06IDI1NzQ0NTA2ODggREhDUERJU0NPVkVSKGV0aDApIDAwOjIzOmRmOmFiOjZi OjMyIApKYW4gMzEgMTU6MjM6MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAy NTc0NDUwNjg4IERIQ1BPRkZFUihldGgwKSAxOTIuMTY4LjMzLjE0OCAwMDoyMzpkZjphYjo2Yjoz MiAKSmFuIDMxIDE1OjIzOjI2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjU3 NDQ1MDY4OCByZXF1ZXN0ZWQgb3B0aW9uczogMTpuZXRtYXNrLCAyOnRpbWUtb2Zmc2V0LCAzOnJv dXRlciwgNCwgNSwgCkphbiAzMSAxNToyMzoyNiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3Bb NTQ1OF06IDI1NzQ0NTA2ODggcmVxdWVzdGVkIG9wdGlvbnM6IDY6ZG5zLXNlcnZlciwgMTI6aG9z dG5hbWUsIDEzOmJvb3QtZmlsZS1zaXplLCAKSmFuIDMxIDE1OjIzOjI2IG1pZ2h0eWpvZXlvdW5n IGRuc21hc3EtZGhjcFs1NDU4XTogMjU3NDQ1MDY4OCByZXF1ZXN0ZWQgb3B0aW9uczogMTU6ZG9t YWluLW5hbWUsIDE3OnJvb3QtcGF0aCwgMTg6ZXh0ZW5zaW9uLXBhdGgsIApKYW4gMzEgMTU6MjM6 MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyNTc0NDUwNjg4IHJlcXVlc3Rl ZCBvcHRpb25zOiAyMjptYXgtZGF0YWdyYW0tcmVhc3NlbWJseSwgMjM6ZGVmYXVsdC10dGwsIApK YW4gMzEgMTU6MjM6MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyNTc0NDUw Njg4IHJlcXVlc3RlZCBvcHRpb25zOiAyODpicm9hZGNhc3QsIDQwOm5pcy1kb21haW4sIDQxOm5p cy1zZXJ2ZXIsIApKYW4gMzEgMTU6MjM6MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0 NThdOiAyNTc0NDUwNjg4IHJlcXVlc3RlZCBvcHRpb25zOiA0MjpudHAtc2VydmVyLCA0Mzp2ZW5k b3ItZW5jYXAsIDUwOnJlcXVlc3RlZC1hZGRyZXNzLCAKSmFuIDMxIDE1OjIzOjI2IG1pZ2h0eWpv ZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjU3NDQ1MDY4OCByZXF1ZXN0ZWQgb3B0aW9uczog NTE6bGVhc2UtdGltZSwgNTQ6c2VydmVyLWlkZW50aWZpZXIsIDU4OlQxLCAKSmFuIDMxIDE1OjIz OjI2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjU3NDQ1MDY4OCByZXF1ZXN0 ZWQgb3B0aW9uczogNTk6VDIsIDYwOnZlbmRvci1jbGFzcywgNjY6dGZ0cC1zZXJ2ZXIsIDY3OmJv b3RmaWxlLW5hbWUsIApKYW4gMzEgMTU6MjM6MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNw WzU0NThdOiAyNTc0NDUwNjg4IHJlcXVlc3RlZCBvcHRpb25zOiA5NzpjbGllbnQtbWFjaGluZS1p ZCwgMTI4LCAxMjksIDEzMCwgMTMxLCAKSmFuIDMxIDE1OjIzOjI2IG1pZ2h0eWpvZXlvdW5nIGRu c21hc3EtZGhjcFs1NDU4XTogMjU3NDQ1MDY4OCByZXF1ZXN0ZWQgb3B0aW9uczogMTMyLCAxMzMs IDEzNCwgMTM1CkphbiAzMSAxNToyMzoyNiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1 OF06IDI1NzQ0NTA2ODggdGFnczogbGFuLCBldGgwCkphbiAzMSAxNToyMzoyNiBtaWdodHlqb2V5 b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI1NzQ0NTA2ODggbmV4dCBzZXJ2ZXI6IDE5Mi4xNjgu MzMuMQpKYW4gMzEgMTU6MjM6MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAy NTc0NDUwNjg4IHNlbnQgc2l6ZTogIDEgb3B0aW9uOiA1MzptZXNzYWdlLXR5cGUgIDAyCkphbiAz MSAxNToyMzoyNiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI1NzQ0NTA2ODgg c2VudCBzaXplOiAgNCBvcHRpb246IDU0OnNlcnZlci1pZGVudGlmaWVyICAxOTIuMTY4LjMzLjEK SmFuIDMxIDE1OjIzOjI2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjU3NDQ1 MDY4OCBzZW50IHNpemU6ICA0IG9wdGlvbjogNTE6bGVhc2UtdGltZSAgMDA6MDE6NTE6ODAKSmFu IDMxIDE1OjIzOjI2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjU3NDQ1MDY4 OCBzZW50IHNpemU6ICA0IG9wdGlvbjogNTg6VDEgIDAwOjAwOmE4OmMwCkphbiAzMSAxNToyMzoy NiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI1NzQ0NTA2ODggc2VudCBzaXpl OiAgNCBvcHRpb246IDU5OlQyICAwMDowMToyNzo1MApKYW4gMzEgMTU6MjM6MjYgbWlnaHR5am9l eW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyNTc0NDUwNjg4IHNlbnQgc2l6ZTogIDQgb3B0aW9u OiAgMTpuZXRtYXNrICAyNTUuMjU1LjI1NS4wCkphbiAzMSAxNToyMzoyNiBtaWdodHlqb2V5b3Vu ZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI1NzQ0NTA2ODggc2VudCBzaXplOiAgNCBvcHRpb246IDI4 OmJyb2FkY2FzdCAgMTkyLjE2OC4zMy4yNTUKSmFuIDMxIDE1OjIzOjI2IG1pZ2h0eWpvZXlvdW5n IGRuc21hc3EtZGhjcFs1NDU4XTogMjU3NDQ1MDY4OCBzZW50IHNpemU6ICA4IG9wdGlvbjogIDY6 ZG5zLXNlcnZlciAgNjguODcuNzEuMjI2LCA2OC44Ny43My4yNDIKSmFuIDMxIDE1OjIzOjI2IG1p Z2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjU3NDQ1MDY4OCBzZW50IHNpemU6ICA0 IG9wdGlvbjogIDM6cm91dGVyICAxOTIuMTY4LjMzLjEKSmFuIDMxIDE1OjIzOjI2IG1pZ2h0eWpv ZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjU3NDQ1MDY4OCBzZW50IHNpemU6ICA5IG9wdGlv bjogNjA6dmVuZG9yLWNsYXNzICA1MDo1ODo0NTo0Mzo2Yzo2OTo2NTo2ZTo3NApKYW4gMzEgMTU6 MjM6MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyNTc0NDUwNjg4IHNlbnQg c2l6ZTogMTcgb3B0aW9uOiA5NzpjbGllbnQtbWFjaGluZS1pZCAgMDA6MjA6MGE6NTQ6NjI6MDY6 OWE6ZGI6NGY6OTA6YzE6OTM6MGQuLi4KSmFuIDMxIDE1OjIzOjI2IG1pZ2h0eWpvZXlvdW5nIGRu c21hc3EtZGhjcFs1NDU4XTogMjU3NDQ1MDY4OCBzZW50IHNpemU6IDEwIG9wdGlvbjogNDM6dmVu ZG9yLWVuY2FwICAwNjowMTowODowYTowNDowMDo1MDo1ODo0NTpmZgpKYW4gMzEgMTU6MjM6MzUg bWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAzMDM4MTE3ODg4IEF2YWlsYWJsZSBE SENQIHJhbmdlOiAxOTIuMTY4LjMzLjEwMCAtLSAxOTIuMTY4LjMzLjE0OQpKYW4gMzEgMTU6MjM6 MzUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAzMDM4MTE3ODg4IFZlbmRvciBj bGFzczogUFhFQ2xpZW50OkFyY2g6MDAwMDA6VU5ESTowMDMwMTYKSmFuIDMxIDE1OjIzOjM1IG1p Z2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMzAzODExNzg4OCBESENQRElTQ09WRVIo ZXRoMCkgMDA6MjM6ZGY6YWI6NmI6MzIgCkphbiAzMSAxNToyMzozNSBtaWdodHlqb2V5b3VuZyBk bnNtYXNxLWRoY3BbNTQ1OF06IDMwMzgxMTc4ODggREhDUE9GRkVSKGV0aDApIDE5Mi4xNjguMzMu MTQ4IDAwOjIzOmRmOmFiOjZiOjMyIApKYW4gMzEgMTU6MjM6MzUgbWlnaHR5am9leW91bmcgZG5z bWFzcS1kaGNwWzU0NThdOiAzMDM4MTE3ODg4IHJlcXVlc3RlZCBvcHRpb25zOiAxOm5ldG1hc2ss IDI6dGltZS1vZmZzZXQsIDM6cm91dGVyLCA0LCA1LCAKSmFuIDMxIDE1OjIzOjM1IG1pZ2h0eWpv ZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMzAzODExNzg4OCByZXF1ZXN0ZWQgb3B0aW9uczog NjpkbnMtc2VydmVyLCAxMjpob3N0bmFtZSwgMTM6Ym9vdC1maWxlLXNpemUsIApKYW4gMzEgMTU6 MjM6MzUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAzMDM4MTE3ODg4IHJlcXVl c3RlZCBvcHRpb25zOiAxNTpkb21haW4tbmFtZSwgMTc6cm9vdC1wYXRoLCAxODpleHRlbnNpb24t cGF0aCwgCkphbiAzMSAxNToyMzozNSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06 IDMwMzgxMTc4ODggcmVxdWVzdGVkIG9wdGlvbnM6IDIyOm1heC1kYXRhZ3JhbS1yZWFzc2VtYmx5 LCAyMzpkZWZhdWx0LXR0bCwgCkphbiAzMSAxNToyMzozNSBtaWdodHlqb2V5b3VuZyBkbnNtYXNx LWRoY3BbNTQ1OF06IDMwMzgxMTc4ODggcmVxdWVzdGVkIG9wdGlvbnM6IDI4OmJyb2FkY2FzdCwg NDA6bmlzLWRvbWFpbiwgNDE6bmlzLXNlcnZlciwgCkphbiAzMSAxNToyMzozNSBtaWdodHlqb2V5 b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDMwMzgxMTc4ODggcmVxdWVzdGVkIG9wdGlvbnM6IDQy Om50cC1zZXJ2ZXIsIDQzOnZlbmRvci1lbmNhcCwgNTA6cmVxdWVzdGVkLWFkZHJlc3MsIApKYW4g MzEgMTU6MjM6MzUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAzMDM4MTE3ODg4 IHJlcXVlc3RlZCBvcHRpb25zOiA1MTpsZWFzZS10aW1lLCA1NDpzZXJ2ZXItaWRlbnRpZmllciwg NTg6VDEsIApKYW4gMzEgMTU6MjM6MzUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThd OiAzMDM4MTE3ODg4IHJlcXVlc3RlZCBvcHRpb25zOiA1OTpUMiwgNjA6dmVuZG9yLWNsYXNzLCA2 Njp0ZnRwLXNlcnZlciwgNjc6Ym9vdGZpbGUtbmFtZSwgCkphbiAzMSAxNToyMzozNSBtaWdodHlq b2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDMwMzgxMTc4ODggcmVxdWVzdGVkIG9wdGlvbnM6 IDk3OmNsaWVudC1tYWNoaW5lLWlkLCAxMjgsIDEyOSwgMTMwLCAxMzEsIApKYW4gMzEgMTU6MjM6 MzUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAzMDM4MTE3ODg4IHJlcXVlc3Rl ZCBvcHRpb25zOiAxMzIsIDEzMywgMTM0LCAxMzUKSmFuIDMxIDE1OjIzOjM1IG1pZ2h0eWpvZXlv dW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMzAzODExNzg4OCB0YWdzOiBsYW4sIGV0aDAKSmFuIDMx IDE1OjIzOjM1IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMzAzODExNzg4OCBu ZXh0IHNlcnZlcjogMTkyLjE2OC4zMy4xCkphbiAzMSAxNToyMzozNSBtaWdodHlqb2V5b3VuZyBk bnNtYXNxLWRoY3BbNTQ1OF06IDMwMzgxMTc4ODggc2VudCBzaXplOiAgMSBvcHRpb246IDUzOm1l c3NhZ2UtdHlwZSAgMDIKSmFuIDMxIDE1OjIzOjM1IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhj cFs1NDU4XTogMzAzODExNzg4OCBzZW50IHNpemU6ICA0IG9wdGlvbjogNTQ6c2VydmVyLWlkZW50 aWZpZXIgIDE5Mi4xNjguMzMuMQpKYW4gMzEgMTU6MjM6MzUgbWlnaHR5am9leW91bmcgZG5zbWFz cS1kaGNwWzU0NThdOiAzMDM4MTE3ODg4IHNlbnQgc2l6ZTogIDQgb3B0aW9uOiA1MTpsZWFzZS10 aW1lICAwMDowMTo1MTo4MApKYW4gMzEgMTU6MjM6MzUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1k aGNwWzU0NThdOiAzMDM4MTE3ODg4IHNlbnQgc2l6ZTogIDQgb3B0aW9uOiA1ODpUMSAgMDA6MDA6 YTg6YzAKSmFuIDMxIDE1OjIzOjM1IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTog MzAzODExNzg4OCBzZW50IHNpemU6ICA0IG9wdGlvbjogNTk6VDIgIDAwOjAxOjI3OjUwCkphbiAz MSAxNToyMzozNSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDMwMzgxMTc4ODgg c2VudCBzaXplOiAgNCBvcHRpb246ICAxOm5ldG1hc2sgIDI1NS4yNTUuMjU1LjAKSmFuIDMxIDE1 OjIzOjM1IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMzAzODExNzg4OCBzZW50 IHNpemU6ICA0IG9wdGlvbjogMjg6YnJvYWRjYXN0ICAxOTIuMTY4LjMzLjI1NQpKYW4gMzEgMTU6 MjM6MzUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAzMDM4MTE3ODg4IHNlbnQg c2l6ZTogIDggb3B0aW9uOiAgNjpkbnMtc2VydmVyICA2OC44Ny43MS4yMjYsIDY4Ljg3LjczLjI0 MgpKYW4gMzEgMTU6MjM6MzUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAzMDM4 MTE3ODg4IHNlbnQgc2l6ZTogIDQgb3B0aW9uOiAgMzpyb3V0ZXIgIDE5Mi4xNjguMzMuMQpKYW4g MzEgMTU6MjM6MzUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAzMDM4MTE3ODg4 IHNlbnQgc2l6ZTogIDkgb3B0aW9uOiA2MDp2ZW5kb3ItY2xhc3MgIDUwOjU4OjQ1OjQzOjZjOjY5 OjY1OjZlOjc0CkphbiAzMSAxNToyMzozNSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1 OF06IDMwMzgxMTc4ODggc2VudCBzaXplOiAxNyBvcHRpb246IDk3OmNsaWVudC1tYWNoaW5lLWlk ICAwMDoyMDowYTo1NDo2MjowNjo5YTpkYjo0Zjo5MDpjMTo5MzowZC4uLgpKYW4gMzEgMTU6MjM6 MzUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAzMDM4MTE3ODg4IHNlbnQgc2l6 ZTogMTAgb3B0aW9uOiA0Mzp2ZW5kb3ItZW5jYXAgIDA2OjAxOjA4OjBhOjA0OjAwOjUwOjU4OjQ1 OmZmCkphbiAzMSAxNToyMzo1MSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4 NjUwIEF2YWlsYWJsZSBESENQIHJhbmdlOiAxOTIuMTY4LjMzLjEwMCAtLSAxOTIuMTY4LjMzLjE0 OQpKYW4gMzEgMTU6MjM6NTEgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1 MCBWZW5kb3IgY2xhc3M6IEFBUExCU0RQQy9pMzg2L01hY0Jvb2s1LDEKSmFuIDMxIDE1OjIzOjUx IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2NTAgREhDUERJU0NPVkVSKGV0 aDApIDAwOjIzOmRmOmFiOjZiOjMyIApKYW4gMzEgMTU6MjM6NTEgbWlnaHR5am9leW91bmcgZG5z bWFzcS1kaGNwWzU0NThdOiAyODY1MCBESENQT0ZGRVIoZXRoMCkgMTkyLjE2OC4zMy4xNDggMDA6 MjM6ZGY6YWI6NmI6MzIgCkphbiAzMSAxNToyMzo1MSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRo Y3BbNTQ1OF06IDI4NjUwIHJlcXVlc3RlZCBvcHRpb25zOiAxOm5ldG1hc2ssIDM6cm91dGVyLCA2 Nzpib290ZmlsZS1uYW1lLCA0Mzp2ZW5kb3ItZW5jYXAsIApKYW4gMzEgMTU6MjM6NTEgbWlnaHR5 am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MCByZXF1ZXN0ZWQgb3B0aW9uczogNjA6 dmVuZG9yLWNsYXNzCkphbiAzMSAxNToyMzo1MSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3Bb NTQ1OF06IDI4NjUwIHRhZ3M6IGxhbiwgZXRoMApKYW4gMzEgMTU6MjM6NTEgbWlnaHR5am9leW91 bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MCBuZXh0IHNlcnZlcjogMTkyLjE2OC4zMy4xCkph biAzMSAxNToyMzo1MSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUwIHNl bnQgc2l6ZTogIDEgb3B0aW9uOiA1MzptZXNzYWdlLXR5cGUgIDAyCkphbiAzMSAxNToyMzo1MSBt aWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUwIHNlbnQgc2l6ZTogIDQgb3B0 aW9uOiA1NDpzZXJ2ZXItaWRlbnRpZmllciAgMTkyLjE2OC4zMy4xCkphbiAzMSAxNToyMzo1MSBt aWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUwIHNlbnQgc2l6ZTogIDQgb3B0 aW9uOiA1MTpsZWFzZS10aW1lICAwMDowMTo1MTo4MApKYW4gMzEgMTU6MjM6NTEgbWlnaHR5am9l eW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MCBzZW50IHNpemU6ICA0IG9wdGlvbjogNTg6 VDEgIDAwOjAwOmE4OmMwCkphbiAzMSAxNToyMzo1MSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRo Y3BbNTQ1OF06IDI4NjUwIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiA1OTpUMiAgMDA6MDE6Mjc6NTAK SmFuIDMxIDE1OjIzOjUxIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2NTAg c2VudCBzaXplOiAgNCBvcHRpb246ICAxOm5ldG1hc2sgIDI1NS4yNTUuMjU1LjAKSmFuIDMxIDE1 OjIzOjUxIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2NTAgc2VudCBzaXpl OiAgNCBvcHRpb246IDI4OmJyb2FkY2FzdCAgMTkyLjE2OC4zMy4yNTUKSmFuIDMxIDE1OjIzOjUx IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2NTAgc2VudCBzaXplOiAgNCBv cHRpb246ICAzOnJvdXRlciAgMTkyLjE2OC4zMy4xCkphbiAzMSAxNToyMzo1MyBtaWdodHlqb2V5 b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUwIEF2YWlsYWJsZSBESENQIHJhbmdlOiAxOTIu MTY4LjMzLjEwMCAtLSAxOTIuMTY4LjMzLjE0OQpKYW4gMzEgMTU6MjM6NTMgbWlnaHR5am9leW91 bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MCBWZW5kb3IgY2xhc3M6IEFBUExCU0RQQy9pMzg2 L01hY0Jvb2s1LDEKSmFuIDMxIDE1OjIzOjUzIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1 NDU4XTogMjg2NTAgREhDUFJFUVVFU1QoZXRoMCkgMTkyLjE2OC4zMy4xNDggMDA6MjM6ZGY6YWI6 NmI6MzIgCkphbiAzMSAxNToyMzo1MyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06 IDI4NjUwIERIQ1BBQ0soZXRoMCkgMTkyLjE2OC4zMy4xNDggMDA6MjM6ZGY6YWI6NmI6MzIgCkph biAzMSAxNToyMzo1MyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUwIHJl cXVlc3RlZCBvcHRpb25zOiAxOm5ldG1hc2ssIDM6cm91dGVyLCA2Nzpib290ZmlsZS1uYW1lLCA0 Mzp2ZW5kb3ItZW5jYXAsIApKYW4gMzEgMTU6MjM6NTMgbWlnaHR5am9leW91bmcgZG5zbWFzcS1k aGNwWzU0NThdOiAyODY1MCByZXF1ZXN0ZWQgb3B0aW9uczogNjA6dmVuZG9yLWNsYXNzCkphbiAz MSAxNToyMzo1MyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUwIHRhZ3M6 IGxhbiwgZXRoMApKYW4gMzEgMTU6MjM6NTMgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0 NThdOiAyODY1MCBuZXh0IHNlcnZlcjogMTkyLjE2OC4zMy4xCkphbiAzMSAxNToyMzo1MyBtaWdo dHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUwIHNlbnQgc2l6ZTogIDEgb3B0aW9u OiA1MzptZXNzYWdlLXR5cGUgIDA1CkphbiAzMSAxNToyMzo1MyBtaWdodHlqb2V5b3VuZyBkbnNt YXNxLWRoY3BbNTQ1OF06IDI4NjUwIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiA1NDpzZXJ2ZXItaWRl bnRpZmllciAgMTkyLjE2OC4zMy4xCkphbiAzMSAxNToyMzo1MyBtaWdodHlqb2V5b3VuZyBkbnNt YXNxLWRoY3BbNTQ1OF06IDI4NjUwIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiA1MTpsZWFzZS10aW1l ICAwMDowMTo1MTo4MApKYW4gMzEgMTU6MjM6NTMgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNw WzU0NThdOiAyODY1MCBzZW50IHNpemU6ICA0IG9wdGlvbjogNTg6VDEgIDAwOjAwOmE4OmMwCkph biAzMSAxNToyMzo1MyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUwIHNl bnQgc2l6ZTogIDQgb3B0aW9uOiA1OTpUMiAgMDA6MDE6Mjc6NTAKSmFuIDMxIDE1OjIzOjUzIG1p Z2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2NTAgc2VudCBzaXplOiAgNCBvcHRp b246ICAxOm5ldG1hc2sgIDI1NS4yNTUuMjU1LjAKSmFuIDMxIDE1OjIzOjUzIG1pZ2h0eWpvZXlv dW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2NTAgc2VudCBzaXplOiAgNCBvcHRpb246IDI4OmJy b2FkY2FzdCAgMTkyLjE2OC4zMy4yNTUKSmFuIDMxIDE1OjIzOjUzIG1pZ2h0eWpvZXlvdW5nIGRu c21hc3EtZGhjcFs1NDU4XTogMjg2NTAgc2VudCBzaXplOiAgNCBvcHRpb246ICAzOnJvdXRlciAg MTkyLjE2OC4zMy4xCkphbiAzMSAxNToyMzo1NCBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3Bb NTQ1OF06IDI4NjUxIEF2YWlsYWJsZSBESENQIHJhbmdlOiAxOTIuMTY4LjMzLjEwMCAtLSAxOTIu MTY4LjMzLjE0OQpKYW4gMzEgMTU6MjM6NTQgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0 NThdOiAyODY1MSBWZW5kb3IgY2xhc3M6IEFBUExCU0RQQy9pMzg2L01hY0Jvb2s1LDEKSmFuIDMx IDE1OjIzOjU0IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2NTEgREhDUElO Rk9STShldGgwKSAxOTIuMTY4LjMzLjE0OCAwMDoyMzpkZjphYjo2YjozMiAKSmFuIDMxIDE1OjIz OjU0IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2NTEgREhDUEFDSyhldGgw KSAxOTIuMTY4LjMzLjE0OCAwMDoyMzpkZjphYjo2YjozMiAKSmFuIDMxIDE1OjIzOjU0IG1pZ2h0 eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2NTEgcmVxdWVzdGVkIG9wdGlvbnM6IDQz OnZlbmRvci1lbmNhcCwgNjA6dmVuZG9yLWNsYXNzCkphbiAzMSAxNToyMzo1NCBtaWdodHlqb2V5 b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUxIHRhZ3M6IGxhbiwgZXRoMApKYW4gMzEgMTU6 MjM6NTQgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MSBuZXh0IHNlcnZl cjogMTkyLjE2OC4zMy4xCkphbiAzMSAxNToyMzo1NCBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRo Y3BbNTQ1OF06IDI4NjUxIHNlbnQgc2l6ZTogIDEgb3B0aW9uOiA1MzptZXNzYWdlLXR5cGUgIDA1 CkphbiAzMSAxNToyMzo1NCBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUx IHNlbnQgc2l6ZTogIDQgb3B0aW9uOiA1NDpzZXJ2ZXItaWRlbnRpZmllciAgMTkyLjE2OC4zMy4x CkphbiAzMSAxNToyMzo1NCBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUx IHNlbnQgc2l6ZTogIDQgb3B0aW9uOiA1MTpsZWFzZS10aW1lICAwMDowMTo1MTo3ZgpKYW4gMzEg MTU6MjM6NTQgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MSBzZW50IHNp emU6ICA0IG9wdGlvbjogIDE6bmV0bWFzayAgMjU1LjI1NS4yNTUuMApKYW4gMzEgMTU6MjM6NTQg bWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MSBzZW50IHNpemU6ICA0IG9w dGlvbjogMjg6YnJvYWRjYXN0ICAxOTIuMTY4LjMzLjI1NQpKYW4gMzEgMTU6MjM6NTUgbWlnaHR5 am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MSBBdmFpbGFibGUgREhDUCByYW5nZTog MTkyLjE2OC4zMy4xMDAgLS0gMTkyLjE2OC4zMy4xNDkKSmFuIDMxIDE1OjIzOjU1IG1pZ2h0eWpv ZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2NTEgVmVuZG9yIGNsYXNzOiBBQVBMQlNEUEMv aTM4Ni9NYWNCb29rNSwxCkphbiAzMSAxNToyMzo1NSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRo Y3BbNTQ1OF06IDI4NjUxIERIQ1BJTkZPUk0oZXRoMCkgMTkyLjE2OC4zMy4xNDggMDA6MjM6ZGY6 YWI6NmI6MzIgCkphbiAzMSAxNToyMzo1NSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1 OF06IDI4NjUxIERIQ1BBQ0soZXRoMCkgMTkyLjE2OC4zMy4xNDggMDA6MjM6ZGY6YWI6NmI6MzIg CkphbiAzMSAxNToyMzo1NSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUx IHJlcXVlc3RlZCBvcHRpb25zOiA0Mzp2ZW5kb3ItZW5jYXAsIDYwOnZlbmRvci1jbGFzcwpKYW4g MzEgMTU6MjM6NTUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MSB0YWdz OiBsYW4sIGV0aDAKSmFuIDMxIDE1OjIzOjU1IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1 NDU4XTogMjg2NTEgbmV4dCBzZXJ2ZXI6IDE5Mi4xNjguMzMuMQpKYW4gMzEgMTU6MjM6NTUgbWln aHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MSBzZW50IHNpemU6ICAxIG9wdGlv bjogNTM6bWVzc2FnZS10eXBlICAwNQpKYW4gMzEgMTU6MjM6NTUgbWlnaHR5am9leW91bmcgZG5z bWFzcS1kaGNwWzU0NThdOiAyODY1MSBzZW50IHNpemU6ICA0IG9wdGlvbjogNTQ6c2VydmVyLWlk ZW50aWZpZXIgIDE5Mi4xNjguMzMuMQpKYW4gMzEgMTU6MjM6NTUgbWlnaHR5am9leW91bmcgZG5z bWFzcS1kaGNwWzU0NThdOiAyODY1MSBzZW50IHNpemU6ICA0IG9wdGlvbjogNTE6bGVhc2UtdGlt ZSAgMDA6MDE6NTE6N2UKSmFuIDMxIDE1OjIzOjU1IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhj cFs1NDU4XTogMjg2NTEgc2VudCBzaXplOiAgNCBvcHRpb246ICAxOm5ldG1hc2sgIDI1NS4yNTUu MjU1LjAKSmFuIDMxIDE1OjIzOjU1IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTog Mjg2NTEgc2VudCBzaXplOiAgNCBvcHRpb246IDI4OmJyb2FkY2FzdCAgMTkyLjE2OC4zMy4yNTUK SmFuIDMxIDE1OjIzOjU3IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2NTEg QXZhaWxhYmxlIERIQ1AgcmFuZ2U6IDE5Mi4xNjguMzMuMTAwIC0tIDE5Mi4xNjguMzMuMTQ5Ckph biAzMSAxNToyMzo1NyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUxIFZl bmRvciBjbGFzczogQUFQTEJTRFBDL2kzODYvTWFjQm9vazUsMQpKYW4gMzEgMTU6MjM6NTcgbWln aHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MSBESENQSU5GT1JNKGV0aDApIDE5 Mi4xNjguMzMuMTQ4IDAwOjIzOmRmOmFiOjZiOjMyIApKYW4gMzEgMTU6MjM6NTcgbWlnaHR5am9l eW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MSBESENQQUNLKGV0aDApIDE5Mi4xNjguMzMu MTQ4IDAwOjIzOmRmOmFiOjZiOjMyIApKYW4gMzEgMTU6MjM6NTcgbWlnaHR5am9leW91bmcgZG5z bWFzcS1kaGNwWzU0NThdOiAyODY1MSByZXF1ZXN0ZWQgb3B0aW9uczogNDM6dmVuZG9yLWVuY2Fw LCA2MDp2ZW5kb3ItY2xhc3MKSmFuIDMxIDE1OjIzOjU3IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3Et ZGhjcFs1NDU4XTogMjg2NTEgdGFnczogbGFuLCBldGgwCkphbiAzMSAxNToyMzo1NyBtaWdodHlq b2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUxIG5leHQgc2VydmVyOiAxOTIuMTY4LjMz LjEKSmFuIDMxIDE1OjIzOjU3IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2 NTEgc2VudCBzaXplOiAgMSBvcHRpb246IDUzOm1lc3NhZ2UtdHlwZSAgMDUKSmFuIDMxIDE1OjIz OjU3IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2NTEgc2VudCBzaXplOiAg NCBvcHRpb246IDU0OnNlcnZlci1pZGVudGlmaWVyICAxOTIuMTY4LjMzLjEKSmFuIDMxIDE1OjIz OjU3IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2NTEgc2VudCBzaXplOiAg NCBvcHRpb246IDUxOmxlYXNlLXRpbWUgIDAwOjAxOjUxOjdjCkphbiAzMSAxNToyMzo1NyBtaWdo dHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUxIHNlbnQgc2l6ZTogIDQgb3B0aW9u OiAgMTpuZXRtYXNrICAyNTUuMjU1LjI1NS4wCkphbiAzMSAxNToyMzo1NyBtaWdodHlqb2V5b3Vu ZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUxIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiAyODpicm9h ZGNhc3QgIDE5Mi4xNjguMzMuMjU1CkphbiAzMSAxNToyNDowMSBtaWdodHlqb2V5b3VuZyBkbnNt YXNxLWRoY3BbNTQ1OF06IDI4NjUxIEF2YWlsYWJsZSBESENQIHJhbmdlOiAxOTIuMTY4LjMzLjEw MCAtLSAxOTIuMTY4LjMzLjE0OQpKYW4gMzEgMTU6MjQ6MDEgbWlnaHR5am9leW91bmcgZG5zbWFz cS1kaGNwWzU0NThdOiAyODY1MSBWZW5kb3IgY2xhc3M6IEFBUExCU0RQQy9pMzg2L01hY0Jvb2s1 LDEKSmFuIDMxIDE1OjI0OjAxIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2 NTEgREhDUElORk9STShldGgwKSAxOTIuMTY4LjMzLjE0OCAwMDoyMzpkZjphYjo2YjozMiAKSmFu IDMxIDE1OjI0OjAxIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2NTEgREhD UEFDSyhldGgwKSAxOTIuMTY4LjMzLjE0OCAwMDoyMzpkZjphYjo2YjozMiAKSmFuIDMxIDE1OjI0 OjAxIG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2NTEgcmVxdWVzdGVkIG9w dGlvbnM6IDQzOnZlbmRvci1lbmNhcCwgNjA6dmVuZG9yLWNsYXNzCkphbiAzMSAxNToyNDowMSBt aWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUxIHRhZ3M6IGxhbiwgZXRoMApK YW4gMzEgMTU6MjQ6MDEgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MSBu ZXh0IHNlcnZlcjogMTkyLjE2OC4zMy4xCkphbiAzMSAxNToyNDowMSBtaWdodHlqb2V5b3VuZyBk bnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUxIHNlbnQgc2l6ZTogIDEgb3B0aW9uOiA1MzptZXNzYWdl LXR5cGUgIDA1CkphbiAzMSAxNToyNDowMSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1 OF06IDI4NjUxIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiA1NDpzZXJ2ZXItaWRlbnRpZmllciAgMTky LjE2OC4zMy4xCkphbiAzMSAxNToyNDowMSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1 OF06IDI4NjUxIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiA1MTpsZWFzZS10aW1lICAwMDowMTo1MTo3 OApKYW4gMzEgMTU6MjQ6MDEgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1 MSBzZW50IHNpemU6ICA0IG9wdGlvbjogIDE6bmV0bWFzayAgMjU1LjI1NS4yNTUuMApKYW4gMzEg MTU6MjQ6MDEgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MSBzZW50IHNp emU6ICA0IG9wdGlvbjogMjg6YnJvYWRjYXN0ICAxOTIuMTY4LjMzLjI1NQpKYW4gMzEgMTU6MjQ6 MDkgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MSBBdmFpbGFibGUgREhD UCByYW5nZTogMTkyLjE2OC4zMy4xMDAgLS0gMTkyLjE2OC4zMy4xNDkKSmFuIDMxIDE1OjI0OjA5 IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjg2NTEgVmVuZG9yIGNsYXNzOiBB QVBMQlNEUEMvaTM4Ni9NYWNCb29rNSwxCkphbiAzMSAxNToyNDowOSBtaWdodHlqb2V5b3VuZyBk bnNtYXNxLWRoY3BbNTQ1OF06IDI4NjUxIERIQ1BJTkZPUk0oZXRoMCkgMTkyLjE2OC4zMy4xNDgg MDA6MjM6ZGY6YWI6NmI6MzIgCkphbiAzMSAxNToyNDowOSBtaWdodHlqb2V5b3VuZyBkbnNtYXNx LWRoY3BbNTQ1OF06IDI4NjUxIERIQ1BBQ0soZXRoMCkgMTkyLjE2OC4zMy4xNDggMDA6MjM6ZGY6 YWI6NmI6MzIgCkphbiAzMSAxNToyNDowOSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1 OF06IDI4NjUxIHJlcXVlc3RlZCBvcHRpb25zOiA0Mzp2ZW5kb3ItZW5jYXAsIDYwOnZlbmRvci1j bGFzcwpKYW4gMzEgMTU6MjQ6MDkgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAy ODY1MSB0YWdzOiBsYW4sIGV0aDAKSmFuIDMxIDE1OjI0OjA5IG1pZ2h0eWpvZXlvdW5nIGRuc21h c3EtZGhjcFs1NDU4XTogMjg2NTEgbmV4dCBzZXJ2ZXI6IDE5Mi4xNjguMzMuMQpKYW4gMzEgMTU6 MjQ6MDkgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MSBzZW50IHNpemU6 ICAxIG9wdGlvbjogNTM6bWVzc2FnZS10eXBlICAwNQpKYW4gMzEgMTU6MjQ6MDkgbWlnaHR5am9l eW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MSBzZW50IHNpemU6ICA0IG9wdGlvbjogNTQ6 c2VydmVyLWlkZW50aWZpZXIgIDE5Mi4xNjguMzMuMQpKYW4gMzEgMTU6MjQ6MDkgbWlnaHR5am9l eW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyODY1MSBzZW50IHNpemU6ICA0IG9wdGlvbjogNTE6 bGVhc2UtdGltZSAgMDA6MDE6NTE6NzAKSmFuIDMxIDE1OjI0OjA5IG1pZ2h0eWpvZXlvdW5nIGRu c21hc3EtZGhjcFs1NDU4XTogMjg2NTEgc2VudCBzaXplOiAgNCBvcHRpb246ICAxOm5ldG1hc2sg IDI1NS4yNTUuMjU1LjAKSmFuIDMxIDE1OjI0OjA5IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhj cFs1NDU4XTogMjg2NTEgc2VudCBzaXplOiAgNCBvcHRpb246IDI4OmJyb2FkY2FzdCAgMTkyLjE2 OC4zMy4yNTUKSmFuIDMxIDE1OjI0OjI1IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4 XTogMjA4NjY2NjI0IEF2YWlsYWJsZSBESENQIHJhbmdlOiAxOTIuMTY4LjMzLjEwMCAtLSAxOTIu MTY4LjMzLjE0OQpKYW4gMzEgMTU6MjQ6MjUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0 NThdOiAyMDg2NjY2MjQgVmVuZG9yIGNsYXNzOiBQWEVDbGllbnQ6QXJjaDowMDAwMDpVTkRJOjAw MzAxNgpKYW4gMzEgMTU6MjQ6MjUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAy MDg2NjY2MjQgREhDUERJU0NPVkVSKGV0aDApIDAwOjIzOmRmOmFiOjZiOjMyIApKYW4gMzEgMTU6 MjQ6MjUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMDg2NjY2MjQgREhDUE9G RkVSKGV0aDApIDE5Mi4xNjguMzMuMTQ4IDAwOjIzOmRmOmFiOjZiOjMyIApKYW4gMzEgMTU6MjQ6 MjUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMDg2NjY2MjQgcmVxdWVzdGVk IG9wdGlvbnM6IDE6bmV0bWFzaywgMjp0aW1lLW9mZnNldCwgMzpyb3V0ZXIsIDQsIDUsIApKYW4g MzEgMTU6MjQ6MjUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMDg2NjY2MjQg cmVxdWVzdGVkIG9wdGlvbnM6IDY6ZG5zLXNlcnZlciwgMTI6aG9zdG5hbWUsIDEzOmJvb3QtZmls ZS1zaXplLCAKSmFuIDMxIDE1OjI0OjI1IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4 XTogMjA4NjY2NjI0IHJlcXVlc3RlZCBvcHRpb25zOiAxNTpkb21haW4tbmFtZSwgMTc6cm9vdC1w YXRoLCAxODpleHRlbnNpb24tcGF0aCwgCkphbiAzMSAxNToyNDoyNSBtaWdodHlqb2V5b3VuZyBk bnNtYXNxLWRoY3BbNTQ1OF06IDIwODY2NjYyNCByZXF1ZXN0ZWQgb3B0aW9uczogMjI6bWF4LWRh dGFncmFtLXJlYXNzZW1ibHksIDIzOmRlZmF1bHQtdHRsLCAKSmFuIDMxIDE1OjI0OjI1IG1pZ2h0 eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjA4NjY2NjI0IHJlcXVlc3RlZCBvcHRpb25z OiAyODpicm9hZGNhc3QsIDQwOm5pcy1kb21haW4sIDQxOm5pcy1zZXJ2ZXIsIApKYW4gMzEgMTU6 MjQ6MjUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMDg2NjY2MjQgcmVxdWVz dGVkIG9wdGlvbnM6IDQyOm50cC1zZXJ2ZXIsIDQzOnZlbmRvci1lbmNhcCwgNTA6cmVxdWVzdGVk LWFkZHJlc3MsIApKYW4gMzEgMTU6MjQ6MjUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0 NThdOiAyMDg2NjY2MjQgcmVxdWVzdGVkIG9wdGlvbnM6IDUxOmxlYXNlLXRpbWUsIDU0OnNlcnZl ci1pZGVudGlmaWVyLCA1ODpUMSwgCkphbiAzMSAxNToyNDoyNSBtaWdodHlqb2V5b3VuZyBkbnNt YXNxLWRoY3BbNTQ1OF06IDIwODY2NjYyNCByZXF1ZXN0ZWQgb3B0aW9uczogNTk6VDIsIDYwOnZl bmRvci1jbGFzcywgNjY6dGZ0cC1zZXJ2ZXIsIDY3OmJvb3RmaWxlLW5hbWUsIApKYW4gMzEgMTU6 MjQ6MjUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMDg2NjY2MjQgcmVxdWVz dGVkIG9wdGlvbnM6IDk3OmNsaWVudC1tYWNoaW5lLWlkLCAxMjgsIDEyOSwgMTMwLCAxMzEsIApK YW4gMzEgMTU6MjQ6MjUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMDg2NjY2 MjQgcmVxdWVzdGVkIG9wdGlvbnM6IDEzMiwgMTMzLCAxMzQsIDEzNQpKYW4gMzEgMTU6MjQ6MjUg bWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMDg2NjY2MjQgdGFnczogbGFuLCBl dGgwCkphbiAzMSAxNToyNDoyNSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIw ODY2NjYyNCBuZXh0IHNlcnZlcjogMTkyLjE2OC4zMy4xCkphbiAzMSAxNToyNDoyNSBtaWdodHlq b2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIwODY2NjYyNCBzZW50IHNpemU6ICAxIG9wdGlv bjogNTM6bWVzc2FnZS10eXBlICAwMgpKYW4gMzEgMTU6MjQ6MjUgbWlnaHR5am9leW91bmcgZG5z bWFzcS1kaGNwWzU0NThdOiAyMDg2NjY2MjQgc2VudCBzaXplOiAgNCBvcHRpb246IDU0OnNlcnZl ci1pZGVudGlmaWVyICAxOTIuMTY4LjMzLjEKSmFuIDMxIDE1OjI0OjI1IG1pZ2h0eWpvZXlvdW5n IGRuc21hc3EtZGhjcFs1NDU4XTogMjA4NjY2NjI0IHNlbnQgc2l6ZTogIDQgb3B0aW9uOiA1MTps ZWFzZS10aW1lICAwMDowMTo1MTo4MApKYW4gMzEgMTU6MjQ6MjUgbWlnaHR5am9leW91bmcgZG5z bWFzcS1kaGNwWzU0NThdOiAyMDg2NjY2MjQgc2VudCBzaXplOiAgNCBvcHRpb246IDU4OlQxICAw MDowMDphODpjMApKYW4gMzEgMTU6MjQ6MjUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0 NThdOiAyMDg2NjY2MjQgc2VudCBzaXplOiAgNCBvcHRpb246IDU5OlQyICAwMDowMToyNzo1MApK YW4gMzEgMTU6MjQ6MjUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMDg2NjY2 MjQgc2VudCBzaXplOiAgNCBvcHRpb246ICAxOm5ldG1hc2sgIDI1NS4yNTUuMjU1LjAKSmFuIDMx IDE1OjI0OjI1IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjA4NjY2NjI0IHNl bnQgc2l6ZTogIDQgb3B0aW9uOiAyODpicm9hZGNhc3QgIDE5Mi4xNjguMzMuMjU1CkphbiAzMSAx NToyNDoyNSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIwODY2NjYyNCBzZW50 IHNpemU6ICA4IG9wdGlvbjogIDY6ZG5zLXNlcnZlciAgNjguODcuNzEuMjI2LCA2OC44Ny43My4y NDIKSmFuIDMxIDE1OjI0OjI1IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjA4 NjY2NjI0IHNlbnQgc2l6ZTogIDQgb3B0aW9uOiAgMzpyb3V0ZXIgIDE5Mi4xNjguMzMuMQpKYW4g MzEgMTU6MjQ6MjUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMDg2NjY2MjQg c2VudCBzaXplOiAgOSBvcHRpb246IDYwOnZlbmRvci1jbGFzcyAgNTA6NTg6NDU6NDM6NmM6Njk6 NjU6NmU6NzQKSmFuIDMxIDE1OjI0OjI1IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4 XTogMjA4NjY2NjI0IHNlbnQgc2l6ZTogMTcgb3B0aW9uOiA5NzpjbGllbnQtbWFjaGluZS1pZCAg MDA6MjA6MGE6NTQ6NjI6MDY6OWE6ZGI6NGY6OTA6YzE6OTM6MGQuLi4KSmFuIDMxIDE1OjI0OjI1 IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjA4NjY2NjI0IHNlbnQgc2l6ZTog MTAgb3B0aW9uOiA0Mzp2ZW5kb3ItZW5jYXAgIDA2OjAxOjA4OjBhOjA0OjAwOjUwOjU4OjQ1OmZm CkphbiAzMSAxNToyNDoyNiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDQyNTg1 MjkyODAgQXZhaWxhYmxlIERIQ1AgcmFuZ2U6IDE5Mi4xNjguMzMuMTAwIC0tIDE5Mi4xNjguMzMu MTQ5CkphbiAzMSAxNToyNDoyNiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDQy NTg1MjkyODAgVmVuZG9yIGNsYXNzOiBQWEVDbGllbnQ6QXJjaDowMDAwMDpVTkRJOjAwMzAxNgpK YW4gMzEgMTU6MjQ6MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiA0MjU4NTI5 MjgwIERIQ1BESVNDT1ZFUihldGgwKSAwMDoyMzpkZjphYjo2YjozMiAKSmFuIDMxIDE1OjI0OjI2 IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogNDI1ODUyOTI4MCBESENQT0ZGRVIo ZXRoMCkgMTkyLjE2OC4zMy4xNDggMDA6MjM6ZGY6YWI6NmI6MzIgCkphbiAzMSAxNToyNDoyNiBt aWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDQyNTg1MjkyODAgcmVxdWVzdGVkIG9w dGlvbnM6IDE6bmV0bWFzaywgMjp0aW1lLW9mZnNldCwgMzpyb3V0ZXIsIDQsIDUsIApKYW4gMzEg MTU6MjQ6MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiA0MjU4NTI5MjgwIHJl cXVlc3RlZCBvcHRpb25zOiA2OmRucy1zZXJ2ZXIsIDEyOmhvc3RuYW1lLCAxMzpib290LWZpbGUt c2l6ZSwgCkphbiAzMSAxNToyNDoyNiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06 IDQyNTg1MjkyODAgcmVxdWVzdGVkIG9wdGlvbnM6IDE1OmRvbWFpbi1uYW1lLCAxNzpyb290LXBh dGgsIDE4OmV4dGVuc2lvbi1wYXRoLCAKSmFuIDMxIDE1OjI0OjI2IG1pZ2h0eWpvZXlvdW5nIGRu c21hc3EtZGhjcFs1NDU4XTogNDI1ODUyOTI4MCByZXF1ZXN0ZWQgb3B0aW9uczogMjI6bWF4LWRh dGFncmFtLXJlYXNzZW1ibHksIDIzOmRlZmF1bHQtdHRsLCAKSmFuIDMxIDE1OjI0OjI2IG1pZ2h0 eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogNDI1ODUyOTI4MCByZXF1ZXN0ZWQgb3B0aW9u czogMjg6YnJvYWRjYXN0LCA0MDpuaXMtZG9tYWluLCA0MTpuaXMtc2VydmVyLCAKSmFuIDMxIDE1 OjI0OjI2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogNDI1ODUyOTI4MCByZXF1 ZXN0ZWQgb3B0aW9uczogNDI6bnRwLXNlcnZlciwgNDM6dmVuZG9yLWVuY2FwLCA1MDpyZXF1ZXN0 ZWQtYWRkcmVzcywgCkphbiAzMSAxNToyNDoyNiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3Bb NTQ1OF06IDQyNTg1MjkyODAgcmVxdWVzdGVkIG9wdGlvbnM6IDUxOmxlYXNlLXRpbWUsIDU0OnNl cnZlci1pZGVudGlmaWVyLCA1ODpUMSwgCkphbiAzMSAxNToyNDoyNiBtaWdodHlqb2V5b3VuZyBk bnNtYXNxLWRoY3BbNTQ1OF06IDQyNTg1MjkyODAgcmVxdWVzdGVkIG9wdGlvbnM6IDU5OlQyLCA2 MDp2ZW5kb3ItY2xhc3MsIDY2OnRmdHAtc2VydmVyLCA2Nzpib290ZmlsZS1uYW1lLCAKSmFuIDMx IDE1OjI0OjI2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogNDI1ODUyOTI4MCBy ZXF1ZXN0ZWQgb3B0aW9uczogOTc6Y2xpZW50LW1hY2hpbmUtaWQsIDEyOCwgMTI5LCAxMzAsIDEz MSwgCkphbiAzMSAxNToyNDoyNiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDQy NTg1MjkyODAgcmVxdWVzdGVkIG9wdGlvbnM6IDEzMiwgMTMzLCAxMzQsIDEzNQpKYW4gMzEgMTU6 MjQ6MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiA0MjU4NTI5MjgwIHRhZ3M6 IGxhbiwgZXRoMApKYW4gMzEgMTU6MjQ6MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0 NThdOiA0MjU4NTI5MjgwIG5leHQgc2VydmVyOiAxOTIuMTY4LjMzLjEKSmFuIDMxIDE1OjI0OjI2 IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogNDI1ODUyOTI4MCBzZW50IHNpemU6 ICAxIG9wdGlvbjogNTM6bWVzc2FnZS10eXBlICAwMgpKYW4gMzEgMTU6MjQ6MjYgbWlnaHR5am9l eW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiA0MjU4NTI5MjgwIHNlbnQgc2l6ZTogIDQgb3B0aW9u OiA1NDpzZXJ2ZXItaWRlbnRpZmllciAgMTkyLjE2OC4zMy4xCkphbiAzMSAxNToyNDoyNiBtaWdo dHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDQyNTg1MjkyODAgc2VudCBzaXplOiAgNCBv cHRpb246IDUxOmxlYXNlLXRpbWUgIDAwOjAxOjUxOjgwCkphbiAzMSAxNToyNDoyNiBtaWdodHlq b2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDQyNTg1MjkyODAgc2VudCBzaXplOiAgNCBvcHRp b246IDU4OlQxICAwMDowMDphODpjMApKYW4gMzEgMTU6MjQ6MjYgbWlnaHR5am9leW91bmcgZG5z bWFzcS1kaGNwWzU0NThdOiA0MjU4NTI5MjgwIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiA1OTpUMiAg MDA6MDE6Mjc6NTAKSmFuIDMxIDE1OjI0OjI2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1 NDU4XTogNDI1ODUyOTI4MCBzZW50IHNpemU6ICA0IG9wdGlvbjogIDE6bmV0bWFzayAgMjU1LjI1 NS4yNTUuMApKYW4gMzEgMTU6MjQ6MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThd OiA0MjU4NTI5MjgwIHNlbnQgc2l6ZTogIDQgb3B0aW9uOiAyODpicm9hZGNhc3QgIDE5Mi4xNjgu MzMuMjU1CkphbiAzMSAxNToyNDoyNiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06 IDQyNTg1MjkyODAgc2VudCBzaXplOiAgOCBvcHRpb246ICA2OmRucy1zZXJ2ZXIgIDY4Ljg3Ljcx LjIyNiwgNjguODcuNzMuMjQyCkphbiAzMSAxNToyNDoyNiBtaWdodHlqb2V5b3VuZyBkbnNtYXNx LWRoY3BbNTQ1OF06IDQyNTg1MjkyODAgc2VudCBzaXplOiAgNCBvcHRpb246ICAzOnJvdXRlciAg MTkyLjE2OC4zMy4xCkphbiAzMSAxNToyNDoyNiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3Bb NTQ1OF06IDQyNTg1MjkyODAgc2VudCBzaXplOiAgOSBvcHRpb246IDYwOnZlbmRvci1jbGFzcyAg NTA6NTg6NDU6NDM6NmM6Njk6NjU6NmU6NzQKSmFuIDMxIDE1OjI0OjI2IG1pZ2h0eWpvZXlvdW5n IGRuc21hc3EtZGhjcFs1NDU4XTogNDI1ODUyOTI4MCBzZW50IHNpemU6IDE3IG9wdGlvbjogOTc6 Y2xpZW50LW1hY2hpbmUtaWQgIDAwOjIwOjBhOjU0OjYyOjA2OjlhOmRiOjRmOjkwOmMxOjkzOjBk Li4uCkphbiAzMSAxNToyNDoyNiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDQy NTg1MjkyODAgc2VudCBzaXplOiAxMCBvcHRpb246IDQzOnZlbmRvci1lbmNhcCAgMDY6MDE6MDg6 MGE6MDQ6MDA6NTA6NTg6NDU6ZmYKSmFuIDMxIDE1OjI0OjI4IG1pZ2h0eWpvZXlvdW5nIGRuc21h c3EtZGhjcFs1NDU4XTogMjIxNDA2ODIyNCBBdmFpbGFibGUgREhDUCByYW5nZTogMTkyLjE2OC4z My4xMDAgLS0gMTkyLjE2OC4zMy4xNDkKSmFuIDMxIDE1OjI0OjI4IG1pZ2h0eWpvZXlvdW5nIGRu c21hc3EtZGhjcFs1NDU4XTogMjIxNDA2ODIyNCBWZW5kb3IgY2xhc3M6IFBYRUNsaWVudDpBcmNo OjAwMDAwOlVOREk6MDAzMDE2CkphbiAzMSAxNToyNDoyOCBtaWdodHlqb2V5b3VuZyBkbnNtYXNx LWRoY3BbNTQ1OF06IDIyMTQwNjgyMjQgREhDUERJU0NPVkVSKGV0aDApIDAwOjIzOmRmOmFiOjZi OjMyIApKYW4gMzEgMTU6MjQ6MjggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAy MjE0MDY4MjI0IERIQ1BPRkZFUihldGgwKSAxOTIuMTY4LjMzLjE0OCAwMDoyMzpkZjphYjo2Yjoz MiAKSmFuIDMxIDE1OjI0OjI4IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjIx NDA2ODIyNCByZXF1ZXN0ZWQgb3B0aW9uczogMTpuZXRtYXNrLCAyOnRpbWUtb2Zmc2V0LCAzOnJv dXRlciwgNCwgNSwgCkphbiAzMSAxNToyNDoyOCBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3Bb NTQ1OF06IDIyMTQwNjgyMjQgcmVxdWVzdGVkIG9wdGlvbnM6IDY6ZG5zLXNlcnZlciwgMTI6aG9z dG5hbWUsIDEzOmJvb3QtZmlsZS1zaXplLCAKSmFuIDMxIDE1OjI0OjI4IG1pZ2h0eWpvZXlvdW5n IGRuc21hc3EtZGhjcFs1NDU4XTogMjIxNDA2ODIyNCByZXF1ZXN0ZWQgb3B0aW9uczogMTU6ZG9t YWluLW5hbWUsIDE3OnJvb3QtcGF0aCwgMTg6ZXh0ZW5zaW9uLXBhdGgsIApKYW4gMzEgMTU6MjQ6 MjggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMjE0MDY4MjI0IHJlcXVlc3Rl ZCBvcHRpb25zOiAyMjptYXgtZGF0YWdyYW0tcmVhc3NlbWJseSwgMjM6ZGVmYXVsdC10dGwsIApK YW4gMzEgMTU6MjQ6MjggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMjE0MDY4 MjI0IHJlcXVlc3RlZCBvcHRpb25zOiAyODpicm9hZGNhc3QsIDQwOm5pcy1kb21haW4sIDQxOm5p cy1zZXJ2ZXIsIApKYW4gMzEgMTU6MjQ6MjggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0 NThdOiAyMjE0MDY4MjI0IHJlcXVlc3RlZCBvcHRpb25zOiA0MjpudHAtc2VydmVyLCA0Mzp2ZW5k b3ItZW5jYXAsIDUwOnJlcXVlc3RlZC1hZGRyZXNzLCAKSmFuIDMxIDE1OjI0OjI4IG1pZ2h0eWpv ZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjIxNDA2ODIyNCByZXF1ZXN0ZWQgb3B0aW9uczog NTE6bGVhc2UtdGltZSwgNTQ6c2VydmVyLWlkZW50aWZpZXIsIDU4OlQxLCAKSmFuIDMxIDE1OjI0 OjI4IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjIxNDA2ODIyNCByZXF1ZXN0 ZWQgb3B0aW9uczogNTk6VDIsIDYwOnZlbmRvci1jbGFzcywgNjY6dGZ0cC1zZXJ2ZXIsIDY3OmJv b3RmaWxlLW5hbWUsIApKYW4gMzEgMTU6MjQ6MjggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNw WzU0NThdOiAyMjE0MDY4MjI0IHJlcXVlc3RlZCBvcHRpb25zOiA5NzpjbGllbnQtbWFjaGluZS1p ZCwgMTI4LCAxMjksIDEzMCwgMTMxLCAKSmFuIDMxIDE1OjI0OjI4IG1pZ2h0eWpvZXlvdW5nIGRu c21hc3EtZGhjcFs1NDU4XTogMjIxNDA2ODIyNCByZXF1ZXN0ZWQgb3B0aW9uczogMTMyLCAxMzMs IDEzNCwgMTM1CkphbiAzMSAxNToyNDoyOCBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1 OF06IDIyMTQwNjgyMjQgdGFnczogbGFuLCBldGgwCkphbiAzMSAxNToyNDoyOCBtaWdodHlqb2V5 b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIyMTQwNjgyMjQgbmV4dCBzZXJ2ZXI6IDE5Mi4xNjgu MzMuMQpKYW4gMzEgMTU6MjQ6MjggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAy MjE0MDY4MjI0IHNlbnQgc2l6ZTogIDEgb3B0aW9uOiA1MzptZXNzYWdlLXR5cGUgIDAyCkphbiAz MSAxNToyNDoyOCBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIyMTQwNjgyMjQg c2VudCBzaXplOiAgNCBvcHRpb246IDU0OnNlcnZlci1pZGVudGlmaWVyICAxOTIuMTY4LjMzLjEK SmFuIDMxIDE1OjI0OjI4IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjIxNDA2 ODIyNCBzZW50IHNpemU6ICA0IG9wdGlvbjogNTE6bGVhc2UtdGltZSAgMDA6MDE6NTE6ODAKSmFu IDMxIDE1OjI0OjI4IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjIxNDA2ODIy NCBzZW50IHNpemU6ICA0IG9wdGlvbjogNTg6VDEgIDAwOjAwOmE4OmMwCkphbiAzMSAxNToyNDoy OCBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIyMTQwNjgyMjQgc2VudCBzaXpl OiAgNCBvcHRpb246IDU5OlQyICAwMDowMToyNzo1MApKYW4gMzEgMTU6MjQ6MjggbWlnaHR5am9l eW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMjE0MDY4MjI0IHNlbnQgc2l6ZTogIDQgb3B0aW9u OiAgMTpuZXRtYXNrICAyNTUuMjU1LjI1NS4wCkphbiAzMSAxNToyNDoyOCBtaWdodHlqb2V5b3Vu ZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIyMTQwNjgyMjQgc2VudCBzaXplOiAgNCBvcHRpb246IDI4 OmJyb2FkY2FzdCAgMTkyLjE2OC4zMy4yNTUKSmFuIDMxIDE1OjI0OjI4IG1pZ2h0eWpvZXlvdW5n IGRuc21hc3EtZGhjcFs1NDU4XTogMjIxNDA2ODIyNCBzZW50IHNpemU6ICA4IG9wdGlvbjogIDY6 ZG5zLXNlcnZlciAgNjguODcuNzEuMjI2LCA2OC44Ny43My4yNDIKSmFuIDMxIDE1OjI0OjI4IG1p Z2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjIxNDA2ODIyNCBzZW50IHNpemU6ICA0 IG9wdGlvbjogIDM6cm91dGVyICAxOTIuMTY4LjMzLjEKSmFuIDMxIDE1OjI0OjI4IG1pZ2h0eWpv ZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjIxNDA2ODIyNCBzZW50IHNpemU6ICA5IG9wdGlv bjogNjA6dmVuZG9yLWNsYXNzICA1MDo1ODo0NTo0Mzo2Yzo2OTo2NTo2ZTo3NApKYW4gMzEgMTU6 MjQ6MjggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMjE0MDY4MjI0IHNlbnQg c2l6ZTogMTcgb3B0aW9uOiA5NzpjbGllbnQtbWFjaGluZS1pZCAgMDA6MjA6MGE6NTQ6NjI6MDY6 OWE6ZGI6NGY6OTA6YzE6OTM6MGQuLi4KSmFuIDMxIDE1OjI0OjI4IG1pZ2h0eWpvZXlvdW5nIGRu c21hc3EtZGhjcFs1NDU4XTogMjIxNDA2ODIyNCBzZW50IHNpemU6IDEwIG9wdGlvbjogNDM6dmVu ZG9yLWVuY2FwICAwNjowMTowODowYTowNDowMDo1MDo1ODo0NTpmZgo= --002354530710bfb2b0047e7be984 Content-Type: text/plain; charset=US-ASCII; name="boot-success.txt" Content-Disposition: attachment; filename="boot-success.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g54ao9d92 IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKI2JlbG93IGlzIHN1Y2Nlc2Z1bGwg Ym9vdAojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwpKYW4gMzEgMTU6MjQ6MjUg bWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMDg2NjY2MjQgQXZhaWxhYmxlIERI Q1AgcmFuZ2U6IDE5Mi4xNjguMzMuMTAwIC0tIDE5Mi4xNjguMzMuMTQ5CkphbiAzMSAxNToyNDoy NSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIwODY2NjYyNCBWZW5kb3IgY2xh c3M6IFBYRUNsaWVudDpBcmNoOjAwMDAwOlVOREk6MDAzMDE2CkphbiAzMSAxNToyNDoyNSBtaWdo dHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIwODY2NjYyNCBESENQRElTQ09WRVIoZXRo MCkgMDA6MjM6ZGY6YWI6NmI6MzIgCkphbiAzMSAxNToyNDoyNSBtaWdodHlqb2V5b3VuZyBkbnNt YXNxLWRoY3BbNTQ1OF06IDIwODY2NjYyNCBESENQT0ZGRVIoZXRoMCkgMTkyLjE2OC4zMy4xNDgg MDA6MjM6ZGY6YWI6NmI6MzIgCkphbiAzMSAxNToyNDoyNSBtaWdodHlqb2V5b3VuZyBkbnNtYXNx LWRoY3BbNTQ1OF06IDIwODY2NjYyNCByZXF1ZXN0ZWQgb3B0aW9uczogMTpuZXRtYXNrLCAyOnRp bWUtb2Zmc2V0LCAzOnJvdXRlciwgNCwgNSwgCkphbiAzMSAxNToyNDoyNSBtaWdodHlqb2V5b3Vu ZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIwODY2NjYyNCByZXF1ZXN0ZWQgb3B0aW9uczogNjpkbnMt c2VydmVyLCAxMjpob3N0bmFtZSwgMTM6Ym9vdC1maWxlLXNpemUsIApKYW4gMzEgMTU6MjQ6MjUg bWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMDg2NjY2MjQgcmVxdWVzdGVkIG9w dGlvbnM6IDE1OmRvbWFpbi1uYW1lLCAxNzpyb290LXBhdGgsIDE4OmV4dGVuc2lvbi1wYXRoLCAK SmFuIDMxIDE1OjI0OjI1IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjA4NjY2 NjI0IHJlcXVlc3RlZCBvcHRpb25zOiAyMjptYXgtZGF0YWdyYW0tcmVhc3NlbWJseSwgMjM6ZGVm YXVsdC10dGwsIApKYW4gMzEgMTU6MjQ6MjUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0 NThdOiAyMDg2NjY2MjQgcmVxdWVzdGVkIG9wdGlvbnM6IDI4OmJyb2FkY2FzdCwgNDA6bmlzLWRv bWFpbiwgNDE6bmlzLXNlcnZlciwgCkphbiAzMSAxNToyNDoyNSBtaWdodHlqb2V5b3VuZyBkbnNt YXNxLWRoY3BbNTQ1OF06IDIwODY2NjYyNCByZXF1ZXN0ZWQgb3B0aW9uczogNDI6bnRwLXNlcnZl ciwgNDM6dmVuZG9yLWVuY2FwLCA1MDpyZXF1ZXN0ZWQtYWRkcmVzcywgCkphbiAzMSAxNToyNDoy NSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIwODY2NjYyNCByZXF1ZXN0ZWQg b3B0aW9uczogNTE6bGVhc2UtdGltZSwgNTQ6c2VydmVyLWlkZW50aWZpZXIsIDU4OlQxLCAKSmFu IDMxIDE1OjI0OjI1IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjA4NjY2NjI0 IHJlcXVlc3RlZCBvcHRpb25zOiA1OTpUMiwgNjA6dmVuZG9yLWNsYXNzLCA2Njp0ZnRwLXNlcnZl ciwgNjc6Ym9vdGZpbGUtbmFtZSwgCkphbiAzMSAxNToyNDoyNSBtaWdodHlqb2V5b3VuZyBkbnNt YXNxLWRoY3BbNTQ1OF06IDIwODY2NjYyNCByZXF1ZXN0ZWQgb3B0aW9uczogOTc6Y2xpZW50LW1h Y2hpbmUtaWQsIDEyOCwgMTI5LCAxMzAsIDEzMSwgCkphbiAzMSAxNToyNDoyNSBtaWdodHlqb2V5 b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIwODY2NjYyNCByZXF1ZXN0ZWQgb3B0aW9uczogMTMy LCAxMzMsIDEzNCwgMTM1CkphbiAzMSAxNToyNDoyNSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRo Y3BbNTQ1OF06IDIwODY2NjYyNCB0YWdzOiBsYW4sIGV0aDAKSmFuIDMxIDE1OjI0OjI1IG1pZ2h0 eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjA4NjY2NjI0IG5leHQgc2VydmVyOiAxOTIu MTY4LjMzLjEKSmFuIDMxIDE1OjI0OjI1IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4 XTogMjA4NjY2NjI0IHNlbnQgc2l6ZTogIDEgb3B0aW9uOiA1MzptZXNzYWdlLXR5cGUgIDAyCkph biAzMSAxNToyNDoyNSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIwODY2NjYy NCBzZW50IHNpemU6ICA0IG9wdGlvbjogNTQ6c2VydmVyLWlkZW50aWZpZXIgIDE5Mi4xNjguMzMu MQpKYW4gMzEgMTU6MjQ6MjUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMDg2 NjY2MjQgc2VudCBzaXplOiAgNCBvcHRpb246IDUxOmxlYXNlLXRpbWUgIDAwOjAxOjUxOjgwCkph biAzMSAxNToyNDoyNSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIwODY2NjYy NCBzZW50IHNpemU6ICA0IG9wdGlvbjogNTg6VDEgIDAwOjAwOmE4OmMwCkphbiAzMSAxNToyNDoy NSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIwODY2NjYyNCBzZW50IHNpemU6 ICA0IG9wdGlvbjogNTk6VDIgIDAwOjAxOjI3OjUwCkphbiAzMSAxNToyNDoyNSBtaWdodHlqb2V5 b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIwODY2NjYyNCBzZW50IHNpemU6ICA0IG9wdGlvbjog IDE6bmV0bWFzayAgMjU1LjI1NS4yNTUuMApKYW4gMzEgMTU6MjQ6MjUgbWlnaHR5am9leW91bmcg ZG5zbWFzcS1kaGNwWzU0NThdOiAyMDg2NjY2MjQgc2VudCBzaXplOiAgNCBvcHRpb246IDI4OmJy b2FkY2FzdCAgMTkyLjE2OC4zMy4yNTUKSmFuIDMxIDE1OjI0OjI1IG1pZ2h0eWpvZXlvdW5nIGRu c21hc3EtZGhjcFs1NDU4XTogMjA4NjY2NjI0IHNlbnQgc2l6ZTogIDggb3B0aW9uOiAgNjpkbnMt c2VydmVyICA2OC44Ny43MS4yMjYsIDY4Ljg3LjczLjI0MgpKYW4gMzEgMTU6MjQ6MjUgbWlnaHR5 am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMDg2NjY2MjQgc2VudCBzaXplOiAgNCBvcHRp b246ICAzOnJvdXRlciAgMTkyLjE2OC4zMy4xCkphbiAzMSAxNToyNDoyNSBtaWdodHlqb2V5b3Vu ZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIwODY2NjYyNCBzZW50IHNpemU6ICA5IG9wdGlvbjogNjA6 dmVuZG9yLWNsYXNzICA1MDo1ODo0NTo0Mzo2Yzo2OTo2NTo2ZTo3NApKYW4gMzEgMTU6MjQ6MjUg bWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMDg2NjY2MjQgc2VudCBzaXplOiAx NyBvcHRpb246IDk3OmNsaWVudC1tYWNoaW5lLWlkICAwMDoyMDowYTo1NDo2MjowNjo5YTpkYjo0 Zjo5MDpjMTo5MzowZC4uLgpKYW4gMzEgMTU6MjQ6MjUgbWlnaHR5am9leW91bmcgZG5zbWFzcS1k aGNwWzU0NThdOiAyMDg2NjY2MjQgc2VudCBzaXplOiAxMCBvcHRpb246IDQzOnZlbmRvci1lbmNh cCAgMDY6MDE6MDg6MGE6MDQ6MDA6NTA6NTg6NDU6ZmYKSmFuIDMxIDE1OjI0OjI2IG1pZ2h0eWpv ZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogNDI1ODUyOTI4MCBBdmFpbGFibGUgREhDUCByYW5n ZTogMTkyLjE2OC4zMy4xMDAgLS0gMTkyLjE2OC4zMy4xNDkKSmFuIDMxIDE1OjI0OjI2IG1pZ2h0 eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogNDI1ODUyOTI4MCBWZW5kb3IgY2xhc3M6IFBY RUNsaWVudDpBcmNoOjAwMDAwOlVOREk6MDAzMDE2CkphbiAzMSAxNToyNDoyNiBtaWdodHlqb2V5 b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDQyNTg1MjkyODAgREhDUERJU0NPVkVSKGV0aDApIDAw OjIzOmRmOmFiOjZiOjMyIApKYW4gMzEgMTU6MjQ6MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1k aGNwWzU0NThdOiA0MjU4NTI5MjgwIERIQ1BPRkZFUihldGgwKSAxOTIuMTY4LjMzLjE0OCAwMDoy MzpkZjphYjo2YjozMiAKSmFuIDMxIDE1OjI0OjI2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhj cFs1NDU4XTogNDI1ODUyOTI4MCByZXF1ZXN0ZWQgb3B0aW9uczogMTpuZXRtYXNrLCAyOnRpbWUt b2Zmc2V0LCAzOnJvdXRlciwgNCwgNSwgCkphbiAzMSAxNToyNDoyNiBtaWdodHlqb2V5b3VuZyBk bnNtYXNxLWRoY3BbNTQ1OF06IDQyNTg1MjkyODAgcmVxdWVzdGVkIG9wdGlvbnM6IDY6ZG5zLXNl cnZlciwgMTI6aG9zdG5hbWUsIDEzOmJvb3QtZmlsZS1zaXplLCAKSmFuIDMxIDE1OjI0OjI2IG1p Z2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogNDI1ODUyOTI4MCByZXF1ZXN0ZWQgb3B0 aW9uczogMTU6ZG9tYWluLW5hbWUsIDE3OnJvb3QtcGF0aCwgMTg6ZXh0ZW5zaW9uLXBhdGgsIApK YW4gMzEgMTU6MjQ6MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiA0MjU4NTI5 MjgwIHJlcXVlc3RlZCBvcHRpb25zOiAyMjptYXgtZGF0YWdyYW0tcmVhc3NlbWJseSwgMjM6ZGVm YXVsdC10dGwsIApKYW4gMzEgMTU6MjQ6MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0 NThdOiA0MjU4NTI5MjgwIHJlcXVlc3RlZCBvcHRpb25zOiAyODpicm9hZGNhc3QsIDQwOm5pcy1k b21haW4sIDQxOm5pcy1zZXJ2ZXIsIApKYW4gMzEgMTU6MjQ6MjYgbWlnaHR5am9leW91bmcgZG5z bWFzcS1kaGNwWzU0NThdOiA0MjU4NTI5MjgwIHJlcXVlc3RlZCBvcHRpb25zOiA0MjpudHAtc2Vy dmVyLCA0Mzp2ZW5kb3ItZW5jYXAsIDUwOnJlcXVlc3RlZC1hZGRyZXNzLCAKSmFuIDMxIDE1OjI0 OjI2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogNDI1ODUyOTI4MCByZXF1ZXN0 ZWQgb3B0aW9uczogNTE6bGVhc2UtdGltZSwgNTQ6c2VydmVyLWlkZW50aWZpZXIsIDU4OlQxLCAK SmFuIDMxIDE1OjI0OjI2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogNDI1ODUy OTI4MCByZXF1ZXN0ZWQgb3B0aW9uczogNTk6VDIsIDYwOnZlbmRvci1jbGFzcywgNjY6dGZ0cC1z ZXJ2ZXIsIDY3OmJvb3RmaWxlLW5hbWUsIApKYW4gMzEgMTU6MjQ6MjYgbWlnaHR5am9leW91bmcg ZG5zbWFzcS1kaGNwWzU0NThdOiA0MjU4NTI5MjgwIHJlcXVlc3RlZCBvcHRpb25zOiA5NzpjbGll bnQtbWFjaGluZS1pZCwgMTI4LCAxMjksIDEzMCwgMTMxLCAKSmFuIDMxIDE1OjI0OjI2IG1pZ2h0 eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogNDI1ODUyOTI4MCByZXF1ZXN0ZWQgb3B0aW9u czogMTMyLCAxMzMsIDEzNCwgMTM1CkphbiAzMSAxNToyNDoyNiBtaWdodHlqb2V5b3VuZyBkbnNt YXNxLWRoY3BbNTQ1OF06IDQyNTg1MjkyODAgdGFnczogbGFuLCBldGgwCkphbiAzMSAxNToyNDoy NiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDQyNTg1MjkyODAgbmV4dCBzZXJ2 ZXI6IDE5Mi4xNjguMzMuMQpKYW4gMzEgMTU6MjQ6MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1k aGNwWzU0NThdOiA0MjU4NTI5MjgwIHNlbnQgc2l6ZTogIDEgb3B0aW9uOiA1MzptZXNzYWdlLXR5 cGUgIDAyCkphbiAzMSAxNToyNDoyNiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06 IDQyNTg1MjkyODAgc2VudCBzaXplOiAgNCBvcHRpb246IDU0OnNlcnZlci1pZGVudGlmaWVyICAx OTIuMTY4LjMzLjEKSmFuIDMxIDE1OjI0OjI2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1 NDU4XTogNDI1ODUyOTI4MCBzZW50IHNpemU6ICA0IG9wdGlvbjogNTE6bGVhc2UtdGltZSAgMDA6 MDE6NTE6ODAKSmFuIDMxIDE1OjI0OjI2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4 XTogNDI1ODUyOTI4MCBzZW50IHNpemU6ICA0IG9wdGlvbjogNTg6VDEgIDAwOjAwOmE4OmMwCkph biAzMSAxNToyNDoyNiBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDQyNTg1Mjky ODAgc2VudCBzaXplOiAgNCBvcHRpb246IDU5OlQyICAwMDowMToyNzo1MApKYW4gMzEgMTU6MjQ6 MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiA0MjU4NTI5MjgwIHNlbnQgc2l6 ZTogIDQgb3B0aW9uOiAgMTpuZXRtYXNrICAyNTUuMjU1LjI1NS4wCkphbiAzMSAxNToyNDoyNiBt aWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDQyNTg1MjkyODAgc2VudCBzaXplOiAg NCBvcHRpb246IDI4OmJyb2FkY2FzdCAgMTkyLjE2OC4zMy4yNTUKSmFuIDMxIDE1OjI0OjI2IG1p Z2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogNDI1ODUyOTI4MCBzZW50IHNpemU6ICA4 IG9wdGlvbjogIDY6ZG5zLXNlcnZlciAgNjguODcuNzEuMjI2LCA2OC44Ny43My4yNDIKSmFuIDMx IDE1OjI0OjI2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogNDI1ODUyOTI4MCBz ZW50IHNpemU6ICA0IG9wdGlvbjogIDM6cm91dGVyICAxOTIuMTY4LjMzLjEKSmFuIDMxIDE1OjI0 OjI2IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogNDI1ODUyOTI4MCBzZW50IHNp emU6ICA5IG9wdGlvbjogNjA6dmVuZG9yLWNsYXNzICA1MDo1ODo0NTo0Mzo2Yzo2OTo2NTo2ZTo3 NApKYW4gMzEgMTU6MjQ6MjYgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiA0MjU4 NTI5MjgwIHNlbnQgc2l6ZTogMTcgb3B0aW9uOiA5NzpjbGllbnQtbWFjaGluZS1pZCAgMDA6MjA6 MGE6NTQ6NjI6MDY6OWE6ZGI6NGY6OTA6YzE6OTM6MGQuLi4KSmFuIDMxIDE1OjI0OjI2IG1pZ2h0 eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogNDI1ODUyOTI4MCBzZW50IHNpemU6IDEwIG9w dGlvbjogNDM6dmVuZG9yLWVuY2FwICAwNjowMTowODowYTowNDowMDo1MDo1ODo0NTpmZgpKYW4g MzEgMTU6MjQ6MjggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMjE0MDY4MjI0 IEF2YWlsYWJsZSBESENQIHJhbmdlOiAxOTIuMTY4LjMzLjEwMCAtLSAxOTIuMTY4LjMzLjE0OQpK YW4gMzEgMTU6MjQ6MjggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMjE0MDY4 MjI0IFZlbmRvciBjbGFzczogUFhFQ2xpZW50OkFyY2g6MDAwMDA6VU5ESTowMDMwMTYKSmFuIDMx IDE1OjI0OjI4IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjIxNDA2ODIyNCBE SENQRElTQ09WRVIoZXRoMCkgMDA6MjM6ZGY6YWI6NmI6MzIgCkphbiAzMSAxNToyNDoyOCBtaWdo dHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIyMTQwNjgyMjQgREhDUE9GRkVSKGV0aDAp IDE5Mi4xNjguMzMuMTQ4IDAwOjIzOmRmOmFiOjZiOjMyIApKYW4gMzEgMTU6MjQ6MjggbWlnaHR5 am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMjE0MDY4MjI0IHJlcXVlc3RlZCBvcHRpb25z OiAxOm5ldG1hc2ssIDI6dGltZS1vZmZzZXQsIDM6cm91dGVyLCA0LCA1LCAKSmFuIDMxIDE1OjI0 OjI4IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjIxNDA2ODIyNCByZXF1ZXN0 ZWQgb3B0aW9uczogNjpkbnMtc2VydmVyLCAxMjpob3N0bmFtZSwgMTM6Ym9vdC1maWxlLXNpemUs IApKYW4gMzEgMTU6MjQ6MjggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMjE0 MDY4MjI0IHJlcXVlc3RlZCBvcHRpb25zOiAxNTpkb21haW4tbmFtZSwgMTc6cm9vdC1wYXRoLCAx ODpleHRlbnNpb24tcGF0aCwgCkphbiAzMSAxNToyNDoyOCBtaWdodHlqb2V5b3VuZyBkbnNtYXNx LWRoY3BbNTQ1OF06IDIyMTQwNjgyMjQgcmVxdWVzdGVkIG9wdGlvbnM6IDIyOm1heC1kYXRhZ3Jh bS1yZWFzc2VtYmx5LCAyMzpkZWZhdWx0LXR0bCwgCkphbiAzMSAxNToyNDoyOCBtaWdodHlqb2V5 b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIyMTQwNjgyMjQgcmVxdWVzdGVkIG9wdGlvbnM6IDI4 OmJyb2FkY2FzdCwgNDA6bmlzLWRvbWFpbiwgNDE6bmlzLXNlcnZlciwgCkphbiAzMSAxNToyNDoy OCBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIyMTQwNjgyMjQgcmVxdWVzdGVk IG9wdGlvbnM6IDQyOm50cC1zZXJ2ZXIsIDQzOnZlbmRvci1lbmNhcCwgNTA6cmVxdWVzdGVkLWFk ZHJlc3MsIApKYW4gMzEgMTU6MjQ6MjggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThd OiAyMjE0MDY4MjI0IHJlcXVlc3RlZCBvcHRpb25zOiA1MTpsZWFzZS10aW1lLCA1NDpzZXJ2ZXIt aWRlbnRpZmllciwgNTg6VDEsIApKYW4gMzEgMTU6MjQ6MjggbWlnaHR5am9leW91bmcgZG5zbWFz cS1kaGNwWzU0NThdOiAyMjE0MDY4MjI0IHJlcXVlc3RlZCBvcHRpb25zOiA1OTpUMiwgNjA6dmVu ZG9yLWNsYXNzLCA2Njp0ZnRwLXNlcnZlciwgNjc6Ym9vdGZpbGUtbmFtZSwgCkphbiAzMSAxNToy NDoyOCBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIyMTQwNjgyMjQgcmVxdWVz dGVkIG9wdGlvbnM6IDk3OmNsaWVudC1tYWNoaW5lLWlkLCAxMjgsIDEyOSwgMTMwLCAxMzEsIApK YW4gMzEgMTU6MjQ6MjggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMjE0MDY4 MjI0IHJlcXVlc3RlZCBvcHRpb25zOiAxMzIsIDEzMywgMTM0LCAxMzUKSmFuIDMxIDE1OjI0OjI4 IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjIxNDA2ODIyNCB0YWdzOiBsYW4s IGV0aDAKSmFuIDMxIDE1OjI0OjI4IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTog MjIxNDA2ODIyNCBuZXh0IHNlcnZlcjogMTkyLjE2OC4zMy4xCkphbiAzMSAxNToyNDoyOCBtaWdo dHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06IDIyMTQwNjgyMjQgc2VudCBzaXplOiAgMSBv cHRpb246IDUzOm1lc3NhZ2UtdHlwZSAgMDIKSmFuIDMxIDE1OjI0OjI4IG1pZ2h0eWpvZXlvdW5n IGRuc21hc3EtZGhjcFs1NDU4XTogMjIxNDA2ODIyNCBzZW50IHNpemU6ICA0IG9wdGlvbjogNTQ6 c2VydmVyLWlkZW50aWZpZXIgIDE5Mi4xNjguMzMuMQpKYW4gMzEgMTU6MjQ6MjggbWlnaHR5am9l eW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMjE0MDY4MjI0IHNlbnQgc2l6ZTogIDQgb3B0aW9u OiA1MTpsZWFzZS10aW1lICAwMDowMTo1MTo4MApKYW4gMzEgMTU6MjQ6MjggbWlnaHR5am9leW91 bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMjE0MDY4MjI0IHNlbnQgc2l6ZTogIDQgb3B0aW9uOiA1 ODpUMSAgMDA6MDA6YTg6YzAKSmFuIDMxIDE1OjI0OjI4IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3Et ZGhjcFs1NDU4XTogMjIxNDA2ODIyNCBzZW50IHNpemU6ICA0IG9wdGlvbjogNTk6VDIgIDAwOjAx OjI3OjUwCkphbiAzMSAxNToyNDoyOCBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNTQ1OF06 IDIyMTQwNjgyMjQgc2VudCBzaXplOiAgNCBvcHRpb246ICAxOm5ldG1hc2sgIDI1NS4yNTUuMjU1 LjAKSmFuIDMxIDE1OjI0OjI4IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs1NDU4XTogMjIx NDA2ODIyNCBzZW50IHNpemU6ICA0IG9wdGlvbjogMjg6YnJvYWRjYXN0ICAxOTIuMTY4LjMzLjI1 NQpKYW4gMzEgMTU6MjQ6MjggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMjE0 MDY4MjI0IHNlbnQgc2l6ZTogIDggb3B0aW9uOiAgNjpkbnMtc2VydmVyICA2OC44Ny43MS4yMjYs IDY4Ljg3LjczLjI0MgpKYW4gMzEgMTU6MjQ6MjggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNw WzU0NThdOiAyMjE0MDY4MjI0IHNlbnQgc2l6ZTogIDQgb3B0aW9uOiAgMzpyb3V0ZXIgIDE5Mi4x NjguMzMuMQpKYW4gMzEgMTU6MjQ6MjggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThd OiAyMjE0MDY4MjI0IHNlbnQgc2l6ZTogIDkgb3B0aW9uOiA2MDp2ZW5kb3ItY2xhc3MgIDUwOjU4 OjQ1OjQzOjZjOjY5OjY1OjZlOjc0CkphbiAzMSAxNToyNDoyOCBtaWdodHlqb2V5b3VuZyBkbnNt YXNxLWRoY3BbNTQ1OF06IDIyMTQwNjgyMjQgc2VudCBzaXplOiAxNyBvcHRpb246IDk3OmNsaWVu dC1tYWNoaW5lLWlkICAwMDoyMDowYTo1NDo2MjowNjo5YTpkYjo0Zjo5MDpjMTo5MzowZC4uLgpK YW4gMzEgMTU6MjQ6MjggbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzU0NThdOiAyMjE0MDY4 MjI0IHNlbnQgc2l6ZTogMTAgb3B0aW9uOiA0Mzp2ZW5kb3ItZW5jYXAgIDA2OjAxOjA4OjBhOjA0 OjAwOjUwOjU4OjQ1OmZmCkphbiAzMSAxNToyNTo0NSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRo Y3BbNzA1Nl06IERIQ1AsIElQIHJhbmdlIDE5Mi4xNjguMzMuMTAwIC0tIDE5Mi4xNjguMzMuMTQ5 LCBsZWFzZSB0aW1lIDFkCkphbiAzMSAxNToyNjoxNyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRo Y3BbNzA1Nl06IDI4Nzk2IEF2YWlsYWJsZSBESENQIHJhbmdlOiAxOTIuMTY4LjMzLjEwMCAtLSAx OTIuMTY4LjMzLjE0OQpKYW4gMzEgMTU6MjY6MTcgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNw WzcwNTZdOiAyODc5NiBWZW5kb3IgY2xhc3M6IEFBUExCU0RQQy9pMzg2L01hY0Jvb2s1LDEKSmFu IDMxIDE1OjI2OjE3IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs3MDU2XTogMjg3OTYgREhD UERJU0NPVkVSKGV0aDApIDAwOjIzOmRmOmFiOjZiOjMyIApKYW4gMzEgMTU6MjY6MTcgbWlnaHR5 am9leW91bmcgZG5zbWFzcS1kaGNwWzcwNTZdOiAyODc5NiBESENQT0ZGRVIoZXRoMCkgMTkyLjE2 OC4zMy4xNDggMDA6MjM6ZGY6YWI6NmI6MzIgCkphbiAzMSAxNToyNjoxNyBtaWdodHlqb2V5b3Vu ZyBkbnNtYXNxLWRoY3BbNzA1Nl06IDI4Nzk2IHJlcXVlc3RlZCBvcHRpb25zOiAxOm5ldG1hc2ss IDM6cm91dGVyLCA2Nzpib290ZmlsZS1uYW1lLCA0Mzp2ZW5kb3ItZW5jYXAsIApKYW4gMzEgMTU6 MjY6MTcgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzcwNTZdOiAyODc5NiByZXF1ZXN0ZWQg b3B0aW9uczogNjA6dmVuZG9yLWNsYXNzCkphbiAzMSAxNToyNjoxNyBtaWdodHlqb2V5b3VuZyBk bnNtYXNxLWRoY3BbNzA1Nl06IDI4Nzk2IHRhZ3M6IGxhbiwgZXRoMApKYW4gMzEgMTU6MjY6MTcg bWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzcwNTZdOiAyODc5NiBuZXh0IHNlcnZlcjogMTky LjE2OC4zMy4xCkphbiAzMSAxNToyNjoxNyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNzA1 Nl06IDI4Nzk2IHNlbnQgc2l6ZTogIDEgb3B0aW9uOiA1MzptZXNzYWdlLXR5cGUgIDAyCkphbiAz MSAxNToyNjoxNyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNzA1Nl06IDI4Nzk2IHNlbnQg c2l6ZTogIDQgb3B0aW9uOiA1NDpzZXJ2ZXItaWRlbnRpZmllciAgMTkyLjE2OC4zMy4xCkphbiAz MSAxNToyNjoxNyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNzA1Nl06IDI4Nzk2IHNlbnQg c2l6ZTogIDQgb3B0aW9uOiA1MTpsZWFzZS10aW1lICAwMDowMTo1MTo4MApKYW4gMzEgMTU6MjY6 MTcgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzcwNTZdOiAyODc5NiBzZW50IHNpemU6ICA0 IG9wdGlvbjogNTg6VDEgIDAwOjAwOmE4OmMwCkphbiAzMSAxNToyNjoxNyBtaWdodHlqb2V5b3Vu ZyBkbnNtYXNxLWRoY3BbNzA1Nl06IDI4Nzk2IHNlbnQgc2l6ZTogIDQgb3B0aW9uOiA1OTpUMiAg MDA6MDE6Mjc6NTAKSmFuIDMxIDE1OjI2OjE3IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs3 MDU2XTogMjg3OTYgc2VudCBzaXplOiAgNCBvcHRpb246ICAxOm5ldG1hc2sgIDI1NS4yNTUuMjU1 LjAKSmFuIDMxIDE1OjI2OjE3IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs3MDU2XTogMjg3 OTYgc2VudCBzaXplOiAgNCBvcHRpb246IDI4OmJyb2FkY2FzdCAgMTkyLjE2OC4zMy4yNTUKSmFu IDMxIDE1OjI2OjE3IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs3MDU2XTogMjg3OTYgc2Vu dCBzaXplOiAzMSBvcHRpb246IDY3OmJvb3RmaWxlLW5hbWUgIDQ0OjY5OjYxOjY3OjMxOjMwOjM2 OjRlOjY1Ojc0OjQyOjZmOjZmLi4uCkphbiAzMSAxNToyNjoxNyBtaWdodHlqb2V5b3VuZyBkbnNt YXNxLWRoY3BbNzA1Nl06IDI4Nzk2IHNlbnQgc2l6ZTogNjUgb3B0aW9uOiAxNzpyb290LXBhdGgg IDZlOjY2OjczOjNhOjMxOjM5OjMyOjJlOjMxOjM2OjM4OjJlOjMzLi4uCkphbiAzMSAxNToyNjox NyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNzA1Nl06IDI4Nzk2IHNlbnQgc2l6ZTogMTQg b3B0aW9uOiA2MDp2ZW5kb3ItY2xhc3MgIDQxOjQxOjUwOjRjOjQyOjUzOjQ0OjUwOjQzOjJmOjY5 OjMzOjM4Li4uCkphbiAzMSAxNToyNjoxNyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNzA1 Nl06IDI4Nzk2IHNlbnQgc2l6ZTogIDYgb3B0aW9uOiA0Mzp2ZW5kb3ItZW5jYXAgIDA4OjA0Ojgx OjAwOjAwOjY3CkphbiAzMSAxNToyNjoxNyBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNzA1 Nl06IDI4Nzk2IHNlbnQgc2l6ZTogIDQgb3B0aW9uOiAgMzpyb3V0ZXIgIDE5Mi4xNjguMzMuMQpK YW4gMzEgMTU6MjY6MTkgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzcwNTZdOiAyODc5NiBB dmFpbGFibGUgREhDUCByYW5nZTogMTkyLjE2OC4zMy4xMDAgLS0gMTkyLjE2OC4zMy4xNDkKSmFu IDMxIDE1OjI2OjE5IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs3MDU2XTogMjg3OTYgVmVu ZG9yIGNsYXNzOiBBQVBMQlNEUEMvaTM4Ni9NYWNCb29rNSwxCkphbiAzMSAxNToyNjoxOSBtaWdo dHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNzA1Nl06IDI4Nzk2IERIQ1BSRVFVRVNUKGV0aDApIDE5 Mi4xNjguMzMuMTQ4IDAwOjIzOmRmOmFiOjZiOjMyIApKYW4gMzEgMTU6MjY6MTkgbWlnaHR5am9l eW91bmcgZG5zbWFzcS1kaGNwWzcwNTZdOiAyODc5NiBESENQQUNLKGV0aDApIDE5Mi4xNjguMzMu MTQ4IDAwOjIzOmRmOmFiOjZiOjMyIApKYW4gMzEgMTU6MjY6MTkgbWlnaHR5am9leW91bmcgZG5z bWFzcS1kaGNwWzcwNTZdOiAyODc5NiByZXF1ZXN0ZWQgb3B0aW9uczogMTpuZXRtYXNrLCAzOnJv dXRlciwgNjc6Ym9vdGZpbGUtbmFtZSwgNDM6dmVuZG9yLWVuY2FwLCAKSmFuIDMxIDE1OjI2OjE5 IG1pZ2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs3MDU2XTogMjg3OTYgcmVxdWVzdGVkIG9wdGlv bnM6IDYwOnZlbmRvci1jbGFzcwpKYW4gMzEgMTU6MjY6MTkgbWlnaHR5am9leW91bmcgZG5zbWFz cS1kaGNwWzcwNTZdOiAyODc5NiB0YWdzOiBsYW4sIGV0aDAKSmFuIDMxIDE1OjI2OjE5IG1pZ2h0 eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs3MDU2XTogMjg3OTYgbmV4dCBzZXJ2ZXI6IDE5Mi4xNjgu MzMuMQpKYW4gMzEgMTU6MjY6MTkgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzcwNTZdOiAy ODc5NiBzZW50IHNpemU6ICAxIG9wdGlvbjogNTM6bWVzc2FnZS10eXBlICAwNQpKYW4gMzEgMTU6 MjY6MTkgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzcwNTZdOiAyODc5NiBzZW50IHNpemU6 ICA0IG9wdGlvbjogNTQ6c2VydmVyLWlkZW50aWZpZXIgIDE5Mi4xNjguMzMuMQpKYW4gMzEgMTU6 MjY6MTkgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzcwNTZdOiAyODc5NiBzZW50IHNpemU6 ICA0IG9wdGlvbjogNTE6bGVhc2UtdGltZSAgMDA6MDE6NTE6ODAKSmFuIDMxIDE1OjI2OjE5IG1p Z2h0eWpvZXlvdW5nIGRuc21hc3EtZGhjcFs3MDU2XTogMjg3OTYgc2VudCBzaXplOiAgNCBvcHRp b246IDU4OlQxICAwMDowMDphODpjMApKYW4gMzEgMTU6MjY6MTkgbWlnaHR5am9leW91bmcgZG5z bWFzcS1kaGNwWzcwNTZdOiAyODc5NiBzZW50IHNpemU6ICA0IG9wdGlvbjogNTk6VDIgIDAwOjAx OjI3OjUwCkphbiAzMSAxNToyNjoxOSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNzA1Nl06 IDI4Nzk2IHNlbnQgc2l6ZTogIDQgb3B0aW9uOiAgMTpuZXRtYXNrICAyNTUuMjU1LjI1NS4wCkph biAzMSAxNToyNjoxOSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNzA1Nl06IDI4Nzk2IHNl bnQgc2l6ZTogIDQgb3B0aW9uOiAyODpicm9hZGNhc3QgIDE5Mi4xNjguMzMuMjU1CkphbiAzMSAx NToyNjoxOSBtaWdodHlqb2V5b3VuZyBkbnNtYXNxLWRoY3BbNzA1Nl06IDI4Nzk2IHNlbnQgc2l6 ZTogMzEgb3B0aW9uOiA2Nzpib290ZmlsZS1uYW1lICA0NDo2OTo2MTo2NzozMTozMDozNjo0ZTo2 NTo3NDo0Mjo2Zjo2Zi4uLgpKYW4gMzEgMTU6MjY6MTkgbWlnaHR5am9leW91bmcgZG5zbWFzcS1k aGNwWzcwNTZdOiAyODc5NiBzZW50IHNpemU6IDY1IG9wdGlvbjogMTc6cm9vdC1wYXRoICA2ZTo2 Njo3MzozYTozMTozOTozMjoyZTozMTozNjozODoyZTozMy4uLgpKYW4gMzEgMTU6MjY6MTkgbWln aHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzcwNTZdOiAyODc5NiBzZW50IHNpemU6IDE0IG9wdGlv bjogNjA6dmVuZG9yLWNsYXNzICA0MTo0MTo1MDo0Yzo0Mjo1Mzo0NDo1MDo0MzoyZjo2OTozMzoz OC4uLgpKYW4gMzEgMTU6MjY6MTkgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzcwNTZdOiAy ODc5NiBzZW50IHNpemU6ICA2IG9wdGlvbjogNDM6dmVuZG9yLWVuY2FwICAwODowNDo4MTowMDow MDo2NwpKYW4gMzEgMTU6MjY6MTkgbWlnaHR5am9leW91bmcgZG5zbWFzcS1kaGNwWzcwNTZdOiAy ODc5NiBzZW50IHNpemU6ICA0IG9wdGlvbjogIDM6cm91dGVyICAxOTIuMTY4LjMzLjEK --002354530710bfb2b0047e7be984 Content-Type: application/octet-stream; name="dnsmasq.conf" Content-Disposition: attachment; filename="dnsmasq.conf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g54as1p43 aW50ZXJmYWNlPWV0aDAKcmVzb2x2LWZpbGU9L3RtcC9yZXNvbHYuZG5zbWFzcQpkaGNwLWxlYXNl ZmlsZT0vdG1wL2Ruc21hc3EubGVhc2VzCmRoY3AtbGVhc2UtbWF4PTU1CmRoY3Atb3B0aW9uPWxh biwzLDE5Mi4xNjguMzMuMQpkaGNwLW9wdGlvbj02LDY4Ljg3LjcxLjIyNiw2OC44Ny43My4yNDIK ZGhjcC1hdXRob3JpdGF0aXZlCmRoY3AtcmFuZ2U9bGFuLDE5Mi4xNjguMzMuMTAwLDE5Mi4xNjgu MzMuMTQ5LDI1NS4yNTUuMjU1LjAsMTQ0MG0KI2RoY3AtYm9vdD1weGVsaW51eC4wLDE5Mi4xNjgu MzMuMSwxOTIuMTY4LjMzLjEKI2RoY3Atb3B0aW9uLWZvcmNlPTIwOCxmMTowMDo3NDo3ZQojZGhj cC1vcHRpb24tZm9yY2U9MjA5LHB4ZWxpbnV4LmNmZy9kZWZhdWx0CgoKI3dvcmtpbmcgYnV0IGRv ZXMgbm90IGRlc2NyaW1pbmF0ZSB3aGljaCBtYWNoaW5lcyBpdCBzZW5kcyBpbmZvIHRvCmRoY3At b3B0aW9uLWZvcmNlPTQzLDA4OjA0OjgxOjAwOjAwOjY3CmRoY3Atb3B0aW9uLWZvcmNlPTYwLCJB QVBMQlNEUEMvaTM4NiIKZGhjcC1vcHRpb24tZm9yY2U9MTcsIm5mczoxOTIuMTY4LjMzLjE6L3Zh ci9saWIvdGZ0cGJvb3Q6RGlhZzEwNk5ldEJvb3QubmJpL05ldEJvb3QuZG1nIgpkaGNwLW9wdGlv bi1mb3JjZT02NywiRGlhZzEwNk5ldEJvb3QubmJpL2kzODYvYm9vdGVyIgoKI25vbiB3b3JraW5n LCBkb2VzIG5vdCBzZW5kIG9wdGlvbiA2MCB0byBjbGllbnQKZGhjcC12ZW5kb3JjbGFzcz1hcHBs ZS1ib290LCJBUFBMQlNEUEMvaTM4NiIKZGhjcC1vcHRpb24tZm9yY2U9YXBwbGUtYm9vdCw0Myww ODowNDo4MTowMDowMDo2NwpkaGNwLW9wdGlvbi1mb3JjZT1hcHBsZS1ib290LDYwLCJBQVBMQlNE UEMvaTM4NiIKZGhjcC1vcHRpb24tZm9yY2U9YXBwbGUtYm9vdCwxNywibmZzOjE5Mi4xNjguMzMu MTovdmFyL2xpYi90ZnRwYm9vdDpEaWFnMTA2TmV0Qm9vdC5uYmkvTmV0Qm9vdC5kbWciCmRoY3At b3B0aW9uLWZvcmNlPWFwcGxlLWJvb3QsNjcsIkRpYWcxMDZOZXRCb290Lm5iaS9pMzg2L2Jvb3Rl ciIK --002354530710bfb2b0047e7be984-- From bogus@does.not.exist.com Mon Sep 7 11:48:48 2009 From: bogus@does.not.exist.com () Date: Mon, 07 Sep 2009 10:48:48 -0000 Subject: No subject Message-ID: o be "dhcp-option-force", since the client is requesting them all= .


dhcp-option-force=3Dapple-boot,43,08:04:81:00:00:67
Assuming fixing the typo gets you the "apple-boot" tag, try chang= ing this to

dhcp-option=3Dvendor:AAPLBSDPC/i386,8,81:00:00:67

And let dnsmasq do the vendor encapsulation. You should end up with the sam= e data sent, but it's clearer what's happening.



dhcp-option-force=3Dapple-boot,60,"AAPLBSDPC/i386"
As an experiment, omit this. the result will be that dnsmasq echoes back th= e vendor-class which the client sent, "AAPLBSDPC/i386/MacBook5,1"= That may be OK for Apple, it may not be, but worth a try.


dhcp-option-force=3Dapple-boot,17,"nfs:192.168.33.1:/var/lib/tftpboot:= Diag106NetBoot.nbi/NetBoot.dmg"
dhcp-option-force=3Dapple-boot,67,"Diag106NetBoot.nbi/i386/booter"= ;


> Any thoughts? =A0I could remove the quotes from the vendor class and t= ry =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 > again.<= br>
It'll make no difference. The quotes will be stripped, if they're t= here but they are not needed as the string doesn't include any meta-cha= racters. Safer to have the quotes.


> =A0Do I need to do anything special to indicate that
> APPLBSDPC/i386 is only the beginning of the vendor class?

No, dhcp-vendorclass will match as long as the match string is a substring = of the actual vendor-class string.


HTH


Simon.


--0015173ff8ce3f2658047eb5cc84-- From bogus@does.not.exist.com Mon Sep 7 11:48:48 2009 From: bogus@does.not.exist.com () Date: Mon, 07 Sep 2009 10:48:48 -0000 Subject: No subject Message-ID: done is to serve a single non-mac-specific ip address as below=2C but I fig= ured I'd ask just to be sure. Thanks! from /etc/dnsmasq.conf # Uncomment this to enable the integrated DHCP server=2C you need # to supply the range of addresses available for lease and optionally # a lease time. If you have more than one network=2C you will need to # repeat this for each network on which you want to supply DHCP # service. dhcp-range=3D192.168.0.50=2C192.168.0.50=2C12h =20 _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/201469227/direct/01/= --_74dcb8cb-2371-44e6-8a22-773b74cdf08b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We use static ips on all our networks=2C but we have two laptops that migra= te between networks. =3B Is there a way to enable the dhcp server so th= at it will just serve designated mac addresses as designated in the dhcp-ho= st directives?

From the dnsmasq=2C it looks like the answer is no=3B= the best that can be done is to serve a single non-mac-specific ip address= as below=2C but I figured I'd ask just to be sure.

Thanks!

f= rom /etc/dnsmasq.conf

# Uncomment this to enable the integrated DHCP= server=2C you need
# to supply the range of addresses available for lea= se and optionally
# a lease time. If you have more than one network=2C y= ou will need to
# repeat this for each network on which you want to supp= ly DHCP
# service.
dhcp-range=3D192.168.0.50=2C192.168.0.50=2C12h
=

Hotmail: Trusted email with powerful SPAM prote= ction. Sign up now. = --_74dcb8cb-2371-44e6-8a22-773b74cdf08b_-- From bogus@does.not.exist.com Mon Sep 7 11:48:48 2009 From: bogus@does.not.exist.com () Date: Mon, 07 Sep 2009 10:48:48 -0000 Subject: No subject Message-ID: --dhcp-hostsfile= Read DHCP host information from the specified file. The file contains information about one host per line. The format of a line is the same as text to the right of '=' in --dhcp-host.