Re: [LEDE-DEV] [PATCH odhcpd] dhcpv6-ia: add option for dhcpv6 privacy address
On 03/10/2017 09:09 AM, Bjørn Mork wrote:
> Eric Luehrsen writes:
>> It appears many other severs and clients dont implement IA_TA. Its a lost
>> option.
> Sure. Very few want this feature. We must however assume that those
> who do want it will implement it.
We must however assume nothing. We may assume something while patiently
waiting for information so we can progress on an idea.
>> It should not break "expectations" as this an central administrative
>> option.
> A client requesting an IA_NA expects a non-temporary address.
>
I hate being "legislative" about engineering, but it looks like this is
headed that way, so I'll bite. First in all engineering requirements you
must define your terms. "non-temporary" does not mean "permanent" and it
appears it is carefully avoided as such. In fact the only implied
definition through the chain of RFC is "non-temporary" is just not the
same as "temporary." "temporary" could be summarized as having the
potential for even per connection or per application duration. With that
"non-temporary" can reasonably be defined by the local site
administration as a work shift (8hrs) or something like that.
This means "non-temporary" is a policy decision by the organization
management ("oh no" software engineers cry, "not management"). If
management wants DHCPv6 to provide a single address per user level
machine, then that's their decision to make. If management wants that
each work day or each work shift enumerates all user level machines
differently, then that's their decision to make. DHCPv6 IA_NA then is
the one and only address that your issued device gets, and it is
different each work day. Static servers may have predefined host
assignments, which I only mention for completeness.
>> If central IT doesnt want user base devices to be permanently reachable
>> or traceable, then that is their authority to choose.
> Definitely. They can easily achieve this by not providing any IA_NA
> adresses.
How is that an answer for above management attempting to implement a
particular policy? DHCPv6 IA_TA is not option for (any?) clients. By
your implied definition, a client device would get also an IA_NA that is
"more lasting." It may try to use it, but management doesn't want that.
DHCPv6 without something else leaves devices easily profiled from
external snooping. It's not MAC but not good either. SLAAC exposes the
MAC publicly. SLAAC+privacy is internally difficult to trace, so likely
fail accountability. SLAAC w/ RA rolling hash isn't any more implemented
than IA_TA.
>> But on the flip side, central IT doesnt want the insanity of SLAAC
>> Privacy all over their network. Consider a fortune 500 company or
>> university with accountibilty and traceability in legal or internal
>> policy requirements.
>>
>> RFC are so namef for a reason and a good working model can change them.
> OK, I think you just explained your level of understanding. Thanks
I'll pretend that it doesn't mean how it reads.
- Eric
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH odhcpd] dhcpv6-ia: add option for dhcpv6 privacy address
This discussion has really put some requirements and restrictions on what I am trying to implement. I like that. Excuse my stream of consciousness writing style, if you question "what? .. crazy?" then its likely my fault for not editing well. On 03/11/2017 11:39 AM, Paul Oranje wrote: >> RFC 3315 section 22.5: >> >>An IA_TA option does not include values for T1 and T2. > The use-case that Eric gave as an example - as I understood it - concerns > policies that are enforced at the server side; at the client site > “management" cannot enforce anything. > Simply, a rational management desire would be to have similar or "transparent" system of policies between IP4 and IP6. They have decades of "Oh! !" lessons learned including tools built around DHCPv4. They want evolution not revolution in the change over. During an hypothetical IP6 roll out plan meeting ... The potential for IP6 to profile a network externally is considered and the emotional response is "unsettling" at best. The potential for loss of control with SLAAC is equally emotional. Hopefully someone well spoken and well respected explains NAT is not security, or storm clouds form. Desire: one global IP6 per (virtual) machine just like was had with IP4. Desire: external network obscurity just like was had with IP4. Desire: full traceability and accountability for all intranet and internet connections. Desire: time and point of first connection logs as mobile devices attach. Desire: not require extra steps or tools for general employees to "work around" issues. Desire: IT policy/training/manuals don't need to change in grand structure (only change specifics in implementation) Desire: DUID or Client-ID or MAC is an "asset tag" and not modified session to session. DHCPv6 IA_NA which is NOT simply a fixed hash of DUID but also a random function over moderate periods of time would be within standard and meet these desires. Within "accountability and traceability" a limit to address roll over frequency creates another rational definition of "non-temporary." >> In any case, there are existing client implementations of IA_TA (for >> example ISC dhclient and dibbler) and RFC7721 stable IIDs (for example >> Linux kernel and NetworkManager). > Maybe you can create a patch that would implement IA_TA in odhcpd, if that > isn’t implemented yet (I do not know, have a look at the code). > That would satisfy another use case. This could/should also be done, but many as-purchased devices just don't handle IA_TA (well). Okay, more generically IP6 isn't often handled (well). It will be hard to test robustly. IA_TA can deliver a plurality of addresses for machine/connection obscurity. "How many?" becomes a compatibility and complexity issue as one example. Hurdle: If IT is conservative about in house modification and wants to deploy user-end equipment as-purchased, then this could limit their supplier options and the buyers negotiation leverage. Modifying and maintaining infrastructure is an IT job. Supporting all the daily user issues is often part of the service contract with the user equipment provider. If we want providers support, then use the equipment as-purchased or within boundaries as specified in the contract. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH odhcpd] dhcpv6-ia: add option for dhcpv6 privacy address
Patchwork: Reject Patch. It needs improvement. The time base for the address needs more stable regulation just for one. - Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Release 17.01.0 binary packages have changed and SDK inconsistency
On 03/28/2017 06:19 PM, Gui Iribarren via Lede-dev wrote: >> Packages from the feeds and even base-packages (think: openssl) can >> change after a release, just like for other distributions. > i agree packages can and should be maintained, but in progressivereleases. >i.e. if i install ubuntu 12.04 today, i expect to have exactly the same > system than what i got if i installed ubuntu 12.04 at the time of its > release >if i want to get the fixes that happened after the time of original > 12.04 release, i'd install 12.04.1 An optional package needs a stable core to compile against to provide a service update. Changing both at the same time without a clear label is bound to cause trouble. A fair debate then would be for which packages are core. What dependencies are so integral that they must be released together? However avoid debating this for too long. Repeatable results are important in science and engineering. As others mention, this can become a serious matter of credibility. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 2/3][RFC] base-files: add option to rc.common to disable default reload behavior
On 03/29/2017 03:17 AM, Alexandru Ardelean wrote: > On Tue, Mar 28, 2017 at 11:36 PM, Hans Dedecker wrote: >> On Mon, Mar 20, 2017 at 3:08 PM, Alexandru Ardelean >> wrote: >>> From: Alexandru Ardelean >>> >>> Traditionally if a reload script fails, it will fallback to restart. >>> >>> That seems to be the default behavior in case no reload >>> handler has been specified, and `reload` will return 1. >>> >>> That also has the disadvantage of masking reload errors >>> from `/etc/init.d/ reload`. >>> >>> Still, it's a pretty old behavior, and in most cases >>> it should be fine. >>> >>> For other cases, the `RESTART_ON_RELOAD_ERR=0` can >>> be specified to override this. >>> >>> Not sure about the correctness of this approach, >>> so this patch is RFC. >> Discussed the restart-on-reload-fail behaviour with Felix and >> Matthias; general consensus is to remove the restart-on-reload-fail >> behaviour in rc.common. Packages do not seem to depend on this >> restart-on-reload fail behaviour and it's more logical to handle >> reload failure in the packages itself if extra logic is required. > > Thanks for the consideration. > > I'll submit another patch series just for this restart-on-reload fail. > > I feel this mechanism was maybe intended to act as default reload > implementation. > In the sense, that a default reload hook is implemented returning > non-zero, and if no specific reload is implemented, this logic [ > restart on reload fail ] would work. > > Will think about it a bit. > > Thanks > Alex I would have concerns with the lack of documentation on how to control the outcome of procd triggers. Restart on reload behavior may fix things without people realizing it. Cross platform contributers may not fully appreciate the quirks of procd vs systemd vs ... This is to be expected without a user guide. For example of a gotcha, triggers on interfaces may be noisy. Look at how often dnsmasq.conf is rewritten on "interface.*" raw trigger. It isn't restarted because the command line doesn't change. The delay timer is a nice robustness action over hotplug scripts. Hotplug scripts are easier to target. Reload needs to be used with this procd trigger but not restart. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] dnsmasq sometimes fails to start on 17.01.0
On 03/29/2017 11:57 AM, Yousong Zhou wrote: > On 24 March 2017 at 03:17, Gui Iribarren via Lede-dev >> I continued yeterday further debugging this, i played with this >> particular number in /e/i/dnsmasq >> (line 815 in http://pastebin.com/FV09f2jG) >> >> procd_add_raw_trigger "interface.*" 2000 /etc/init.d/dnsmasq reload > > I cannot yet reproduce the issue, but here are some findings after > reading code of procd > > The 2000ms and 6ms above as argument of procd_add_raw_trigger is a > delay before running the specified action when the event occurs. It's > NOT a timeout to wait for the action to complete before killing it. I have noticed other quirks with this trigger. It seems to be busy or noisy. If you replace "reload" with "restart" for example or if you inspect time stamps of /var/etc/dnsmasq.conf, then you will see that the trigger issues every few minutes. The hotplug/iface script is much more targeted at IFUP with new and unique configuration. The busyness and the short fuse (2 seconds) may be falling over itself. I ran into this setting up the net/unbound package to work like dnsmasq. I made the mistake of "restart" instead of "reload". I just though I'd use hotplug I put in last fall, but with procd. The delay timer is nice. When a power outage cause the router and modem to go through a few handshakes on reboot, Unbound would be crashed out in procd. "reload" fixed that, but then no hard "restart" trigger is configured. It would be nice if (1) procd had a README with a solid paragraph on each procd.sh user-end function. (2) there were ways to be better refine the interface triggers to only a true interface reconfiguration. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Planning v17.01.1
On 04/09/2017 10:14 AM, Jo-Philipp Wich wrote: > Hi, > I'd like to start preparing the v17.01.1 release during the upcoming > week with the goal to release final binaries during the easter holidays > (~14.04. - 17.04.). > You can find the current list of changes since v17.01.0 at > https://lede-project.org/releases/17.01/changelog-17.01.1 > If you want specific fixes cherry-picked/backported to lede-17.01, > please mention them in a reply to this mail. > If you have any objections to the release time frame, please speak up :) > Also, please reply with a quick ACK / NACK on whether you'd like to see > an -RC build before 17.01.1 final. > Thanks, > Jo Hi Jo, An RC may attract some people unsure of building their own. The wider feedback may sort out a few bugs before final release. Thanks for the continued effort. Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH odpcpd] dhcpv6: allow creating new bindings on REBIND
On 04/10/2017 05:08 AM, Lubomir Rintel wrote: > There might be unassigned IAs among the options the client sends when it > issues a REBIND. In fact, that's how the ISC dhclient reqests new IA_PDs > to be assigned. However, odhcpd would just return the IA_PDs back > without assigning a prefix: The patch (or its concept) could be a good thing. REBIND should probably be able to do this. I would express concern using dhclient, Network-Manager, or any implementation as standards references. Just for one example, dhclient seems to have an unresolved issue (for a while now) with handling the fqdn.fqdn option. Downstream Network-Manager and Debian solve this by just squashing the option all together. End result, host name does not end up in DHCPv6 leases. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH netifd 1/2] interface-ip: set address indicator flag when IPv6 address lifetime changes
On Thu, Mar 9, 2017 at 10:20 PM, Matthias Schiffer
wrote:
> On 03/09/2017 05:32 PM, Hans Dedecker wrote:
>> Trigger interface update event when IPv6 address lifetime changes by
setting
>> the address indicator flag to inform external subsystems about IPv6
address
>> lifetime change.
>>
>> Signed-off-by: Hans Dedecker
>
> AFAICT, this will cause a lot of ifupdate events in big IPv6 networks
(for
> example, some large mesh networks based on Gluon have more than 4000
client
> and 5-10 radvds, often causing more than one RA per second, each updating
> valid/preferred lifetimes). We *really* want to avoid causing lots of
> reloads for services that set triggers on interface updates; the majority
> of services is not interested in the lifetimes of addresses at all.
>
> Matthias
>
>
>> ---
>> interface-ip.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/interface-ip.c b/interface-ip.c
>> index ddca5d2..366f69a 100644
>> --- a/interface-ip.c
>> +++ b/interface-ip.c
>> @@ -563,8 +563,10 @@ interface_update_proto_addr(struct vlist_tree
*tree,
>> keep = false;
>>
>> if (a_old->valid_until != a_new->valid_until ||
>> - a_old->preferred_until !=
a_new->preferred_until)
>> + a_old->preferred_until !=
a_new->preferred_until) {
>> + iface->updated |= IUF_ADDRESS;
>> replace = true;
>> + }
>>
>> if ((a_new->flags & DEVADDR_FAMILY) == DEVADDR_INET4 &&
>> a_new->broadcast != a_old->broadcast)
It appears that the concerns with this commit have manifested as
undesirable side effects. For name servers, this flushes the cache. This
is would be a regression with perspective from other packages that use
the interface triggers only to start/reload. With my device and ISP,
this can happen as often as every 2 minutes. Please consider reverting
this commit or fix this new behavior to be a controllable feature. Maybe
enable/disable or limit to not more than every hour or other choice
time. FS#713. netifd/a03216660797173fbe67866f75564e3fec9c1e8d
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH netifd] Revert: set prefix indicator flag when IPv6 prefix lifetime, changes
This reverts commit a03216660797173fbe67866f75564e3fec9c1e8d. The previous
change causes IFUP events to occur from 30 seconds to 30 minutes depending
on various conditions at the WAN6 (typ.) interface. If a DHCPv6 lease is
24 hours and the connection is stable, then in other linux distro we would
expect IFUP every 24 hours. This is therefore a significant inconsistency
for LEDE. Add on package maintainers are going to be surprised by the
behavior. Use of the interface triggers in procd will experience further
thrashing. For example, procd managed DNS servers like dnsmasq and Unbound
will dump their DNS cache every 30sec to 30min due to reload triggers.
---
interface-ip.c | 4
1 file changed, 4 deletions(-)
diff --git a/interface-ip.c b/interface-ip.c
index 140ef34..dc246f0 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -1047,10 +1047,6 @@ interface_update_prefix(struct vlist_tree *tree,
list_for_each_entry(c, &prefix_new->assignments, head)
if ((iface = vlist_find(&interfaces, c->name, iface,
node)))
interface_set_prefix_address(c, prefix_new,
iface, true);
-
- if (prefix_new->preferred_until != prefix_old->preferred_until
||
- prefix_new->valid_until !=
prefix_old->valid_until)
- ip->iface->updated |= IUF_PREFIX;
} else if (node_new) {
// Set null-route to avoid routing loops
system_add_route(NULL, &route);
--
2.11.0
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH netifd] Revert: set prefix indicator flag when IPv6 prefix lifetime, changes
On 04/23/2017 10:23 PM, Eric Luehrsen wrote: > This reverts commit a03216660797173fbe67866f75564e3fec9c1e8d. The previous > change causes IFUP events to occur from 30 seconds to 30 minutes depending > on various conditions at the WAN6 (typ.) interface. If a DHCPv6 lease is > 24 hours and the connection is stable, then in other linux distro we would > expect IFUP every 24 hours. This is therefore a significant inconsistency > for LEDE. Add on package maintainers are going to be surprised by the > behavior. Use of the interface triggers in procd will experience further > thrashing. For example, procd managed DNS servers like dnsmasq and Unbound > will dump their DNS cache every 30sec to 30min due to reload triggers. > Original Patch discussion: >> Re: [LEDE-DEV] [PATCH netifd 1/2] interface-ip: set address indicator flag >> when IPv6 address lifetime changes >> On Thu, Mar 9, 2017 at 10:20 PM, Matthias Schiffer >> wrote: >> On 03/09/2017 05:32 PM, Hans Dedecker wrote: >>> Trigger interface update event when IPv6 address lifetime changes by setting >>> the address indicator flag to inform external subsystems about IPv6 address >>> lifetime change. >>> >>> Signed-off-by: Hans Dedecker >> >> AFAICT, this will cause a lot of ifupdate events in big IPv6 networks (for >> example, some large mesh networks based on Gluon have more than 4000 client >> and 5-10 radvds, often causing more than one RA per second, each updating >> valid/preferred lifetimes). We *really* want to avoid causing lots of >> reloads for services that set triggers on interface updates; the majority >> of services is not interested in the lifetimes of addresses at all. >> >> Matthias See Also FS#713 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH netifd] Revert: set prefix indicator flag when IPv6 prefix lifetime, changes
Hi Hans I guess I should have double checked FS#713. I thought it was set to notify, and just wasn't touched. Sorry about that. wrt: > As explained in FS#713 reverting this patch will lead to complaints > from people homenet is broken > (https://github.com/openwrt/openwrt/issues/346[1]); a more > fundamental fix is required possible in procd to fix the issue. Just a collection of thoughts: If HNET is "broken," then is HNET the daemon that needs a change not netifd? If a network parameter is a trivial change, then should a daemon use ubus/dbus/whatever to poll it on its own schedule? If a network parameter is critical to function like address (non-wildcard binding) or route, then isn't the network manager necessary to announce the surprise updates? If a package is "core," then shouldn't it be cared for more than something more external? Do we want dnsmasq to flush its cache frequently in the default LEDE distro, or do we want HNET to work (for how many users)? If procd isn't discerning about trigger types, then is netifd update premature? Should procd be fixed before netifd? As LEDE gets supplemented with more packages, we need delay-trigger control like LEDE, but frequent noise like this doesn't help? I see a few issues with a balanced path to a solution. So maybe a better plan could be revert this for _now_ and have a less troublesome change with procd and netifd updated coherently. Thanks Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 5/7] firewall3: add UBUS support for ipset sections
On 05/02/2017 05:36 PM, Paul Oranje wrote: > Assignment within a condition is easily read by (dyslectic) humans as a test > for equality (==) and is for that reason als better avoided. > Paul > >> Op 2 mei 2017, om 18:43 heeft Philip Prindeville >> het volgende geschreven: >> >> >>> On May 2, 2017, at 6:15 AM, Pierre Lebleu wrote: >>> >>> Hi Philip, >>> >>> 2017-04-29 3:11 GMT+02:00 Philip Prindeville >>> : >>> Inline… >>> >>> >>> [snip] + if (!(ipset = fw3_alloc_ipset(state))) >>> >>> >>> Minor nit… Assignments inside of conditionals are a bear to step through >>> in a debugger like GDB. >>> >>> -Philip >>> >>> It is a trivial assignment and it is already done in this style along the >>> file. >>> >>> -- >>> Pierre >>> >> >> >> It’s not about trivial vs. nontrivial. It’s about whether you could step >> through the assignment with (say) gdb, execute just the assignment, examine >> the value, and then step through the “if”. And the answer is, “you can’t”. >> Because gdb is a source level debugger where the unit of source is the >> “line”. >> >> (Actually, it’s also the unit of source for gcc when it generates debugging >> symbols.) >> >> The way to separate to 2 individual statements in C (for the purposes of gdb >> debugging) is to put them on separate lines. Yes, that’s a glaring >> limitation of gcc and gdb, but that’s our reality. >> >> As for what’s already done in this style in the file… Having separate >> assignments and tests is *also* done, and indeed it’s done more often. >> >> -Philip Others may have been clever but it doesn't mean a construct should continue. This if-assignment combo and other clever C constructs are frowned upon in popular software quality standards. Many simply are due to the above mentioned maintainability issues. Some industries may be more sensitive, but the rationale for avoidance is solid. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] dnsmasq-full should deselect dnsmasq
On 05/02/2017 02:22 PM, Andrew McConachie wrote: > > > On 5/2/17 10:13, Jo-Philipp Wich wrote: >> Hi Andrew, >> >>> When selecting package dnsmasq-full from make menuconfig I believe it >>> should deselect package dnsmasq. >> this is not easily solvable within the current Kconfig framework and >> most likely a "won't fix" item in the foreseeable future. >> >> ~ Jo > > Hi Jo, > > How then should my package depend on dnsmasq-full? If it's not possible > to de-select a package as a consequence of selecting another package, > then how can there be packages that provide the same files? > > Perhaps this is another stupid question, but what's the point of having > a package like dnsmasq-full if it cannot be DEPENDed upon? > > --Andrew Within the build tools there appears to be a construct for a single package, but with options that are selectable (for conditional compile or otherwise). Maybe dnsmasq Makefile should be redone for this method. I am not sure if it fixes the dependency issues. However, should multiple packages provide the "same-different" files is a good question. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] openwrt and lede - remerge proposal
Glad to hear the merge is coming and that enough issues were resolved to make this go forward. So ... I'll just throw my thoughts into the hopper. > On 05/08/2017 09:19 AM, John Crispin wrote: > > *) branding > From a raw objective stand, OpenWrt has better market value as a brand. Its longer lived on the net and more unique audibly. If we surveyed 1000 somewhat technical people, then we would have way more recognition hits. I realize the vote concluded already, but hopefully this thought helps ease some less happy minds. > > *) git / github > This is were LEDE staging model can really shine, if you use it. Lock both OpenWrt and LEDE to new business for set dates. Close all outstanding PR in both. Perform any "best of" merge activity in staging areas with core members who have time to participate. (not plebes from the peanut gallery like me.) Iterate on a few broken merges. Push the new-and-improved tree to OpenWrt. Reopen for business. If the project will use github, then have all project components (netifd, procd, odhcpd/c) use github. The half-in-half-out can be confusing and exclude participation. > > *) landing page > I would toss up a third possibility. Why not use the LuCI boot-strap theme as inspiration? The OpenWrt headline and radial from openwrt.org is good but the paneling could look a little more modern. > > *) trac > At some point, archive to raw text documents. No body wants to delete anything, but maintaining an active server-application to that end is just a burden. > > *) email accounts > For OpenWrt integrity, I would recommend a more assertive removal of personal email accounts. I realize this is contentious, but long term it protects OpenWrt from individuals who may attempt to misuse the brand. > > *) wiki / forum > There are long running discussions in each forum that serve as "documentation" in the absence of "documentation." OpenWrt wiki has a lot of outdated information. LEDE wiki is sparse. Closing this question requires a focused effort on improved documentation. Its easier to change if the human dependencies are not so tenuous. > > *) trademark/sponsorship > OpenWrt may generate a high value brand target in the future. Having seen charities and non-profits overrun by their sponsors I would simply urge caution. All most all sponsors have good intentions, selfish promotion yes, but good for the sponsored entity. It only requires one that doesn't and a hungry lawyer to make things difficult. Key sponsor concepts: non-exclusive sponsorship, limited term sponsorship, and no product delivery for sponsorship. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] openwrt and lede - remerge proposal
I read this on going thread and ... (sigh). "Good fences make good neighbors." Robert Frost People don't like rules and that could be even more true with open source work groups. However, a good set of _limited_ rules can make life easier. You may focus on important work or joyful recreation while not worrying about accidental trespasses. I was trying to hold back a thought as formal as "bylaws" but perhaps that is really the best way. That is ignore all the thoughts of what to name the community, who would handle the accounts, and where to point the DNS to. First thing and prerequisite to all others is a set of governing principals for a yet unnamed community. This community is for members who share a common affliction that they cannot help themselves but hack on embedded networking software. This applies not only to the voting members, but to the interactions respective to the wider community of contributers and power users. Much of OpenWrt/LEDE progress, interest, relevance, and value is made by these members of the wider community. The size of the sphere of influence and the community's self worth are determined by issues such as: on-boarding of voting members, on-boarding of committing members, separating requirement of commits from votes, transparency of decision making, email accounts, other privileges that over emphasize badge of authority, and general attitude of the core voting members. Such schisms occur in all organizations (business and nations). When it happens the first time, then it is a leaning opportunity. If the opportunity is ignored, or the solution glosses over the details of the underlying root cause, then the situation will repeat. A repeat event is more damaging to the credibility of an organization than the first one. - Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] openwrt and lede - remerge proposal
In my comments, recognize LEDE rules and consider them a great start. Also there seems to be a lot of chatter about concerns of merge compromise to these rules. Some of those concerns seem well founded. I would suggest that the LEDE rules be edited with some more consideration to recently raised concerns. Then, all members OpenWrt and LEDE side vote to agree to adhere to the (new?) rules as written. It can all be in the details. The following are examples of deeper thinking that could to go into the rules. The following are not the "answer" but rather the stream of consciousness that might arrive at the right "question." For example, rule (7) says all votes and decisions will be public but it lacks a formal expression that some decisions (intermediate term) need confidentiality. How do you handle bidding for services or inquiries by sponsors? "Time Limited Confidentiality" is a necessity but uncovered by the rules it becomes what we call in process engineering "hidden factory." It erodes the value of the rule and evolves into an excuse to ignore the rule. For example, rule (10) contentious email clause could be dealt with maybe if rule (12) had more details and more teeth. What if rule (12) put a higher order of behavioral expectations on voting members. Would that permit personally named email accounts with the project domain to be given for the purpose of representing the project in upstream commits? What if a new rule was added that all email between the project and outside individuals or organizations is cc: to an archive? This archive would be made public, only redacting unfinished business for short time as I mentioned for updates to rule (7). Would this calm people down? On 05/12/2017 12:17 AM, David Lang wrote: > thereare formal rules: > > https://lede-project.org/rules > > 1. The only role distinction within the LEDE project is between > committers and non-committers, there is no core developer group or other > specially privileged members. > > 2. All committers have the right to vote and are invited to liberally > exercise this voting right in order to keep a broad consensus on project > matters. > > 3. Project matters, overall development directions etc. are decided by > simple majority votes. Votes may be held in different ways like simple > yes/no decisions, majority decisions among multiple proposed choices etc. > > 4. Committers being unreachable for three months in a row shall get > their commit and voting rights revoked in order to retain the ability to > do majority votes among the remaining active committers. > > 5. There shall be only full commit rights in any case, no partial access > or otherwise restricted access to the repositories. > > 6. Frequent contributors may become committers after a simple majority > agreement among existing committers. Project members are free to suggest > suitable people. > > 7. Any votes and decisions made will be made public on the project > websites. > > 8. Project infrastructure should be outsourced FOSS community operated > services whenever possible in order to allow project members to focus on > actual development efforts. > > 9. Any infrastructure that cannot be outsourced and/or is operated by > the project itself shall be administrable by at least three different > people to reduce the likelyhood of the project getting locked out due to > operators being unreachable. > > 10. Responsible operators for the various services shall be documented > publicly. The project will not offer email accounts under its project > domain for privacy and equality reasons. > > 11. Changes to these rules require a two third majority among the > committers holding voting rights and shall be documented. > > 12. Be nice to each other. > > what is it on this list that people are objecting to? > > what is it that people say needs to be added to the list? > > are the people objecting amoung those who would have to comply with > these rules? or are they outsiders (I am an outsider) > > David Lang > > On Fri, 12 May 2017, Eric Luehrsen wrote: > >> Date: Fri, 12 May 2017 04:09:31 + >> From: Eric Luehrsen >> Cc: LEDE Development List >> Subject: Re: [LEDE-DEV] openwrt and lede - remerge proposal >> >> I read this on going thread and ... (sigh). >> >> "Good fences make good neighbors." Robert Frost >> >> People don't like rules and that could be even more true with open >> source work groups. However, a good set of _limited_ rules can make life >> easier. You may focus on important work or joyful recreation while not >> worrying about accidental trespasses. >> >> I was trying to hold back a thought as formal as "bylaws&q
Re: [LEDE-DEV] convention on uid/gid for packages
On 05/13/2017 06:23 PM, Val Kulkov wrote: > Is there any convention on the use of uid and gid when creating new > users or groups? Can someone point me to it, if it exists? > > I noticed that two packages, icecast and postfix, compete for the same uid=87: > > icecast's Makefile: > USERID:=icecast=87:icecast=87 > > postfix's postfix.init: > user_exists postfix || user_add postfix 87 > > There may be more packages competing for the same uid/gid's, I have > not fully researched it. > > I am preparing a new package, opendkim, which should be run as a > non-privileged user. For this, > USERID:=opendkim=:opendkim= seems appropriate, > but what numbers should I assign? > > Val I think that it is possible to allow the package installer to randomly assign the UID/GID. "USERID:=user:group" This didn't work for all releases, so I didn't try it for Unbound. Maybe it is time to give it a chance. - Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] convention on uid/gid for packages
On 15.05.2017 18:02, Val Kulkov wrote: > On 15 May 2017 at 11:46, Yousong Zhou wrote: >> On 15 May 2017 at 23:29, Val Kulkov wrote: >>> Yousong, perhaps I was not clear. What I am suggesting is to change >>> the auto-allocation to start from 1000 rather than from 100 (1000 is >>> just a suggestion, it could be anything else that is high enough), and >>> to have a convention to allocate the 1-999 range to the services. >>> Then, the allocation of uid/gid for any new package would be subject >>> to review and approval by the reviewers. We would have to maintain a >>> Wiki page listing all uids and gids that have already been taken, >>> FreeBSD-style. >>> >>> This way, we would only have to reallocate uids and gids for packages >>> that are 1000 and higher. The other packages that use uids and gids in >>> the 1-999 range would not be affected, other than the packages that >>> already have a conflict (icecast and postfix, for example). >>> >> I guess the the user, group related utility functions are intended for >> use by services only. Adding users and groups for multi-user >> interactive is just not the use case for LEDE (this is only personal >> opinion and not in the book). >> >> The suggestion is to let default_postinst to auto-allocation uid/gid >> from 1 or 100, and let useradd/useradd/groupadd/addgroup to start from >> whatever high number. >> >> If we can automate things without separately maintaining a list of any >> kind and manual cooperation across groups of people, we should prefer >> that >> >> yousong > I agree that not depending on the manual cooperation across groups of > people would be ideal. However, updating 35+ packages to use the > auto-allocation mechanism is not an easy undertaking. Besides, some of > the packages might actually rely on particular numeric uid/gid's - we > don't know until we run tests with these packages. > > Here is another suggestion. make menuconfig might collect all USERID:= > strings from all packages and produce a list of uids and gids that > have been taken so that the auto-allocation mechanism will stay away > from these uids/gids. Such lists will likely be fairly compact, taking > perhaps less than 500 bytes. This will (1) avoid conflicts between > packages, (2) avoid the need to re-do the uid/gid allocation for 35+ > packages, and (3) not require manual cooperation between groups of > people in the future. I know for Unbound package the hard coded GID/UID doesn't functionally matter. Many other packages seem to be the same. You need a non-root user to drop down to. You also don't want one common other user or else "nobody:nogroup" becomes the new root (in a way). It may not be so difficult to get cooperation. Trouble occurs supporting LEDE vs OpenWrt split. Some people want to SDK only a few latest add on packages, but keep their preferred stable base. 15.01.1 doesn't support install UID/GID assignment. There are other divergences. Compatibility across the split generates non-ideal design choices. It makes maintaining optional packages more and more difficult. Once that matter is closed, this symptom effect may all but solve itself. - Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] openwrt and lede - remerge proposal
On 05/15/2017 09:11 PM, Philip Prindeville wrote: >> On May 11, 2017, at 10:09 PM, Eric Luehrsen wrote: >> >> People don't like rules and that could be even more true with open >> source work groups. However, a good set of _limited_ rules can make life >> easier. You may focus on important work or joyful recreation while not >> worrying about accidental trespasses. > > > I can’t say I agree. > > Part of my past frustration with submissions to OpenWRT was that I was cited > “requirements” that needed to be satisfied before my PR’s could be merged. > Oftentimes these “requirements” weren’t written down anywhere else and didn’t > seem to be applied in a even-handed way. These “requirements” occasionally > seemed more like individual preferences, and more than once I was told by one > person “You need to do things this way” only to be told I needed to do things > the exact opposite some time later by yet another person. > > That was a few years ago. Lately things are marginally better, if noticeably > bandwidth-limited. > > In sort… I’d rather have the rules all called out and be out in the open, > thereby people can be assured that if they follow the rules they will have > met the requirements (ALL the requirements) for their PR’s to be merged > without having to watch the goal posts be moved… > > -Philip I was referring to policy, procedure, organization, and behavior rules. The kind that once you accept them for the organization they keep you from stepping on each others toes. Style guides and other work product detail rules are part in another subject. But again we can consider a similar concept of _limited_ and as you said _written_ rules. When they are unwritten, then some unpleasant individual can block your participation because, well, just because. If a group writes "these are seven submission requirements and the only seven," and they adhere to them, then it is much harder for an unpleasant individual to be arbitrary. -Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] openwrt and lede - remerge proposal
On 05/15/2017 10:16 PM, Philip Prindeville wrote: >> On May 12, 2017, at 6:02 AM, Edwin van Drunen wrote: >> >> I understand that the vote is done amongst the developers, the people >> actually running the project, this makes sense. >> But if the goal of the project is not only to keep yourself busy, but also >> to target a larger audience, it makes sense to base some decisions on >> "market research". >> The name is very important for user perception and influences the audience >> you will reach. > > > Maybe one person as the “user ombudsman” could be given a vote. > > I have no idea how such a person would be chosen, however. > > -Philip An assigned vote might be a bit much. Mailing list banter like this could be useful advice, if it is observed carefully. A two-pass voting process with a comment period could help. Any organization should find a way to stay in touch with its patronage, whether its funds or volunteer labor. -Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Remerge logo ideas
On 05/29/2017 07:45 AM, Imre Kaloz wrote: > On 2017-05-29 13:10, Jamie Stuart wrote: >> See another iteration, with: >> >> - correct capitalisation >> - antenna to the side (will not work with lowercase ’n’) >> - open sans typeface (open source) >> - mockups of website header >> - accent colours >> >> http://i.imgur.com/ZKtcFXo.png > > Nice :) Personally I like the darker color set of the last, but the > layout of the first the most (when the "signal" is at the end). > > > Imre Excellent. Many simple picture-and-word logos lead with the picture and follow with the word. This may help with recognition. If an individual or product maker is advertising support for OpenWrt, then that may strengthen their efforts. Also because it is simple, the choice of color may warrant more iteration or time to be sure it right. - Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] openwrt and lede - remerge proposal V3
On 05/29/2017 03:03 AM, John Crispin wrote: > (resend, this time as plain text) > > Hi, > > here is a V3 of the remerge proposal, I tried to fold all the comments > people made into it, if anything is missing let me know. Please remeber > that post remerge anything can be voted on, so cluttering the proposal > with many details will delay the remerge even more. > > Ideally we manage to vote during this week. > > John I agree with respect to participation as an outsider. Rules, voting, and email line items should (continue to) encourage high participation. Shifting OpenWrt name to the current LEDE home, bug tracker, and git trees might be psychological reenforcement of the same. - Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] solar wifi AP designs
On 06/04/2017 08:46 PM, Dave Taht wrote: > I keep finding nicely integrated solar/battery/camera designs like these > > https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Delectronics&field-keywords=solar+wifi&rh=n%3A172282%2Ck%3Asolar+wifi > > But what I'd like is just something with solar and battery that could > function as an AP, that was well supported by lede. Ideas? > A router that runs on a 12V supply - https://www.amazon.com/TP-Link-Archer-C7-Wireless-Gigabit/dp/B00BUSDVBQ/ref=sr_1_2?ie=UTF8&qid=1496629045&sr=8-2&keywords=tp+link+archer+c7 Good old fashioned lead acid battery - https://www.amazon.com/Interstate-Batteries-SLA1116-Lead-Battery/dp/B004KNPIWS/ref=sr_1_4?ie=UTF8&qid=1496628899&sr=8-4&keywords=Interstate+Batteries 12V Solar Panel - http://www.homedepot.com/p/Nature-Power-22-Watt-Amorphous-Solar-Panel-Charging-Kit-with-8-Amp-Charge-Controller-for-12-Volt-Systems-42022/300854090?MERCH=REC-_-PIPHorizontal1_rr-_-204759893-_-300854090-_-N Duct Tape :-) - http://www.homedepot.com/p/NATIONAL-1-89-in-x-40-yd-Utility-Grade-Duct-Tape-Silver-1118105/202352331 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] dnsmasq: write resolv.conf also when noresolv = 1
Hi Paul - The solution I put into Unbound scripts was due to this trickiness. dnsmasq and its little extra functions have become entrenched and necessary in base OpenWrt/LEDE. This includes the oddities in architecture for UCI and LuCI. Normally, it is much easier to bind to the wild card address. So one might assume that the primary binds to #53, and any other instance must use a different port. It is also possible to bind per interface. An instance may bind to 127.0.0.1#53, another 192.168.1.1#53, and yet another to 192.168.2.1#53. Depending on subnet management and access limiting controls, this could get complicated. Requirements first. In an ecosystem with a choice of DNS servers (multiple instances each and stub vs recursive), what shall be the direct or inferred protocol to denote the primary DNS instance? The scripts all but write themselves with such requirement set and agreed to. - Eric > (in short: when dnsmasq.noresolv=1 and dnsmasq.resolvfile is unset, then > /tmp/resolv.conf is not handled). > > After some analysis the conclusion is that the dnsmasq init script should > handle /tmp/resolv.conf, if and only if, when its main instance is run. The > main instance is designated the one that will listen on 127.0.0.1#53 > (naturally there can be only one such instance). > > When using unbound with UCI unbound.dhcp_link set to “dnsmasq”, the unbound > init script does **not** handle /tmp/resolv.conf and leaves it to dnsmasq to > do so. In the dhcp_link=dnsmasq setup it is unbound that listens on > 127.0.0.1#53 and so no instance of dnsmasq can possibly be the main instance. > Which makes sense. > > An attempt to solve this problem just within the scope of the dnsmasq init > script has proven to be more convoluted than I first thought. > > A simple, sane and much more elegant solution would be: > a) dnsmasq indeed only handles /tmp/resolv.conf when it runs the main > instance and > b) unbound does so when it the main instance, i.e. will listen on > 127.0.0.1#53. > > Do you agree ? > > If so, could you share your thoughts on how best to do the unbound change ? > A few different approaches to the determination of $resolvsym seem possible, > but I’m sure that picking best/easiest/whatever approach is best chosen by > you. > > Regards, > Paul > > >> Op 4 jun. 2017, om 16:26 heeft Paul Oranje het volgende >> geschreven: >> >> Good afternoon, >> >> Conclusions: >> 1) Always initialise $resolvfile (i.e. independently of the state of >> noresolv). >> 2) The value of $resolvfile cannot not be used the determine the dnsmasq >> main instance since several instances likely will an equal value. >> 3) The main dnsmasq instance is the instance that listens on 127.0.0.1:53 >> (of which there can only be one or none). >> 4) When no local DNS resolver runs /tmp/resolv.conf should soft-link >> $resolvfile (and that could possible be something else than >> /tmp/resolv.conf.auto). >> >> ad 3) >> The designated main instance can be determined at runtime by: >> - at start of an instance X, when this instance is configured to listen on >> 127.0.0.1#53 and no process listens on that socket, then >> - at stop of an instance X, when this instance is configured to listen on >> 127.0.0.1#53 and a process listens on that socket, then >> >> For a listening-on test something like “nslookup localhost 127.0.0.1#53 >> >/dev/null” would seemingly work (though not on OWRT CC), but that will >> incur a timeout delay (10 sec ?) when no daemon is listening. >> Understandably, suggestions for an alternative test that will not incur such >> a timeout are welcome. >> >> The above determination of the main instance assume that only one of >> multiple instances is configured to listen on 127.0.0.1#53, otherwise the >> tests may result erroneously in undefined behaviour. >> >> ad 4) >> A use-case for setting resolvfile to a non-default might be the use of >> different upstream resolvers for different subnets, though that could easily >> be achieved with the server options of UCI dhcp.dnsmasq[x]. >> >> >> Regards, >> Paul >> >> >> >>> Op 4 jun. 2017, om 00:09 heeft Hans Dedecker het >>> volgende geschreven: >>> >>> On Sat, Jun 3, 2017 at 3:33 PM, Paul Oranje wrote: Thanks, please see a few quick reactions of mine inline ... Paul > Op 3 jun. 2017, om 14:18 heeft Hans Dedecker het > volgende geschreven: > > On Thu, Jun 1, 2017 at 12:00 PM, Paul Oranje wrote: >> Hello Hans, >> >> A new version of this small patch is worked on -overlooked your previous >> comment and have lately been busy with other stuff-, but after studying >> the code a little more I’ve a few questions. The intended patch changes >> code that was added with commit a35f9bbc43c3da06eed042f80dc09e8c1da681b4 >> (dnsmasq: Multiple dnsmasq instances support) that was authored by you. >> >> >> The routines dnsmasq_start() and dnsmasq_stop() contain a guard on >>>
Re: [LEDE-DEV] ddns problem
On 06/05/2017 11:39 AM, Toke Høiland-Jørgensen wrote: > "Giuseppe Lippolis" writes: >> Dear All, >> I have a problem with the pkg ddns-scripts_2.7.6-14_all. >> I'm using the option service_name 'dyndns.org'. >> >> After running the script I get in logread: >> >> Mon Jun 5 15:27:27 2017 user.err ddns-scripts[2591]: myddns_ipv4: No or >> private or invalid IP '100.67.31.70' given! Please check your >> configuration > It means what it says: that IP is in a private address space (allocated > for carrier grade NAT; see > https://en.wikipedia.org/wiki/Private_network#Dedicated_space_for_carrier_grade_NAT_deployments). > So you can't get your real public IP off the router; and probably, you > won't be able to access the router from the outside regardless of > whether your dyndns setup works, sadly... :/ 100.64.0.0/10 is shared address space under RFC6598. IETF seems to point to significant restrictions on its use. Customer connectivity issues are clear in the RFC. Chasing mobile load and avoiding rerouting global IP space is likely fair. Enumerating users fixed wire line end points is likely not fair. CGN should free IP from internal routing equipment for customer assignment. Depending on the consumer protections in your jurisdiction, you may wish to give your ISP a call. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] dnsmasq: write resolv.conf also when noresolv = 1
On 06/05/2017 06:48 AM, Paul Oranje wrote
>The current guard (resolvsym) is now determined with:
> if [ ! -x /usr/sbin/dnsmasq -o ! -x /etc/init.d/dnsmasq ] ; then
> resolvsym=1
> else
> /etc/init.d/dnsmasq enabled || resolvsym=1
> fi
>
> This assumes that dnsmasq when enabled, in whatever way, will handle
/tmp/resolv.conf.
> A correct solution would be to handle /tmp/resolv.conf in the unbound
init script whenever unbound will listen on 127.0.0.1#53. Then
/tmp/resolv.conf is handled whenever either dnsmasq or unbound listens
on 127.0.0.1#53.
> Agree ?
>
> The unbound init routines **should** handle /tmp/resolv in this case,
but currently do not (when dnsmasq is the dhcp_link).
> Proposed code:
>
> unbound_ismain() # true=0, false=1.
> {
> if [ "$UNBOUND_D_DHCP_LINK" = "none" ] \
> && /etc/init.d/dnsmasq enabled && [ -x /usr/sbin/dnsmasq -a
-x /etc/init.d/dnsmasq ] ; then
> return 1
> fi
>
> # unbound is designated to listen on 127.0.0.1#53.
> return 0
> }
>
The Unbound scripts load all the configuration into script global
variables first. It should make this kind of thing much easier than
that. If Unbound owns #53 and dnsmasq doesn't (by UCI), then it can
manage resolv.conf. After determining if dnsmasq is even active (keep
current if-else), then make sure there is no UCI conflict (if resolvsym
and owns #53). If someone is just beginning to reconfigure UCI after an
install, then Unbound needs to defer to the default while in conflict.
Something like that I think might work, and not foul a system during a
package load and configure.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] dns setup problem
On 06/21/2017 03:42 PM, e9hack wrote: > Hi, > > the dns setup for dnsmasq does have a bug. If option resolvfile is used and > its value isn't '/tmp/resolv.conf.auto', > name resolution doesn't work. The given file is empty. A file > '/tmp/resolv.conf.auto' is generated and contains the > correct dns servers, but it isn't used by dnsmasq. This makes option > resolvfile useless. > > Regards, > Hartmut Isn't the purpose of this option to (1) normally use the default auto generated copy or (2) use one that is custom as either static or generated by another means. That is to say, if you change this option, then you need to provide the target file for the option. - Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] LEDE call for vote on remerge proposal V3
On 06/27/2017 04:55 PM, Hauke Mehrtens wrote: > On 06/26/2017 11:59 PM, Hauke Mehrtens wrote: >> On 06/10/2017 03:13 PM, Hauke Mehrtens wrote: >>> Hi, >>> >>> As many already acknowledged this proposal I would like to call for an >>> official vote among the LEDE committers till 14.6.2017 on this proposal. >>> I counted the following replays to the proposal already as an >>> acknowledgment: >>> Steven, Matthias, Stijn, Hauke, Florian, Daniel, Hans, John, Rafał, >>> Felix, Alexander, Piotr >>> If you till ack it, you do not have to do it again. >>> >>> I haven't seen any NACK among the LEDE committers till now. >>> >>> If this will get accepted by the LEDE committers and also the OpenWrt >>> core developers accept it, I would like the OpenWrt core developers >>> start with migrating the openwrt.org domain to the SPI as a first step. >>> >>> Hauke >> Sorry it took me longer to count the votes. ;-) >> >> The remerge proposal was acknowledged by the following LEDE developers: >> Steven, Matthias, Stijn, Hauke, Florian, Daniel, Hans, John, Rafał, >> Felix, Alexander, Piotr and Jonas (13) >> >> In addition it was acknowledged by the following OpenWrt hackers: >> Zoltan, Miken, Imre and Matteo (4) > John told me that OpenWrt is currently only represented by Imre, Luka > und Zoltan, so Matteo and Mike then probably go into the next category, > but this does not change the end result. > >> The following people I was unable to put into one of these groups also >> acknowledged it: ;-) >> Koen, Vincenzo, Alexandru and Eric (4) This might be called an "advisory opinion" in some context. That is encouragement or suggestions from active participants eternal to the core group. It only has the power of persuasion and no authority. >> I counted one Not acknowledge: >> Jow (1) >> >> I used this list for the LEDE developers: >> https://lede-project.org/about#people >> >> With that vote the remerge is officially approved by the LEDE developers >> and also by the OpenWrt hackers. >> >> >> As a first step I would like to see the openwrt.org domain being >> transfered to the Software in the Public Interest, Inc (SPI) so the SPI >> can take the ownership of the domain in the name of the project, like >> they do for the debian.org domain name. >> Imre will you take care of this please. > Transferring the openwrt.org domain to the SPI is seen as a prerequisite > before the next steps will be taken by the LEDE developers. > > @Imre: I assume this needs multiple steps, could you please update us on > the status of transferring the openwrt.org domain to the SPI please. > >> Imre and John volunteered to represent us at the SPI. As I haven't read >> anybody having a problem with that in the mail threads, I assume that >> this is ok with everyone. Imre and John can you please also work on this >> topic. If anyone wants a formal vote on this or would like to have other >> people representing us please speak up now. > John said that he would represent the merged project at the SPI. > > Hauke > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Stock config files as templates
I would recommend two options and break this into two steps or concepts. (1) A new option removes default servers. This option is independent of option 2. For implementation, an inline awk script might have more robust syntax then sed. (2) Current list server option adds servers to the list. Easy and purely additive. - Eric > Original message > From: Philip Prindeville > Date: 7/25/17 12:29 (GMT-05:00) > To: LEDE Development List > Subject: [LEDE-DEV] Stock config files as templates > > I’m working on Issue #4588 (ntpd needs UCI parsing comparable to sysntpd) and I had a question… > > ntpd ships with the canned /etc/ntp.conf from the distro, but if we specify: > > config timeserver ntp > list server ‘ntp.redfish-solutions.com’ > > then the /etc/ntp.conf file needs to be rewritten as: > > driftfile /var/lib/ntp/ntp.drift > > server 0.openwrt.pool.ntp.org iburst > server 1.openwrt.pool.ntp.org iburst > server 2.openwrt.pool.ntp.org iburst > server 3.openwrt.pool.ntp.org iburst > ... > > to: > > drift file /var/lib/ntp/ntp.drift > > server ntp.redfish-solutions.com iburst > ... > > instead. Are there any good guidelines (or examples) on how to mangle config files in-place? > I’m guessing I’d need a sed script with a loop to gather all of the ‘server’ lines and replace them with one. > Or am I missing something obvious? > > Thanks, > -Philip ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] RFC [PATCH] odhcpd: don't enable server mode on dhcp lan
On Thu, Aug 31, 2017 at 11:35 PM, Karl Palsson wrote: > > > > Daniel Golle wrote: > >> Hi Karl, > >> > >> On Thu, Aug 31, 2017 at 05:17:38PM +, Karl Palsson wrote: > >> > Instead of blindly enabling the odhcpd v6 server and RA server on the > >> > lan port, only do that if the lan port isn't set to DHCP. > >> > > >> > This prevents the unhelpful case of a device being a dhcpv4 > client and > >> > v6 server on the same ethernet port. > >> > >> Generating UCI from presumingly already generated UCI has > >> proven to be a bad practise in the past. See inline for an > >> alternative approach. > > > > Cool with me, the json_load approach is. kinda opaque still > > at the moment, but if that's the future and meant to be magically > > more stable, awesome. (This file was _already_ looking at "uci -q > > get dhcp.odhcpd" not using any json loading, so... I just > > followed the course) > > > > But the general concept? Is that ok? That's more interesting to > > me :) > I like the idea > I wonder if enabling DHCPv6 and RA as server on interfaces having a > non static protocol is usefull; so can we just check for the protocol > being static to enable DHCPv6 and RA as server ? > > Hans > > > > Sincerely, > > Karl Palsson > > > >> > uci -q get dhcp.odhcpd && exit 0 > >> > touch /etc/config/dhcp > >> > > >> > +LANPROTO=$(uci -q get network.lan.proto) > >> > >> Imho it'd be nicer to read this via > >> ``` > >> . /usr/share/libubox/jshn.sh > >> > >> json_load "$(cat /etc/board.json)" > >> json_select network > >> json_select lan > >> json_get_vars protocol > >> json_select .. > >> json_select .. > >> ``` > >> > >> > >> > +MODE=server > >> > + > >> > +case "$LANPROTO" in > >> > +"dhcp") > >> > + echo "odhcpd: Not enabling server mode on a dhcp lan!" > > /dev/kmsg > >> > + MODE=disabled > >> > + ;; > >> > +esac > >> > + > >> > uci batch < >> > set dhcp.odhcpd=odhcpd > >> > set dhcp.odhcpd.maindhcp=0 > >> > set dhcp.odhcpd.leasefile=/tmp/hosts/odhcpd > >> > set dhcp.odhcpd.leasetrigger=/usr/sbin/odhcpd-update > >> > set dhcp.odhcpd.loglevel=4 > >> > -set dhcp.lan.dhcpv6=server > >> > -set dhcp.lan.ra=server > >> > +set dhcp.lan.dhcpv6=$MODE > >> > +set dhcp.lan.ra=$MODE > >> > commit dhcp > >> > EOF > >> > -- > >> > 2.4.11 This is just a consideration, not a complete thought. odhcpd is a light weight server so it doesnt participate with fail over controls (without scripting). But fail-over DHCP severs can configure from the master/acting DHCP sever; then remain on standby until needed. An dynamic LAN protocol could then re-serve on the same interface. - Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [RFC] A new developper documentation for OpenWrt/LEDE
On 10/25/2017 12:19 PM, John Norton wrote: On 25/10/2017 17:22, Baptiste Jonglez wrote: Hi, As an occasional contributor to OpenWrt/LEDE, I am often frustrated by the lack of good technical documentation. By "technical documentation", I mean a detailed, reasonably complete and up-to-date documentation on "How things work under the hood" and "How to do advanced stuff with the build system". That is, documentation targeted at hackers, contributors, and would-be developers. So, here is a RFC proposal of a new developer documentation based on git and Sphinx: I share the frustration, and imho the lack of good docs is a big barrier to serious contributions (I mean beyond adding support for new devices). I like your idea, I don't think that being in git would be bad for developer docs, as: people actually writing these things should be developers in the first place so it's reasonable to assume that they won't be turned off by having to use git, as they use git anyway. Also the fact that to change the docs you need to get past a person with commit access should help filter and correct changes by someone that actually knows well the system. We can easily import the text from git to be shown (read-only) in the wiki too, for the sake of easy access for all. What MUST live in the wiki is user-oriented documentation, as it is the one most non-developers contribute to. -Alberto User-oriented documentation should go with specific packages in their respective git home. I have seen where packages like adblock, travelmate, and odhcpd (partially) have their documentation in .../files/README.md. I have made sure the same is done for Unbound. The focus of these should be "this package only," and optionally if not too wordy or complex, some minor recipes for integrating the package with another. External packages and core packages (like dnsmasq) should really all follow this pattern. Also, make sure the LuCI page(s) have a formatted link to the repo (github or...). -Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] umdns: Replace unnecessary memset calls with {}.
On 11/12/2017 09:49 PM, ros...@gmail.com wrote:
On Wed, 2017-11-08 at 21:17 +0100, Arjen de Korte wrote:
Citeren Rosen Penev :
Less verbose.
And uses a GCC extension which makes it less portable. ISO C
forbids
empty initializer braces [1]. See for yourself by adding the
-pedantic
flag to your CFLAGS. The correct way to initialize to all-zeros is
therefore { 0 }.
[1] ISO/IEC 9899:201x, paragraph 6.7.9 Initialization, clause 21
"If there are fewer initializers in a brace-enclosed list than
there
are elements or members
of an aggregate, or fewer characters in a string literal used to
initialize an array of known
size than there are elements in the array, the remainder of
the aggregate shall be
initialized implicitly the same as objects that have static storage
duration."
I decided to test this with the following program.
#include
#include
#include
int main()
{
struct k {
int h;
int t;
};
struct k z = {5};
printf("%d", z.t);
return 0;
}
;
0 was printed instead of 5.
This is what should happen. It doesn't repeat a pattern. To rephrase
ISO-C standard. If the implied initialization of COMMON or weak
definitions is 0, then partial initialization will initialize forgotten
elements to 0. As a consequence one quality check done in some
organizations is expect: {0} only, maybe require curls representing
nested depth, or all elements explicitly initialized, else any other is
rejected.
- Eric
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] procd: Remove unnecessary memset calls.
On 11/12/2017 10:53 PM, ros...@gmail.com wrote:
Tested compile size difference. Saves 32 bytes. ¯\_(ツ)_/¯
On Tue, 2017-11-07 at 12:05 -0800, Rosen Penev wrote:
Changes allocation to calloc and {} as needed.
Signed-off-by: Rosen Penev
---
inittab.c | 6 ++
plug/hotplug.c | 7 ++-
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/inittab.c b/inittab.c
index 21172f7..c27c324 100644
--- a/inittab.c
+++ b/inittab.c
@@ -284,8 +284,7 @@ void procd_inittab(void)
regcomp(&pat_inittab, "([a-zA-Z0-9]*):([a-zA-Z0-9]*):([a-zA-
Z0-9]*):(.*)", REG_EXTENDED);
line = malloc(LINE_LEN);
- a = malloc(sizeof(struct init_action));
- memset(a, 0, sizeof(struct init_action));
+ a = calloc(1, sizeof(struct init_action));
while (fgets(line, LINE_LEN, fp)) {
char *tags[TAG_PROCESS + 1];
@@ -322,8 +321,7 @@ void procd_inittab(void)
if (add_action(a, tags[TAG_ACTION]))
continue;
line = malloc(LINE_LEN);
- a = malloc(sizeof(struct init_action));
- memset(a, 0, sizeof(struct init_action));
+ a = calloc(1, sizeof(struct init_action));
}
fclose(fp);
diff --git a/plug/hotplug.c b/plug/hotplug.c
index 49c177f..6e55f67 100644
--- a/plug/hotplug.c
+++ b/plug/hotplug.c
@@ -434,12 +434,10 @@ static void handle_button_complete(struct
blob_attr *msg, struct blob_attr *data
if (!name)
return;
- b = malloc(sizeof(*b));
+ b = calloc(1, sizeof(*b));
if (!b)
return;
- memset(b, 0, sizeof(*b));
-
b->data = malloc(blob_pad_len(data));
b->name = strdup(name);
b->seen = timeout;
@@ -584,11 +582,10 @@ void hotplug_last_event(uloop_timeout_handler
handler)
void hotplug(char *rules)
{
- struct sockaddr_nl nls;
+ struct sockaddr_nl nls = {};
int nlbufsize = 512 * 1024;
rule_file = strdup(rules);
- memset(&nls,0,sizeof(struct sockaddr_nl));
nls.nl_family = AF_NETLINK;
nls.nl_pid = getpid();
nls.nl_groups = -1;
wrt. hotplug() -- When a fixed size aggregate will live only on the
stack, initializing it is faster than calling allocation function(s).
Not that any _one_ of them would be significant, but as a coding pattern
it can add up. Even if you permit in-line standard functions, then there
still are presumed behaviors of the function which will likely be
implemented. Initialization on the stack will not incur the overhead.
- Eric
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] odhcpd: possible regression in make DHCPv4 support compiletime configurable
FS#1188 has been raised due to problems for optional build recipes in "dhcpv4: make DHCPv4 support compiletime configurable" (d80621fea5cafcdca3f7fe762fede374a66e4b2) because no odhcpd-full package is build bot available. However, it also appears that conditionally compiling DHCPv4 back in does not work. This may be a rather significant regression. - Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Using older kernel in 17.01.4
Hi Nishant - As a possible alternate solution... If you don't need the curvature feature of HFSC, then HTB will work just as well. It handles the hierarchy and bandwidth sharing. Some may express concern HTB is slower at high bandwidths. This isn't entirely true. The HTB parameters "burst" and "cburst" are the bucket(s). These two parameters need to be sized to hold about 0.5 [ms] of flow (or min. MTU+10%). Otherwise, each time the bucket is empty a software interrupt occurs. With whatever the router needs to do, this can hurt throughput. You can look at the sqm-scripts github history [https://github.com/tohojo/sqm-scripts] for some of the discussions comparing the different shapers. - Eric On 11/24/2017 12:43 AM, Nishant Sharma wrote: Hi, The bug in HFSC and SCH is big issue for us as we can't do QoS reliably. I had to rollback to OpenWrt 15.05.1 in order to resolve the issue. Is there a way where I could specify an older kernel version while building the firmware using source of 17.01.4? Thanks in advance for pointers. Regards, Nishant ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] odhcpd: possible regression in make DHCPv4 support compiletime configurable
On 11/23/2017 03:54 AM, Hans Dedecker wrote: Hi, On Thu, Nov 23, 2017 at 6:38 AM, Eric Luehrsen wrote: FS#1188 has been raised due to problems for optional build recipes in "dhcpv4: make DHCPv4 support compiletime configurable" (d80621fea5cafcdca3f7fe762fede374a66e4b2) because no odhcpd-full package is build bot available. However, it also appears that conditionally compiling DHCPv4 back in does not work. This may be a rather significant regression. I'm running odhcpd as DHCPv4 server in a CI setup and don't notice any issue. Please provide more info as requested in https://bugs.lede-project.org/index.php?do=details&task_id=1188 to facilitate trouble shooting as I'm unable to reproduce the issue. Hans - Eric It seems that it was something happening in 'make' (w/ CMake) build avoidance. In an attempt to figure it out, I think I lost the rabbit. My system works now as well. - Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] DNS split horizon *without* dnsmasq
On 03/25/2018 03:27 AM, Philip Prindeville wrote: Thinking Bind, probably. On Mar 23, 2018, at 5:38 PM, Eric Luehrsen wrote: What do you want to serve your dns then? Unbound or Bind? - Eric On Fri, Mar 23, 2018, 1:31 PM Philip Prindeville wrote: Hi all, As the ISC-DHCP maintainer, I need to eat my own dogfood so I run that here, before anyone quips, “Why don’t you just run dnsmasq instead?” So… I have some internal names that I want to be able to resolve internally, but I also need to provide DNS service for all of my DHCP clients. Is there a way to prime a “fake” local zone (or cache) and run a caching only nameserver that’s been primed with this “split-horizon” info (i.e. the local names for machines on 192.168.1.0/24, etc)? Or equally, have DHCP prime the local names into the DNS as they get allocated (well, that wouldn’t fully solve my problem as my mail server has a statically allocated IP address, so DHCP wouldn’t know about that). Any ideas? Thanks, -Philip With Bind, you will also need to install rndc "remote named control." Otherwise you need to reload bind when the zonefile is changed. That purges the recursion cache. You will need to declare the local domain and local ptr domain as static-stub zones (data local only to bind). You can add forwarders to those zones for static corporate resources manged by another DNS server. You then need a script call from dhpcd to parse its lease file and write a zonefile for the local domain and local pointer domain each. After those are written, rndc calls to reload the two respective zones without restarting all of Bind. With Unbound, the OpenWrt package already supports odhcpd for this. It would make a reasonable example for dhcpd and bind. Although both dhcpd and bind have complex lease and configuration formats. I haven't used dhcpd on embedded equipment. Maybe someone could add dhcpd to Unbound conversion script. - Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] DNS split horizon *without* dnsmasq
It seems I have static-stub wrong for its purpose. dhcpd and bind do
work together. To accomplish this, the bind instance needs to be master
for the domain zone and ptr zone where DHCP records will be entered.
This master zone needs to permit remote updates, preferably with a
secure key. dhcpd needs to be configure to dynamically update DNS
through binds remote control, again with the key if configured.
dhcpd reference conf to get started, incomplete
```||
|ddns-update-style standard;|||
|ddns-rev-domainname "in-addr.arpa.";|||
||
|zone openwrt.lan. {|
||| # where to send updates for hostid.openwrt.lan|
| primary 127.0.0.1; };|
||
|zone 1.168.192.in-addr.arpa. {|
| primary 127.0.0.1; }|;
||
|```|
||
bind reference conf to get started, incomplete
https://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html#dynamic_update_policies
```||
|zone "|||openwrt.lan|" { |
| type master;|
| file "/var/lib/bind/db.openwrt.lan||"; |
| update-policy {
# you can restrict record types, rather than "any"
|| grant [key-name] zonesub any; |
| }; |
|}; |
||
|zone "1.168.192.in-addr.arpa" {|
| type master;|
| file "|||/var/lib/bind|/db.1.168.192.in-addr.arpa";|
| update-policy {|
| grant [key-name] zonesub any;|
| };|
|};|
```
Both could include a key file like
```||
|key "key-name" { |
| algorithm [hash];
secret "passphrase"; };|
```
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] DNS split horizon *without* dnsmasq
On 03/31/2018 06:03 PM, Philip Prindeville wrote:
On Mar 31, 2018, at 12:57 PM, Eric Luehrsen wrote:
It seems I have static-stub wrong for its purpose. dhcpd and bind do work
together. To accomplish this, the bind instance needs to be master for the
domain zone and ptr zone where DHCP records will be entered. This master zone
needs to permit remote updates, preferably with a secure key. dhcpd needs to be
configure to dynamically update DNS through binds remote
Rather than using a secure key, what about listening on localhost: and
allowing updates only from there? Bind has reasonable ACL capabilities…
Formatting below got a little buggered up.
What are we looking at?
Thanks,
-Philip
Local host ACL would work I think. The encryption key is just part of
the reference manual. And cleaning up the noise
dhcpd incomplete reference conf to get started
```
ddns-update-style standard;
ddns-rev-domainname "in-addr.arpa.";
zone openwrt.lan. {
# where to send updates for hostid.openwrt.lan
primary 127.0.0.1; };
zone 1.168.192.in-addr.arpa. {
primary 127.0.0.1; };
```
bind incomplete reference conf to get started
https://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html#dynamic_update_policies
```
zone "openwrt.lan" {
type master;
file "/var/lib/bind/db.openwrt.lan";
update-policy {
# you can restrict record types, rather than "any"
grant [key-name] zonesub any;
};
};
zone "1.168.192.in-addr.arpa" {
type master;
file "/var/lib/bind/db.1.168.192.in-addr.arpa";
update-policy {
grant [key-name] zonesub any;
};
};
```
optional key file for both
```
key "key-name" {
algorithm [hash];
secret "passphrase"; };
```
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] s/dnsmasq/unbound+odhcpd/
>>>Sound interesting. Can it do multiple instances? (1) The UCI scripts are not configured for instances, but ... (2) It wouldn't be a good idea. Recursive servers keep a lot of infrastructure cache with the zone data. This grows with DNSSEC. Lame paths (broken DSKEY chains) and slow responding NS with mirrors are cached. The memory can be controlled, but at the cost of performance, so you want one big one with all the cache, and ... (3) There is no need. Unbound 1.6.0 has "views:" which means from a zone or IP range, you can restrict what is seen. Two obvious uses: -- CoffeeShop/Guest WiFi. Guests cannot DNS each other or the coffee shop equipment. Firewall prevents access, but why let them enumerate it. view: -> (Guest 172.16.20.0/24) -> drop all queries for domain "joes-coffee.example.com" view: -> (CoffeeShop172.16.10.0/24) -> DHCP-DNS domain "joes-coffee.example.com" and adblock everything so employees don't do whatever -- Home/ChildProof WiFi. view: -> (ChildProof 172.16.20.0/24) -> big list of "kittens.jpeg" zones loaded by adblocker package. view: -> (Home 172.16.10.0/24) -> normal and mom and dad can do what they want. ERIC ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] netifd: "bridge: disable IGMP snooping by default"
Dave, May I quote you for pull requests to achieve "dnsmasq: make DHCPv6 work in standalone dnsmasq installation": https://github.com/lede-project/source/pull/704 https://github.com/lede-project/source/pull/674 >>> "It's just odhcpd that sucks rocks through a straw." Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] s/dnsmasq/unbound+odhcpd/
Its more of having time to gather common wants and establish sane limits on the scope. Stuff like this can get out of control in feature creep. Good structure is necessary for future maintenance and LuCI. Also its a new feature in 1.6.0 and I want to test it manually first and have yay/nay reports from others. - Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] initialisation/startup of dnsmasq for multiple instances is broken
That should all be happening "within" the instance and all options written to the current instance conf file. Each 'config dhcp name' section is unique to itself yet another layer within this. Precisely, what are you expecting and what isnt happening? Could you cut n paste snippets from uci and conf as examples? - Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] initialisation/startup of dnsmasq for multiple instances is broken
That should all be happening "within" the instance and all options written to the current instance conf file. Each 'config dhcp name' section is unique to itself yet another layer within this. Precisely, what are you expecting and what isnt happening? Could you cut n paste snippets from uci and conf as examples? - Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Is there a location for utility scripts?
I would strongly recommend two things: (1) a core "packages/.../helpdesk" kit always built into LEDE for this purpose. Maybe some LuCI to run its best parts. (2) Substantial planning and forethought before lobbing a bunch of script code into another package. - Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] dnsmasq make DHCPv6 viable for standalone dnsmasq install
I will look at it this weekend. It seems that maybe some intermediate rebase-to-trunk event chewed up a line of code. The commit was lingering for quite a while. There is a report for another issue also. Its probably an esay fix, just need to stare at it for a while. - Eric Original message From: Daniel Petre Date: 2/3/17 05:26 (GMT-05:00) To: Eric Luehrsen , Jo-Philipp Wich Subject: Re: dnsmasq: make DHCPv6 viable for standalone dnsmasq install On 02/02/2017 07:52 PM, Eric Luehrsen wrote: > What I submitted I had tested on TL WDR3600 and TL Archer C7 ... working > together. The archer DHCP-PD with odhcpd to the Wdr with dnsmasq full. I only tried the dnsmasq-dhcpv6 and dnsmasq-full with only IPv6 selected. Should i compile in all dnsmasq options? > Also pulled from. JOW staging at some point to see ... but I may not > have tested any last minute fixup work. > > > > - Eric > > > Original message > From: Daniel Petre > Date: 2/2/17 10:55 (GMT-05:00) > To: Eric Luehrsen , Jo-Philipp Wich > Subject: dnsmasq: make DHCPv6 viable for standalone dnsmasq install > > Hi, > are you sure your commit works..? Did you tested it? > >https://github.com/lede-project/source/commit/9525743c076393336cd2129539c974f8a01c7894 > > I have just removed odhcpd and tried both dnsmasq-dhcpv6 and the full > dnsmasq with ipv6 enabled without luck. No IPv6 is getting to my wifi > laptop from a nexx wt3020 router while the setup with odhcpd works just > fine. > > I have a /64 via PD on pppoe. > > Thanks! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] dnsmasq make DHCPv6 viable for standalone dnsmasq install
I just rebuilt LEDE trunk on TL-WDR3600 with dnsmasq-full and odhcpd excluded. I also rebuilt LEDE trunk on TL-Archer-C7 which runs odhcpd+Unbound instead. The Archer is the internet gateway. The WDR is subnet from the Archer. The laptop sending this email is a client of the WDR. We have DHCP-PD to the laptop (until odhcpd flakes out and kills that route). The static ULA-domains and routes work [fd00::] around this and I can connect IP6 to any device in the network upstream or downstream. dnsmasq is handing out RA and DHCPv6 to the laptop. Cabel -> Modem -> Archer (AP) -> WiFi -> (Client) WDR -> Wire -> Laptop If you build LEDE nearly default and later disable odhcpd, then don't forget to stop odhcpd or reboot the router. odhcpd will hold the port (547/548) and dnsmasq will not be able to obtain it. On 02/03/2017 04:46 PM, Eric Luehrsen wrote: > I will look at it this weekend. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] dnsmasq make DHCPv6 viable for standalone dnsmasq install
UCI for stateful+stateless mode. This makes hosts easy targets for ping and other testing (dns-dhcp). This allows Android devices to connect because they won't do DHCPv6 (argh! Google!) config dhcp 'lan' option dhcpv4 'server' option dhcpv6 'server' option interface 'lan' option limit '150' option leasetime '4h' option ra 'server' option ra_management '1' option ra_preference 'medium' option start '100' list dhcp_option 'option:ntp-server,0.0.0.0' list dhcp_option 'option:dns-server,0.0.0.0' list dhcp_option '252,"\n"' # Many clients don't like DNS [fe80::] so this tells dnsmasq # to issue the ULA on this interface (RA and DHCPv6 options) list dhcp_option 'option6:ntp-server,[fd00::]' list dhcp_option 'option6:dns-server,[fd00::]' On 02/03/2017 10:30 PM, Eric Luehrsen wrote: > Cabel -> Modem -> Archer (AP) -> WiFi -> (Client) WDR -> Wire -> Laptop > > On 02/03/2017 04:46 PM, Eric Luehrsen wrote: >> I will look at it this weekend. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] initialisation/startup of dnsmasq for multiple instances is broken
Small mistake that is easily fixed. See pull request: https://github.com/lede-project/source/pull/780 On 02/03/2017 10:21 AM, e9hack wrote: > my dhcp config file looks like this: ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] utils/busybox: prevent weak root passwords
As much a good "debate" over password strength may be healthy, it is not for LEDE. Password enforcement is a policy decission, and not an engineering decission. LEDE should provide tools to help enforce a diversity of policies. LEDE should not create or enforce any policy. - Eric Original message From: David Lang Date: 2/17/17 07:52 (GMT-05:00) To: Alberto Bursi Cc: lede-dev@lists.infradead.org Subject: Re: [LEDE-DEV] [PATCH] utils/busybox: prevent weak root passwords On Fri, 17 Feb 2017, Alberto Bursi wrote: .. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] LEDE re-saving entropy in /etc/urandom.seed only seconds after each boot?
A random seed doesn't need to be stored all that often. Statistical randomness or entropy is a physics concept more so than security (quantum physics, Heisenberg). As long as the random seed is generated with respect to the devices unique perspective within the universe including time reference that perspective is seen, then no other device should have the same seed. This is a greatly over simplified outline. Assuming a good hash algorithm this could be accomplished in a few steps. Permanent Static Seed: hash all the known physically identifying unique and non-unique things you can find on the device (CPUID, MAC, OS Release); save it for convenience even though you could redo. Permanent Dynamic Seed: hash the static seed with first time dynamic events. ... the first DHCP WAN address and time it was received, back corrected by true time using NTP, and NTP time that was first adjusted, and, and, and, ... save that. Session Dynamic Seed: using the permanent dynamic seed to start redo the dynamic time based hash every new session, reboot, or VM launch. Don't save this; redo it fresh. Each step checked for statistical anomalies (suppose all 0xA5) and take some fix-up path. But this should show how to have random data for a unique device that is unique for that devices own timeline. You should not need to overuse the flash. On 02/18/2017 06:03 PM, Etienne Champetier wrote: > Hi Kostas, > > In general you should always add lede-dev so that more people can > answer and/or benefit from the answer > > 2017-02-18 13:38 GMT-08:00 Kostas Papadopoulos : >> >> >> Etienne/John, I'd like to say that I very much appreciate your contributions >> to OpenWrt/LEDE on improving its security, but I have a question about the >> relatively new LEDE feature that saves entropy once into /etc/urandom.seed >> (default) and then re-seeds the pool at every boot. > > This default of saving a seed only once was chosen to not write too > often to the flash and damage the user router without the user > consent, > but it still help to have all same model routers (with same firmware) > to not share the same state (after the second boot) > >> >> My other systems (Debian, Ubuntu) re-save entropy at every shutdown and >> re-seed the pool at every boot. >> >> If I enable (by configuring a path to the file /etc/urandom.seed) entropy >> re-saving in LEDE, it re-saves entropy only a few seconds after every >> reboot. But it's hardly enough time for new entropy to accumulate, isn't it? > > We are using the getrandom syscall which gives this promise > http://man7.org/linux/man-pages/man2/getrandom.2.html > "getrandom() will block until the entropy pool has been initialized" > So my answer is: it's enough according to the kernel devs (and if it's > not enough it's a bug on the kernel side that need to be fixed) > >> >> Is there a new solution in the works that does preserves entropy between >> shutdowns, as the other Linux distros do? > > We save the seed on startup because you can't rely on clean > shutdown/reboot in the embedded world (people often unplug/replug the > power to reboot) > Also saving on startup or shutdown doesn't make any difference as long > as the entropy pool has been initialized (that's getrandom promise) > > So for me, by setting 'urandom_seed' config to a file > (/etc/urandom.seed) you "preserve enough entropy" between restart, and > it's equivalent to what other distro do (save a seed / restore it) > > Small disclaimer, I'm not a security expert and this is only my > understanding on the subject > > Regards > Etienne > >> >> Thank you in advance for your consideration, >> >> KP > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51
On 02/27/2017 03:17 PM, Stijn Segers wrote: > Okay, so I tracked it down to cake being the culprit. When I disable the > Cake SQM instance, no more of those traces, and no more sudden reboots. > > If I can help debug this, let me know - I enabled a Cake SQM instance on > an APU2 and so far that seems to run fine. > > So, in short: .50/51 bump is okay. > > Cheers > > Stijn It wasn't long ago that HFSC was causing issues with 4.4. I am not sure it was all worked out. I withdrew HFSC based scripts from SQM despite being one of a few proponents otherwise. Maybe something else in the TC chain is the root cause. Maybe? Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [Cake] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51
On 03/02/2017 07:02 PM, Jonathan Morton wrote: >> On 3 Mar, 2017, at 01:55, John Yates wrote: >> >> The virtue of a prime number of buckets is that when you mod >> your 32-bit hash value to get a bucket index you harvest _all_ >> of the entropy in the hash, not just the entropy in the bits you >> preserve. > True, but you incur the cost of a division, which is very much non-trivial on > ARM CPUs, which are increasingly common in CPE. > > - Jonathan Morton Also with SQM you may not what idealized entropy in your queue distribution. It is desired by some to have host-connection fairness, and not so much interest in stream-type fairness. So overlap in a few hash "tags" may not be always such a bad thing depending on how it works itself out. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [Cake] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51
On 03/02/2017 11:35 PM, Jonathan Morton wrote: >> On 3 Mar, 2017, at 06:31, Eric Luehrsen wrote: >> >> Also with SQM you may not what idealized entropy in your queue >> distribution. It is desired by some to have host-connection fairness, >> and not so much interest in stream-type fairness. So overlap in a few >> hash "tags" may not be always such a bad thing depending on how it works >> itself out. > That sort of thing is explicitly catered for by the triple-isolate algorithm. > I don’t want to rely on particular hash behaviour to achieve an inferior > result. I’d much rather have a good hash with maximal entropy. > > - Jonathan Morton That's not what I was going for. Agree, it would not be good to depend on an inferior hash. You mentioned divide as a "cost." So I was proposing a thought around a "benefit" estimate. If hash collisions are not as important (or are they), then what is "benefit / cost?" ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH odhcpd] dhcpv6-ia: add option for dhcpv6 privacy address
IP6 SLAAC plus privacy is common. DHCPv6 should be able to provide
the same funciton. This way central IT can maintain integrity and
traceability. However, individual machines will not be easily
placed into a pattern over time by external snooping.
'option dhcpv6_privacy (bool)' is added per interface to switch
from reasonablely consistent 16 bit HOSTID to a random rolling
32 bit HOSTID. See FS#403.
Signed-off-by: Eric Luehrsen
---
README | 2 ++
src/config.c| 7 +++
src/dhcpv6-ia.c | 27 ---
src/odhcpd.h| 1 +
4 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/README b/README
index ebb2d99..c382852 100644
--- a/README
+++ b/README
@@ -86,6 +86,8 @@ dhcpv4stringdisabledDHCPv4 service
ndpstringdisabledNeighbor Discovery Proxy
[disabled|relay|hybrid]
+dhcpv6_privacybool032-bit random HOSTID
+for DHCPv6
dynamicdhcpbool1dynamically create leases
for DHCPv4 and DHCPv6
router list Routers to announce
diff --git a/src/config.c b/src/config.c
index 689d4ce..6c196e0 100644
--- a/src/config.c
+++ b/src/config.c
@@ -40,6 +40,7 @@ enum {
IFACE_ATTR_DOMAIN,
IFACE_ATTR_FILTER_CLASS,
IFACE_ATTR_DHCPV6_RAW,
+IFACE_ATTR_DHCPV6_PRIVACY,
IFACE_ATTR_RA_DEFAULT,
IFACE_ATTR_RA_MANAGEMENT,
IFACE_ATTR_RA_OFFLINK,
@@ -76,6 +77,7 @@ static const struct blobmsg_policy
iface_attrs[IFACE_ATTR_MAX] = {
[IFACE_ATTR_DOMAIN] = { .name = "domain", .type =
BLOBMSG_TYPE_ARRAY },
[IFACE_ATTR_FILTER_CLASS] = { .name = "filter_class", .type =
BLOBMSG_TYPE_STRING },
[IFACE_ATTR_DHCPV6_RAW] = { .name = "dhcpv6_raw", .type =
BLOBMSG_TYPE_STRING },
+[IFACE_ATTR_DHCPV6_PRIVACY] = { .name = "dhcpv6_privacy", .type =
BLOBMSG_TYPE_BOOL },
[IFACE_ATTR_PD_MANAGER] = { .name = "pd_manager", .type =
BLOBMSG_TYPE_STRING },
[IFACE_ATTR_PD_CER] = { .name = "pd_cer", .type =
BLOBMSG_TYPE_STRING },
[IFACE_ATTR_RA_DEFAULT] = { .name = "ra_default", .type =
BLOBMSG_TYPE_INT32 },
@@ -195,6 +197,7 @@ static void set_interface_defaults(struct interface
*iface)
iface->managed = 1;
iface->learn_routes = 1;
iface->dhcpv4_leasetime = 43200;
+iface->dhcpv6_privacy = 0;
iface->ra_maxinterval = 600;
iface->ra_mininterval = iface->ra_maxinterval/3;
iface->ra_lifetime = -1;
@@ -441,6 +444,10 @@ int config_parse_interface(void *data, size_t len,
const char *name, bool overwr
iface->dhcpv4_end.s_addr = htonl(
ntohl(iface->dhcpv4_start.s_addr) + blobmsg_get_u32(c));
+if ((c = tb[IFACE_ATTR_DHCPV6_PRIVACY])) {
+iface->dhcpv6_privacy = blobmsg_get_bool(c);
+}
+
if ((c = tb[IFACE_ATTR_MASTER]))
iface->master = blobmsg_get_bool(c);
diff --git a/src/dhcpv6-ia.c b/src/dhcpv6-ia.c
index fb50448..e9438f6 100644
--- a/src/dhcpv6-ia.c
+++ b/src/dhcpv6-ia.c
@@ -572,16 +572,37 @@ static bool assign_pd(struct interface *iface,
struct dhcpv6_assignment *assign)
static bool assign_na(struct interface *iface, struct
dhcpv6_assignment *assign)
{
-/* Seed RNG with checksum of DUID */
uint32_t seed = 0;
-for (size_t i = 0; i < assign->clid_len; ++i)
+
+for (size_t i = 0; i < assign->clid_len; ++i) {
+/* Seed RNG with simple sum of DUID */
seed += assign->clid_data[i];
+}
+
+
+if (iface->dhcpv6_privacy) {
+/* Little less predictable */
+seed += ((uint32_t)time(NULL));
+}
+
srand(seed);
+
/* Try to assign up to 100x */
for (size_t i = 0; i < 100; ++i) {
uint32_t try;
-do try = ((uint32_t)rand()) % 0x0fff; while (try < 0x100);
+
+if (iface->dhcpv6_privacy) {
+/* DHCPv6+Privacy similar to SLAAC+Privacy */
+do try = (((uint32_t)rand()) * ((uint32_t)rand())) %
0x;
+while (try < 0x1000);
+}
+
+else {
+/* reasonably constant address */
+do try = ((uint32_t)rand()) % 0x;
+while (try < 0x1000);
+}
struct dhcpv6_assignment *c;
list_for_each_entry(c, &iface->ia_assignments, head) {
diff --git a/src/odhcpd.h b/src/odhcpd.h
index 538a7e5..d28184d 100644
--- a/src/odhcpd.h
+++ b/src/odhcpd.h
@@ -152,6 +152,7 @@ struct interface {
bool ra_advrouter;
bool ra_useleasetime;
bool no_dynamic_dhcp;
+bool dhcpv6_privacy;
// RA
int learn_routes;
--
2.7.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] 18.06 Status?
On 05/01/2018 10:47 AM, Hannu Nyman wrote: I think that the main source tree is in pretty good shape, so branching off the 18.0X rather soon might make sense I would also think its time to branch 18.[something-soon], and rather than focus on work that needs yet to be completed, look to cut hardware and packages that are not ready for a release. There is always some heart ache when such decisions are made, but at a point those decisions do need to be made. Without an official release to punctuate both the core team and other packagers hard work, OpenWrt/LEDE could risk losing support from the community and its limited sponsorship. I imagine this project means something personally to the core team, so those risks should be considered. - Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] Add procd triggers only for interfaces that dnsmasq is interested in.
On 05/07/2018 06:37 PM, hux wrote: Signed-off-by: hux --- Right now interface.update events are sent out by netifd upon interface state, route, address (lifetime), prefix lifetime changes. Dnsmasq is only interested in interface state changes and currently adds an interface trigger for all the "interface.*" events. In combination with commit 23bba9cb330, which triggers a SIGHUP signal to dnsmasq, IPv6 address/prefix lifetime changes on the wan will trigger dnsmasq reloads which can become frequent in case of shorter lifetimes. To avoid frequent dnsmasq reload, this patch adds specific interface triggers. During dnsmasq init, it loops dhcp uci section. If the value of the ignore option is set to 0, then the corresponding interface trigger is not installed. Otherwise, if the ignore option value is 1, then procd_add_interface_trigger is called and the trigger is added. It would be nice, if the root cause in netifd and procd as a combination was somehow resolved. Bug tracker that's been idle awhile: https://bugs.openwrt.org/index.php?do=details&task_id=713 - Eric ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
