Re: [LEDE-DEV] [OpenWrt-Devel] Images are too big in LEDE but not in OpenWRT

[David Lang]

two years of development means that lots of packages are larger. you will have 
to see fi there are config options for the packages that you are using that 
reduce their size


I don't know what configuring limits would mean? not produce an image if it's 
too large? start leaving things out when it hits a limit?


David Lang

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

Re: [LEDE-DEV] [PATCH v1] kernel: bump 4.4 to 4.4.112 for 17.01

[David Lang]

given that 4.4.114 added meltdown/spectrefixes, shouldn't we move to it?

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

Re: [LEDE-DEV] Fwd: [FSFE PR][EN] FSFE makes copyrights computer readable

[David Lang]

that's mostly a question to direct at the upstream software sources. only a 
small portion of things are written by the LEDE team


SPDX is mostly useful for people wanting to fork or extract code from opensource 
projects, not for the project writing the code


David Lang

On Thu, 9 Nov 2017, Paul Oranje wrote:


Date: Thu, 9 Nov 2017 11:34:23 +0100
From: Paul Oranje <p...@oranjevos.nl>
To: LEDE Development List <lede-dev@lists.infradead.org>
Subject: [LEDE-DEV] Fwd: [FSFE PR][EN] FSFE makes copyrights computer readable

Would reuse.software (SPDX) be something that could benefit LEDE/OpenWrt ?



Begin doorgestuurd bericht:

Van: pr...@fsfe.org
Onderwerp: [FSFE PR][EN] FSFE makes copyrights computer readable
Datum: 8 november 2017 11:19:56 CET
Aan: press-rele...@lists.fsfe.org
Antwoord aan: pr...@fsfeurope.org, pr...@fsfe.org

= FSFE makes copyrights computer readable =

[ Read online: https://fsfe.org/news/2017/news-20171108-01.en.html ]

The Free Software Foundation Europe (FSFE) is proud to release its next
version of our REUSE practices [1] designed to make computers understand
software copyrights and licenses.

The REUSE practices help software developers make simple additions to
license headers which make it easier for a computer to determine what
license applies to the various parts of a programs source code. By
following the REUSE practices, software developers can ensure their
intent to license software under a particular license is understood and
more readily adhered to.

Together with the updated practices, which mostly clarify and make
explicit some points, the FSFE is also releasing a set of developer
tools and examples which show the REUSE practices in action. Three
example repositories, together with an example walkthrough of the
process used to make the cURL project REUSE compliant, are complemented
with a simple tool to validate whether a program is REUSE compliant.

   With our REUSE initiative, we hope to inspire software developers to
   think about writing copyright and license information -- the
   metadata of software -- in ways which make them easier to parse
   programmatically.

   says Jonas Öberg, Executive Director of the FSFE.

The new REUSE practices and related documentation and examples can be
found on: https://reuse.software [2].

== Tags ==

- front-page [3]

- reuse [4]

- software [5]

- developer-tools [6]

- update [7]

- curl [8]

1: https://reuse.software/
2: https://reuse.software/
3: https://fsfe.org/tags/tagged-frontpage.en.html
4: https://fsfe.org/tags/tagged-reuse.en.html
5: https://fsfe.org/tags/tagged-software.en.html
6: https://fsfe.org/tags/tagged-developertools.en.html
7: https://fsfe.org/tags/tagged-update.en.html
8: https://fsfe.org/tags/tagged-curl.en.html

 == About the Free Software Foundation Europe ==

 Free Software Foundation Europe is a charity that empowers users to
 control technology. Software is deeply involved in all aspects of our
 lives; and it is important that this technology empowers rather than
 restricts us. Free Software gives everybody the rights to use,
 understand, adapt and share software. These rights help support other
 fundamental freedoms like freedom of speech, press and privacy.

 The FSFE helps individuals and organisations to understand how Free
 Software contributes to freedom, transparency, and self-determination.
 It enhances users' rights by abolishing barriers to Free Software
 adoption, encourage people to use and develop Free Software, and
 provide resources to enable everyone to further promote Free Software
 in Europe.

 http://fsfe.org
___
Press-release mailing list
press-rele...@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/press-release



___
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] [PATCH][ubox] Add log priority filtering to daemon

[David Lang]

On Wed, 8 Nov 2017, John Crispin wrote:

you can probably drop the validation. if the users passes 9 as a 
priority everything will be logged. passing -1 will cause silent logging.


you should do limit checks and cap the internal value to the limit, otherwise 
you have to do more work for each log message than a simple mask and unsigned 
compare.


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

Re: [LEDE-DEV] LEDE version numbers?

[David Lang]

17.01 is pointer to a particular commit on the master branch

I haven't looked at the specific method used for the r# generation, but I think 
it's incremented daily


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

Re: [LEDE-DEV] LEDE version numbers?

[David Lang]

These version numbers are used between releases, the part after the - is enough 
of the git commit id (it's hash) for you to identify it. The r#  gives you an 
idea if it's newer or older than another one (since git hashes don't give you 
that info)


nightly builds are not point releases, so they should not be given point release 
IDs, they are automatic snapshots taken each night.


The Linux kernel project releases a new release candidate every two weeks, but 
there are people doing nightly builds directly from git, they don't bother with 
the r## and just use the git hash.


LEDE makes fewer official release candidates and the nightly snapshots are just 
that.


David Lang

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

Re: [LEDE-DEV] [PATCH] dropbear: make syslog support configurable

[David Lang]

On Sat, 4 Nov 2017, Hans Dedecker wrote:


On Sat, Nov 4, 2017 at 10:14 AM, Petr Štetiar  wrote:

Hans Dedecker  [2017-11-03 13:46:14]:

Hi,


By default dropbear logs to syslog which discloses info about account names
when doing connection attempts (e.g. "Bad password attempt for 'engineer'
from x.x.x.x:y")


I don't get it, syslog discloses this information to whom and how?

One case is different accounts being defined configured on a router
like user/engineer/administrator/root each having access to logread.
People using an account should not be able to find out the the other
defined accounts eg by simple using logread


anyone on the system can read /etc/passwd and get a list of valid accounts.

if you are worried about data in the logs, change the permissions so that only 
some people can read the logs, don't eliminate them.





As this facilitates brute force attempts against account names;


So instead of preventing this brute force attempts, you'll just ignore them
now? I'm wondering how is the brute forcing easier with syslog logging.


make syslog support configurable in order not to leak sensitive info via
syslog.


I think, that those are nice warning messages, reminding you, that you're

Visions differ about these being nice warning messages dependant on
whom you're talking to; after the latest dnsmasq CVE and Krack
vulnerabilities people/ISPs have become worried and want to have the
knobs not to leak sensitive info. Classifying info as sensitive is
again another matter of discussion and differs from person to person.


leaking sensitive information to who? Why do you have your logs readable by 
people you don't trust?


if you really want full control of what is logged and where the logs go, enable 
rsyslog of syslog-ng and you won't have to worry about the logread command


disabling all logging is going to cripple any secuity ork.

Yes, logs contain sensitive information, anytime you log a failed login, you are 
guaranteed that someday someone will get out of sync with the login prompt and 
type their password in the userid field for example. But the fix for this is not 
to disable all logging, but rther to log so that only people you trust can see 
the logs.


While LEDE is a linux system, it's designed for very specialized systems, and as 
such, it has not focused on maintaining a safe multi-user environment, it's 
designed as a gateway or a server where only administrators are logging in to 
the define directly. If you are going to have untrusted people getting shell 
access on the device, thereare probably a LOT of things that you need to worry 
about a lot more than 'logread', I'll start with the uci command for example


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

Re: [LEDE-DEV] Kernel version in next major release

[David Lang]

On Sat, 7 Oct 2017, Hauke Mehrtens wrote:


* Port the generic patches


what are the 'generic patches' and is there an effort to get them upstream so 
that they don't need to be ported in each release?



* Make all the out of tree modules work with it


is there any work being done to make these in-tree?


* Port all targets to this kernel version
 * Some targets are not so well maintained any more and there an
additional delay could be introduced.


do we have a list of these devices? do any of these warrent "we need a 
maintainer or they won't be supported" calls?


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

Re: [LEDE-DEV] [PATCH] firewall3: Enable TCP_ECN by default.

[David Lang]

On Tue, 3 Oct 2017, Kevin Darbyshire-Bryant wrote:

It's tempting to set it to 1 (like I have for the past year+) and be damned 
:-)


So what is the failure mode and how will people who experience failures know 
what they need to change?


David Lang

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

Re: [LEDE-DEV] kernel 4.9 migration for next release

[David Lang]

note that the kernel currently under development (4.14) is tagged to be a LTS 
kernel (6 years of support), so it would be good to work on that if possible.


___
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

[David Lang]

the vote on the name was held several months ago, please stop trying to re-do 
the vote just because it didn't come out the way you wanted it to.

k

___
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

[David Lang]

On Sun, 14 May 2017, Giuseppe Lippolis wrote:


*) branding
- the owrt side sees no option of using the lede brand

- a (minor) majority voted for openwrt as a name over lede whilst most
people said they did not care

- as the last vote had a 100% ACK for a remerge using the owrt brand is

the

only feasible option


Passionate: I start to develop with lede, therefore I'm fond to this brand.
More rational: Lede differ from OWRT because it should be more open to
generic embedded architecture. IMHO this is a big advantage compared to OWRT
that shall be kept.


and others are equally passionate in the other direction, while still others are 
less passionate.


But the vote is the vote, and stating how passionate you are on one side or 
another doesn't alter the vote.


David Lang

___
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

[David Lang]

The original post in this thread listed the remaining items to be 
done/decided for a remerge.


David Lang

On Fri, 12 May 2017, Fernando Frediani wrote:


If the majority voted for the name OpenWRT what's the remaining issue then ?

Fernando

On 12 May 2017 23:40, "David Lang" <da...@lang.hm> wrote:


On Fri, 12 May 2017, Val Kulkov wrote:

I should also note that it is extremely important to ask the right

question. You get what you ask for. Apparently, the developers voted
on this question: "Re-brand LEDE to OpenWrt?" (see the link above)
IMHO the question should have been "Should the merged project be
called OpenWrt?"



the vote was not "should lede be re-branded", it was "what should the
merged project be named"

Because the issue is not whether to re-brand LEDE to OpenWrt, the

issue is the whether the merged project should retain the old name
that quite a few people consider to be tainted now.



yes, there are some people who hold very strong opinions on the topic, but
the vote was held and the majority voted for the name openwrt.

I hope that the developers who voted on the question "re-brand LEDE to

OpenWrt" should at least consider voting on "should the merged project
be called OpenWrt" before the final decision on the name of the merged
project is made.



they already voted on exactly that question.

David Lang

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

[David Lang]

On Fri, 12 May 2017, Val Kulkov wrote:


I should also note that it is extremely important to ask the right
question. You get what you ask for. Apparently, the developers voted
on this question: "Re-brand LEDE to OpenWrt?" (see the link above)
IMHO the question should have been "Should the merged project be
called OpenWrt?"


the vote was not "should lede be re-branded", it was "what should the merged 
project be named"



Because the issue is not whether to re-brand LEDE to OpenWrt, the
issue is the whether the merged project should retain the old name
that quite a few people consider to be tainted now.


yes, there are some people who hold very strong opinions on the topic, but the 
vote was held and the majority voted for the name openwrt.



I hope that the developers who voted on the question "re-brand LEDE to
OpenWrt" should at least consider voting on "should the merged project
be called OpenWrt" before the final decision on the name of the merged
project is made.


they already voted on exactly that question.

David Lang

___
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

[David Lang]

On Fri, 12 May 2017, Edwin van Drunen wrote:


I'm pretty sure the ship has sailed on that approach


That would be too bad.
It seems to me that the vote was held amongst a small group of heavily biased 
people, of which a part was responsible for the split between OpenWRT and LEDE 
in the first place.
I am very sure if you would poll the large OpenWRT/LEDE user base the results 
of such a vote would be quite different, but these people never get asked 
anything


the vote included all the LEDE voting developers who made the fork, but also the 
OpenWRT developers.


no, the 'large OpenWRT/LEDE user base' was not part of the vote, both LEDE and 
OpenWRT limit the vote to a fairly small set of people who contribute to the 
code (very common in opensource projects. I don't know of any who allow the user 
base to vote on project infrastructure)


David Lang


I also get the feeling more and more that the split was perfectly justified, 
probably there’s a bit too much ego involved.
What is the use of a project in the Public interest, when the targeted audience 
is not involved in the process?
This is exactly where the LEDE project did better than OpenWRT.

With kind regards,
Edwin van Drunen


On 12 May 2017, at 13:09, David Lang <da...@lang.hm> wrote:

On Fri, 12 May 2017, Daniel Golle wrote:


Hi Edwin,

On Fri, May 12, 2017 at 10:02:36AM +0200, Edwin van Drunen wrote:

As a long time user of OpenWRT and recent “LEDE convert” I would also like to 
chime in on the naming and branding of the post-merge project.
My employer and several of my industrial clients have used OpenWRT/LEDE 
extensively over the past few years in many projects, ranging from routers and 
access points to embedded servers and industrial controllers.
It was the small footprint combined with the versatility of the platform that 
made it work and the availability of generic pre-built images for many 
platforms and documentation that made it a success.
But despite the great track record of the system, there was always a bit of a 
“hobbyist” feel that the OpenWRT name brought with it and a sense of 
unprofessionalism being perceived by management and some end users.
Most likely this is because the name OpenWRT is strongly related to “hacking" 
consumer routers (WRT54GL etc.) and the 90’s style website also didn’t help.
When LEDE was forked and presented as a more multi-purpose embedded linux, came 
with new releases quickly and with a more modern website and interface to code 
and documentation, the switch was easily made.
Not having WRT in the name, implying it would be for wireless routers, but 
instead using the broad term “development environment” was helping to better 
describe what the platform is and give it a more professional sound.
With the new name the platform was now seen as a professional piece of 
infrastructure.


This quite matches the experience I've made when presenting the LEDE
fork...


In my opinion LEDE perfectly describes the combination of OpenWRT’s version of 
the buildroot system, the set of patches and the Luci interface:
The entire development environment that is needed to build a generic bootable 
image and software packages from source for almost any platform, with matching 
pre-built SDK’s and image builders.
OpenWRT better describes the wide range of specific system images built for COTS 
products (which are mostly wireless routers) and is a more suitable name for a final 
“product".
You should consider maintaining the LEDE name or somehow differentiatie between the 
“development environment” and the "final product".


I strongly agree here as well, I believe the "LEDE" project could
release an "OpenWrt" product in reasonable time intervals and that
should be targetting home routers and similar embedded systems.


I'm pretty sure the ship has sailed on that approach, being rejected by the 
current openwrt devs last year.

remember that a vote has been held already on the naming scheme. There was near 
universal agreement that a remerge should happen, and a slight majority that 
the result should be named openwrt. it doesn't do anyone any good to keep 
arguing points that have been agreed on.

David Lang



___
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

[David Lang]

On Fri, 12 May 2017, Daniel Golle wrote:


Hi Edwin,

On Fri, May 12, 2017 at 10:02:36AM +0200, Edwin van Drunen wrote:

As a long time user of OpenWRT and recent “LEDE convert” I would also like to 
chime in on the naming and branding of the post-merge project.

My employer and several of my industrial clients have used OpenWRT/LEDE 
extensively over the past few years in many projects, ranging from routers and 
access points to embedded servers and industrial controllers.
It was the small footprint combined with the versatility of the platform that 
made it work and the availability of generic pre-built images for many 
platforms and documentation that made it a success.
But despite the great track record of the system, there was always a bit of a 
“hobbyist” feel that the OpenWRT name brought with it and a sense of 
unprofessionalism being perceived by management and some end users.
Most likely this is because the name OpenWRT is strongly related to “hacking" 
consumer routers (WRT54GL etc.) and the 90’s style website also didn’t help.

When LEDE was forked and presented as a more multi-purpose embedded linux, came 
with new releases quickly and with a more modern website and interface to code 
and documentation, the switch was easily made.
Not having WRT in the name, implying it would be for wireless routers, but 
instead using the broad term “development environment” was helping to better 
describe what the platform is and give it a more professional sound.
With the new name the platform was now seen as a professional piece of 
infrastructure.


This quite matches the experience I've made when presenting the LEDE
fork...



In my opinion LEDE perfectly describes the combination of OpenWRT’s version of 
the buildroot system, the set of patches and the Luci interface:
The entire development environment that is needed to build a generic bootable 
image and software packages from source for almost any platform, with matching 
pre-built SDK’s and image builders.

OpenWRT better describes the wide range of specific system images built for COTS 
products (which are mostly wireless routers) and is a more suitable name for a final 
“product".
You should consider maintaining the LEDE name or somehow differentiatie between the 
“development environment” and the "final product".


I strongly agree here as well, I believe the "LEDE" project could
release an "OpenWrt" product in reasonable time intervals and that
should be targetting home routers and similar embedded systems.


I'm pretty sure the ship has sailed on that approach, being rejected by the 
current openwrt devs last year.


remember that a vote has been held already on the naming scheme. There was near 
universal agreement that a remerge should happen, and a slight majority that the 
result should be named openwrt. it doesn't do anyone any good to keep arguing 
points that have been agreed on.


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

[David Lang]

On Fri, 12 May 2017, Stijn Segers wrote:


David Lang wrote:

The (soon to be former) LEDE developers don't want @openwrt.org addresses, 
so
providing a way to not break the existing addresses and not giving out new 
ones

doesn't seem like it is upsetting to any of the developers.


Let's not get ahead of ourselves. The thread title states 'proposal', and as 
far as I understand it, it's a 'package deal' that still has to be voted on.


true, but there si a lot in it that is the result of negotiations between the 
developers already. It seems like there are now some outsiders who have not been 
part of the discussions (and who may not be active developers) who are 
expressing concerns and seem unaware of the details of the rules that have been 
proposed.


There is 'some are more equal than others' and there is not breaking existing 
communications channels.


The aftermath of the split showed there's good reason for disabling them 
altogether: people using their @openwrt e-mail addresses to claim legitimacy 
and authority while being barely visible in the day-to-day dealings of the 
project.


You can never eliminate @openwrt.org addresses from all the documentation 
on the

Internet, or from everyone's address books, so it makes sense to have the
existing addresses keep working.


Indeed you cannot, but you could obsolete existing addresses perfectly fine, 
and just have them forward e-mail to one general contact address.


well, I'm an outsider, but one who has been through a similar situation with a 
work e-mail that I used for too much stuff at one point.


The stated problem is people using @openwrt e-mail addresses to claim authority, 
and it seems that there is agreement that people should not be able to send from 
@openwrt e-mail addresses.


So far, so good.

But breaking inbound addresses, especially quickly, causes problems as well. 
Thus the suggestions to either:


turn them into mailing lists that multiple people can subscribe to (for things 
like official contact e-mails, security notifications, domain registrations, 
etc)


or for the personal addresses, change them into inbound-only forwarders so that 
anyone who has he old addresses in address books and uses them for personal 
communications, will still get the messages through, but people will not be able 
to send from the addresses to claim legitimacy/authority.


This personal e-mail address forward could be done as a short term thing, but I 
know from personal experience that after making a change, mail will trickle in 
to the old address for a long time, so I think it's also reasonable to not put a 
time limit on it, setup the forwards and forget it (unless someone starts 
abusing it by continuing to hand out a personal @openwrt address, which will be 
pretty obvious)


David Lang

___
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

[David Lang]

On Fri, 12 May 2017, Eric Luehrsen wrote:


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.


I don't see any reason why they can't wait until they have such a decision to 
make before they set rules for secret decisions.



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?


As I understand things, your proposals undermine the purpose of rule 10. They 
specifically do not want people submitting things to upstream projects under the 
name of the project, they want such submissions to be by the individual without 
involving the project.


There should be no difference between the submission to an upstream project 
between submitting it as da...@lang.hm and david.l...@openwrt.org, so why imply 
that there is a difference by handing out @openwrt.org addresses.


This is one of the things that caused the fork, so such addresses are not to be 
used.


The remerge negotiations aren't doing a hard cut-off for the existing 
@openwrt.org addresses, but are drastically reducing their utility. They will 
either be simple redirects to the person's personal address (with no outgoing 
use of the @openwrt address), or they will be mailing lists that any voting 
member can subscribe to (I've seen both mentioned, I am not sure the exact 
details). But in any case, no new @openwrt addresses will be given out to 
people, and those who have them will not be using them as source addresses for 
performing acts on behalf of openwrt.


David Lang

___
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

[David Lang]

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.

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



___
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

[David Lang]

On Fri, 12 May 2017, Paul Oranje wrote:


Op 11 mei 2017, om 14:18 heeft Imre Kaloz <ka...@openwrt.org> het volgende 
geschreven:

On 2017-05-11 00:33, Paul Oranje wrote:



Op 10 mei 2017, om 11:31 heeft Imre Kaloz <ka...@openwrt.org> het volgende 
geschreven:

On 2017-05-10 00:52, Jo-Philipp Wich wrote:

[cut]


*) SPI

- TBD post remerge

I'd prefer to tackle this first.

Before the merge non-OpenWrt people are outsiders from both SPI's and the 
world's PoV. After the merge everyone can vote on these topics.

This does not feel right. The desire to have the ownership of the domain being 
properly handled before bringing the project - which currently is LEDE - back 
under the openwrt domain name is very reasonable. The fork this have a cause.
If I’ve misunderstood Imre’s position, please tell.

You did :) If you take a look at the original mail from John, that "TBD" is 
there for SPI, the handling of the domain is before that point. This part is about how to 
pick and elect the liaisons, as it has been explained before in John's reply to Rafal.

The SPI has a relationship with OpenWrt, not LEDE. When LEDE devs are OpenWrt devs, they 
"become visible" for SPI. It's matter of steps you have to do in order, nothing 
else.

Thank for the extra info.
So okay, but then agreement on the rules that governs the liason would probably 
still be required before.

Stating that OpenWrt has an exclusive position with SPI - certainly true for 
the name OpenWrt - ignores that the LEDE project itself now has so much to 
offer and momentum that it could very well consider self setting up a relation 
with SPI.


why should people spend time setting up a new relationship with SPI when the 
re-merge is going to let them use the existing one? That sounds like a lot of 
effort for nothing.



- start pushing to the openwrt organisation

By force-overwriting the history of openwrt/openwrt ?

No one said it won't cause a bit of pain, but would ease the transition on the 
long run.

Seems the solution to un-fork may cause more problems than it solves. And all 
that for just the name ?

I don't think rebasing your changes is that much of a pain, and this only 
causes a hiccup for people who are using the OpenWrt git tree for real.
Probably true, but does concern pain of others ... 
Why wouldn’t the re-merged project have its living repository named LEDE ? Is that a problem ? 
(or is it wished for taht all commits on LEDE seem to be in openwrt ?)


The decision was made last year that the resulting codebase would be the LEDE 
codebase, the OpenWRT devs were given commit rights to the LEDE repo so that 
they could migrate over anything they considered significant.


So why would there be a separate LEDE and OpenWRT repo?


What I referred to is that LEDE explicitly decided not to issue e-mail 
addresses in order to avoid that such address would place some people in a 
special position, in order to avoid undue discrimination. Making exceptions 
could amount to some being more equal than others.


There is 'some are more equal than others' and there is not breaking existing 
communications channels.


You can never eliminate @openwrt.org addresses from all the documentation on the 
Internet, or from everyone's address books, so it makes sense to have the 
existing addresses keep working.


It has been decided that such addresses should not be handed out and generally 
used going forward, but it's a reasonable compromise to keep the old addresses 
working (redirecting to personal mailboxes or becoming mailing lists that the 
voting members of the project can subscribe to).


The (soon to be former) LEDE developers don't want @openwrt.org addresses, so 
providing a way to not break the existing addresses and not giving out new ones 
doesn't seem like it is upsetting to any of the developers.


It seems like you are getting upset on the behalf of others, who aren't 
themselves upset. That doesn't seem like a productive thing.



Intentions do matter until you've created the rules, after that the rules 
might not serve the original intentions. Anyways, I only wanted to point out 
that the current LEDE rules aren't perfect either. Don't get me wrong, the 
OpenWrt ones [1] [2] weren't perfect either, specially because the majority 
didn't care about them.


It seems that this is again a case of you being concerned on the behalf of 
others. The discussions that have been taking place have included discussions on 
the rules. If there are OpenWRT devs that are unhappy with the LEDE rules, I 
would be expecting them to be speaking up in these discussions, and not in 
general terms, but with what they specifically are unhappy with.


It almost sounds like you are trolling to stir up trouble where the principals 
in the negotiation have not been disagreeing significantly.


David Lang

P.S. there is no blanket ban of LEDE discussion on the OpenWRT forums, but I 
know that there are various people who have consi

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

[David Lang]

On Thu, 11 May 2017, Alberto Bursi wrote:


On 05/11/2017 12:33 AM, Paul Oranje wrote:



Some of the rules has to change, and as we've discussed it with John, one might 
want to send upstream submissions to make OpenWrt show up there like other 
projects do. You might also want to open a private conversation between the 
upstream platform / driver maintainer where having a project email address 
could be useful. Personally I only use my owrt address for FOSS related stuff 
and as far as I know, most people do the same.

LEDE has a rule which says: "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." This rule is clearly 
problematic if you would like to extend voting rights to non-coders which I believe we 
want to do. Someone maintaining the wiki or the forums might never commit anything, but 
we do want to get their opinion heard. In the past we didn't make it easy for the 
community to interfere with decisions, I doubt we want to make the same mistake again.

Intentions matter. Nonetheless a rule that tries to prevent that 
non-cooperation can be used as a way to obstruct, should not be set aside by 
intentions; this rule may very well be a sleeping rule that, unhoped for, might 
just be needed when lesser intentions become a problem. While on the other hand 
in the interpretation of a rule, its intention is very relevant and helps to 
apply it to cases that may seem not to fit when interpreted in a (to) narrowly 
strict way.




That's easily dealt with by adding conditions for non-programmers to get
(and also lose) "voting rights", while leaving the current condition for
programmers.


I'm confused, how do the current conditions for comitters not work for other 
contributers? They don't in any way involve the person contributing code, it 
just requires that they are reachable one time in a three month window. If you 
can't respond to one e-mail in three months, then you really aren't part of the 
project any longer.


All it takes is changing the word "Committers" to "Contributers".

The existing method of giving programmers commit/voting privileges will work 
just as well for non-programmers (i.e. a vote of the people who currently have 
voting privileges)


David Lang

___
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

[David Lang]

On Tue, 9 May 2017, A. Benz via Lede-dev wrote:

Likewise, OpenWRT while more recognizable than LEDE, is not worth as much as 
people here paint it, and will only remain relevant as long as people keep 
using it. Market/brand concept (in retail) doesn't really apply.


I'll point out that just last week we had an official contact from the Open 
Compute project to OpenWRT looking to integrate OpenWRT for dealing with wifi 
devices in Open Compute.


Open Compute is a pretty significant project that's expected to keep up with 
technology. If they do not know of LEDE and think of OpenWRT for the purpose, it 
shows that LEDE has not make the progress that you think it has in name 
recognition.


But in any case, the decision has been made, it doesn't really help to keep 
arguing the name issue. There's enough other work to be done.


I'm glad to see this progress and look forward to the remerge happening.

David Lang

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

Re: [LEDE-DEV] [AD] support me hacking on OpenWrt/LEDE

[David Lang]

May I suggest that you talk directly rather than through the mailing list?

David Lang

On Mon, 3 Apr 2017, lede-proj...@bepo.de wrote:


Date: Mon, 3 Apr 2017 13:51:21 +0200
From: "lede-proj...@bepo.de" <lede-proj...@bepo.de>
To: lede-dev@lists.infradead.org
Subject: Re: [LEDE-DEV] [AD] support me hacking on OpenWrt/LEDE

Hi Daniel,
as I already says: I think it was good way to payback the active
community. So we talking about the possibility for you to continue your
work on lede-project.org, but as an employer in our company.
I have a the moment not enough time to a detailed answer your mail, but
I can understand your concern.
Our company is a "eierlegendewollmichsau". :-)
We support Windows, Mac and do a lot of Linux-Stuff in background. We
try to push proprietary solutions out and replace it with FLOSS (GPL) or
minimal a opensource (BSD/MIT/...) solution. Our customer are small
companies (KMU), these are flexible enough to try our way.
We create stuff (but not only) like VPN, multi WAN, WLAN with multiple
AP, directional radio links and similar with OpenWRT/LEDE. It was always
a pain, but often the only way for our customer to get high-level
functionality without CISCO and similar. If you can help us to provide
better service, that would be great, but if you work only on important
low-level stuff for LEDE (which I see here in this mailinglist) that is
also ok for us.

I shall write more today night, hope to decrease your concern.

Cheers
Benni

Am 03.04.2017 um 12:05 schrieb Daniel Golle:

Hi Benni,

On Mon, Apr 03, 2017 at 11:30:45AM +0200, lede-proj...@bepo.de wrote:

Hello Daniel,

I have explore the patreon site becauce I do not know it before. Short:
I do not like this service at all (5% fee, only paypal/creditcard, ...)

If you in Germany/Leipzig and a german citizen, so I can offer you an
Midi-Job (witch include a health insurance).


That'd be amazing, obviously :)



We use lot of openwrt (and freifunk) a couple of years (and try use LEDE
now), so it was a good style for us to payback the active community. And
IMHO better then collecting cash via patreon's "Klingelbeutel".


For sure. I also try to avoid receiving payments through patreon,
but only a small fraction of the people who are supporting me right now
are from within the EU and hence have access to free SEPA transfers.
And if people provide $$$ outside of patreon I need to do all the paper
work (and when counting the hours for that 5% seems to be not too bad of
a deal...)
Some others offered sending bitcoin and such, which I for now refuse
because I don't even know how the boureaucracy (tax-wise) works in that
case, because they obviously want to remain anonymous and hence I can't
know their name and address and all that...



Our office is in Hamburg, but we want open a small office in Leipzig
this year (asap).

Is this a option for you, or is this a stupid idea?


Depends on what you want me to do. The difference here is that patreon
allows me to do what I believe is important or fun to do and people
can reward me for that or just support me even for reasons beyond my
own understanding. A job, opposed to that, usually comes with quite
different expectations of the people who provide the cash. I usually
don't survive in those settings, because I'm not a very obediant
person (apparently so) and I simply cannot force myself to do things
which I don't believe in myself. If I try anyway, I very quickly get
very depressed, sick and angry, because I truely hate the outcomes of
most commercially motivated technological progress (such as selling
more useless stuff, knowing more about customers, brainwashing people
into mindless and ultra-dependent isolated consumers, ...)
Excuses like 'but we need to make a business somehow' don't count and
don't really increase my motivation...
Hence I shifted my commercial activity to work in kitchens most of
the time, because making good food doesn't contradict with my own will
and my expectations towards food seem to correlate with the taste and
expectations of the people entering the restaurant... Business-wise
that didn't work well, the restaurant had to close last year due to
increasing rent and labour costs (they payed minimum wage)...

Anyway, all that may all sound too harsh and I don't even know what
your company is doing. Maybe it's totally what I believe would be great
to do and have on this planet, create a future which I'd want to live
in and so on... So please tell me more :)


Cheers


Daniel




Cheers

Benni

Am 22.03.2017 um 11:22 schrieb Daniel Golle:

Hi everyone,

most of you might know me for hacking on embedded stuff while having
the common good in mind. Because I'm practically always out of money,
I decided to setup a patreon account which can help me to gather at
least the $$$ needed to pay for obligatory health insurance and such
things. It'd be great if you spread the word and also give me feedback
(off-list!) so I can improve my patreon pag

Re: [LEDE-DEV] [PATCH fstools] cmake: Make blockd link against libjson-c

[David Lang]

Just a note in case you were not aware, json-c is not thread-safe (the rsyslog 
project forked it to libfastjson to fix the thread safety and drastically 
improve speed)


On Mon, 27 Mar 2017, Florian Fainelli wrote:


Date: Mon, 27 Mar 2017 17:10:57 -0700
From: Florian Fainelli 
To: lede-dev@lists.infradead.org
Cc: Florian Fainelli , j...@phrozen.org
Subject: [LEDE-DEV] [PATCH fstools] cmake: Make blockd link against libjson-c

Similar to commit 35aa20c51995 ("cmake: Link against libjson-c"), blockd
uses libblob_msg which needs libjson-c.

Fixes: 98bbb5a068d6 ("blockd: add automounting support")
Signed-off-by: Florian Fainelli 
---
CMakeLists.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 08d277f92513..a828244db109 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -54,12 +54,12 @@ ADD_EXECUTABLE(mount_root mount_root.c)
TARGET_LINK_LIBRARIES(mount_root fstools)
INSTALL(TARGETS mount_root RUNTIME DESTINATION sbin)

+find_library(json NAMES json-c json)
+
ADD_EXECUTABLE(blockd blockd.c)
-TARGET_LINK_LIBRARIES(blockd fstools ubus blobmsg_json)
+TARGET_LINK_LIBRARIES(blockd fstools ubus blobmsg_json ${json})
INSTALL(TARGETS blockd RUNTIME DESTINATION sbin)

-find_library(json NAMES json-c json)
-
ADD_EXECUTABLE(block block.c probe.c probe-libblkid.c)
IF(DEFINED CMAKE_UBIFS_EXTROOT)
ADD_DEFINITIONS(-DUBIFS_EXTROOT)



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

Re: [LEDE-DEV] Github's new TOS

[David Lang]

On Thu, 2 Mar 2017, Daniel Golle wrote:


Sounds very reasonable to me. From what I understood that was all
about partial quotes which show up as part of search-results and the
github website without the attribution required or full-text license
next to it. In a way that sounded like an excuse, because they could
just embed the required text-blocks into the site and display them
on-mouse-over of the SPDX tag, which would technically speaking make
that change in their usage terms unnessecary, thus I got suspicous.


haivng to send a large chunk of license data for each snippet in a search result 
would greatly multiply the size of the downloaded page, not nice to users.


This change seems reasonable to me.

David Lang

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

Re: [LEDE-DEV] automated signed firmware upgrades / hide a secret in image

[David Lang]

The kernel already includes facilities for signing modules, if you are looking 
for a way to sign and verify things, it seems like it would make sense to adapt 
that to sign the entire image.


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

Re: [LEDE-DEV] [PATCH] utils/busybox: prevent weak root passwords

[David Lang]

On Fri, 17 Feb 2017, Alberto Bursi wrote:


On 02/17/2017 12:52 PM, David Lang wrote:

On Fri, 17 Feb 2017, Alberto Bursi wrote:

And having no password is a much bigger change than having a short
password when you are testing things. It makes a lot of sense to be
excercising the password routine when doing tests, and very little
difference if you are excercising it with a short password or a long one.



What? if I'm testing things that are completely unrelated to login
(system configurations for tutorials or stuff for device support) then
how I log in is irrelevant.


if you are testing specific features, than any other features are irrelevant, 
but if you are doing more general testing, then one of the things that needs to 
be in the tests is the authentication.


and if you are setting up test scripts, it's best to make them scripts that 
users can test with as well, and they are almost always going to have 
authentication enabled.



Why are you saying that short passwords are bad? Is it just because you
have been told that they are?

Remember, a short password is only a problem if attackers have the
ability to make brute force attacks on the system. If attackers can't
get at the interface, or if there are other strategies in place to
defeat brute force attacks, a short password can be acceptable.



True. Are there such systems in place for ssh access?


They are available.

To start with, SSH access is not enabled on the WAN side.

If password brute forcing from the inside is considered a threat, then turning 
on rate limiting/temporary lockouts/alerts/etc is a far better thing to do than 
to try to force 'better' passwords.


people who don't want good passwords are going to find a way to not have good 
passwords.


password1! is not a much better password to use than password, even though the 
password strength tests will claim that it is. If you force people to have 
'longer' or 'more complex' passwords, they are far more likely to add some easy 
to guess nonsense on the end of their previous 'bad' password than to come up 
with a 'good' password.


David Lang

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

Re: [LEDE-DEV] [PATCH] utils/busybox: prevent weak root passwords

[David Lang]

On Fri, 17 Feb 2017, Alberto Bursi wrote:


On 02/17/2017 12:26 PM, John Crispin wrote:



On 17/02/2017 12:16, Dan Lüdtke wrote:

Hi David,

thanks for the fast response!


On 17 Feb 2017, at 11:54, David Lang <da...@lang.hm> wrote:
But deciding that you know better than the admin of the system is not.


Not that I am a fan of telling admins what to do, but do you see any chance 
that we  can get an consistent and enforceable approach to *minimum* 
requirements, e.g. minimum password length? Maybe by using a configuration 
variable? Havon only the GUI enforce minimum password length and not the CLI is 
rather inconsistent (some may say useless or even confusing).



you don't have any idea what the security environment is for the system, or why 
the admin is selecting that password.

It's not just a busybox thing to allow the root user to select a password that 
is shorter than 'recommended', that's normal behavior on *nix systems and has 
been for decades, even as the 'recommendations' have changed.


I rather see this as a "LEDE" system not a standard *nix system, even though it is based 
on Linux and runs a Linux kernel. The question is, is this a more a "product" or just 
another Linux system?

"has been for decades" is not a good argument. The others are. But that one is 
just not.


Cheers,

Dan


i agree with david lang, i regularly use "a" as a passwd on test units.

John



I don't use a password in test units at all and there is no issue (shows
the warning on login but not much else), so I think the "I need short
passords for testing" is a weak argument here.


That's just an example of an environment where the security policy makes short 
passwords accpetable.


And having no password is a much bigger change than having a short password when 
you are testing things. It makes a lot of sense to be excercising the password 
routine when doing tests, and very little difference if you are excercising it 
with a short password or a long one.


Why are you saying that short passwords are bad? Is it just because you have 
been told that they are?


Remember, a short password is only a problem if attackers have the ability to 
make brute force attacks on the system. If attackers can't get at the interface, 
or if there are other strategies in place to defeat brute force attacks, a short 
password can be acceptable.


And if the resource you are giving access to is not very important, but you 
can't easily do a blank password, or want to stop/slow unknown automated access, 
but want to have it accessable to any human, a simple password can be a great 
choice.


David Lang
(17 years in providing network security for Banks)___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] utils/busybox: prevent weak root passwords

[David Lang]

On Fri, 17 Feb 2017, danrl wrote:


Date: Fri, 17 Feb 2017 11:42:14 +0100
From: danrl <m...@danrl.com>
To: lede-dev@lists.infradead.org
Cc: Dan Luedtke <m...@danrl.com>
Subject: [LEDE-DEV] [PATCH] utils/busybox: prevent weak root passwords

Hi devs,

We are trying to make passwords on LEDE a tiny bit more secure by refusing weak 
or short (read: less than 6 characters) passwords.

Please see related discussion over here, where the inconsistencies were 
discovered:
https://github.com/openwrt/luci/pull/878

Here is what the patch changes in user experience:

Router running an image NOT including the proposed patch:

 root@rtr:~# passwd
 Changing password for root
 New password:
 Bad password: too short
 Retype password:
 passwd: password for root changed by root

The password minimum length is not enforced for the root user, also weak 
passwords are accepted for the root user despite showing a warning.


Router running an image including the proposed patch:

 root@lede-dev:~# passwd
 Changing password for root
 New password:
 Bad password: too short
 passwd: password for root is unchanged

It refuses to accept a password that is too short or considered weak.


Please don't do this.

providing a warning in fine, even asking for a confirmation is acceptable.

But deciding that you know better than the admin of the system is not.

you don't have any idea what the security environment is for the system, or why 
the admin is selecting that password.


It's not just a busybox thing to allow the root user to select a password that 
is shorter than 'recommended', that's normal behavior on *nix systems and has 
been for decades, even as the 'recommendations' have changed.


David Lang

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

Re: [LEDE-DEV] Makefile question

[David Lang]

On Sun, 12 Feb 2017, Philip Prindeville wrote:


If you look for where the /files/* are copied into the filesystem, that is 
probably the place you would want to add your scripting hooks.


Good idea.  I’ll look there.


Once you find this, may I suggest that you create /scripts/* and contribute the 
infrastructure to support it back upstream?

I have seen a lot of people wanting to do similar things.



Surprisingly, I’m still trying to find in the Makefiles where $(topdir)/files/ 
gets copied over…

-Philip


It's prepare_rootfs doing this job at the moment.

   yousong


Sorry to be thick headed, but what’s the path to that?


grep -r "/files/" finds

scripts/env:cp -a "$ENVDIR/files/"* "$BASEDIR/files" 2>/dev/null 
>/dev/null
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Makefile question

[David Lang]

On Sat, 11 Feb 2017, Philip Prindeville wrote:


This can't eliminate the /etc/rc.d/S* files as it only adds files, and it's not 
as flexibile as adding a user or changing a password (as it would just let you 
replace the /etc/passwd, /etc/shadow files, not modify them).

If you look for where the /files/* are copied into the filesystem, that is 
probably the place you would want to add your scripting hooks.


Good idea.  I’ll look there.


Once you find this, may I suggest that you create /scripts/* and contribute the 
infrastructure to support it back upstream?


I have seen a lot of people wanting to do similar things.

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

Re: [LEDE-DEV] Makefile question

[David Lang]

On Fri, 10 Feb 2017, Philip Prindeville wrote:


Hi.

I was wondering if there’s an obvious place to install a hook that’s:

(a) after all the packages have been installed;
(b) before the root filesystem image gets finalized;

I’d like to be able to run some simple sed scripts inside the root-to-be 
directory to make some changes, maybe do an rm etc/rc.d/S??sshd so that the 
sshd service is installed but isn’t enabled by default, maybe inject a new 
root password or create an extra user login, etc.


That sort of thing.

I looked around through the makefiles but nothing stood out.

Should be easy, right?


some of what you are talking about can be done by putting the replacement files 
in the /files heirarchy and they will replace the files created by the packages.


This can't eliminate the /etc/rc.d/S* files as it only adds files, and it's not 
as flexibile as adding a user or changing a password (as it would just let you 
replace the /etc/passwd, /etc/shadow files, not modify them).


If you look for where the /files/* are copied into the filesystem, that is 
probably the place you would want to add your scripting hooks.


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

Re: [LEDE-DEV] NETSHe mac80211 GPL sources

[David Lang]

On Fri, 3 Feb 2017, Daniel Golle wrote:


Hi Alberto,

On Fri, Feb 03, 2017 at 10:59:38AM +, Alberto Bursi wrote:



On 02/03/2017 07:35 AM, Stanislav V. Korsakov wrote:

Hi Daniel,

We provide our GPLed and dual licensed source codes to our customer only.
Not our source code is available at http://gw.stasoft.net/dl/



What you wrote here sounds like a license violation.
Source code of GPLed software you use *must* be provided to everyone
that asks it, not just to customers.
That's what the GPL license requires.


Strictly speaking, it must be provided to anyone who also got access
to the binary. So, if you offer a free download of the binary, you must
provide the sources under the same terms. Ie. by downloading the
binaries from the website, that makes me a customer entitled to ask for
the sources.
However, if you provide the binaries only to customers or keep them
"in-house" (that's what most telcos do), only the parties which were
handed the binaries can ask for the sources, that's at least how I
understood the GPLv2.


If you never distribute the binaries, then you don't have to provide source to 
anyone (but if you sell devices with the binaries, you are distributing them)


If you "enclose a written offer for the source" when you ship the binaries, that 
offer is good to anyone, not just those who receive the binaries (and must be in 
place for at least three years). Most companies do this and put tarballs of the 
source on a server and forget about it.


If you ship the source with the binaries on the same media, then you are not 
required to setup any additional methods/processes for people to ask for the 
source. Your obligations under the GPL are satisfied by shipping the source with 
the binaries, so this is the easiest thing to do in the long run.


There have been a number of companies who have tried to set things up so that 
they only give the source to their customers, and only when they ask, with 
restrictions preventing the customers from giving the source to anyone else. 
These have always been a violation of the GPL and while none have gone to court 
in the US, that's because the violators have always settled before getting into 
court (with vmware being the only exception, and I haven't heard that that case 
has gone to trial yet)


David Lang

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

Re: [LEDE-DEV] NETSHe mac80211 GPL sources

[David Lang]

On Fri, 3 Feb 2017, Alberto Bursi wrote:


On 02/03/2017 07:35 AM, Stanislav V. Korsakov wrote:

Hi Daniel,

We provide our GPLed and dual licensed source codes to our customer only.
Not our source code is available at http://gw.stasoft.net/dl/



What you wrote here sounds like a license violation.
Source code of GPLed software you use *must* be provided to everyone
that asks it, not just to customers.
That's what the GPL license requires.


If it's shipped with the binary (as opposed to a separte download), they don't 
have to offer it to anyone else. But any of the customers are free to pass the 
source along, as it is GPL.


But if it's a separate download, it does have to be made available to anyone.

David Lang

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

[LEDE-DEV] forum limitations

[David Lang]

currently new users (for some definition of 'new', I have 63 posts starting 
within a day or two of when the forum was created) are limited to 3 replies in a 
topic.


This limit is really easy to hit in a technical discussion and is going to drive 
people to create extra topics to work around the limitation.



example error message via e-mail:

We're sorry, but your email message to 
["forum+reply-83162f79a9a8b8efaf1a2e8dae533...@lede-project.org"] (titled Re: 
[LEDE Project
Forum] [Installing and Using LEDE] Wlan 2.4/5Ghz to slow fpr 1080p/60fps?) 
didn't work.


Reason:

We're sorry, but new users are temporarily limited to 3 replies in the same 
topic.


If you can correct the problem, please try again.



David Lang

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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[David Lang]

On Mon, 26 Dec 2016, Kathy Giori wrote:


On Wed, Dec 21, 2016 at 11:31 PM, John Crispin <j...@phrozen.org> wrote:



[..]

i am still very much in favour of having 2 trees, one stable and one dev
tree. this would allow everyone to choose what they think fits their
needs best.


I too have liked this idea since I first heard it.



This sounds good at first listen, but doesn't actually work.

tl;dr this is a "I think you should do a lot of boring work" plan. nobody is 
volunteering to do the work


people don't want a 'stable branch' with only known good stuff in it, they want 
a 'stable' branch with all the latest features added, but none of the bugs that 
go with those features.


If you could identify the bugs, they wouldn't be buggy in the bleeding edge 
version.


It also takes a lot of manpower to maintain the stable branch, and those 
people are not able to work on anything new and interesting (because such 
development is, by definition, not yet stable)


It also generates a LOT of support questions, esepecially of the "why doesn't X 
work in the stable branch yet"


The OpenWRT folks have said that they are not willing to become the 'stable' 
developers, if they merge the trees/projects, they want to be able to work on 
whatever they want without being tied down with some sort of 'stable' criteria


If you think it's a great idea, organize a team to make stable versions of what 
OpenWRT/LEDE release. If you are able to sustain the results for a few versions, 
people may start to trust and use it (or they may just use the more up-to-date 
tree)


David Lang (who has no authority within LEDE or OpenWRT)

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

Re: [LEDE-DEV] Release planning

[David Lang]

On Thu, 22 Dec 2016, Rich Brown wrote:


Is it too soon to begin identifying/enumerating the features/packages that will 
go into the 17.01 release? Thanks.


nope, you can start going through the git log history to pick out things that 
you think should be highlighted now. Even if the release doesn't happen for a 
while, the list will still be useful as it reduces how far back people would 
have to go at the point of release.


David Lang

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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[David Lang]

On Thu, 22 Dec 2016, John Crispin wrote:


On 22/12/2016 09:42, David Lang wrote:

On Thu, 22 Dec 2016, John Crispin wrote:


Yes, the name is pointing at a product that doesn't exist any longer,
but Deb and Ian aren't involved with Debian any longer either. At some
point the fact that a name is known matters far more than the historical
reasons for the name.


a problem that can be solved by a http redirect ...


Is that going to break all links in discussions that point at OpenWRT
docs and/or forum threads?

That's a high cost.

David Lang


it is something worth considering if the alternative content is
available and easy to look up and if we keep archives in ro mode of
existing content.

claiming that there is only one option and no alternatives is just not
constructive and wont lead to a broad discussion during which we can
find a consensus.


sorry, I did not mean to imply there is only one option.

I think there is a lot of value in the OpenWRT name and all the links around the 
web that refer to it. So there is a huge cost to going with a different name.


IMHO, this makes it an easy decision to make, but not the only one possible.

David Lang

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

Re: [LEDE-DEV] Release planning

[David Lang]

On Thu, 22 Dec 2016, James Feeney wrote:


On 12/22/2016 01:33 AM, David Lang wrote:

the reason for this is sort order, if something is sorting versions with an
alpha sort, you want the ~rc to show up as older than the YY.MM release, and you
want that to show up as older than the YY.MM.N releases.


A "cleaner looking" format could be "YY.MM.~m" for the release candidates?


cleaner looking but more confusing. people are used to 'rc' 'beta', etc. .~3 
just doesn't have the human readable factor.


David Lang

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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[David Lang]

On Thu, 22 Dec 2016, John Crispin wrote:


Yes, the name is pointing at a product that doesn't exist any longer,
but Deb and Ian aren't involved with Debian any longer either. At some
point the fact that a name is known matters far more than the historical
reasons for the name.


a problem that can be solved by a http redirect ...


Is that going to break all links in discussions that point at OpenWRT docs 
and/or forum threads?


That's a high cost.

David Lang

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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[David Lang]

On Wed, 21 Dec 2016, Dave Taht wrote:


On Wed, Dec 21, 2016 at 12:29 PM, David Lang <da...@lang.hm> wrote:

On Wed, 21 Dec 2016, Kathy Giori wrote:


From a PR perspective, I strongly suggest keeping the term OpenWrt as
part of the branding of the project moving forward. It can just be
cosmetic (web site, etc.) but the name has so much history, and
positive connotation, that you don't want to lose that brand attached
to the development moving forward.



I agree, I think this is an obvious choice to make. OpenWRT has a lot of
name recognition, it would be foolish to throw that away.


Just to take the other side for rhetorical purposes, a purpose of a
re-branding exercise is to show a change in the "product" or
organisation behind it. OpenWrt is widely known... as a bleeding edge,
sometimes unstable, somewhat hard to use 3rd party firmware. DD-Wrt
and Tomato get a lot more press for some reason. So do things like
Yocto. If lede were to succeed in meeting its other goals, coherently,
preserving "lede" and moving forward as a separate project does make
sense.


I'll point out OpenOffice vs LibreOffice and the fact that years after 
development of OO has really stopped, people are still finding it and 
downloading it instead of LO (it's replacement)


there's a lot of stuff out there pointing at OpenWRT, unless you are going to 
replace all the OpenWRT stuff with pointers to LEDE, you are better off taking 
advantage of the millions of references to OpenWRT.


David Lang

Yes, the name is pointing at a product that doesn't exist any longer, but Deb 
and Ian aren't involved with Debian any longer either. At some point the fact 
that a name is known matters far more than the historical reasons for the name.


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

Re: [LEDE-DEV] Release planning

[David Lang]

On Thu, 22 Dec 2016, James Feeney wrote:

On 12/21/2016 12:13 PM, Jo-Philipp Wich wrote:



Tags will follow the format "vYY.MM.N[-RC#]" with YY.MM being the base
release version, N being the number of the minor release and an optional
-RC# designating release candidate numbers.


With respect to the version name, do you really want to use a "dash" instead of
a "period", for the release candidate numbers?  I would think that adding the
character string "RC" already provides enough information to distinguish a
release candidate - where the ".n" suffix would be changed to ".RCm" - and that
changing ".n" to "-RCm" just makes this suffix more difficult to parse.  Would
it not be more practical to consistently use a "period" as the suffix delimiter?


I missed this, you don't want to use a dash or a period, you want to use a tilde 
'~'


the reason for this is sort order, if something is sorting versions with an 
alpha sort, you want the ~rc to show up as older than the YY.MM release, and you 
want that to show up as older than the YY.MM.N releases.


David Lang

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

Re: [LEDE-DEV] [OpenWrt-Devel] Talks between OpenWrt and LEDE

[David Lang]

On Wed, 21 Dec 2016, Kathy Giori wrote:


From a PR perspective, I strongly suggest keeping the term OpenWrt as
part of the branding of the project moving forward. It can just be
cosmetic (web site, etc.) but the name has so much history, and
positive connotation, that you don't want to lose that brand attached
to the development moving forward.


I agree, I think this is an obvious choice to make. OpenWRT has a lot of name 
recognition, it would be foolish to throw that away.


David Lang

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

Re: [LEDE-DEV] Release planning

[David Lang]

On Wed, 21 Dec 2016, Jo-Philipp Wich wrote:


   - set grace period of 5 days to identify and fix blockers



 day 16 - extend grace period by 5 days until blockers are resolved


As a practical matter, make these 7 days rather than 5 days. the shift between 
the work-week and the release schedule will cause problems both for devs and 
testers.



- When do we want to branch?

 Personally I'd like to branch before Christmas so that we can use the
 free time for building images (it takes about 8 days and ~2TB of space
 to build all targets and all packages).


how big is the build farm? how much hardware would people need to donate to 
reduce this significantly (1-2 days for example)?


David Lang

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

Re: [LEDE-DEV] [PATCH] include: image.mk: ext4: double the default inode counter

[David Lang]

On Tue, 22 Nov 2016, Felix Fietkau wrote:


On 2016-11-22 17:48, David Lang wrote:

On Tue, 22 Nov 2016, Felix Fietkau wrote:


On 2016-11-22 17:43, David Lang wrote:

On Tue, 22 Nov 2016, Felix Fietkau wrote:


On a 16M filesystem, we probably want to use a 1K block size and have an inode
for every couple of blocks.

I'd say on a 16M filesystem we probably want to use squashfs+ext4
instead of plain ext4 and avoid the inode issue altogether.


I'm not sure I understand how this would work?

Pad a plain squashfs image to the intended target size, include mke2fs
and mkf2fs (for bigger sizes) in the image.
fstools will take care of the rest at boot time.


you still have to set the parameters for mkfs to use.

It will be created as an empty overlay filesystem, so there's lots of
free inodes available.


but by default, it wouldn't have lots of free inodes, the default is one inode 
per 16K of filesystem, which is how we get to 1024 inodes on a 16M filesystem.


We need to be able to say that this is a tiny filesystem, and should really use 
a smaller blocksize and more inodes.


David Lang

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

Re: [LEDE-DEV] [PATCH] include: image.mk: ext4: double the default inode counter

[David Lang]

On Tue, 22 Nov 2016, Felix Fietkau wrote:


On 2016-11-22 17:43, David Lang wrote:

On Tue, 22 Nov 2016, Felix Fietkau wrote:


On a 16M filesystem, we probably want to use a 1K block size and have an inode
for every couple of blocks.

I'd say on a 16M filesystem we probably want to use squashfs+ext4
instead of plain ext4 and avoid the inode issue altogether.


I'm not sure I understand how this would work?

Pad a plain squashfs image to the intended target size, include mke2fs
and mkf2fs (for bigger sizes) in the image.
fstools will take care of the rest at boot time.


you still have to set the parameters for mkfs to use.

David Lang

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

Re: [LEDE-DEV] [PATCH] include: image.mk: ext4: double the default inode counter

[David Lang]

On Tue, 22 Nov 2016, Felix Fietkau wrote:


On a 16M filesystem, we probably want to use a 1K block size and have an inode
for every couple of blocks.

I'd say on a 16M filesystem we probably want to use squashfs+ext4
instead of plain ext4 and avoid the inode issue altogether.


I'm not sure I understand how this would work?

David Lang

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

Re: [LEDE-DEV] [PATCH] include: image.mk: ext4: double the default inode counter

[David Lang]

On Tue, 22 Nov 2016, Jo-Philipp Wich wrote:


1)
detect via makefile if PARTITION is small and autoadjust BLOCKSIZE
(if not given)


iirc the blocksize setting is a choice menu, so it is always defined.


2)
set BLOCKSIZE default to 1K via x86/UML-Makefile


It was explicitly raised to 4k for x86 to reduce wear on MMC storage
which is common on non-virtual x86 targets (Alix/APU boards etc.)


3)
the first approach by changing 'make_ext4fs.c'


That would be preferred. Our make_ext4fs variant is forked anyway
already so there is no upstream we need to adhere to.


changing the blocksize doesn't really address the problem of too few inodes, 
except indirectly in that the default number of inodes is calculated from the 
number of blocks on the filesystem.


In the case of LEDE, we tend to have fewer large files on the ext4 partition 
than most distros, for a couple of reasons. First we are always concerned with 
space, so we tend to have smaller files to start with, and then we tend to have 
most of the larger files in a system on jffs2/squashfs with ext4 being used only 
to track the config files (which tend to be tiny)


Setting these involve trade-offs that don't matter much at the typical desktop 
drive size, but matter a lot when space is really tight.


on a 16M filesystem, 1024 inodes means that you are assuming that your average 
file size is going to be ~16K, that's larger than what we are going to use on an 
overlay filesystem. with a 4K block size, your minimum filesize is effectivly 4K


However, on a very large filesystem, you are probably going to be filling that 
space with large files (audio files at multiple MB each, video files at multiple 
GB each, iso images at multiple GB, etc), so having a small blocksize and an 
inode for every 4K of disk space ends up wasting a fair amount of space (a 4T 
filesystem with one inode per 4K block uses 128GB just in inodes)



Having gone through all of this, I think we need to step back a bit and change 
the kconfig settings.


Instead of specifying blocksize by default, we should have a 'useage pattern' 
for the filesystem (lots of small files, default, large files, gigantic files, 
custom) and set the filesystem blocksize based on the combination of the usage 
pattern and the filesystem size.


mkfs.ext* has the -T flag to specify usage type (lots of small files, default, 
lots of large file, gigantic files) to set the blocksize and number of inodes on 
the filesystem. The definitions are in /etc/mke2fs.conf


We should leverage this (and possibly add our own definitions)

On a 16M filesystem, we probably want to use a 1K block size and have an inode 
for every couple of blocks.


On a 10TB filesystem, we probably want 4K block size and an inode for every few 
K blocks


A menu to customize these rather than calculating them will allow people to 
tweak them to fit the uncommon cases that LEDE is likely to be used for.


David Lang

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

Re: [LEDE-DEV] Release Preparation Questions

[David Lang]

On Sat, 19 Nov 2016, Jo-Philipp Wich wrote:


Hi all,

I am currently on working on automating the required steps to cut a
proper release - in order to make this process as standardized and
repeatable as possible, I intend to script any required steps to avoid
the need for manual setup tasks as much as possible.

Ideally I want to reach a point where one runs a "make_release.sh" with
just two arguments: a release number and a code name.

In order to achieve that goal, we must ensure that any related resources
like download URLs, Git repositories etc. are using predictable names
which can be constructed from the version number (or the nickname) alone.

Below is a list of things I'd propose for automating release cutting,
please let me know if you agree or think otherwise.


REPOSITORY PREPARATION

1) Branch "source.git" and name it "lede-$version"

2) In the used package feeds, branch "lede-$version" and use it


does it really make sense to make a branch instead of just tagging commits? Is 
there really an expectation that there will be different changes in a release 
branch vs the mainline (especially for feeds, I can see an argument for the 
lede source in that you may backport some fixes into a release branch)


Other than this, it looks reasonable.

David Lang

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

Re: [LEDE-DEV] Actual community change and additional developers compared to OpenWrt

[David Lang]

On Mon, 24 Oct 2016, Jo-Philipp Wich wrote:


I would be interested in a more contributor oriented insight at this
point. For example it took me a while to realize that being on Github
suddenly means that people edit C code via the web interface without any
means to syntax / compile / run test their changes or to sign off their
commits.


One thing that has helped us over in the rsyslog project was that we spent a 
signficant chunk of time setting up Travis (tied into github) and have that 
doing compile/testsuite runs for PRs that are submitted.


It took quite a while to get done (very little other work for a couple release 
cycles, about 3 months) but the results have been well worth it.


It would be even harder to setup for LEDE as it is bigger and has more different 
compile options to test, but I think this would be a very worthwhile thing to 
do. It's also something that could be setup by someone outside of the core group 
(working with their own fork of the project until they get things functioning)


David Lang

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

Re: [LEDE-DEV] A Wiki for LEDE Documentation

[David Lang]

On Fri, 9 Sep 2016, Aaron Z wrote:


Being as:
1. OpenWRT is on DocuWiki (and it seems to work fairly well)


This would seem to be a major factor. There will be enough work copying things 
and checking what's current. Eliminating the need to change links/markup/etc 
would seem to make it a no-brainer to use the same software for the LEDE wiki.


David Lang

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

Re: [LEDE-DEV] Documentation for router support means the famous Table of Hardware

[David Lang]

On Thu, 8 Sep 2016, Rich Brown wrote:


What a great discussion! I am delighted to see so much interest in the LEDE 
project, and concern for its success.

But I want to pick up on something that Thomas said...


On Sep 8, 2016, at 1:38 PM, Thomas Endt <tm...@gmx.de> wrote:

... However, I'm
hesitating to invest as much time as I used to some months ago, since I
don't want to see my efforts wasted in a project that's somehow stalled due
to the split in LEDE and OpenWrt. I can only invest time in _one_ project,
and preferrably that would be a project that is live and vital.


The way to ensure that LEDE thrives is to cause more people to come to it. That 
means, making it inviting. Right now, a new visitor to lede-project.org will 
see a few nicely formatted welcome pages, downloadable firmware images, but no 
documentation to speak of, and no (obvious) community.

Yet the mailing list that shows an incredibly high level of activity from the 
core developers (dozens of patches a day), and this discussion shows there that 
LEDE involves a lively and interested group of people.

To indicate this vibrancy to the world, we need to be more proactive in telling 
the world about ourselves. I advocate that we set up:

1) A Wiki that serves as documentation for LEDE
2) A Forum that lets the community talk to each other

I'll talk about each in their own threads, so each conversation can continue on 
its own. Thanks.


I'm cosely following work on the wrt1900/1200 routers right now and what I'm 
seeing is that the openwrt forums are mostly treating lede as just another 
community build, no better and no worse than what others build with closer forks 
of the openwrt tree.


I think this is a healthy thing to do for the moment while we see what can 
happen from the merger discussions and the openwrt development.


I've said before that if lede starts it's own forums, I'd like it to be 
something that can integrate mailing lists with web interaction (and mentioned 
how Baen books uses FUDForum and mailman to offer e-mail, web, and nntp access 
to the same messages)


David Lang

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

Re: [LEDE-DEV] lede forum

[David Lang]

A bit more setup, but fudforum (Fast Uncompromising Discussion Forum, 
fudforum.org) can integrate with nttp, which mailman can then integrate with 
mailing lists, allowing for full interaction between people accessing the forum 
through all three methods.


David Lang

On Mon, 25 Jul 2016, A. Benz wrote:


Hi Ted and all,

PhpBB or SMF (Simple Machines Forum) are popular free choices and take a 
minute or so to setup.


The other day on IRC I had a few people telling me how bad of an idea a 
forum is, and now it seems to be on the agenda ;)


I'd say set up the forum, content and mods will be done and get polished 
by community. I see many people on OWRT forum that work on community 
builds and dedicate a lot of time helping others, this type of people 
would make ideal mods. A few names come to mind already as I type this.


Does anyone know what kind of traffic the OWRT forum gets? If its not 
very demanding I could assist in providing hosting.


Regards,
A. Benz

On 07/25/16 07:03, Ted Hess wrote:

On Sun, 2016-07-24 at 16:37 +0200, moeller0 wrote:


On Jul 24, 2016, at 15:41 , tapper <j.lanc...@ntlworld.com> wrote:

Hi with the ssl sert being messed up on the openwrt forum we really need 

a
forum for lede. I don't know how to set one up but wen one is put up i 

wood
like to be a admin to help with noobs and getting rid of spam. I have bin 

a
admin on the Gargoyle forum now for a long time and like helping people 

out.

thanks  Tapper..
	Oh, speaking of a forum, I believe, if LEDE wants to get its own 

forum

(which) I would support it should come with more administration than the
openwrt forums that, at times, are pretty far away from lede’s “be nice to
each other” guidelines. I am not advocating to keep the ban-hammer 

swinging
all times, but there should be some feed-back and potential consequences 

of

prolonged and repeated lack of nice-ness…
I believe that tapper has shown exactly the kind of moderation a
potential lede forum should have, so I support his “election” to forum
administrator/moderator (for what it is worth)…


@tapper, @moeller0, & others

We had a brief discussion at our last mtg about what to do about a Wiki and
forum. One suggestion was to become a sub-forum in the OpenWrt forum if 

they'd
have us as a 'community build' - aka "The Dark Side" ;) That's sort of moot 

at

the moment since openwrt.org is in a certificate service valley.

We don't think we can handle our own wiki & forum without a whole lot of 

help
with content, moderation & management. We also have to find resources to 

host

the sites.

And... do you guys have any suggestions/recommendations for software 

(presumably

free) to deploy.

I'm here to help with the staging and systems work (installing and 

deploying the
base software) - I would like to see other volunteers to take on forum 

and/or

wiki admin, etc.

/ted


___
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
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Routing two interfaces on same subnet

[David Lang]

If the network interface goes through the switch in the AP, then you will not 
see the interface on the CPU go up/down. At best you could poll the switch info 
(if it gives you link state)


David Lang

On Tue, 12 Jul 2016, Baptiste Clenet wrote:


Ok thanks Tobias.
How can I detect that ethernet is plugged with hotplug? I tried some
script but it never raises.
Thing is I will know when wifi is up, ok but I have to know if eth is
plugged or not since there is no eth down when eth is unplugged.

2016-07-07 0:30 GMT+02:00 Tobias Welz <t...@wiznet.eu>:

Hum, now you want to toggle wifi - this is a totally different request. This
can maybe done by hotplug events on the ethernet executing "wifi up" and
"wifi down"
You could also have a look if there is some package that might support
something like that - i don't know if e.g. mwan3 package can do that.


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

Re: [LEDE-DEV] Lede r881 - how to get better Wireless performace ?

[David Lang]

On Sun, 3 Jul 2016, Dennis Schneck wrote:


Hello,
i use a TP Link Archer C7 v2 with LEDE r811.
But the Wireless performace (2,4GHz) is not optimal.
Are the parameter or something else to tune the performace ?
If use other Firmware in the same Environment get better transfer rates.
 
CPU use is near 10% at the speed test.
Free memory near 95MB


you don't give us any information here.

what is not optimal? what are you trying to do? what speed are you getting? what 
speed are you expecting to get? how many things are using overlapping wifi 
channels in your area? were you getting better speeds before an upgrade (or 
with other firmware)?

The odds are that the problem is just too many people using overlapping channels 
in your area, and other than changing to a less used channel, there isn't 
anything much you can do to solve it.


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

Re: [LEDE-DEV] portal wifi router

[David Lang]

On Thu, 23 Jun 2016 14:55:05 -0400, Michael Richardson wrote:

Bill Moffitt <bmoff...@ayrstone.com> wrote:
> I love the idea of meshing WiFi systems adapting their channel 
settings
> around local interference... so the Plume in my house detects 
that my

> next door neighbor's Portal is interfering, so it changes its
> channel. However, the Plume in my garage is much closer to the 
neighbor
> behind me than the Plume in my house, and changes the channel 
to avoid
> them. This then interferes with the neighbor's Portal, which 
changes
> its channel to avoid my interference, which then interferes 
with the
> neighbor behind me, who changes channel to avoid that 
interference...


This is the map colouring problem as you point out:

> P.S. for the mathematically inclined, note the discrepancy 
between the
> 3 distinct channels in the 2.4 GHz. band and the application of 
the

> 4-color theorem to channel selection. Sucks...

Am I wrong in thinking that if you can lower your Tx power that you 
can bleed

less into adjacent channels?


well, lowering TX power reduce your impact on everything, including 
adjacent channels, but not enough.


things can be done with good antenna design, but you would need to do 
the same thing on both ends, and you still have a problem that your 
transmitter and receiver are so close to each other that it's really 
hard to isolate them.


unfocused power drops off at the cube of the distance, so things a few 
feet apart have a tremendous advantage to the same things within a 
couple inches of each other (completely ignoring signals propagating 
over power/ground busses and things like that)


David Lang

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

Re: [LEDE-DEV] portal wifi router

[David Lang]

On Wed, 22 Jun 2016, Bill Moffitt wrote:

P.S. for the mathematically inclined, note the discrepancy between the 3 
distinct channels in the 2.4 GHz. band and the application of the 4-color 
theorem to channel selection. Sucks...


It gets even worse when you realize that so many people actually have a 3D 
version of the problem, not just the 'simple' 2D version.


David Lang

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

Re: [LEDE-DEV] [PATCH] Support Candela-Tech ath10k and ath9k out-of-tree driver.

[David Lang]

On Tue, 21 Jun 2016, Ben Greear wrote:


On 06/21/2016 03:04 PM, David Lang wrote:
I'll point out that there is a lot of work being done on these drivers 
right now in terms of making significant changes to how they do buffering 
that in

increasing network speed as well as reducing latency

search the follwoing lists for [make-wifi-fast] to see the details and 
benchmarks
make-wifi-f...@lists.bufferbloat.net, 
ath9k-de...@venema.h4ckr.net,linux-wirel...@vger.kernel.org


Yes, and I will pull that stuff into my tree as it becomes stable and/or as I 
have time.


It seems I have little chance to ever get my ath10k patches in the upsteam 
kernel, so this is the

best I can think of for now.

It might be best to entirely decouple my ath10k from ath9k so folks can use 
stock (LEDE) ath9k

but my ath10k.  Maybe I simply had some typo in my first attempt at this.

I figure Felix will know better how to make this all work, so this patch 
should probably

wait for him to comment on and/or fix.


One more thing that I didn't really see in the patch (but I may have skimmed 
over it)


What is the difference/improvement between the stock driver and the Candela-Tech 
driver? (i.e. as someone configuring LEDE, why would I pick your driver?)


David Lang

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

Re: [LEDE-DEV] looking for ar7 testers

[David Lang]

On Sun, 19 Jun 2016, Daniel Curran-Dickinson wrote:


On Wed, 2016-06-15 at 19:52 -0700, David Lang wrote:

Is there a list of hardware that is needed? (or do you want donations of money
for the project to buy hardware)?


TBH I'm not sure how useful random hardware donations are.  For example
getting a router which is more than just updating image generation
specifics (and assuming there is even enough information available via
flash browsing etc to do that, which isn't always the case), there is
the problem most chips manufacturers don't talk to random developer X,
and only want to give data sheets and programming information to people
who sign an NDA and have a support contract, presumably with contracts
to by X units from ODM who is actually the one making the information
available, or enabling the request).

Dealing with unsupported hardware is not something developers can often
do something about simply by having random device X.  If it's just image
generation usually it can be figured out, but beyond that it normally
requires some level of information that isn't easy to discover simply by
having a device.


Well, I'll point out that the thread I'm replying to started off with "I no 
longer have the hardware to test this"


I agree that random, unsolicited donations are likely to be less useful, but 
donations of hardware to solve the "I can't test this" or add to a test farm are 
directly useful.


And getting a new piece of equipment can get a developer interested enough to go 
after the NDAs needed to make it work well.


In some cases the vendors involved are known to 'not play well with others' and 
so donations of their hardware will do no good.


But those of us out in the wild can't tell the difference between the different 
categories.


That's why I asked for a list of what would be useful to donate :-)

David Lang

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

Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

[David Lang]

On Thu, 16 Jun 2016, Aaron Z wrote:


it would be nice to have Nano installed by default (hard to
use vi over ssh from a phone that doesn't have an escape key :D).


If you are using Android, look at the hacker keyboard

https://play.google.com/store/apps/details?id=org.pocketworkstation.pckeyboard

it gives you a traditional keyboard (including escape)

David Lang

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

Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

[David Lang]

On Tue, 14 Jun 2016, Daniel Curran-Dickinson wrote:


On Tue, 2016-06-14 at 11:05 -0700, David Lang wrote:

On Mon, 13 Jun 2016, Daniel Curran-Dickinson wrote:


On Mon, 2016-06-13 at 11:17 +0200, Jo-Philipp Wich wrote:

Hi,


Again I think you read too much into what I said (admittedly I do the
same myself, at times, as you well know)


fair enough, now we've both clarified and find that we are pretty much in 
agreement.



, but I wasn't saying there is
no use case for it, only that it's not the 'primary', or 'default' use
case.

By all means, I'm game for maximum flexibility that doesn't hurt the
primary use case.

In the case the 2TB+ drives, I was concerned that such support would come
*at the expense of* the primary use; fortunately it doesn't, but if it did,
I would argue against kernel options (for example) for making the support
the *default* (e.g. in buildbot builds), except maybe for something like x86
boards/use cases (in the case of x86 I'm not sure that limiting hardware
support to save space is in most cases necessary; other cases like default
userspace I'd argue should be kept consistent and changes from default
management with things like ImageBuilder.

In general I'm a fan of ImageBuilder because, provided the kernel support is 
there,
you can use the SDK and build whatever packages you want to add on, and use
ImageBuilder to generate images that use those packages (along with the standard
ones you still want), without getting in the way of the primary use case.


I generally compile my own images because I am tweaking even kernel options 
(disabling connection tracking on any build that's not a firewall for example), 
but getting better images and image generation would be very good.


With Imagebuilder and things pre-compiled, what does it take to create an image? 
I'm wondering if this is something that can be converted to a web UI where we 
could have someone select stuff (or upload a config file) and have the system 
spit out a custom tailored image a few seconds later.


Something like this could do wonders to move people away from the 'base image 
must contain what I need' mentality.



To a certain extent though, I question the need for something as restricted as 
OpenWrt
for the new bigger devices anyway; there are elements like netifd that would be 
good to
see continue, but I'm not sure that most of OpenWrt really makes as much sense 
when you're
not needing to squeeze maximum use out of very erase block, and that therefore, 
while it
may be a smaller market/mindshare, that focussing on the the true embedded type 
scenario,
seems to be more of what LEDE's niche is.


LEDE/OpenWRT is a good fit for any device that operates on raw flash instead of
a hard drive or ssd with wear leveling. Once you have storage that you don't
worry about wearing out and is large enough to hold a normal Linux Distro, it
makes sense to move to such a distro and update packages individually.


Hmmm...the wear levelling thing is confusing.  I was told by someone who I 
thought knew
what they were talking about, that flash chips included some form of 
hardware-based
wear levelling built in already.  Apparently that is was inaccurate 
(hardware-level
support is something I only having minor knowledge of; it's not the part the 
interests me,
nor where I have worked on it for any length of time; I'm more interested in 
what you can
do with existing hardware support combined with software rather developing the 
core support
itself).


raw flash chips like we have in a router have nothing.

flash chips packaged in SD cards, USB drives, etc commonly have very primitive 
wear leveling (in many cases only targeted at the places that the FAT filesystem 
is going to use)


flash chips packaged into SSD drives or anything more sophisticated tend to have 
very extensive wear leveling setups, and will move existing, unmodified data if 
needed to balance things.


I haven't looked recently, but a couple years ago the idea of having an 
in-kernel flash wear leveling capability was getting a lot of discussion on the 
kernel mailing list. I din't remember seeing what finally happened with that.


For the very tiny devices, it doesn't make sense to try and make use of 
something like that (it takes more space ond isn't going to apply to a static, 
pre-build compressed filesystem)


But for the overlay filesystem where new stuff may get added on newer devices 
that have the much larger NAND flash, it may be something to look into, even 
though it complicates the base config for such systems.


David Lang

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

Re: [LEDE-DEV] looking for ar7 testers

[David Lang]

On Thu, 16 Jun 2016, John Crispin wrote:


But for the general case, my question still stands. What hardware
(including brand-new devices, wishlists for future devices, etc) is
wanted, how can it be donated?


talk to your local developer and support him as per need i guess.


Ok, who is 'local' to Los Angeles, California, the US, or the western 
hemisphere? ( with e-mail lists, this is not always obvious :-)



personally i am right now looking for donations of ipq hardware that is
not locked down.


If you can point at such hardware on amazon/e-bay or similar, I can pay for it, 
but I don't know enough to know what qualifies.


David Lang

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

Re: [LEDE-DEV] looking for ar7 testers

[David Lang]

Ok, so it sounds like this particular hardware is not wanted and support may be 
dropped.


But for the general case, my question still stands. What hardware (including 
brand-new devices, wishlists for future devices, etc) is wanted, how can it be 
donated?


David Lang

On Wed, 15 Jun 2016, Daniel Gimpelevich wrote:


Ethernet support on ar7 had to be shoehorn-hacked in for each device
individually. What would fix it on one would break it on another. I had
been in process of trying to come up with a unifying Ethernet hack a few
years ago, but I became discouraged by the incomplete GPL tarballs, the
lack of a wireless driver for the 1350A chipset, the kludgey state of
ATM support, and the shortage of RAM on pretty much every supported
device.

On Wed, 2016-06-15 at 19:52 -0700, David Lang wrote:

Is there a list of hardware that is needed? (or do you want donations of money
for the project to buy hardware)?

David Lang

On Wed, 15 Jun 2016, John Crispin wrote:


Date: Wed, 15 Jun 2016 09:29:31 +0200
From: John Crispin <j...@phrozen.org>
To: LEDE Development List <lede-dev@lists.infradead.org>
Subject: [LEDE-DEV] looking for ar7 testers

Hi,

the ar7 boots with v4.4 but ethernet apparently passes no traffic and
atm is untested.

we need someone to pick up the maintainer ship and fix this issue. i
have no longer got any hw that can be used for testing. we need this
fixed for it to be part of the release.

John

___
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



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

Re: [LEDE-DEV] looking for ar7 testers

[David Lang]

Is there a list of hardware that is needed? (or do you want donations of money 
for the project to buy hardware)?


David Lang

On Wed, 15 Jun 2016, John Crispin wrote:


Date: Wed, 15 Jun 2016 09:29:31 +0200
From: John Crispin <j...@phrozen.org>
To: LEDE Development List <lede-dev@lists.infradead.org>
Subject: [LEDE-DEV] looking for ar7 testers

Hi,

the ar7 boots with v4.4 but ethernet apparently passes no traffic and
atm is untested.

we need someone to pick up the maintainer ship and fix this issue. i
have no longer got any hw that can be used for testing. we need this
fixed for it to be part of the release.

John

___
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] TR-069 and OpenWrt discussion on these lists?

[David Lang]

On Wed, 15 Jun 2016, L. D. Pinney wrote:


It's a Development List ... no place for corporate agendas.


if adding a feature is a corporate agenda because a company is interested in it 
working correctly, you are shutting down all development.



The problem is more pervasive than just TR-069.

It's about cross-posting and pushing forwards about who's going to the
corporate sponsored events and other drivel.


Some amount of cross posting is very reasonable. In this case, they are talking 
about what developers are going to go to this event to coordinate their 
development work. If they were talking about what CxO folks they were getting 
together it would be less relevant (but I'll point out that LEDE doesn't have 
any list to coordinate management/publicity/etc stuff, so it may very well end 
up here anyway)


If this was a non-profit organizing a similar meeting would you be telling them 
to go away, that their contributions are not wanted?



These things have little or nothing to do with the PRIMARY reason of a
Development List.

IF these people have something to contribute such as a [PATCH] this
would be correct mailing list...otherwise it's BS


There is more to development than just [PATCH] e-mails.

In this case there are multiple people/companies have code that they are 
releasing and looking to get integrated, and they want to coordinate instead of 
fighting each other. This is generally considered a good thing.


Driving people away because they aren't helping in exactly the way that you 
consider ideal is a good way to kill a project.


David Lang


On Wed, Jun 15, 2016 at 5:14 PM, David Lang <da...@lang.hm> wrote:

Like individuals, companies do things that benefit them. Almost all Open
Source software development is done by people who benefit from the results.
If benefiting from the results makes it that the LEDE project doesn't want
to hear from you, the project will die _really_ fast.

I hope your hostile attitude doesn't spread.

David Lang

On Wed, 15 Jun 2016, L. D. Pinney wrote:


Date: Wed, 15 Jun 2016 17:10:36 -0500
From: L. D. Pinney <ldpin...@gmail.com>
To: David Lang <da...@lang.hm>
Cc: LEDE Development List <lede-dev@lists.infradead.org>

Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?

Just because a company works on something doesn't make it evil.
Yes of course large corporations are well known for altruistic behavior.

On Wed, Jun 15, 2016 at 5:03 PM, David Lang <da...@lang.hm> wrote:


Is it really pushing a corporate agenda to coordinate efforts to make
LEDE/OpenWRT support remote management protocols?

Just because a company works on something doesn't make it evil.

David Lang

On Wed, 15 Jun 2016, L. D. Pinney wrote:


Date: Wed, 15 Jun 2016 16:29:08 -0500
From: L. D. Pinney <ldpin...@gmail.com>
To: LEDE Development List <lede-dev@lists.infradead.org>
Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?


Postings to the LEDE Development List should be devoted to technical
development issues.

Persons from prplfoundation et.al should respect conventional mail list
etiquette such as found here :

http://www.arm.linux.org.uk/mailinglists/etiquette.php

Pay particular attention to 4, 7, and 10 on the above etiquitte list.

I see prplfoundation as a hostile takeover of LEDE / OpenWrt by a
corporate conspiracy.

Free Software is meant to be free ...

Free from the manipulation of governments and corporations.

Pushing your corporate backed agenda on the Development List(s)
torques me off every time.

On Wed, Jun 15, 2016 at 3:31 PM, Eric Schultz
<eschu...@prplfoundation.org> wrote:



As we continue the TR-069 support discussion, I wanted to ask folks
whether they want me to continue to cross post to these list in
addition
to the prplwrt list at open...@lists.prplfoundation.org. I have no
problem doing either way, but I don't want to fill people's inbox will
stuff they feel is off topic. Just wanted to get a sense of what people
would prefer.

Thanks,

Eric
--
Eric Schultz, Community Manager, prpl Foundation
http://www.prplfoundation.org
eschu...@prplfoundation.org
cell: 920-539-0404
skype: ericschultzwi
@EricPrpl

___
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











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

Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?

[David Lang]

Like individuals, companies do things that benefit them. Almost all Open Source 
software development is done by people who benefit from the results. If 
benefiting from the results makes it that the LEDE project doesn't want to hear 
from you, the project will die _really_ fast.


I hope your hostile attitude doesn't spread.

David Lang

On Wed, 15 Jun 2016, L. D. Pinney wrote:


Date: Wed, 15 Jun 2016 17:10:36 -0500
From: L. D. Pinney <ldpin...@gmail.com>
To: David Lang <da...@lang.hm>
Cc: LEDE Development List <lede-dev@lists.infradead.org>
Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?

Just because a company works on something doesn't make it evil.
Yes of course large corporations are well known for altruistic behavior.

On Wed, Jun 15, 2016 at 5:03 PM, David Lang <da...@lang.hm> wrote:

Is it really pushing a corporate agenda to coordinate efforts to make
LEDE/OpenWRT support remote management protocols?

Just because a company works on something doesn't make it evil.

David Lang

On Wed, 15 Jun 2016, L. D. Pinney wrote:


Date: Wed, 15 Jun 2016 16:29:08 -0500
From: L. D. Pinney <ldpin...@gmail.com>
To: LEDE Development List <lede-dev@lists.infradead.org>
Subject: Re: [LEDE-DEV] TR-069 and OpenWrt discussion on these lists?


Postings to the LEDE Development List should be devoted to technical
development issues.

Persons from prplfoundation et.al should respect conventional mail list
etiquette such as found here :

http://www.arm.linux.org.uk/mailinglists/etiquette.php

Pay particular attention to 4, 7, and 10 on the above etiquitte list.

I see prplfoundation as a hostile takeover of LEDE / OpenWrt by a
corporate conspiracy.

Free Software is meant to be free ...

Free from the manipulation of governments and corporations.

Pushing your corporate backed agenda on the Development List(s)
torques me off every time.

On Wed, Jun 15, 2016 at 3:31 PM, Eric Schultz
<eschu...@prplfoundation.org> wrote:


As we continue the TR-069 support discussion, I wanted to ask folks
whether they want me to continue to cross post to these list in addition
to the prplwrt list at open...@lists.prplfoundation.org. I have no
problem doing either way, but I don't want to fill people's inbox will
stuff they feel is off topic. Just wanted to get a sense of what people
would prefer.

Thanks,

Eric
--
Eric Schultz, Community Manager, prpl Foundation
http://www.prplfoundation.org
eschu...@prplfoundation.org
cell: 920-539-0404
skype: ericschultzwi
@EricPrpl

___
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







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

Re: [LEDE-DEV] lede integration issues remaining from the detrius of cerowrt

[David Lang]

On Sat, 11 Jun 2016, Daniel Curran-Dickinson wrote:


Hi Dave,

I don't speak for the LEDE team, but it looks to me a lot of your
problem is that you are using LEDE/openwrt for far bigger iron than the
primary target (standard routers, including pre-AC non-NAND ones, which
are really quite small and low powered).  2 TB+ storage for example, or
using lighttpd instead of uhttpd are really things that don't affect the
primary use case and if you want to support this, you need to find a way
to do that does not negatively affect your typical router (without
external storage).


While CeroWRT has expanded it's aim to be able to support today's faster network 
connections (up to and including the 1G connections now available), that's not 
really the issue here.


Even low-end devices now include a USB port, and it's really easy to plugi in an 
external USB drive that's >2TB. 3TB drives are now <$100


Now, if support for larger drives really does add a lot to the system footprint, 
it should be optional. But how much space are we talking about here? It should 
at least be an easy-to-select option.


David Lang

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

Re: [LEDE-DEV] [OpenWrt-Devel] TR-069 for OpenWrt

[David Lang]

On Sat, 28 May 2016, Hauke Mehrtens wrote:


On 05/27/2016 12:43 PM, David Lang wrote:

On Thu, 26 May 2016, Delbar Jos wrote:


We are conscious of the fact that together with the proposals made by
Felix, Luka and Wojtek we are now looking at many "competing"
proposals. As a next step, we recommend to organize a workshop, at a
practical location and time, where we put everything on the table and
define the most appropriate path forward to the benefit of OpenWrt as
a whole.


nothing wrong with supporting many different remote management daemons.


TR-069 is a complicated remote management system and in order to make
this initiative a success, we must ensure that the complexity is
handled in an elegant way and with respect for OpenWrt's core
architecture. More than on the protocol itself, we believe that we
should focus on the architectural enhancements required to support
remote management in general.


What is it that you think is needed to "support remote management in
general"?

It's worth pointing out that many people are remotely managing OpenWRT
devices, Ansible/Salt/Puppet/Chef/etc are all common tools for the job.

now, those are all tools aimed at managing Linux Servers, not networking
gear, but OpenWRT is a server.

So I'd suggest starting off by creating a daemon that talks  and just stores the stuff it's sent in some simple files so
that it can return the info when queried.

Once you have something that talks the network protocol correctly,
modifying it to change the real files, make uci calls, etc for different
distros is much easier (just write your daemon with the expectation that
the input and output details are going to change, so don't get fancy
with them).

David Lang


The TR-069 family is currently wildly used by ISPs controlling the (DSL)
CPE devices of their customers. There are probably more than 100 million
device controlled by standards from the TR-069 family out there.  When
you get a DSL router from your ISP or buy one in the retail store it is
very likely it supports the standards from the TR-069 family, as a
vendor in this area you basically need support for this to sell your
devices.


I wasn't questioning why it's useful to support TR-069. The only part I was 
questioning was the statement that OpenWRT needed work to make it support remote 
management.


There are already many tools to remotely manage/monitor OpenWRT

But that's why I'm saying that it seems like most of the work is in the protocol 
interface. If there is already a daemon that does the network protocol properly, 
that should make things very easy. If such a daemon needs to be written, that 
would be the place I would suggest that they focus. There are a lot of people 
who can do the plumbing work to make the daemon do the right thing on the 
system, who are not in a position to work on the network protocol side and make 
sure that it works properly with the management software.


David Lang

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

Re: [LEDE-DEV] [Cerowrt-devel] WRT1900ACS Testing

[David Lang]

There was a new wifi firmware release today (not yet in LEDE or OpenWRT trunk) 
announced around post 11400 on this forum


https://forum.openwrt.org/post.php?tid=50173=325044

David Lang

On Fri, 20 May 2016, Dave Taht wrote:


Date: Fri, 20 May 2016 14:16:13 -0700
From: Dave Taht <dave.t...@gmail.com>
To: Dheeran Senthilvel <dheeranm...@gmail.com>
Cc: lede-dev@lists.infradead.org,
"cerowrt-de...@lists.bufferbloat.net"
<cerowrt-de...@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [LEDE-DEV] WRT1900ACS Testing

We had found some pretty major performance problems on this hardware
as of a few months ago. I am curious if they still exist? A whole
bunch of benchmarks went by on the cerowrt-devel list, also.

They were:

1) broken local ethernet network stack - running 4 copies of netperf
against it - one would grab all the bandwidth and the other three
barely even start or hang completely.

2) No BQL in the ethernet driver

3) Wifi was horribly overbuffered in general

4) Wifi would crash against flent's rrul test.


On Thu, May 19, 2016 at 3:37 AM, Dheeran Senthilvel
<dheeranm...@gmail.com> wrote:

Hi,
I am currently running LEDE r274 build dated 18-May-2015. The build seems to be 
stable as of now, have been flashing the images ever since the snapshot was 
made available in the repository. Current Status of the device is as follows,

# Wireless - both 2.4Ghz (@297MB/s) and 5Ghz(@1079MB/s) are working 
fine.(Speed tested using iperf).

# USB - Not Tested

# LEDs - Only Power, WiFi & LAN leds are functioning. WAN & USB are not 
working (Similar OpenWrt Ticket - https://dev.openwrt.org/ticket/21825)

#Terminal Output



root@Shelby:~# lsmod


ahci_mvebu  1653  0
ahci_platform   2367  0
armada_thermal  3284  0
cfg80211  220675  2 mwlwifi
compat 13025  2 mac80211
crc_ccitt979  1 ppp_async
ehci_hcd   34246  2 ehci_orion
ehci_orion  2563  0
ehci_platform   4368  0
gpio_button_hotplug 5988  0
hwmon   2026  3 tmp421
i2c_core   18339  3 tmp421
i2c_dev 4551  0
i2c_mv64xxx 7033  0
ip6_tables  9625  3 ip6table_raw
ip6t_REJECT 1056  2
ip6table_filter  682  1
ip6table_mangle 1042  1
ip6table_raw 648  0
ip_tables   9775  4 iptable_nat
ipt_MASQUERADE   698  1
ipt_REJECT   914  2
iptable_filter   736  1
iptable_mangle   868  1
iptable_nat 1029  1
iptable_raw  702  0
ledtrig_usbdev  2307  0
libahci19501  3 ahci_mvebu
libahci_platform4501  2 ahci_mvebu
libata127382  5 ahci_mvebu
mac80211  401118  1 mwlwifi
mmc_block  21754  0
mmc_core   77838  2 mvsdio
mvsdio  7362  0
mwlwifi69628  0
nf_conntrack   60523  9 nf_nat_ipv4
nf_conntrack_ipv4   6125 11
nf_conntrack_ipv6   6564  6
nf_conntrack_rtcache2461  0
nf_defrag_ipv4   884  1 nf_conntrack_ipv4
nf_defrag_ipv6 13185  1 nf_conntrack_ipv6
nf_log_common   2407  2 nf_log_ipv4
nf_log_ipv4 3218  0
nf_log_ipv6 3663  0
nf_nat 10036  4 nf_nat_ipv4
nf_nat_ipv4 4054  1 iptable_nat
nf_nat_masquerade_ipv41509  1 ipt_MASQUERADE
nf_nat_redirect  919  1 xt_REDIRECT
nf_reject_ipv4  1911  1 ipt_REJECT
nf_reject_ipv6  2236  1 ip6t_REJECT
nls_base5190  1 usbcore
ppp_async   6521  0
ppp_generic19930  3 pppoe
pppoe   8047  0
pppox   1239  1 pppoe
pwm_fan 2840  0
sata_mv26825  0
scsi_mod   88117  3 usb_storage
sd_mod 23412  0
slhc4543  1 ppp_generic
thermal_sys20307  2 armada_thermal
tmp421  2500  0
usb_common  1676  1 usbcore
usb_storage37368  0
usbcore   120847  8 ledtrig_usbdev
x_tables   10689 26 ipt_REJECT
xhci_hcd   81489  2 xhci_plat_hcd
xhci_pci2324  0
xhci_plat_hcd   3897  0
xt_CT   2797  0
xt_LOG   851  0
xt_REDIRECT  825  0
xt_TCPMSS   2660  2
xt_comment   511 62
xt_conntrack2516 16
xt_id506129
xt_limit1241 20
xt_mac   631  0
xt_mark  704  0
xt_multiport1308  0
xt_nat  1329  0
xt_state 801  0
xt_tcpudp   1800 10
xt_time 1670  0


root@Shelby:~# cat /etc/config/system


config system
option hostname 'Shelby'
option timezone 'IST-5:30'
option ttylogin '0'

config timeserver 'ntp'
 

Re: [LEDE-DEV] OpenWRT tree vs LEDE tree

[David Lang]

On Thu, 19 May 2016, Daniel Curran-Dickinson wrote:


Do I think there are potentially problems, like my, and others,
impressions, that there is a fair amount of back channel (private) email
that *isn't* part of the public discussion that I thing is contrary to
the stated goal of transparency, if if the only reason is they think
it's just trivial or trying to hash things out?  Then yes, I think there
is *too much* back channel mail, and that if they're *serious* about
transparency they will fix that, even if it's hard to adopt that working
style.

You know I personally am not afraid to go on the record with my thoughts
and opinions, and I think that kind of approach is what it takes to do
transparency right, if it can be uncomfortable and keeps a history of
thing one might wish were not on the record.



regarding the open decision-making process: *the* channel for any kind
of serious discussion should be the open mailing list.
- as others pointed out, irc plain does not work for such stuff. the
  whole concept of meetings (or generally real-time communication about
  non-trivial matters) doesn't work for many people, so just scratch it.
- alone the fact that "important stuff" happens "out of band" and needs
  to be actively collected by those "passively interested" is a problem.
  probably the problem that triggered bjoern's mail in the first place.


Exactly.  It seems like there is still a lot of back channel talk that
is not public.


Guys, give them a little time to transition here.

Not all conversations should be public.

does the concept of "don't play with matches in a powder magazine" make sense?

negotiations and discussions of blame/hurt feelings don't work well if there is 
a large crowd of hecklers around. They (both LEDE and OpenWRT folks) need to be 
able to meet and discuss history and the effects that it will have going forward 
without people second guessing every move and parsing every word for hidden 
meanings.


The LEDE folks flubbed the announcemnt, but that was only a couple weeks ago. 
These are people working on this part-time, they have families and jobs to deal 
with. It is going to take them time to figure out what and how to change and 
communicate the details between them.


Would you really like it if they started announcing changes, only to have other 
LEDE folks contradict them?


Focus on Code and Tools, you know, technical stuff. Let them have a little 
breathing room to figure out the governence stuff.


Watch what's changing, make suggestions, sure. But tone down the demands and 
criticism until they actually show that they aren't willing to change. So far 
they've seemed very willing to tweak things in response to suggestions.


David Lang

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

[LEDE-DEV] how to update a package to a new upstream version was: Re: How to start?

[David Lang]

On Thu, 19 May 2016, Gabriel F.C. Mazzocato wrote:


2016-05-19 17:51 GMT-03:00 David Lang <da...@lang.hm>:


Is this something that's not already packaged for LEDE/OpenWRT?

It's far more complex to add something new than to just select different
options that are already configured.



Yeah. Currently iptables is at 1.4.21 version at both dists. I was
trying to bump to 1.6.0 and if successful, upload a diff to the dev
team. Tryied through Quilt too using the patch source, almost got it.
The kmod-ipt-* I was trying to build from the source (xtables_$$$.c).


Ok, then your question isn't how to configure OpenWRT/LEDE but rather how to 
update a package to a new version.


That's a question I don't know enough to answerbut by framing the question 
better, you may get more appropriate help (and or different search terms will 
help you find the info)


David Lang

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

Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, Ferry Huberts wrote:


On 18/05/16 11:10, David Lang wrote:

On Wed, 18 May 2016, Ferry Huberts wrote:


On 18/05/16 10:03, David Lang wrote:

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 09:46, Ferry Huberts wrote:



already in-place in Fedora and RedHat/CentOS.

You then get even stronger protection and run-time performance
impact is
negligible.


the stuff i proposed has not runtime hit. selinux is simple to full


SELinux's hit is for all intents and purposes zero as well nowadays.


blown and hard to maintain. the idea would be to create a custom
tailored solution for our requirements.


That is why I prefer AppArmor, you don't have the interaction between
different application configs that you do with SELinux, so you can focus
on the specific application that you are concerned about.


AppArmor is significantly less secure than SELinux.
And with SELinux you don't need all the preloading stuff that was
talked about, you can just declare which ports are allowed.


tightly configured in expert hands, you are right. However, that's not
the normal user of LEDE/OpenWRT. For what (little) it's worth, I'll
point out that if home users are familar with Linux, the odds are good
that it's a flavor of Ubuntu that uses AA rather than Fedora that uses
SELinux. (not worth much because the home user probably hasn't touched
AA or SELinux)


That should not be an argument to do one or the other.
You should ask yourself how far you would want to go in securing a router. 
Personally, I would absolutely love a router with a tight SELinux policy 
since it protects me well from unsavory access from the outside.




do all the compressed filesystems support the tagging needed by SELinux?
what about external drives with FAT* or NTFS?


FAT and NTFS do not support it AFAIK, but how is that a problem?
You'd run SELinux on your internal filesystem.


it's not uncommon for people to attach an external drive for more space, and 
then have stuff run off of that drive.


If SELinux can't find the appropriate labels, does it deny or allow by default.

One of the things that annoys me about SELinux is the fact that a daemon can 
behave differently depending on if it's started by init, or started by the root 
user. I've fielded a lot of problem reports because something worked fine when 
they tested it as root and then failed when init started the process (also as 
uid 0). I've also seen cases where the testing as root created a file/directory 
with a label that isn't allowed when the process is started by init, so they 
have to detect the problem and remove the file to let it be created in the 
correct context.


For the compressed filesystems: I don't know, they will probably support it 
if they're good citizen Linux filesystems.


not all linux filesystems support xattrs.





How do you handle the possible need to re-label your files on a
read-only filesystem?



Don't know, but take a look at Android, it has SELinux enabled in enforcing 
mode (the strongest mode).


android devices tend to have a lot more storage/ram than many routers. They also 
aren't running on read-only filesystems.



what is the difference in kernel size (and tool size) between AA and
SELinux?





Don't know.


For clarity (and for weaseling out): I read a snip of the discussion and 
wanted to offer another alternative, so that the discussion could consider 
it.


And I think it's a good thing to bring up and discuss. I happen to dislike 
SELinux and would not have brought up AppArmor until after things were moved to 
not run as root in the first place. But I think it's a good discussion to have.


I am not trying to shout you down, just raising concerns.

David Lang

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

Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, Ferry Huberts wrote:


On 18/05/16 10:03, David Lang wrote:

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 09:46, Ferry Huberts wrote:



already in-place in Fedora and RedHat/CentOS.

You then get even stronger protection and run-time performance impact is
negligible.


the stuff i proposed has not runtime hit. selinux is simple to full


SELinux's hit is for all intents and purposes zero as well nowadays.


blown and hard to maintain. the idea would be to create a custom
tailored solution for our requirements.


That is why I prefer AppArmor, you don't have the interaction between
different application configs that you do with SELinux, so you can focus
on the specific application that you are concerned about.


AppArmor is significantly less secure than SELinux.
And with SELinux you don't need all the preloading stuff that was talked 
about, you can just declare which ports are allowed.


tightly configured in expert hands, you are right. However, that's not the 
normal user of LEDE/OpenWRT. For what (little) it's worth, I'll point out that 
if home users are familar with Linux, the odds are good that it's a flavor of 
Ubuntu that uses AA rather than Fedora that uses SELinux. (not worth much 
because the home user probably hasn't touched AA or SELinux)


do all the compressed filesystems support the tagging needed by SELinux? what 
about external drives with FAT* or NTFS?


How do you handle the possible need to re-label your files on a read-only 
filesystem?


what is the difference in kernel size (and tool size) between AA and SELinux?

David Lang

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

Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 09:46, Ferry Huberts wrote:



On 18/05/16 09:25, John Crispin wrote:



On 18/05/2016 09:21, Radu Anghel wrote:

/* sending again because i hit 'reply' instead of 'reply all' :) */

On Wed, May 18, 2016 at 8:29 AM, John Crispin <j...@phrozen.org> wrote:


ok, there had been some discussion about building a super daemon that
runs, then ld-preloading bind() and co and using ubus to transport
sockets around. using caps or /proc sounds like a good i between until
such a daemon exists



Most daemons I know of that need to bind to ports <1024 start as root
and after binding to the port they drop privileges to the privileges
of the user specified in their config file. For those daemons just
adding a user and specifying it in their config file should be enough.
For the daemons that don't need to bind to <1024 just starting them
from their own user account is ok as they don't need additional
privileges.

For example the dnsmasq daemon has these options:

# If you want dnsmasq to change uid and gid to something other
# than the default, edit the following lines.
#user=
#group=

I don't think that integrating such functionality in ubus or some
other LEDE-only super-daemon is a good idea. Config options +
capabilities for those daemons withut such options is a good way of
doing this in my opinion. Also use different users for different
daemons, as others said.


to elaborate, imagine dnsmasq running inside a jailm where ut only
thinks it is root but is not in reality. also ld-preloading bind and
connect would allow us to do pretty adavnced stuff like only allowing
dnsmasq to open certain ports. essentially an acl around the
bind/connect calls.




You might just as well switch on SELinux and use the policies that are
already in-place in Fedora and RedHat/CentOS.

You then get even stronger protection and run-time performance impact is
negligible.


the stuff i proposed has not runtime hit. selinux is simple to full
blown and hard to maintain. the idea would be to create a custom
tailored solution for our requirements.


That is why I prefer AppArmor, you don't have the interaction between different 
application configs that you do with SELinux, so you can focus on the specific 
application that you are concerned about.


SELinux configs that Fedora uses have to be so permissive to keep from breaking 
too many 'normal' use cases that I really question how valuable they are.


A SELinux system tuned by an expert is going to be more secure than an AppArmor 
system tuned by an expert, SELinux just can do more (at least right now). But 
there aren't many experts of that caliber around. A reasonably competent 
sysadmin can understand an AppArmor config and tweak it for their layout without 
too much effort (once they identify that AppArmor is blocking what they are 
trying to do)


David Lang

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

Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 09:21, Radu Anghel wrote:

/* sending again because i hit 'reply' instead of 'reply all' :) */

On Wed, May 18, 2016 at 8:29 AM, John Crispin <j...@phrozen.org> wrote:


ok, there had been some discussion about building a super daemon that
runs, then ld-preloading bind() and co and using ubus to transport
sockets around. using caps or /proc sounds like a good i between until
such a daemon exists



Most daemons I know of that need to bind to ports <1024 start as root
and after binding to the port they drop privileges to the privileges
of the user specified in their config file. For those daemons just
adding a user and specifying it in their config file should be enough.
For the daemons that don't need to bind to <1024 just starting them
from their own user account is ok as they don't need additional
privileges.

For example the dnsmasq daemon has these options:

# If you want dnsmasq to change uid and gid to something other
# than the default, edit the following lines.
#user=
#group=

I don't think that integrating such functionality in ubus or some
other LEDE-only super-daemon is a good idea. Config options +
capabilities for those daemons withut such options is a good way of
doing this in my opinion. Also use different users for different
daemons, as others said.


to elaborate, imagine dnsmasq running inside a jailm where ut only
thinks it is root but is not in reality. also ld-preloading bind and
connect would allow us to do pretty adavnced stuff like only allowing
dnsmasq to open certain ports. essentially an acl around the
bind/connect calls.


well, between the different namespace options (pid, user, network, filesystem) 
you can have the thing running in the container thinking that it is root and the 
container configuration limit what it can do. This is the bleeding edge of 
containerization, so advanced use cases like you are defining are going to be 
fragile as the kinks get worked out. But there are a lot of people working in 
this problem space right now.


I personally think that the best bet is to ignore the problem for now, but keep 
an eye on the different container projects, try to make them all work on LEDE, 
and as the dust starts to settle, pick the top (or top few) survivors and start 
using them.


Right now some of the namespace types open up as many vulnerabilities as they 
allow you to close.




Another think to keep in mind is that most of these projects allow you to 
package up and containerize individual daemons, but as soon as you start needing 
to have the different things interact with each other (say the container running 
LUCI needs to start configuring the container running asterisk), they get really 
ugly.




And finally, many of the people focusing on these projects are aiming for the 
cloud datacenter market where every machine is ephemeral and is expected to 
disappear and take all data/configs stored on it as it goes. So they all rely on 
some external storage/database setup to hold all that stuff. Not something 
normally available to LEDE type devices running in homes and small offices.



David Lang

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

Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, John Crispin wrote:


On 18/05/2016 08:09, Daniel Curran-Dickinson wrote:

On 16-05-18 01:05 AM, John Crispin wrote:

Hi,

we had previously started building the infra for running stuff as !root.
so far we have added

* the userid/gid stuff
* acl on ubus

things that i know are missing

* handling network ports < 1024

what am i missing ? can anyone think of other issues we need to address
before we change uid to !root ?



Er, do you mean uid of procd or ubus or everything?  I'm not sure we're
clear on which uid you mean?


ok, my mail that sounded totally obvious to me apparently was hard to
understand.

right now we run $everything as root which is obviously rather daring so
we need to change it to what normal distros do and run stuff as their
own users wherever it makes sense and give those users only the
permissions required.


Ok, that makes a lot of sense. The good news here is that we don't have to start 
off with doing fancy stuff like passing sockets around, playing with 
capabilities to bind to low ports, SELinux/AppArmor, etc. We can start off by 
just copying the sysV init configs that have existed for other distros.


Most of the work is actually going to be in undoing OpenWRT specific configs 
that run everything as root and fall more in line with what the other distros 
are doing.


The first question I would have is if we are going to the system users in an 
essentially random order (as needed so two systems with the same packages 
installed in a different order have different user->uid mapping) or if we are 
going to define service accounts distro wide so they are always going to be the 
same.


David Lang

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

Re: [LEDE-DEV] running stuff as !root

[David Lang]

On Wed, 18 May 2016, John Crispin wrote:


Hi,

we had previously started building the infra for running stuff as !root.
so far we have added

* the userid/gid stuff
* acl on ubus

things that i know are missing

* handling network ports < 1024

what am i missing ? can anyone think of other issues we need to address
before we change uid to !root ?


what things are you trying to run as !root?

just changing everything to run as user lede (uid 1) instead of root (uid 0) 
doesn't actually buy much, especially if user lede is able to administer things 
https://xkcd.com/1200/


you want to end up running different types of things as different users, and 
there the permissions get more 'interesting'


there is a capability you can give to binaries to let them bind to ports < 1024, 
there is also a proc setting you can use to let anything bind to ports < 1024.


There are various other things that will require capabilities to work (including 
some versions of ping and traceroute), but it's a matter of fixing them as you 
bump into them.


don't try to make everything run as the same !root user, migrate things one (or 
at least one category) at a time.


David Lang

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

Re: [LEDE-DEV] [PATCH 2/2] [ubox] logd: add ubus reload method

[David Lang]

On Fri, 13 May 2016, Alexandru Ardelean wrote:


On Fri, May 13, 2016 at 8:55 PM, David Lang <da...@lang.hm> wrote:

On Fri, 13 May 2016, Helmut Schaa wrote:

I was thinking of a different use-case:
Increasing the buffer size on the fly comes in handy during a debug
session
where you'd like to not interrupt logging (and thus potentially lose some
parts
of the syslog when restarting logd).

Independent of how the implementation looks like I think the functionality
would be quite useful.



I don't think it's very valuable. If you are debugging, you really don't
want to be tweaking anything in the middle of trying to capture data. you
want to set everything up and let it run, then analyze the data.

I don't see that changing the log size in the middle of a capture run is a
good idea, let alone one that is common enough to have to introduce uci
specific knowledge into the logd daemon.

You are better off sending to a remote logserver anyway.

David Lang


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


First of all, let's agree on a few things:
1) the patch " [ubox] syslog: use realloc to change log buffer size ",
which precedes this, is an improvement over the existing code in logd
; the initial code of logd, includes a logic to dynamically increase
the log buffer (using malloc() + memcpy()) ; there are 2 logical
options regarding that code:
  1.1) make it work (as that patch does)
  1.2) remove it
2) there are people that don't need this ability to dynamically
increase the log buffer ; we do need it, but are not blocked by not
having it ; it would be neat to have in upstream ubox/logd, given that
logd was initially written with this ability partially intended;

I don't know if this pushback is also amplified by my snappy reply to KarlP.
If it is, well, c'est la vie :) .  I lost an argument because of a
snappy come-back that upset some people. Wouldn't be the first time.

I feel that this change [to dynamically increase the log-size] can be
achieved with minimal impact on code/binary size and logd behavior
(given point 1) ).
Normal operation should not be affected (or the patchset can be
adapted to less affect normal operation).
And then, if it's in, people can choose to use it or not.
Or, if it's too intrusive/bothersome, we can drop the patchset altogether.

I'm still unclear yet how patch submission works in LEDE, and how
patches are accepted/voted, or who has the final go.
At least this process can shed some on light on that (for us).


People don't object to the ability to resize the buffer if the code impact is 
small, but when you start saying that you want to have logd understand/parse UCI 
in the binary (as opposed to the script that starts the binary), the code impact 
is not that small any longer.


The use case isn't non-existant, but it is marginal.

David Lang

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

Re: [LEDE-DEV] [PATCH 2/2] [ubox] logd: add ubus reload method

[David Lang]

On Fri, 13 May 2016, Helmut Schaa wrote:


On Fri, May 13, 2016 at 12:03 PM, Bastian Bittorf
<bitt...@bluebottle.com> wrote:

* Conor O'Gorman <i...@conorogorman.net> [13.05.2016 11:52]:

On 13/05/16 07:23, Alexandru Ardelean wrote:

Short version is: we have a configuration management system on top of
OpenWrt ; system boots with default settings (on every boot), and
config management applies config changes (whether it's right after
boot, or during system's normal operation).
Maybe other people do something similar.

Not many. Most people store the config, which is the current model.
It has benefits.


We also have an approach like Alexandru, but i dont see
the problem: logd starts at START='12'. Our config-thingy
fires at START=01 and uci-sets all the stuffs. So we can still
"rotate the knobs" e.g. uci set system.@system[0].log_size=64


I was thinking of a different use-case:
Increasing the buffer size on the fly comes in handy during a debug session
where you'd like to not interrupt logging (and thus potentially lose some parts
of the syslog when restarting logd).

Independent of how the implementation looks like I think the functionality
would be quite useful.


I don't think it's very valuable. If you are debugging, you really don't want to 
be tweaking anything in the middle of trying to capture data. you want to set 
everything up and let it run, then analyze the data.


I don't see that changing the log size in the middle of a capture run is a good 
idea, let alone one that is common enough to have to introduce uci specific 
knowledge into the logd daemon.


You are better off sending to a remote logserver anyway.

David Lang

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

Re: [LEDE-DEV] [PATCH] bcm53xx: calculate TRX CRC32 using whole kernel partition

[David Lang]

Just a note, rather than removeing copyright openwrt you should probably say 
parts are copyright openwrt and parts copyright lede


just because you added a bit doesn't give you sole copyright of the file :-)

but it does mean that openwrt doesn't own the copyright of the entire file any 
more either.


the git history can untangle this for anyone who cares.

But there is enough bad feelings going around, we don't need someone getting 
angry over copyright notices being removed.


David Lang

On Mon, 9 May 2016, Rafał Miłecki wrote:


Date: Mon,  9 May 2016 20:35:20 +0200
From: Rafał Miłecki <zaj...@gmail.com>
To: lede-dev@lists.infradead.org
Cc: Hauke Mehrtens <ha...@hauke-m.de>, Rafał Miłecki <zaj...@gmail.com>
Subject: [LEDE-DEV] [PATCH] bcm53xx: calculate TRX CRC32 using whole kernel
partition

This provides better protection of flash data.

Signed-off-by: Rafał Miłecki <zaj...@gmail.com>
---
target/linux/bcm53xx/base-files/etc/uci-defaults/09_fix_crc | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/target/linux/bcm53xx/base-files/etc/uci-defaults/09_fix_crc 
b/target/linux/bcm53xx/base-files/etc/uci-defaults/09_fix_crc
index abbb04a..e8a7e4d 100644
--- a/target/linux/bcm53xx/base-files/etc/uci-defaults/09_fix_crc
+++ b/target/linux/bcm53xx/base-files/etc/uci-defaults/09_fix_crc
@@ -1,7 +1,12 @@
#!/bin/sh
#
-# Copyright (C) 2007 OpenWrt.org
+# Copyright (C) 2016 LEDE project
#
#

-mtd fixtrx firmware || mtd fixseama firmware
+kernel_size=$(cat /proc/mtd | egrep -m 1 "kernel|linux" | cut -d ' ' -f 2)
+[ -n "$kernel_size" ] && kernel_size=$((0x$kernel_size))
+
+mtd ${kernel_size:+-c $kernel_size} fixtrx firmware && exit 0
+mtd fixseama firmware && exit 0
+exit 1
--
1.8.4.5


___
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] RFC: Throughput testing results.

[David Lang]

On Fri, 6 May 2016, Ben Greear wrote:


On 05/06/2016 12:05 PM, David Lang wrote:

On Fri, 6 May 2016, Ben Greear wrote:


On 05/06/2016 10:20 AM, Toke Høiland-Jørgensen wrote:

Ben Greear <gree...@candelatech.com> writes:


I am interested in feedback on the testing output. My goal is to add a
few more different hardware configurations and then do nightly (or at
least weekly) tests.


So that is showing up to 10s of *seconds* of latency, right? (I'm not
sure I'm reading the units right).


Yes, 10 seconds of latency.  My traffic generator is using pfifo-fast,
RENO, and default socket sizes, so it can be at least part of the problem.


That's so much latency that you may as well be down.

Please look at the make-wifi-fast mailing list and the tests that are being 
done there. they show latency spikes as well as throughput, and show how it 
is very
possible to get low latency without affecting throughput (in some cases, 
throughput actually increases)


I understand that.  My test case is fairly abusive, and my generator is not 
optimized for

low-latency at this time.

In many cases, throughput does go down though, so I have been slow to try the 
buffer bloat stuff.  I can run some tests with codel enabled sometime soon.


I can also run my capacity test with UDP only.  That might be better for pure 
throughput testing.  My hope is to be able to show regressions/improvements 
over time as LEDE changes...


This is a good idea, but it is going to be very specific to the exact setup you 
use for the testing. Use different hardware, or add/remove nodes from the test 
(or have someone nearby create additional noise) and you can end up with very 
different results.


I think it would be a bad idea to setup something that encourages chasing 
benchmarks. I agree it's a good idea to watch out for regressions. The hard 
thing is doing the latter without the former :-)


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

Re: [LEDE-DEV] RFC: Throughput testing results.

[David Lang]

On Fri, 6 May 2016, Ben Greear wrote:


On 05/06/2016 10:20 AM, Toke Høiland-Jørgensen wrote:

Ben Greear  writes:


I am interested in feedback on the testing output. My goal is to add a
few more different hardware configurations and then do nightly (or at
least weekly) tests.


So that is showing up to 10s of *seconds* of latency, right? (I'm not
sure I'm reading the units right).


Yes, 10 seconds of latency.  My traffic generator is using pfifo-fast,
RENO, and default socket sizes, so it can be at least part of the problem.


That's so much latency that you may as well be down.

Please look at the make-wifi-fast mailing list and the tests that are being done 
there. they show latency spikes as well as throughput, and show how it is very 
possible to get low latency without affecting throughput (in some cases, 
throughput actually increases)


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

Re: Future of Chaos Calmer

[David Lang]

On Fri, 6 May 2016, Vittorio G (VittGam) wrote:



On 05/05/2016 21:30:56 CEST, David Lang wrote:

On Thu, 5 May 2016, Vittorio G (VittGam) wrote:


Hello,

I'd like to know if there are any plans for Chaos Calmer?

Will it become mantained by LEDE?


almost certinly not. But LEDE will create their own release to replace it.


Okay, it would be great to have a LEDE release derived by the CC codebase, 
too.


remember that part of maintaining a release is making updates to it 
available.


OpenWRT updates against *openwrt.org servers, so LEDE is not going to be 
able to do anything there.


David Lang


Trunk introduces important changes, for example the switch from uClibc to
musl, so until everything's polished and ready for release I'd rather not
use trunk on "production" devices, like the main home modem/router or all
the antennas of a wireless community that are mounted on the roofs...


shrug, you need to do testing anyway. I ran 120 APs from Trunk at the Scale 
conference in January and they worked well.


Well, of course I would never flash deployed antennas with trunk without
testing; but sometimes trunk reserves strange surprises that may not be
caught even while testing... As an extreme example, some years ago I had
some APs flashed with a supposedly "stable" revision of AA (when it still
was the trunk). After some time, when trying to update to BB, I saw that
some of the routers were rebooting in the middle of flashing, because the
watchdog process wasn't terminated properly, so the hardware watchdog
remained active and triggered in the middle of the upgrade.


True, but I've run into problems with releases having subtle problems that don't 
show up in testing too.


you pick something and take your chances :-)

and you have a plan for when, not if, something fails on you.

David Lang

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

Web forums for LEDE

[David Lang]

Given that many people strongly prefer web forums, I assume that LEDE is going 
to set them up at some point.


I would like to get a request in early that the web forms that get setup be 
cross-connected with mailing lists. Not just for 'something new has happened' 
the way the OpenWRT forms are, but as true lists where someone can reply via 
e-mail and it will appear in the forum.


Baen publishing does this (bar.baen.com) allowing full participation with 
e-mail, nttp, and web forums. They use mailman for the e-mail and nntp and then 
FUDForum for the web forums (it ties in to the nntp feed that mailman can 
provide).


I believe that I saw that a recent version of mailman added a web interface to 
mailing lists, but I haven't seen anyone using it yet.


David Lang

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

Re: [LEDE-DEV] List Prefix

[David Lang]

On Thu, 5 May 2016, John Crispin wrote:


On 05/05/2016 10:14, David Woodhouse wrote:

On Thu, 2016-05-05 at 08:13 +0200, John Crispin wrote:


Hi David,

some folks would prefer to have the prefix on the 2 lists. I just had a
look in the mailman settings and failed to quickly spot the location
where this can be achieved.


Ick, they really ought to be able to handle that locally without
polluting the subject header for everyone. But if you want to turn it
back on, it's in the 'general options' page — the first one when you
log in to the admin interface. About the fourth option down.

Or directly at
http://lists.infradead.org/mailman/admin/lede-adm/?VARHELP=general/subject_prefix



can this be turned on by subscribers manually for their subscription or
is there only one global option ? for the list ?


I'm pretty sure it's a list-wide option.

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

Re: Proposal to sign all commits

[David Lang]

On Thu, 5 May 2016, John Crispin wrote:


On 04/05/2016 23:38, Kus wrote:

Greetings

I'd like to propose that all commits (at least to master) going forward be 
signed with the commiter's gpg key.

https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

Thoughts?


we could do that. if you look at the keyring.git, you will see that we
already asked those with commit access to submit their gpg keys.


At that point, all you are signing is who merged the work into the tree. That 
doesn't give you any information about who created the work.


Is there enough value in this to be worth the hassle?

David Lang

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