Re: [Dnsmasq-discuss] leases file only contains a single entry, FAQ

2019-07-28 Thread Geert Stappers
On Wed, Jul 24, 2019 at 11:20:41PM -0400, Joseph Muro wrote:
> Hi,
> 
> The dnsmasq.leases file only contains a single entry, even though 3 DHCP
> leases have been acknowledged.
> 
> Here is content of leases file:
> 
> 1564110359 52:54:00:da:34:b0 10.20.102.208 *
> > ff:00:d9:85:be:00:01:00:01:24:95:20:a9:52:54:00:d9:85:be
> 
> 
> Here is snippet of configuration:
> 
> >
> > pid-file=/home/jmuro/dnsmasq/10.20.102/dnsmasq.pid
> > dhcp-hostsfile=/home/jmuro/dnsmasq/10.20.102/hostsfile
> > addn-hosts=/home/jmuro/dnsmasq/10.20.102/addnhosts
> > dhcp-leasefile=/home/jmuro/dnsmasq/10.20.102/dnsmasq.leases
> >
> > # Log options
> > log-facility=/home/jmuro/dnsmasq/10.20.102/dnsmasq.log
> > log-queries=extra
> > log-dhcp
> 
> 
> I attached log file.
> 
> What am I missing?

Not you, this project is missing FAQ answers list.

| Q: Why don't I see all leases in the leases file?
| A: MAC-address IP-address configuration reseverations
|don't get an entry in the lease file.
|
| Q: Why are there recently so few releases?
| A: Dnsmasq is mature code that is maintained.
|
| Q: How to get a submitted patch reviewed?
| A: Good question. It is OK to send them again.
|
| Q: Why is my posting to the mailinglist ignored?
| A: Nothing personal, but probably personal.
|Rewrite _your_ posting so that it isn't _your_ problem,
|but something that appeals the dnsmasq mailinglist subscribers.
|See Eric S. Raymond "How to ask smart questions?" for advice.


Groeten
Geert Stappers
-- 
Leven en laten leven


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


Re: [Dnsmasq-discuss] RESOLVED: dnsmaq on OpenWRT, configuration question

2019-07-28 Thread Geert Stappers
On Sun, Jul 28, 2019 at 02:36:29PM -0400, Art Greenberg wrote:
> DNS from the Roku streamers is working as it should.
> 
> I am not sure idea why.
> 
> I learned a little about tcpdump and ran it on the router while using
> nslookup and dig on a Linux machine to learn how to use tcpdump and
> to see what "normal" traffic looked like.
> 
> In my dnsmasq.conf, I took the "net:red" tags off of the dhcp-host
> assignments for the Rokus, and waited for DHCP lease renewals. Then
> I used tcpdump on the router to observe incoming DNS requests and saw
> that they were addressing the router.
> 
> Then I put the "net:red" tags back on the dhcp-host assignments,
> and again waited for DHCP lease renewals. Again using tcpdump on the
> router to observe incoming DNS requests I saw the Rokus were indeed
> talking to the assigned DNS server at 1.1.1.1, and lo and behold the
> apps that were previously not working due to failing to access their
> advertising servers are now working.
> 
> I'm preplexed. I am sure I've changed nothing else, but in all of the
> thrashing around to figure out what is happening I must have touched
> something that mattered.
> 
> Thank you to all who offered advice. I know more about networking and
> my new router now thanks to your input, and that's a definite positive.

 :-)

and thanks for reporting that it is solved.


Groeten
Geert Stappers
-- 
Leven en laten leven

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


[Dnsmasq-discuss] RESOLVED: dnsmaq on OpenWRT, configuration question

2019-07-28 Thread Art Greenberg
DNS from the Roku streamers is working as it should.

I am not sure idea why.

I learned a little about tcpdump and ran it on the router while using nslookup 
and dig on a Linux machine to learn how to use tcpdump and to see what "normal" 
traffic looked like.

In my dnsmasq.conf, I took the "net:red" tags off of the dhcp-host assignments 
for the Rokus, and waited for DHCP lease renewals. Then I used tcpdump on the 
router to observe incoming DNS requests and saw that they were addressing the 
router.

Then I put the "net:red" tags back on the dhcp-host assignments, and again 
waited for DHCP lease renewals. Again using tcpdump on the router to observe 
incoming DNS requests I saw the Rokus were indeed talking to the assigned DNS 
server at 1.1.1.1, and lo and behold the apps that were previously not working 
due to failing to access their advertising servers are now working.

I'm preplexed. I am sure I've changed nothing else, but in all of the thrashing 
around to figure out what is happening I must have touched something that 
mattered.

Thank you to all who offered advice. I know more about networking and my new 
router now thanks to your input, and that's a definite positive.

-- 
Art Greenberg
a...@artg.tv


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


Re: [Dnsmasq-discuss] dnsmaq on OpenWRT, configuration question

2019-07-28 Thread Kevin Darbyshire-Bryant


> On 27 Jul 2019, at 16:34, Art Greenberg  wrote:
> 
> I had been running dnsmasq on a machine on my network and using addn-hosts 
> for ad blocking. My router was configured with my ISP's DNS servers.
> 
> I used "net:red" to assign the router as DNS server for certain devices (Roku 
> streamers, notably) to avoid the ad blocking, because some of the apps on the 
> router would not work properly with the ad blocking in place. This told those 
> devices to go directly to the router for DNS services.
> 
> router/gateway 192.168.2.1
> dnsmasq machine 192.168.2.11
> 
> ## dnsmasq.conf fragment
> 
> domain-needed
> bogus-priv
> no-resolv
> local=/artg.tv/
> interface=eth0
> domain=artg.tv
> server=8.8.8.8,8.8.4.4
> 
> dhcp-option=option:dns-server,192.168.2.11
>  ## use dnsmasq machine for DNS
> dhcp-option=net:red,option:dns-server,192.168.2.1
> 
> dhcp-host=00:01:03:27:84:95,192.168.2.15,martha   
>  ## typical of computer assignments
> dhcp-host=d8:31:34:36:d0:18,192.168.2.135,ROKU-1-WIFI,net:red## typical 
> of ad blocking avoidance
> 
> ## end dnsmasq.conf fragment
> 
> This all worked fine.
> 
> Then I obtained a newer router and installed OpenWRT on it. This, too, worked 
> fine until I moved dnsmasq onto the router. The configuration now looks like 
> this:
> 
> router/gateway 192.168.2.1
> dnsmasq machine 192.168.2.1
> 
> ## dnsmasq.conf fragment
> 
> domain-needed
> bogus-priv
> no-resolv
> local=/artg.tv/
> interface=br-lan
> domain=artg.tv
> server=8.8.8.8,8.8.4.4
> 
> dhcp-option=option:dns-server,192.168.2.1 
>## use dnsmasq on the router for DNS
> dhcp-option=net:red,option:dns-server,8.8.8.8,8.8.4.4
> ## Google public DNS servers
> 
> dhcp-host=00:01:03:27:84:95,192.168.2.15,martha   
>  ## typical of computer assignments
> dhcp-host=d8:31:34:36:d0:18,192.168.2.135,ROKU-1-WIFI,net:red## typical 
> of ad blocking avoidance
> 
> Now the Roku streamers and some of the apps on them aren't so happy. Despite 
> the "net:red" tag, dnsmasq is intercepting all DNS requests and it is 
> returning 0.0.0.0 when the host being looked up is in one of the addn-hosts 
> files.

dnsmasq won’t be intercepting requests, it will answer requests that are sent 
to it.  It doesn’t snoop on the wire looking for requests to hijack.

That sort of behaviour can be configured with firewall rules, ie. redirect any 
packets sent to port 53 on this host to another host/port combination.  Indeed 
adblock itself has this exact option to do so, it’s called 'option 
adb_forcedns’.  It would be worth checking this is set to ‘0’.

Also it would be worth checking on the router that something else hasn’t done 
this sort of redirection.

adblock implements it with the following rules:

iptables -v -t nat -L | grep -i adblock
0 0 REDIRECT   tcp  --  anyany anywhere anywhere
 tcp dpt:domain /* !fw3: Adblock DNS, port 53 */ redir ports 53
   30  2164 REDIRECT   udp  --  anyany anywhere anywhere
 udp dpt:domain /* !fw3: Adblock DNS, port 53 */ redir ports 53
0 0 REDIRECT   tcp  --  anyany anywhere anywhere
 tcp dpt:853 /* !fw3: Adblock DNS, port 853 */ redir ports 853
0 0 REDIRECT   udp  --  anyany anywhere anywhere
 udp dpt:853 /* !fw3: Adblock DNS, port 853 */ redir ports 853
0 0 REDIRECT   tcp  --  anyany anywhere anywhere
 tcp dpt:mdns /* !fw3: Adblock DNS, port 5353 */ redir ports 5353
   32  9171 REDIRECT   udp  --  anyany anywhere anywhere
 udp dpt:mdns /* !fw3: Adblock DNS, port 5353 */ redir ports 5353



Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] dnsmaq on OpenWRT, configuration question

2019-07-28 Thread Art Greenberg
On Sun, Jul 28, 2019, at 10:41, Kevin Darbyshire-Bryant wrote:

> dnsmasq won’t be intercepting requests, it will answer requests that 
> are sent to it.  It doesn’t snoop on the wire looking for requests to 
> hijack.

So, how does DNS on my network work then? All of the machines on my network are 
configured via DHCP to go to the router at 192.168.2.1:53 for DNS requests. 
Doesn't dnsmasq see those requests, and forward on the ones it cannot answer 
locally to the configured servers?

> That sort of behaviour can be configured with firewall rules, ie. 
> redirect any packets sent to port 53 on this host to another host/port 
> combination.  Indeed adblock itself has this exact option to do so, 
> it’s called 'option adb_forcedns’.  It would be worth checking this is 
> set to ‘0’.

I'm not using AdBlock. Instead, I have specified the addn-hosts option in 
dnsmasq and those files contain blocked servers with an IP address of 0.0.0.0.
 
> Also it would be worth checking on the router that something else 
> hasn’t done this sort of redirection.

Yes. I'm new to iptables et. al. so its becoming quite the learning opportunity.
 
> adblock implements it with the following rules:

There should be no AdBlock related rules in my firewall as I'm not using it, 
but I'll be looking at what is there.
 
> Cheers,
> 
> Kevin D-B

-- 
Art Greenberg
a...@artg.tv


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


Re: [Dnsmasq-discuss] dnsmaq on OpenWRT, configuration question

2019-07-28 Thread Art Greenberg
On Sun, Jul 28, 2019, at 09:59, john doe wrote:
> This might void your warranty but accessing the Roku using Telnet might
> be worth a try 'telnet roku-ip-address 8085' (1).
> 
> 
> On the roku, can you specify the DNS server(s) manually?
> 
> 
> The URL (2) was found when googling.
> 
> 
> 1)
> https://developer.roku.com/en-gb/docs/developer-program/debugging/debugging-channels.md
> 2)
> https://lifehacker.com/all-the-roku-secret-commands-and-menus-in-one-graphic-1779010902
> 
> --
> John Doe

Thanks for that.

You cannot set anything other than wireless SSID manually two of the Roku 
devices I have, and you can only see the DHCP-assigned IP address. The third 
has a wired network connection in addition to WiFi, but I don't recall how that 
is set up. I'll have to look. They're all recent models with up to date 
firmware.

I've seen quite a bit of "secret menu" information already. A lot of it is out 
of date. Many of the secret menu key sequences no longer work, and those that 
do don't show IP details that aren't already available normally.

The developer info is interesting, but I didn't find anything about seeing IP 
details. Apparently telnet doesn't drop into a general purpose shell, but 
rather one of a few in-built debugging consoles with a focus on app developers. 
I'll poke around a bit more. I should sign up as a developer - maybe there is a 
way to write an app that will display that information. LOL.

-- 
Art Greenberg
a...@artg.tv


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


Re: [Dnsmasq-discuss] dnsmaq on OpenWRT, configuration question

2019-07-28 Thread john doe
On 7/28/2019 1:46 PM, Art Greenberg wrote:
> On Sun, Jul 28, 2019, at 02:41, Geert Stappers wrote:
>> I think that "aren't so happy" needs elaboration.
>
> I don't know if you're familiar with the Roku. Its a streaming platform, and 
> service providers like Netflix and HBO have written applications that run on 
> the platform to play their "entertainment" content. Some of those 
> applications insert advertising into that content in real time - the 
> advertisements are not embedded in the content. When the application detects 
> that its unable to source advertising, it refuses to play the content.
>
>>> Yet when they make a DNS request, its being processed by dnsmasq
>>
>> That is _not supposed_ to happen.
>
>>> and the add-hosts files are being consulted,
>>
>> Because the "red" hosts are on the wrong track ...
>
> OK.
>
>>> Is there a simpler way to deal with this?
>>
>> Yes and you are almost there.
>>
>> Explore why red hosts resolve via 192.168.2.1, they shouldn't.
>
> OK.
>
>>> I cannot tell what the Roku streamers have assigned. The UI doesn't expose 
>>> that information.
>>
>> Report that annoying inconvenience at https://support.roku.com/en-gb/
>
> Hahaha. I'll certainly try that. If there isn't already a hidden way to get 
> that information, don't have any expectation that asking for something like 
> that to be implemented will do much good in the short term, at least.
>

This might void your warranty but accessing the Roku using Telnet might
be worth a try 'telnet roku-ip-address 8085' (1).


On the roku, can you specify the DNS server(s) manually?


The URL (2) was found when googling.


1)
https://developer.roku.com/en-gb/docs/developer-program/debugging/debugging-channels.md
2)
https://lifehacker.com/all-the-roku-secret-commands-and-menus-in-one-graphic-1779010902

--
John Doe

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


Re: [Dnsmasq-discuss] dnsmaq on OpenWRT, configuration question

2019-07-28 Thread Art Greenberg
On Sun, Jul 28, 2019, at 02:41, Geert Stappers wrote:
> I think that "aren't so happy" needs elaboration.

I don't know if you're familiar with the Roku. Its a streaming platform, and 
service providers like Netflix and HBO have written applications that run on 
the platform to play their "entertainment" content. Some of those applications 
insert advertising into that content in real time - the advertisements are not 
embedded in the content. When the application detects that its unable to source 
advertising, it refuses to play the content.
 
> > Yet when they make a DNS request, its being processed by dnsmasq
> 
> That is _not supposed_ to happen.
 
> > and the add-hosts files are being consulted,
> 
> Because the "red" hosts are on the wrong track ...

OK.
 
> > Is there a simpler way to deal with this?
> 
> Yes and you are almost there.
> 
> Explore why red hosts resolve via 192.168.2.1, they shouldn't.

OK.

>> I cannot tell what the Roku streamers have assigned. The UI doesn't expose 
>> that information.
>
> Report that annoying inconvenience at https://support.roku.com/en-gb/

Hahaha. I'll certainly try that. If there isn't already a hidden way to get 
that information, don't have any expectation that asking for something like 
that to be implemented will do much good in the short term, at least.

>> I don't know enough about how DNS works, but ... maybe they have
>> accepted that assignment, but the first DNS server in the request chain
>> is dnsmasq - and it answers rather than relays the request to Google's
>> servers because dnsmasq "knows" the answer - its in the addn-hosts file.
>>
>> Does that make sense?

> No, something is misbehaving.
> It is plain wrong to "explain" broken behaviour.

Perhaps you can improve my understanding. What happens, exactly, when a host on 
a (small) network resolves a DNS request, and a resolver is running on the host 
and on the gateway? What happens when I run nslookup or dig on the host and 
specify a DNS server outside the network? (I assume that's a fair analog to my 
problem.)

> Right now we don't know which device has a "special" feature.
> We do need to dig deeper. Networksniff the DNS traffic
> of the Roku streamer for starters.

Thanks. I've been playing with Wireshark, learning how to capture and filter to 
see just what I want to see has been a bit of a challenge. That runs on a Linux 
box on my network, where maybe not everything I want to see is visible.

I have also turned on DNS logging in dnsmasq, and I can capture logs. And I can 
perhaps instrument some things inside the router as well, perhaps even run a 
capture in there.

I can also use a Linux box as a stand-in for the Roku to at least work with a 
platform where I can see everything that happens and make some inference about 
what should take place.

I'll get back to the list when I have useful results. In the meantime, its 
simple enough to disable the ad blocking when I want to run a stream that 
demands advertising.

-- 
Art Greenberg
a...@artg.tv

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


Re: [Dnsmasq-discuss] dnsmaq on OpenWRT, configuration question

2019-07-28 Thread Geert Stappers
On Sat, Jul 27, 2019 at 04:01:13PM -0400, Art Greenberg wrote:
> On Sat, Jul 27, 2019, at 15:45, Andrew Miskell wrote:
> > What do the devices say their DNS server is? If it???s the .1 address 
> > this would expected behavior because that???s the dnsmasq dns address. 
>  
> I cannot tell what the Roku streamers have assigned. The UI doesn't expose 
> that information.

Report that annoying inconvenience at https://support.roku.com/en-gb/

 
> In the previous configuration, with dnsmasq on 192.168.2.11 and
> the gateway on .1, they DID properly go directly to the router on as
> directed by dhcp-option while everything else on the network went to .11
> as expected. So either they defaulted to the gateway address for DNS or
> they accepted the assignment from DHCP. They do ask for option 6, I can
> see the DHCP request and response in the log. That much looks correct.
> 
> In this configuration, I've told them to use Google servers.
> 
> I don't know enough about how DNS works, but ... maybe they have
> accepted that assignment, but the first DNS server in the request chain
> is dnsmasq - and it answers rather than relays the request to Google's
> servers because dnsmasq "knows" the answer - its in the addn-hosts file.
> 
> Does that make sense?

No, something is misbehaving.
It is plain wrong to "explain" broken behaviour.

Right now we don't know which device has a "special" feature.
We do need to dig deeper. Networksniff the DNS traffic
of the Roku streamer for starters.



Groeten
Geert Stappers
-- 
Leven en laten leven

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


Re: [Dnsmasq-discuss] dnsmaq on OpenWRT, configuration question

2019-07-28 Thread Geert Stappers
On Sat, Jul 27, 2019 at 11:34:41AM -0400, Art Greenberg wrote:
> I had been running dnsmasq on a machine on my network and using
> addn-hosts for ad blocking. My router was configured with my ISP's
> DNS servers.
> 
> I used "net:red" to assign the router as DNS server for certain devices
> (Roku streamers, notably) to avoid the ad blocking, because some of
> the apps on the router would not work properly with the ad blocking
> in place. This told those devices to go directly to the router for
> DNS services.
> 
> router/gateway 192.168.2.1
> dnsmasq machine 192.168.2.11
> 
> ## dnsmasq.conf fragment
> 
> domain-needed
> bogus-priv
> no-resolv
> local=/artg.tv/
> interface=eth0
> domain=artg.tv
> server=8.8.8.8,8.8.4.4
> 
> dhcp-option=option:dns-server,192.168.2.11## use dnsmasq machine 
> for DNS
> dhcp-option=net:red,option:dns-server,192.168.2.1
> 
> dhcp-host=00:01:03:27:84:95,192.168.2.15,martha   ## typical of computer 
> assignments
> dhcp-host=d8:31:34:36:d0:18,192.168.2.135,ROKU-1-WIFI,net:red## typical 
> of ad blocking avoidance
> 
> ## end dnsmasq.conf fragment
> 
> This all worked fine.
> 
> Then I obtained a newer router and installed OpenWRT on it. This, too,
> worked fine until I moved dnsmasq onto the router. The configuration
> now looks like this:
> 
> router/gateway 192.168.2.1
> dnsmasq machine 192.168.2.1
> 
> ## dnsmasq.conf fragment
> 
> domain-needed
> bogus-priv
> no-resolv
> local=/artg.tv/
> interface=br-lan
> domain=artg.tv
> server=8.8.8.8,8.8.4.4
> 
> dhcp-option=option:dns-server,192.168.2.1## use 
> dnsmasq on the router for DNS
> dhcp-option=net:red,option:dns-server,8.8.8.8,8.8.4.4## Google 
> public DNS servers
> 
> dhcp-host=00:01:03:27:84:95,192.168.2.15,martha  ## typical 
> of computer assignments
> dhcp-host=d8:31:34:36:d0:18,192.168.2.135,ROKU-1-WIFI,net:red## typical 
> of ad blocking avoidance
> 
> Now the Roku streamers and some of the apps on them aren't so happy.

I think that "aren't so happy" needs elaboration.


> Despite the "net:red" tag, dnsmasq is intercepting all DNS
> requests and it is returning 0.0.0.0 when the host being looked up is
> in one of the addn-hosts files.
> 
> I have DHCP and DNS logging turned on in dnsmasq and can see the
> Roku streamers ask for option 6 (dns-server) and they get the expected
> response (the Google DNS servers).

OKay, so far the DHCP part


> Yet when they make a DNS request, its being processed by dnsmasq

That is _not supposed_ to happen.

> and the add-hosts files are being consulted,

Because the "red" hosts are on the wrong track ...


> the result being that hosts listed in one of the files have their IP
> address returned as 0.0.0.0.
> 
> I suppose this is expected, as dnsmasq is acting as a DNS relay only
> if it cannot resolve the request, and since the ad hosts are listed
> in an addn-hosts file, dnsmasq -can- resolve the request despite it
> not being within the local, private IP address block.
> 
> I'm thinking I need a second dnsmasq instance configured to handle those
> devices that cannot have ad blocking, and the appropriate division of
> configurations, including complimentary use of the "ignore" option to
> dhcp-host on the two configurations.
> 
> Is there a simpler way to deal with this?

Yes and you are almost there.

Explore why red hosts resolve via 192.168.2.1, they shouldn't.


> And no, I'd rather not move back to using a machine on the network
> for dnsmasq if I can avoid it.

Fair enough

> Thanks.


Groeten
Geert Stappers
-- 
Leven en laten leven

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