Re: [Dnsmasq-discuss] dnsmasq coding style
On 9/26/2019 7:47 PM, Maarten de Vries wrote: > > On 26-09-2019 18:03, Kurt H Maier wrote: >> On Thu, Sep 26, 2019 at 03:10:00PM +0300, Ariel Miculas wrote: >>> What about the issue regarding trailing whitespaces? There are empty >>> lines >>> which have random tabs/spaces, also there are spaces before newline >>> characters. >>> What is the rationale against removing trailing whitespaces? >> This stuff only matters if your tooling is broken. >> >> khm > > Which is my it matters for open source projects. There will be people > with broken tooling that commit trailing whitespace. > That is the issue, simply use a hook to avoied that 'pre-commit' in this case. -- John Doe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq coding style
On Thu, Sep 26, 2019 at 07:47:45PM +0200, Maarten de Vries wrote: > > On 26-09-2019 18:03, Kurt H Maier wrote: > > Which is my it matters for open source projects. There will be people > with broken tooling that commit trailing whitespace. The consequences of which range, of course, from absent to negligible. This software is not written in tcl. > And whitespace fixes can definitely make certain git tasks (like > merging, rebasing or just inspecting diffs) more difficult than they > otherwise would be. So it isn't a weird idea to aim for consistent > white-space usage. Git already contains tooling to ignore this, as all competent tools do. khm ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq coding style
On 26-09-2019 18:03, Kurt H Maier wrote: On Thu, Sep 26, 2019 at 03:10:00PM +0300, Ariel Miculas wrote: What about the issue regarding trailing whitespaces? There are empty lines which have random tabs/spaces, also there are spaces before newline characters. What is the rationale against removing trailing whitespaces? This stuff only matters if your tooling is broken. khm Which is my it matters for open source projects. There will be people with broken tooling that commit trailing whitespace. And whitespace fixes can definitely make certain git tasks (like merging, rebasing or just inspecting diffs) more difficult than they otherwise would be. So it isn't a weird idea to aim for consistent white-space usage. -- Maarten ___ 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
It's perfectly valid to have multiple distinct prefixes configured on an interface, so just remembering one subnet isn't good enough in the general case. Although it's certainly an improvement over a single address. I think a complete fix would be to remember all (interface, prefix) pairs that we're doing RAs on, and only (re)start fast RAs for the interface if the subnet isn't already being served RA's. I imagine this list already exists somewhere, since the RAs are being sent there. But it's been a while since I looked through the code. -- Maarten On 11-09-2019 23:40, Simon Kelley wrote: 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=, 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=, 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
Re: [Dnsmasq-discuss] dnsmasq coding style
On Thu, Sep 26, 2019 at 03:10:00PM +0300, Ariel Miculas wrote: > What about the issue regarding trailing whitespaces? There are empty lines > which have random tabs/spaces, also there are spaces before newline > characters. > What is the rationale against removing trailing whitespaces? This stuff only matters if your tooling is broken. khm ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq coding style
Thanks, John I've just read through it, I'm surprised there is no solution to it especially since it's so easy to fix it and clearly I'm not the only one bothered by this. What about the issue regarding trailing whitespaces? There are empty lines which have random tabs/spaces, also there are spaces before newline characters. What is the rationale against removing trailing whitespaces? Regards On Thu, Sep 26, 2019 at 2:50 PM john doe wrote: > On 9/26/2019 12:23 PM, kingarley . wrote: > > Hello, > > > > As I'm reading through dnsmasq's codebase, something that bothers me is > the > > mix of tabs and spaces and also the trailing whitespace. > > There are tools that make it easy to adhere to a coding style, so this > > issue can be fixed quite easily. > > For example, http://astyle.sourceforge.net/ could be used, picking a > coding > > style and sticking to it. > > This topick was recently discust on this very mailing list, please have > a look in the mailing list archive. > > -- > 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] dnsmasq coding style
On 9/26/2019 12:23 PM, kingarley . wrote: > Hello, > > As I'm reading through dnsmasq's codebase, something that bothers me is the > mix of tabs and spaces and also the trailing whitespace. > There are tools that make it easy to adhere to a coding style, so this > issue can be fixed quite easily. > For example, http://astyle.sourceforge.net/ could be used, picking a coding > style and sticking to it. This topick was recently discust on this very mailing list, please have a look in the mailing list archive. -- John Doe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] dnsmasq coding style
Hello, As I'm reading through dnsmasq's codebase, something that bothers me is the mix of tabs and spaces and also the trailing whitespace. There are tools that make it easy to adhere to a coding style, so this issue can be fixed quite easily. For example, http://astyle.sourceforge.net/ could be used, picking a coding style and sticking to it. I would like to know your thoughts on this. Regards, Ariel Miculas ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss