date:20190911

Re: [Dnsmasq-discuss] code style

2019-09-11 Thread Simon Kelley

There seems to be confusion here between code style, and code
representation.

Code style, ie layout, indent width, is not negotiable.

Code representation is the use of tab characters at 8-character stops.
If your IDE or other device doesn't use 8 characher stops, it will
mangle code. That doesn't mean the code is badly formatted, it means
your display method is incompatible.

It's quite possible to get around this by running expand on every
commit, so that only spaces are used in the repo. It's even possible to
run expand on every existing file, at the expense of polluting the logs.
I don't think there are any other downsides to this.

Or people could  configure IDEs and editors to use sane tab stops.

Cheers,

Simon.

On 07/09/2019 18:21, john doe wrote:
> On 9/7/2019 6:25 PM, Shota Hino wrote:
>> Whatever the width of the tab is, converting all tabs to whitespaces (or
>> the other way around) would be better.
>> If code formatting was forced at the time of each commit, there would be no
>> need for anybody to set the tab width on their editor.
>> Consistent coding style will help more developers in the future.
>>
>>
>>
> 
> I agree, consistent code is best, clear guideline could be usefull for
> new code.
> Simon Kelley, the belligerent dictator of the Dnsmasq project will need
> to way in on such changes though.
> 
> --
> John Doe
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

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

Re: [Dnsmasq-discuss] code style

2019-09-11 Thread Shota Hino

How do you feel about the mix usage of tab and leading white spaces?
The code is mangled because some liens use a tab and some use white spaces.
I do not think the choice of tab vs white spaces is code representation.



On Wed, Sep 11, 2019 at 2:05 PM Simon Kelley 
wrote:

> There seems to be confusion here between code style, and code
> representation.
>
> Code style, ie layout, indent width, is not negotiable.
>
> Code representation is the use of tab characters at 8-character stops.
> If your IDE or other device doesn't use 8 characher stops, it will
> mangle code. That doesn't mean the code is badly formatted, it means
> your display method is incompatible.
>
> It's quite possible to get around this by running expand on every
> commit, so that only spaces are used in the repo. It's even possible to
> run expand on every existing file, at the expense of polluting the logs.
> I don't think there are any other downsides to this.
>
> Or people could  configure IDEs and editors to use sane tab stops.
>
> Cheers,
>
> Simon.
>
> On 07/09/2019 18:21, john doe wrote:
> > On 9/7/2019 6:25 PM, Shota Hino wrote:
> >> Whatever the width of the tab is, converting all tabs to whitespaces (or
> >> the other way around) would be better.
> >> If code formatting was forced at the time of each commit, there would
> be no
> >> need for anybody to set the tab width on their editor.
> >> Consistent coding style will help more developers in the future.
> >>
> >>
> >>
> >
> > I agree, consistent code is best, clear guideline could be usefull for
> > new code.
> > Simon Kelley, the belligerent dictator of the Dnsmasq project will need
> > to way in on such changes though.
> >
> > --
> > John Doe
> >
> > ___
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss@lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [BUG] [PATCH] RA are sent too fast and slows down the machine

2019-09-11 Thread Simon Kelley

That's nasty.

I'm not sure how to properly solve this. I'm inclined to apply your
patch, on the grounds that it at least works better.



Simon.



On 02/09/2019 18:45, Petr Mensik wrote:
> Yes, it seems originating system is auto configuring interface on behalf
> own RA. I have modified the test to include ip monitor output. It
> receives autoconfiguration few seconds after bridge interface comes up.
> 
> Don't know how much is involved fact network namespace is used on a
> bridge, it should not matter. A bit suspicious is STALE router just
> before autoconfiguration. I doubt it is related, but Avahi is trying
> mdns on that interfaces. Of course, Network Manager is touching it also.
> 
> Since it is custom interface created in namespace, any other host cannot
> send RA to it. So I am positive it autoconfigures itself, at least on my
> Fedora 29. Has same results when only bridge is used and when loopback
> is also used.
> 
> 14:32:22.711> 2: simbrinet6 fc58:a22:180d:7800::1/64 scope global
> ...
> 14:32:25.289> fe80::6887:6dff:fe07:6f54 dev simbr lladdr
> 6a:87:6d:07:6f:54 router STALE
> 14:32:25.293> prefix fc58:a22:180d:7800::/64dev simbr onlink autoconf
> valid 1800 preferred 1800
> 14:32:27.317> 2: simbrinet6
> fc58:a22:180d:7800:6887:6dff:fe07:6f54/64 scope global dynamic mngtmpaddr
> 14:32:27.318> valid_lft 1798sec preferred_lft 1798sec
> 
> Cheers,
> Petr
> 
> On 8/30/19 11:26 PM, Simon Kelley wrote:
>> This is useful information, but what I don't understand, is where the
>> flooding comes from. Sure, this confusion means that unsolicted ra will
>> run every time there's a "new address" event, even if the new address
>> isn't on the expected interface, but I can't see how it generates more
>> "new address events" and therefore a flood of packets.
>>
>>
>> Unless, the originating system receives _its_own_ RA and that generates
>> a "new address" event?
>>
>> Simon.
>>
>>
>>
>> On 28/08/2019 20:38, Petr Mensik wrote:
>>> Hi,
>>>
>>> I have found what is going on.
>>>
>>> That RA seems to be switching between dynamically assigned address and
>>> manually assigned address. It is just wrong to assume there is one
>>> address on physical interface, especially in IPv6 world.
>>>
>>> It seems my patch (attached), checking just subnet and not caring for
>>> exact address inside, fixes advertisement floods. But I am not sure
>>> whether it also does not stop announces for new dynamic addresses as it
>>> should. It might help to use valid parameter to distinguish between
>>> static address and dynamic. I am unsure if it is required for both or
>>> just dynamic one?
>>>
>>> I am sure it would send once for newly created interface. I think it
>>> should be enough, right?
>>>
>>> Some notes from debugging:
>>>
>>> Breakpoint 1, construct_worker (scope=, flags=>> out>, preferred=, valid=1800,
>>> vparam=0x7ffc9afc2b60, if_index=2, prefix=64, local=0xa6dda4) at
>>> dhcp6.c:685
>>> 2: /x *local = {__in6_u = {__u6_addr8 = {0xfc, 0x58, 0xa, 0x22, 0x18,
>>> 0xd, 0x78, 0x0, 0x8, 0x21, 0xd1, 0xff, 0xfe, 0x74, 0xec,
>>>   0x2a}, __u6_addr16 = {0x58fc, 0x220a, 0xd18, 0x78, 0x2108, 0xffd1,
>>> 0x74fe, 0x2aec}, __u6_addr32 = {0x220a58fc, 0x780d18,
>>>   0xffd12108, 0x2aec74fe}}}
>>>
>>> Breakpoint 1, construct_worker (scope=, flags=>> out>, preferred=, valid=-1,
>>> vparam=0x7ffc9afc2b60, if_index=2, prefix=64, local=0xa6ddec) at
>>> dhcp6.c:685
>>> 685 ra_start_unsolicited(param->now, template);
>>> 2: /x *local = {__in6_u = {__u6_addr8 = {0xfc, 0x58, 0xa, 0x22, 0x18,
>>> 0xd, 0x78, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1},
>>> __u6_addr16 = {0x58fc, 0x220a, 0xd18, 0x78, 0x0, 0x0, 0x0, 0x100},
>>> __u6_addr32 = {0x220a58fc, 0x780d18, 0x0, 0x100}}}
>>>
>>> Cooperative ip link:
>>> 2: simbr:  mtu 1500 qdisc noqueue state
>>> UP group default qlen 1000
>>> link/ether 0a:21:d1:74:ec:2a brd ff:ff:ff:ff:ff:ff
>>> inet 172.30.16.1/24 scope global simbr
>>>valid_lft forever preferred_lft forever
>>> inet6 fc58:a22:180d:7800:821:d1ff:fe74:ec2a/64 scope global dynamic
>>> mngtmpaddr
>>>valid_lft 1699sec preferred_lft 1699sec
>>> inet6 fc58:a22:180d:7800::1/64 scope global
>>>valid_lft forever preferred_lft forever
>>> inet6 fe80::821:d1ff:fe74:ec2a/64 scope link
>>>valid_lft forever preferred_lft forever
>>>
>>>
>>> Regards,
>>> Petr
>>>
>>> On 8/27/19 10:42 PM, Maarten de Vries wrote:
 Hey,

 I haven't dug very deep yet, but I can comment on the intent of the
 particular commit: without it, dnsmasq didn't do any unsolicited RAs on
 interfaces that are created after dnsmasq was started. It definitely
 should do unsolicited RAs on those interfaces too, although obviously
 not quite so many so often. I'm not sure why that happens. Note that the
 commit didn't introduce the fast RAs, it only enabled unsolicited RAs
 (including fast) for newly created interfaces too.

 I wonder why thi

Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus

2019-09-11 Thread Tore Anderson

* Tore Anderson

> I can confirm that Dnsmasq 69a0477 resolves www.linuxquestions.org and 
> www.ipv6.org.uk as expected (DNSSEC state insecure). Great work, thanks!

Apologies, I botched my test (using the wrong upstream server). It does *not* 
work, but the error is different:

$ src/dnsmasq -d -p 5353
dnsmasq: started, version 2.80-71-g69a0477 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt DBus no-UBus no-i18n IDN2 DHCP 
DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify dumpfile
dnsmasq: DNSSEC validation enabled
dnsmasq: configured with trust anchor for  keytag 20326
dnsmasq: configured with trust anchor for  keytag 19036
dnsmasq: using nameserver 87.238.33.1#53
dnsmasq: cleared cache
dnsmasq: query[A] www.ipv6.org.uk from 127.0.0.1
dnsmasq: forwarded www.ipv6.org.uk to 87.238.33.1
dnsmasq: dnssec-query[DS] uk to 87.238.33.1
dnsmasq: dnssec-query[DNSKEY] . to 87.238.33.1
dnsmasq: reply . is DNSKEY keytag 59944, algo 8
dnsmasq: reply . is DNSKEY keytag 20326, algo 8
dnsmasq: reply uk is DS keytag 43876, algo 8, digest 2
dnsmasq: dnssec-query[DS] org.uk to 87.238.33.1
dnsmasq: dnssec-query[DNSKEY] uk to 87.238.33.1
dnsmasq: reply uk is DNSKEY keytag 43876, algo 8
dnsmasq: reply uk is DNSKEY keytag 43056, algo 8
dnsmasq: reply org.uk is DS keytag 41523, algo 8, digest 2
dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1
dnsmasq: dnssec-query[DNSKEY] org.uk to 87.238.33.1
dnsmasq: reply org.uk is DNSKEY keytag 41523, algo 8
dnsmasq: reply ipv6.org.uk is no DS
dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1
dnsmasq: reply ipv6.org.uk is no DS
dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1
dnsmasq: reply ipv6.org.uk is no DS
dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1
dnsmasq: reply ipv6.org.uk is no DS
dnsmasq: dnssec-query[DS] ipv6.org.uk to 87.238.33.1
dnsmasq: reply ipv6.org.uk is no DS
[...]

This query is repeated ~44 times in a tight loop. It makes a total of 50 
queries before giving up, I guess it hits a built-in limit.

PCAP attached.

It seems to happen with *all* Insecure domain names (not only those that have 
CNAMES pointing to other Secure domain names).

Tore


foo.pcap
Description: application/vnd.tcpdump.pcap
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] code style

2019-09-11 Thread Simon Kelley

On 11/09/2019 22:12, Shota Hino wrote:
> How do you feel about the mix usage of tab and leading white spaces?
> The code is mangled because some liens use a tab and some use white spaces.
> I do not think the choice of tab vs white spaces is code representation.

With tab stops set to 8, a single tab or eight spaces are just alternate
representations of the same thing, surely?


Simon

> 
> 
> 
> On Wed, Sep 11, 2019 at 2:05 PM Simon Kelley  > wrote:
> 
> There seems to be confusion here between code style, and code
> representation.
> 
> Code style, ie layout, indent width, is not negotiable.
> 
> Code representation is the use of tab characters at 8-character stops.
> If your IDE or other device doesn't use 8 characher stops, it will
> mangle code. That doesn't mean the code is badly formatted, it means
> your display method is incompatible.
> 
> It's quite possible to get around this by running expand on every
> commit, so that only spaces are used in the repo. It's even possible to
> run expand on every existing file, at the expense of polluting the logs.
> I don't think there are any other downsides to this.
> 
> Or people could  configure IDEs and editors to use sane tab stops.
> 
> Cheers,
> 
> Simon.
> 
> On 07/09/2019 18:21, john doe wrote:
> > On 9/7/2019 6:25 PM, Shota Hino wrote:
> >> Whatever the width of the tab is, converting all tabs to
> whitespaces (or
> >> the other way around) would be better.
> >> If code formatting was forced at the time of each commit, there
> would be no
> >> need for anybody to set the tab width on their editor.
> >> Consistent coding style will help more developers in the future.
> >>
> >>
> >>
> >
> > I agree, consistent code is best, clear guideline could be usefull for
> > new code.
> > Simon Kelley, the belligerent dictator of the Dnsmasq project will
> need
> > to way in on such changes though.
> >
> > --
> > John Doe
> >
> > ___
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss@lists.thekelleys.org.uk
> 
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


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

[Dnsmasq-discuss] Failure to resolve boinc.berkeley.edu (kind of)

2019-09-11 Thread Andrew Duty

I am having a problem that I do not understand. I am running dnsmasq 2.80
and cannot resolve boinc.berkeley.edu even though my upstream DNS servers
(8.8.8.8 and 8.8.4.4) resolve it fine. Here is what I get in the logs (I
have replaced my IP address with my_ip):

dnsmasq[5635]: query[A] boinc.berkeley.edu from my_ip
dnsmasq[5635]: forwarded boinc.berkeley.edu to 8.8.4.4
dnsmasq[5635]: dnssec-query[DS] berkeley.edu to 8.8.4.4
dnsmasq[5635]: reply berkeley.edu is DS keytag 3456, algo 10, digest 2
dnsmasq[5635]: dnssec-query[DNSKEY] berkeley.edu to 8.8.4.4
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 57107, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 51617, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 6233, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 3456, algo 10
dnsmasq[5635]: dnssec-query[DNSKEY] berkeley.edu to 8.8.4.4
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 3456, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 57107, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 51617, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 6233, algo 10
dnsmasq[5635]: dnssec-query[DNSKEY] berkeley.edu to 8.8.4.4
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 6233, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 3456, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 57107, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 51617, algo 10
dnsmasq[5635]: dnssec-query[DNSKEY] berkeley.edu to 8.8.4.4
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 57107, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 51617, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 6233, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 3456, algo 10
dnsmasq[5635]: dnssec-query[DNSKEY] berkeley.edu to 8.8.4.4
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 57107, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 51617, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 6233, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 3456, algo 10
dnsmasq[5635]: dnssec-query[DNSKEY] berkeley.edu to 8.8.4.4
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 51617, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 6233, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 3456, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 57107, algo 10
dnsmasq[5635]: dnssec-query[DNSKEY] berkeley.edu to 8.8.4.4
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 6233, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 3456, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 57107, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 51617, algo 10
dnsmasq[5635]: dnssec-query[DNSKEY] berkeley.edu to 8.8.4.4
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 6233, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 3456, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 57107, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 51617, algo 10
dnsmasq[5635]: dnssec-query[DNSKEY] berkeley.edu to 8.8.4.4
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 51617, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 6233, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 3456, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 57107, algo 10
dnsmasq[5635]: dnssec-query[DNSKEY] berkeley.edu to 8.8.4.4
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 3456, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 57107, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 51617, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 6233, algo 10
dnsmasq[5635]: dnssec-query[DNSKEY] berkeley.edu to 8.8.4.4
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 57107, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 51617, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 6233, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 3456, algo 10
dnsmasq[5635]: dnssec-query[DNSKEY] berkeley.edu to 8.8.4.4
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 57107, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 51617, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 6233, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 3456, algo 10
dnsmasq[5635]: dnssec-query[DNSKEY] berkeley.edu to 8.8.4.4
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 3456, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 57107, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 51617, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 6233, algo 10
dnsmasq[5635]: dnssec-query[DNSKEY] berkeley.edu to 8.8.4.4
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 57107, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 51617, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 6233, algo 10
dnsmasq[5635]: reply berkeley.edu is DNSKEY keytag 3456,

Re: [Dnsmasq-discuss] dns flag day 2020

2019-09-11 Thread Simon Kelley

On 02/09/2019 19:52, Dave Taht wrote:
> 
> Does anyone have an opinion on:
> 
> https://github.com/dns-violations/dnsflagday/issues/125
> 
> (posteth not here, but on that thread)
> 

Dnsmasq has code which tries to detect lost oversize UDP packets and
reduces the maximum sent to 1280.  If the powers that be can comes up
with a  definitive solution, I'd like to implement it.

> sort of spawned by that, though, are three questions, which
> perhaps we can answer here...
> 
> 1) How much is the dnssec stuff in dnsmasq enabled?
> 
> For example, although it's available in openwrt, I think it is disabled
> by default. It was enabled by default in cerowrt (my old project), but
> had enough bugs revealed after the final release for most to disable it.
> 
> That said, I do run it where I can, in openwrt, but I figure it's kind
> of lonely.
> 

I don't know. I suspect not often. Why bother? most of the net is not
signed anyway.

We eat our own DNSSEC dogfood here at thekelleys, and don't see any
problems, forwarding to 8.8.8.8 or 1.1.1.1
Most of the bug reports I see these days seem to be due it
different/unexpected behaviour of upstreams which catches out code
tested almost exclusively on those two.

> 2) How often does it succeed over udp?
> 
> 3) How often does it have to fallback to tcp?
> 

I don't know for sure, and don;t have any recent logs. I've not,
historically, seen high TCP fallback rates.

Cheers,

Simon.

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

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

Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus

2019-09-11 Thread Simon Kelley

On 04/09/2019 18:40, Tore Anderson wrote:

> 
> (By the way, I did send the promised PCAP yesterday. However, because the 
> message was >40KB, it was queued for moderation by the mailing list 
> administrator.)
> 
So you did, it's there, as are several others, which raises the question
of why mailman didn't email me about it.



it did, but over-enthusiastic spam-removal rules in my procmail deleted
it. Fixed now, I think.


Cheers,

Simon.


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

[Dnsmasq-discuss] FW: Too many DISCOVER packets than actual clients

2019-09-11 Thread P, Sreelakshmi

Hi,

I have IXIA port connected to an interface on which dnsmasq is running. I'm 
simulating 8k DHCP clients from IXIA and see that there are more than 12k 
DISCOVER packets sent from IXIA, but the ones logged in dnsmasq log is exactly 
8k. Why is this difference and what dnsmasq is doing with remaining packets.

There are more than 2 DISCOVER packets from every client. When this happens? 
Both DISCOVER packets are reaching an interface on which dnsmasq is running.

Could anyone explain me how this works and who is the culprit here. Please find 
below the snippet from IXIA.

[cid:image001.png@01D50BFE.DB88EC00]

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

[Dnsmasq-discuss] Too many DISCOVER packets than actual clients

2019-09-11 Thread P, Sreelakshmi

Hi,

I have IXIA port connected to an interface on which dnsmasq is running. I'm 
simulating 8k DHCP clients from IXIA and see that there are more than 12k 
DISCOVER packets sent from IXIA, but the ones logged in dnsmasq log is exactly 
8k. Why is this difference and what dnsmasq is doing with remaining packets.

There are more than 2 DISCOVER packets from every client. When this happens? 
Both DISCOVER packets are reaching an interface on which dnsmasq is running.

Could anyone explain me how this works and who is the culprit here. PFA the 
snippet from IXIA.

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

Re: [Dnsmasq-discuss] code style

2019-09-11 Thread Shota Hino

>
> With tab stops set to 8, a single tab or eight spaces are just alternate
> representations of the same thing, surely?


Yes.

But what I am asking in this thread is to use either tabs or white spaces
(not both).
If only one is used, the width of tab in IDE does not matter. Hence, I
think this is a code style question request.


*Shota Hino*Connectivity Software
*m* 650-476-9668
*e* sh...@eero.com

*eero LLC *660 3rd St, 4th Floor
San Francisco, CA 94107



On Wed, Sep 11, 2019 at 2:49 PM Simon Kelley 
wrote:

> On 11/09/2019 22:12, Shota Hino wrote:
> > How do you feel about the mix usage of tab and leading white spaces?
> > The code is mangled because some liens use a tab and some use white
> spaces.
> > I do not think the choice of tab vs white spaces is code representation.
>
> With tab stops set to 8, a single tab or eight spaces are just alternate
> representations of the same thing, surely?
>
>
> Simon
>
> >
> >
> >
> > On Wed, Sep 11, 2019 at 2:05 PM Simon Kelley  > > wrote:
> >
> > There seems to be confusion here between code style, and code
> > representation.
> >
> > Code style, ie layout, indent width, is not negotiable.
> >
> > Code representation is the use of tab characters at 8-character
> stops.
> > If your IDE or other device doesn't use 8 characher stops, it will
> > mangle code. That doesn't mean the code is badly formatted, it means
> > your display method is incompatible.
> >
> > It's quite possible to get around this by running expand on every
> > commit, so that only spaces are used in the repo. It's even possible
> to
> > run expand on every existing file, at the expense of polluting the
> logs.
> > I don't think there are any other downsides to this.
> >
> > Or people could  configure IDEs and editors to use sane tab stops.
> >
> > Cheers,
> >
> > Simon.
> >
> > On 07/09/2019 18:21, john doe wrote:
> > > On 9/7/2019 6:25 PM, Shota Hino wrote:
> > >> Whatever the width of the tab is, converting all tabs to
> > whitespaces (or
> > >> the other way around) would be better.
> > >> If code formatting was forced at the time of each commit, there
> > would be no
> > >> need for anybody to set the tab width on their editor.
> > >> Consistent coding style will help more developers in the future.
> > >>
> > >>
> > >>
> > >
> > > I agree, consistent code is best, clear guideline could be usefull
> for
> > > new code.
> > > Simon Kelley, the belligerent dictator of the Dnsmasq project will
> > need
> > > to way in on such changes though.
> > >
> > > --
> > > John Doe
> > >
> > > ___
> > > Dnsmasq-discuss mailing list
> > > Dnsmasq-discuss@lists.thekelleys.org.uk
> > 
> > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> > >
> >
> > ___
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss@lists.thekelleys.org.uk
> > 
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
>
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] IPv6 Router Advertisements eating a CPU Core + Constantly being Multicasted

2019-09-11 Thread Cooper Lees

Hi,

Many thanks for your suggestions.

Maybe I was not clear enough. With `dhcp-range=2601:647:4d01:fbf::,ra-names` in 
the config causes 'top' to show a lot of CPU used (>90%):
```
19492 dnsmasq   20   0   11076   2536   2228 R  93.4   0.1 815:27.43 
/usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -r 
/run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new 
--local-service
```
AND tcpdump shows a barrage of RAs being advertised:
```
06:39:00.390680 IP6 fe80::dea6:32ff:fe02:b43d > ff02::1: ICMP6, router 
advertisement, length 88
06:39:00.391455 IP6 fe80::dea6:32ff:fe02:b43d > ff02::1: ICMP6, router 
advertisement, length 88
06:39:00.392017 IP6 fe80::dea6:32ff:fe02:b43d > ff02::1: ICMP6, router 
advertisement, length 88
06:39:00.392564 IP6 fe80::dea6:32ff:fe02:b43d > ff02::1: ICMP6, router 
advertisement, length 88
06:39:00.393103 IP6 fe80::dea6:32ff:fe02:b43d > ff02::1: ICMP6, router 
advertisement, length 88
```
- Please look at the timestamps here
- Milliseconds apart 

I've replied to everything else in line. I guess it's going to be time to dig 
into the source code here if nothing else in my config looks outside the 
ordinary.

Cheers,
Cooper

> On Aug 4, 2019, at 11:29 PM, Geert Stappers  wrote:
> 
> On Sun, Aug 04, 2019 at 03:05:45PM -0700, Cooper Lees wrote:
>> Hello,
>> 
>> I'm running dnsmasq 2.80 on a Raspberry PI and when I enable IPv6
>> Router Advertisements on even one interface the CPU usage pins a
>> core with continually advertising RAs. Logs and tcpdump confirm it's
>> something to do with enabling IPv6 RAs / SLAAC on an interface (when
>> I remove CPU goes right back down to where I'd imagine this daemon to
>> be on a ~10 node home network). I've tried to tune the advertisement
>> to every 4 seconds, but it seems to have no effect. I've also tried
>> TRUNK/HEAD and it reproduces with my config. I've added the options +
>> config used below to help provide a reproducible setup.
>> 
>> Any suggestions I could try / do or is this indeed a bug with dnsmasq?
>> 
>> ./src/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -r 
>> /run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new 
>> --local-service
> 
> The`,.dpkg-dist,.dpkg-old,.dpkg-new` somewhat odd.
> Probably a side effect of some wildcard expansion.
> 
> Check what is inside those  .dpkg-distl.dpkg-old .dpkg-new files.
> Remove them if there is nothing usefull in. And surely remove
> them when there is only duplicate configuration.

This seems to be a default with the raspbian install - There is nothing in 
/etc/dnsmasq.d
```
cooper@home:~ $ find /etc/dnsmasq.d
/etc/dnsmasq.d
/etc/dnsmasq.d/README
```

Removing these and running the daemon has no effect.
```
31737 dnsmasq   20   02244120  0 R  85.8   0.0   0:15.87 
./src/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -r 
/run/dnsmasq/resolv.conf --local-service
```

> 
> 
>> ```
>> Log from starting with HEAD:
>> Aug  4 14:44:30 home dnsmasq[19340]: started, version 2.80-58-g3052ce2 
>> cachesize 150
>> Aug  4 14:44:30 home dnsmasq[19340]: compile time options: IPv6 GNU-getopt 
>> no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset 
>> auth no-DNSSEC loop-detect inotify dumpfile
>> Aug  4 14:44:30 home dnsmasq-dhcp[19340]: DHCP, IP range 10.6.9.10 -- 
>> 10.6.9.200, lease time 1d
>> Aug  4 14:44:30 home dnsmasq-dhcp[19340]: DHCP, IP range 192.168.107.10 -- 
>> 192.168.107.100, lease time 1h
>> Aug  4 14:44:30 home dnsmasq-dhcp[19340]: DHCPv4-derived IPv6 names on 
>> 2601:647:4d01:fbf::
>> Aug  4 14:44:30 home dnsmasq-dhcp[19340]: router advertisement on 
>> 2601:647:4d01:fbf::
>> Aug  4 14:44:30 home dnsmasq[19340]: reading /run/dnsmasq/resolv.conf
>> Aug  4 14:44:30 home dnsmasq[19340]: using nameserver 75.75.75.75#53
>> Aug  4 14:44:30 home dnsmasq[19340]: using nameserver 75.75.76.76#53
>> Aug  4 14:44:30 home dnsmasq[19340]: read /etc/hosts - 6 addresses
>> Aug  4 14:44:30 home dnsmasq-dhcp[19340]: SLAAC-CONFIRM(eth0.69) 
>> 2601:647:4d01:fbf:fea1:83ff:fe5e:d592 amazon-057c5fa7e
>> Aug  4 14:44:30 home dnsmasq-dhcp[19340]: SLAAC-CONFIRM(eth0.69) 
>> 2601:647:4d01:fbf:36d2:70ff:feb1:f402 amazon-9ad27ed72
>> Aug  4 14:44:30 home dnsmasq-dhcp[19340]: SLAAC-CONFIRM(eth0.69) 
>> 2601:647:4d01:fbf:8a71:e5ff:fedb:b5e6 amazon-77495bfb3
>> Aug  4 14:44:30 home dnsmasq-dhcp[19340]: DHCPDISCOVER(eth0.69) 
>> dc:a2:66:59:6d:1f
>> Aug  4 14:44:30 home dnsmasq-dhcp[19340]: DHCPOFFER(eth0.69) 10.6.9.189 
>> dc:a2:66:59:6d:1f
>> Aug  4 14:44:30 home dnsmasq-dhcp[19340]: DHCPREQUEST(eth0.69) 10.6.9.189 
>> dc:a2:66:59:6d:1f
>> Aug  4 14:44:30 home dnsmasq-dhcp[19340]: DHCPACK(eth0.69) 10.6.9.189 
>> dc:a2:66:59:6d:1f
>> ```
> 
> Nothing that indicates a 25% CPU load.
- This is because I added the `quiet-ra` option 
- Otherwise it's just 1s `dnsmasq-dhcp[19424]: RTR-ADVERT(eth0.69) 
2601:647:4d01:fbf::` lines in logs

> 
>> 
>> Log Messages (without quiet-ra)
>> ```
>> Aug  4 14:52:30 home dnsmasq-dhcp[19424]: R

Re: [Dnsmasq-discuss] code style, decision

2019-09-11 Thread Geert Stappers

On Wed, Sep 11, 2019 at 03:09:31PM -0700, Shota Hino wrote:
> On Wed, Sep 11, 2019 at 2:49 PM Simon Kelley wrote:
> > On 11/09/2019 22:12, Shota Hino wrote:
> > > On Wed, Sep 11, 2019 at 2:05 PM Simon Kelley wrote:
> > > > On 07/09/2019 18:21, john doe wrote:
> > > > >   some earlier postings:
> > > > > >   
> > > > >
> > > > > I agree, consistent code is best, clear guideline could be
> > > > > usefull for new code.
> > > > >
> > > > > Simon Kelley, the belligerent dictator of the Dnsmasq project
> > > > > will need to way in on such changes though.
> > > >
> > > > There seems to be confusion here between code style, and code
> > > > representation.
> > > >
> > > > Code style, ie layout, indent width, is not negotiable.
> > > >
> > > > Code representation is the use of tab characters at 8-character
> > > > stops.  If your IDE or other device doesn't use 8 characher
> > > > stops, it will mangle code. That doesn't mean the code is badly
> > > > formatted, it means your display method is incompatible.
> > > >
> > > > It's quite possible to get around this by running expand on
> > > > every commit, so that only spaces are used in the repo. It's even
> > > > possible to run expand on every existing file, at the expense of
> > > > polluting the logs.  I don't think there are any other downsides
> > > > to this.
> > > >
> > > > Or people could  configure IDEs and editors to use sane tab stops.
> > > >
> > > > Cheers,
> > > >
> > > > Simon.
> > > >
> > > How do you feel about the mix usage of tab and leading white spaces?
> > > The code is mangled because some liens use a tab and some use white 
> > > spaces.
> > > I do not think the choice of tab vs white spaces is code representation.
> >
> > With tab stops set to 8, a single tab or eight spaces are just alternate
> > representations of the same thing, surely?
> >
> >
> > Simon
> >
> 
> Yes.
> 
> But what I am asking in this thread is to use either tabs or white spaces
> (not both).
> If only one is used, the width of tab in IDE does not matter.

Now it waits for a decision.

With which character should the code be indented?


Regards
Geert Stappers

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

Re: [Dnsmasq-discuss] code style

Re: [Dnsmasq-discuss] code style

Re: [Dnsmasq-discuss] [BUG] [PATCH] RA are sent too fast and slows down the machine

Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus

Re: [Dnsmasq-discuss] code style

[Dnsmasq-discuss] Failure to resolve boinc.berkeley.edu (kind of)

Re: [Dnsmasq-discuss] dns flag day 2020

Re: [Dnsmasq-discuss] Insecure CNAME pointing to Secure name incorrectly validates as Bogus

[Dnsmasq-discuss] FW: Too many DISCOVER packets than actual clients

[Dnsmasq-discuss] Too many DISCOVER packets than actual clients

Re: [Dnsmasq-discuss] code style

Re: [Dnsmasq-discuss] IPv6 Router Advertisements eating a CPU Core + Constantly being Multicasted

Re: [Dnsmasq-discuss] code style, decision

13 matches

Site Navigation

Mail list logo

Footer information