Re: [LEDE-DEV] [PATCH] Add procd triggers only for interfaces that dnsmasq is interested in.

[Eric Luehrsen]

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_id=713

- Eric

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] 18.06 Status?

[Eric Luehrsen]

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] DNS split horizon *without* dnsmasq

[Eric Luehrsen]

On 03/31/2018 06:03 PM, Philip Prindeville wrote:



On Mar 31, 2018, at 12:57 PM, Eric Luehrsen <ericluehr...@gmail.com> 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] DNS split horizon *without* dnsmasq

[Eric Luehrsen]

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

[Eric Luehrsen]

On 03/25/2018 03:27 AM, Philip Prindeville wrote:

Thinking Bind, probably.




On Mar 23, 2018, at 5:38 PM, Eric Luehrsen <ericluehr...@gmail.com> wrote:

What do you want to serve your dns then? Unbound or Bind?

- Eric

On Fri, Mar 23, 2018, 1:31 PM Philip Prindeville 
<philipp_s...@redfish-solutions.com> 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] odhcpd: possible regression in make DHCPv4 support compiletime configurable

[Eric Luehrsen]

On 11/23/2017 03:54 AM, Hans Dedecker wrote:

Hi,

On Thu, Nov 23, 2017 at 6:38 AM, Eric Luehrsen <ericluehr...@gmail.com> 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_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] Using older kernel in 17.01.4

[Eric Luehrsen]

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

[LEDE-DEV] odhcpd: possible regression in make DHCPv4 support compiletime configurable

[Eric Luehrsen]

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] [PATCH] procd: Remove unnecessary memset calls.

[Eric Luehrsen]

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(_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(,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

Re: [LEDE-DEV] [PATCH] umdns: Replace unnecessary memset calls with {}.

[Eric Luehrsen]

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] [RFC] A new developper documentation for OpenWrt/LEDE

[Eric Luehrsen]

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] RFC [PATCH] odhcpd: don't enable server mode on dhcp lan

[Eric Luehrsen]

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] Stock config files as templates

[Eric Luehrsen]

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] LEDE call for vote on remerge proposal V3

[Eric Luehrsen]

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] dns setup problem

[Eric Luehrsen]

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] [PATCH] dnsmasq: write resolv.conf also when noresolv = 1

[Eric Luehrsen]

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] ddns problem

[Eric Luehrsen]

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

[Eric Luehrsen]

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.

Re: [LEDE-DEV] solar wifi AP designs

[Eric Luehrsen]

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=solar+wifi=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=1496629045=8-2=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=1496628899=8-4=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] openwrt and lede - remerge proposal V3

[Eric Luehrsen]

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] [OpenWrt-Devel] Remerge logo ideas

[Eric Luehrsen]

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

[Eric Luehrsen]

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 and lede - remerge proposal

[Eric Luehrsen]

On 05/15/2017 09:11 PM, Philip Prindeville wrote:
>> On May 11, 2017, at 10:09 PM, Eric Luehrsen <ericluehr...@hotmail.com> 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] convention on uid/gid for packages

[Eric Luehrsen]

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] convention on uid/gid for packages

[Eric Luehrsen]

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] openwrt and lede - remerge proposal

[Eric Luehrsen]

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 <ericluehr...@hotmail.com>
>> Cc: LEDE Development List <lede-dev@lists.infradead.org>
>> 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.
>>
>> 

Re: [LEDE-DEV] openwrt and lede - remerge proposal

[Eric Luehrsen]

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

[Eric Luehrsen]

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] dnsmasq-full should deselect dnsmasq

[Eric Luehrsen]

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] [PATCH 5/7] firewall3: add UBUS support for ipset sections

[Eric Luehrsen]

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] [PATCH netifd] Revert: set prefix indicator flag when IPv6 prefix lifetime, changes

[Eric Luehrsen]

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 netifd] Revert: set prefix indicator flag when IPv6 prefix lifetime, changes

[Eric Luehrsen]

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

[LEDE-DEV] [PATCH netifd] Revert: set prefix indicator flag when IPv6 prefix lifetime, changes

[Eric Luehrsen]

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, _new->assignments, head)
if ((iface = vlist_find(, 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, );
-- 
2.11.0
___
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

[Eric Luehrsen]

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

Re: [LEDE-DEV] [PATCH odpcpd] dhcpv6: allow creating new bindings on REBIND

[Eric Luehrsen]

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

Re: [LEDE-DEV] Planning v17.01.1

[Eric Luehrsen]

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] dnsmasq sometimes fails to start on 17.01.0

[Eric Luehrsen]

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] [PATCH 2/3][RFC] base-files: add option to rc.common to disable default reload behavior

[Eric Luehrsen]

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] Release 17.01.0 binary packages have changed and SDK inconsistency

[Eric Luehrsen]

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 odhcpd] dhcpv6-ia: add option for dhcpv6 privacy address

[Eric Luehrsen]

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] [PATCH odhcpd] dhcpv6-ia: add option for dhcpv6 privacy address

[Eric Luehrsen]

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

[Eric Luehrsen]

On 03/10/2017 09:09 AM, Bjørn Mork wrote:
> Eric Luehrsen <ericluehr...@hotmail.com> 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

[LEDE-DEV] [PATCH odhcpd] dhcpv6-ia: add option for dhcpv6 privacy address

[Eric Luehrsen]

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 <ericluehr...@hotmail.com>
---
  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, >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] [Cake] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51

[Eric Luehrsen]

On 03/02/2017 11:35 PM, Jonathan Morton wrote:
>> On 3 Mar, 2017, at 06:31, Eric Luehrsen <ericluehr...@hotmail.com> 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

Re: [LEDE-DEV] [Cake] Cake SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51

[Eric Luehrsen]

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 SQM killing my DIR-860L - was: [17.01] Kernel: bump to 4.4.51

[Eric Luehrsen]

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] dnsmasq make DHCPv6 viable for standalone dnsmasq install

[Eric Luehrsen]

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

[LEDE-DEV] dnsmasq make DHCPv6 viable for standalone dnsmasq install

[Eric Luehrsen]

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 <daniel.pe...@gavana3.ro>
Date: 2/3/17 05:26 (GMT-05:00)
To: Eric Luehrsen <ericluehr...@hotmail.com>, Jo-Philipp Wich <j...@mein.io>
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 <daniel.pe...@gavana3.ro>
> Date: 2/2/17 10:55 (GMT-05:00)
> To: Eric Luehrsen <ericluehr...@hotmail.com>, Jo-Philipp Wich <j...@mein.io>
> 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] s/dnsmasq/unbound+odhcpd/

[Eric Luehrsen]

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] netifd: "bridge: disable IGMP snooping by default"

[Eric Luehrsen]

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/

[Eric Luehrsen]

>>>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